[HN Gopher] Code Verify: An open source browser extension for ve...
___________________________________________________________________
Code Verify: An open source browser extension for verifying code
authenticity
Author : harporoeder
Score : 36 points
Date : 2024-02-20 07:09 UTC (1 days ago)
(HTM) web link (engineering.fb.com)
(TXT) w3m dump (engineering.fb.com)
| mdaniel wrote:
| (2022)
|
| https://github.com/facebookincubator/meta-code-verify is the
| goods, and is MIT
|
| https://github.com/facebookincubator/meta-code-verify#instal...
| says Safari support is "coming soon" (from 2022) so I guess they
| think those users don't need to "verify[..] the integrity of a
| web page."
| sa-code wrote:
| For those who haven't heard of it before, a sentence from the
| article explaining what it is
|
| > With Code Verify, you can confirm that your Instagram Web code
| hasn't been tampered with or altered, and that your Instagram Web
| experience is the same as everyone else's.
| paxys wrote:
| Isn't that what HTTPS is for?
| mcosta wrote:
| HTTPS guarantee the source, not that meta is sending you the
| same code as everyone else. With this, an adversary at meta
| must compromise Meta and Cloudflare.
| ametrau wrote:
| I think you would still have big problems if you had an
| adversary at meta. Bigger than this.
| cookiengineer wrote:
| By that logic the extension from the very same vendor is
| automatically compromised, too.
|
| If a website is compromised, no extension will fix this.
|
| Only a rollback to a specific known-to-be-legit hash in
| IPFS.
|
| And meta won't embrace IPFS, ever.
| paxys wrote:
| Makes sense at a technical level, but the threat this is meant to
| mitigate (FB's servers/TLS certs get compromised and start
| serving you malicious JS scripts, a browser extension pings
| Cloudflare and sees that the hash is incorrect) is a little too
| far fetched. For example wouldn't the attacker also be able to
| update the expected hash on Cloudflare's side, considering they
| have already compromised FB's servers?
| quenix wrote:
| Why does compromising FB servers make compromising Cloudflare
| more likely?
| paxys wrote:
| You don't need to compromise Cloudflare, just tell them "this
| is the latest hash" while pretending to be FB.
| smileybarry wrote:
| I assume this is meant for countries where ISPs/governments
| MITM traffic and force you to trust their CA. It's possible the
| Cloudflare verification is HSTS-pinned, or perhaps it's
| distrusting of TLS PKI and signs the hash in some way. (Or it's
| just built that way because governments are more likely to MITM
| Meta services than CF at scale)
| markussss wrote:
| I think that that is supposed to prepare web apps for
| verification in the browser, in order to not allow them to run or
| connect to a remote server unless they are confirmed to be not
| tampered with, and that the main goal of this is to disallow
| usage of websites and related services unless ads are served. An
| adblock-blocker in the browser, sold as a security feature that
| protects against no real threats.
|
| I refuse to believe that rouge browser extensions and userscripts
| are such a big problem that Meta decides to invest in security
| against those attack vectors.
| danShumway wrote:
| Because it's Facebook, I can't say that they aren't planning
| that.
|
| But if anyone else mentioned this tech, I would assume it was
| benign. Subresource Integrity
| (https://developer.mozilla.org/en-
| US/docs/Web/Security/Subres...) is primarily aimed at servers
| proving to _clients_ that their code is unaltered, not the
| other way around. I haven 't personally tried it before, but I
| can't imagine why extensions wouldn't be able to override
| integrity strings or remove them from script elements.
|
| For WhatsApp I'm not sure I see the point necessarily, but it's
| an understandable goal for Open Source and offline webapps or
| for apps that use 3rd-party CDNs. The main problem for
| personally hosted code is that the integrity string is also
| getting served from the server, so there's no reason it can't
| also be altered if the server that gives the HTML is
| compromised.
|
| In theory with some tweaking and a way to pin integrity strings
| in a user-controlled way (which an extension could do I
| suppose) it could be a step towards allowing users to know when
| a PWA is being updated, which would be helpful for some
| security models. In its current state it's fairly niche and I'm
| not sure how useful the standard is outside of securing CDN
| requests.
|
| Although why that would matter to WhatsApp, :shrug: It does
| feel weird that Facebook would be leading that push.
___________________________________________________________________
(page generated 2024-02-21 23:01 UTC)