Sounds like it's been rendered useless since at least late 2020? From the github:<p>> UPDATE October 2020. These instructions will only work if you use an old Firefox version which was around in 2015 (e.g. v37). Additionally the website you plan notarize must support TLS 1.0 or TLS 1.1 (a rare thing in 2020). Finally, you will have to modify /src/shared/pubkeys.txt and provide pubkeys which are up-to-date. Run the auditee like this python2 ./src/auditee/tlsnotary-auditee.py<p>Also, the site fails hard at explaining <i>how the hell it works</i>. If you're in a situation where you need something like this, <i>you</i> understanding how it works is irrelevant. It needs to be understood and believed by the person arbitrating the dispute. I'm a sysadmin, I've read it three times, and I'm still left blinking in confusion. I can't figure out whether it's exploiting some TLS weakness, or the plugin is performing a separate fetch of the page with the user's session credentials, or what.<p>Can anyone explain?
There's other mechanisms that work with recent TLS protocols, like Deco: <a href="https://arxiv.org/abs/1909.00938" rel="nofollow">https://arxiv.org/abs/1909.00938</a>
As far as I can tell "by logging out before delivering the data, he can render any session cookies invalid" means that if you use this mechanism and forget to sign out partway through the process you're potentially handing over session cookies. This seems like a really unsafe design.
<a href="https://www.youtube.com/watch?v=cVknXa1bg2M" rel="nofollow">https://www.youtube.com/watch?v=cVknXa1bg2M</a><p>Why is the video shot in Windows XP? How old is this project?