Code Verify: An open source browser extension for verifying code authenticity | Hacker News Reader

Code Verify: An open source browser extension for verifying code authenticity

engineering.fb.com

60 pointsharporoeder28 comments

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.

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.

Do ad blockers modify client-side scripts? I figured they just use some feature allowing extensions to block network requests. If they are modifying client-side scripts, then it might be tricky for a tool like this to allow some forms of modification without allowing other forms of modification.

Here's what ChatGPT says:

Most ad blocker browser extensions primarily work by intercepting and blocking network requests made by web pages to known advertising servers or domains. When a web page loads, it typically requests various resources such as images, scripts, and stylesheets from different servers. Ad blockers analyze these requests and compare them against a list of known ad servers or patterns commonly associated with advertising content. If a match is found, the ad blocker prevents the resource from loading, effectively blocking the ad from appearing on the page.

Some ad blockers also employ additional techniques such as element hiding, where they modify the Document Object Model (DOM) of the webpage to hide elements that are recognized as ads. This can include hiding divs, iframes, or other HTML elements that contain advertising content.

Overall, while there are variations in implementation, most ad blockers primarily rely on blocking network requests to known ad servers or domains, with some employing additional techniques to hide or remove ad content from web pages.

Isn't it fundamentally impossible to secure a client? You can always write your own app that sends exactly the same request as a verified client.

(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."

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?

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)

Why does compromising FB servers make compromising Cloudflare more likely?

You don't need to compromise Cloudflare, just tell them "this is the latest hash" while pretending to be FB.

The hashes are checked against an endpoint hosted by Cloudflare. So technically Cloudflare or anyone able to MitM traffic to them (which would be anyone in a position to MitM Facebook as well) can still do evil things.

I haven't ripped apart the extension yet, but there is no mention of cryptographically verifying the response from Cloudflare.

Edit: looks like they are checking for a number of ad blocking extensions and mark it as "At Risk" if detected.

Edit 2: Oh boy, I hope this is covered by their bug bounty program.

looks like they are checking for a number of ad blocking extensions and mark it as "At Risk" if detected

Not surprised at all. As with a lot of things these days, the "security" they are talking about is to secure their ability to shove whatever shit they want down your throat without you being able to resist.

Problem with this approach at present is that many other browser extensions installed (not just extensions that have something to do with the FB site) will cause a false negative verification result. This is because they inject code into every JS file loaded.

I've already had to "crack" web apps with my MITM proxy to force them to behave, but in the past there haven't been many. This is an escalation that is not surprising, and the reason why we must strongly oppose remote attestation if we are to continue to have freedom and control over our computing environments.

They are 100% using "open source" as a distraction here. The fact that you can see the source is irrelevant for the purpose they are trying to use this for.

I don't want to run "authentic" instagram which doesn't even let me zoom the page.. That's why I'm running the modified version and I won't give it up without a (technical) fight

There’s a modified version? Where?

I use an ubo scriptlet to enable zoom/download on instagram but my setup is rather exotic, maybe there are other extensions for mobile firefox

Wait, what even is the threat model here? I can't come up with many scenarios in which this makes sense

MITM attacks on the root page of an app/site (leaf files can already be validated by subresource integrity checksum). Also if you are interested in a system where software (say, defined as files in a public git repo somewhere) can be both served to a user's browser by an untrusted web server but also trusted by the browser user, you need some e2e validation scheme like this.

MITM will be stopped by SSL, won't they?

For the second use case, isn't that what digital signatures are for?

A different threat model is that you have web applications with some kind of user-controlled encryption (e.g. keys only in local storage, never uploaded to the server) but an adversary tries to substitute a different version of the web application on the server-side that will leak the private keys or decrypt data and then upload it.

That adversary could be a government trying to compel the web application developer to serve a compromised version to a particular user or group of users.

At least, this is a threat model that I talked about with people who were working on similar tools a few years ago.

Edit: for example, you could imagine a messenger application that has end-to-end encryption with a web version of the client. With traditional web applications, the developer could trivially substitute a backdoored version at any time in the future, and users couldn't plausibly detect that.

Well if the developer is the adversary, then surely they can update the hash on Cloudflare as they upload the backdoor.

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.

Isn't that what HTTPS is for?

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.

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.

The idea is you install the extension ahead of time when you do trust the source.

What is the difference to resource integrity and certificate pinning which is already implemented among every single Browser via the HSTS policies?

Also, do you really think meta's products will have static assets for eternity from the point of installing an extension? Absurdly unlikely.

I think you would still have big problems if you had an adversary at meta. Bigger than this.

Reply on news.ycombinator.com