If the JavaScript bundle that is being served is built on a public CI/CD service, it could be possible to do the following, for transparency and verification:
- Include in a header comment: the build URL, Git SHA-1 of the commit, and other metadata
- Sign the bundle using public/secret key cryptography
Having the build URL and sources URL help with discoverability and transparency, while integrity can be verified with the signature.
Adversary models now shift from the bundle provider to the CI/CD platform that runs the build, and any PKI used for the public key for signature verification. If the public key is versioned with the code, it can help reduce trust to a single entity (where the code is stored).
Yes, but there's no provision in the browser to do these kinds of integrity checks. If the browser isn't verifying it there's no point in adding any of this info, because it can be substituted covertly. In principle such 'version-pinning' could be added to the browser, but no-one has done so yet.
In theory you can generate the code locally and compare it with the deployed version to see that it's one to one.. But maybe we could do something in order to improve the said security check.
Not even in theory: the version you download to "check" and the version served to your web browser may not be the same content, as the webserver can respond with different content for the same URL, on a per request basis, for example serving the exploit code only to a specific ip + user-agent header combination, so that it steals your keys in your browser but shows the safe version to `curl`.
Subresource Integrity allows the HTML file to insist that the js file hasn't changed. I guess it would be possible to download and run the html file from your own machine.
Alternatively, it would be possible to create a service worker that uses a local copy and makes much more of a deal about files changing - it could always confirm changes with the user before allowing a change. Security sensitive apps should probably be doing this.
JS allows overriding overriding any object or method with separately loaded code. So even your “trusted” code could be compromised by separate “trusted” code.
Even native app packagers and languages can suffer from this when loading libraries dynamically (from search-path or symlink manipulation for example).
If browsers supported it, then it could be done much the way Linux distro packages work: include a signature from a trusted party together with the code, as a guarantee of being verified to match some standard (e.g. same as CI, or not malicious).
Don't this still apply to a native client? You can be sure unless you build the client from source, but you can also build the website from source too right?
I'm not sure where you're coming from, where soliciting for votes/likes/whatever is NOT frowned upon. Only community I can come up with is producthunt, where it used to be frowned upon but doesn't seem to be anymore.
Edit: also, missing to read the rules of community before participating doesn't seem like a honest mistake. vjeux been around for a long time and I'm sure knows how to navigate the different communities. Also since the whole "no vote rings please" thing is mentioned in 3 or more places on news.ycombinator.com.
