If I'm reading this right it's in-browser JS signing software. The author makes the claim that native software is hard to audit, but neglects the much bigger problem of having to verify the JS downloaded on-demand for every session. What you are served is not guaranteed to be the same as what's hosted on GitHub.
These days with service workers and what not you might need more than a quick glance at the network log if you suspect the web page is malicious.
Even for non-malicious sites this can be a problem.
I think a notable case of the second category is jwt.io which last I checked definitely seemed to fire a few network requests after I pasted a token.
(Happy to be corrected if this is obviously false or has been corrected later.)
That said I couldn't see my token in one of them but it is scary enough to make me avoid using that site.
BTW, I think their statement/claim
> "Warning: JWTs are credentials, which can grant access to resources. Be careful where you paste them! We do not record tokens, all validation and debugging is done on the client side."
is correct, it's just to scary for me to put client credentials there at all when it isn't trivially east to prove that they aren't uploaded.
> I think a notable case of the second category is jwt.io which last I checked definitely seemed to fire a few network requests after I pasted a token.
They do make request to https://b.6sc.co/ all the time, regardless of you pasting stuff or just having it as an idle tab. Seems to be some kind of analytics that just tracks your time on the page and if you are active or not. With that said, I just fired up a proxy now when you mentioned it, have not actually properly investigated it.
My guess it is just analytics, but as recent events have shown they are then one misconfiguration away from sending highly sensitive data to Facebook or someone else.
This is for signing a document with a "hand" signature, not cryptographically signing it with a cryptographic signature. Besides, if you don't trust in-browser JS then you shouldn't trust any site on the web, e.g. online banking.
That this is running completely locally without any software to install is pretty useful and cool. Your criticism isn't great (IMO borders on concern-trolling) because the alternative is something where the docs go to some centralized SaaS that store everything including your signature for an unknown period of time.
> the alternative is something where the docs go to some centralized SaaS that store everything including your signature for an unknown period of time.
No. The alternative is using a desktop application, which offers a superior UX in every way.
I don't get what's so bad about installing applications. It's painless. Browsing the web on the other hand is painful.
"This is for signing a document with a "hand" signature, not cryptographically signing it with a cryptographic signature. "
Ah very well, then it's not as important.
"Besides, if you don't trust in-browser JS then you shouldn't trust any site on the web, e.g. online banking."
Online banking is different from the PoV of expectation of privacy. With online banking I'm managing the account the bank has plaintext access to by definition. Had this been about digitally signing a document, the vendor would be an untrustworthy third party (the signer and the verifier being 1st and 2nd parties).
"That this is running completely locally without any software to install is pretty useful and cool."
No it's running in-browser, not natively. It's not enough it runs locally, it needs to run locally the same way, every day, without requiring 365.25 code-audits per year, per user.
"Your criticism isn't great (IMO borders on concern-trolling) because the alternative is something where the docs go to some centralized SaaS that store everything including your signature for an unknown period of time."
No the alternative is a native client that does this offline, where you can inspect the source, download and compile it (hopefully reproducibly), and where you know you can trust the program acts the same way during runtime, every time. That's not true for JS applications. Since this isn't about digital signatures, I admit I was wrong in that respect. However, wrt security related programs, in-browser crypto isn't safe as the sources showed.
If there is software entirely in a web page and does not send data to internet, then you could just save the HTML file (and other needed files, if any) to your computer and then use that.
You do not have to connect to the internet to access a local HTML file. If you disconnect the internet, then anything in the file that tries to access the internet will not work, so you can also know that it isn't sending stuff to the internet.
Yeah there are hacks around the problem, even JS application could be downloaded to a VM that is airgapped and the sate of which is saved, and after auditing the minified code (painful as hell) you know you can trust it on consecutive runs. This is all mostly fine but having to rely on such sandboxes isn't what we really want from security software, especially when minification makes auditing e.g. implementation of cryptographic algorithms really difficult.
One way to improve it might be to add a new JavaScript function into HTML which causes all further network access made by the current document to be blocked; the user who downloads the file can insert that command at the beginning of the file if they want to disable network access. (Since it is called before the rest of the document can change its definition, it will be effective.) (It is one of the many things which will need to be fixed in a newer web browser program, I think.)
In the case of sensitive pdfs, it's enough to check you network is not inexplicably in use, and I explain how to do a network audit in the notebook (yay literate programming). BTW this is "sign" as in overlay an image of your physical signature, not certify with a digital signature.
That’s what most want when they think of signing a document. There’s all sorts of technical stuff relative to PDF Signing (cryptographic) and why it matters but most people that want signed documents want to be able to say the user was presented with this document and signed it. Most also fail to understand the technical mechanisms that are important to be able to defend that a user saw what you wanted them to see and then signed it. It’d be easy to argue that the other party showed you another document, got your signature and then overlaid it onto a new document. That’s the issue with many open source signing schemes, they aren’t provable because few if any implement both cryptographic signing and signature overlay.
I'm not talking about XSS vulnerabilities, but having to trust the vendor to do the right thing every time I use it. Some companies can be coerced, internally compromised, and TLS and X.509 isn't exactly designed to be safe against nation state attackers so MITM can inject malicious JS clients.
Native clients suffer from code distribution problems too, but to much lesser extent, especially with reproducible builds and actually readable code as opposed to minified JS.
Tony Arcieri explains the issues more broadly here https://tonyarcieri.com/whats-wrong-with-webcrypto
Also, Nadim Kobeissi formalized it wrt Protonmail a while ago: https://eprint.iacr.org/2018/1121.pdf