A new kind of auditing - cryptographic proof of online accounts

The technology

  • Based on an original algorithm as described in How it works.

  • Provides cryptographic proof without MITM-ing your connection.

  • Install the browser extension PageSigner, start proving pages with one click.

  • No need to give login credentials to a third party.

What it can do

  • Prove your name and address if it's recorded on a trusted website

  • Prove you received a threatening private message from an internet troll

  • Prove you received a money transfer.

  • Prove your status as an elite trader with something better than a photoshopped statement.

  • Prove that a scammy website doctored the claims on its front page.

PageSigner - the easy way to use TLSNotary

A high level technical view of TLSNotary

This is how the main TLSNotary protocol works; PageSigner has the same core design but with some extra usability features; after you're finished here, you can read more on that here.

A user, called the 'auditee', wants to prove to another user, called the 'auditor', a certain fact attested to by an organisation (a bank, a government, a company etc.). This fact could be a monetary balance on an account, the fact of a money transfer, a particular set of identity information such as address, amongst others. The auditor and auditee create an encrypted messaging connection between each other. The auditee connects to the website as normal and logs in, and then browses to the specific page that proves the required information. Then the auditor and auditee use their encrypted connection to negotiate secrets for the SSL/TLS session such that the auditor can find out what is on the page that the auditee loads, without gaining control of the connection or seeing the auditee's login details. The diagram below gives the outline of what happens.

The auditee has the full defense against impersonation and eavesdropping that he would have in a normal TLS protected interaction with the server. The differences to a normal TLS connection (marked in green) allow the auditor to nevertheless get irrefutable proof of the content of the server response, for the single response (usually an html page) that the auditee chooses. This process can, and should, occur after the auditee has established his application-level login, and so by logging out before delivering the data, he can render any session cookies invalid.
More details are available in the How it works document.