Serving the content with HTTPS ought to ensure that. What Cloudflare does with WhatsApp is to prove to facebook the user hasn't modified the code locally. This is dis-empowering the user, not protecting the user.
Serving the content with HTTPS ought to ensure that. What Cloudflare does with WhatsApp is to prove to facebook the user hasn't modified the code locally. This is dis-empowering the user, not protecting the user.
I don't follow. How does this system:
A) force users not to ignore the hash mismatch?
B) guarantee to Facebook that they haven't ignored the hash mismatch?
C) even communicate to Facebook anything about the hash mismatch? This is a clientside comparison, I don't see anything about reporting to Facebook that hashes mismatch.
My local Linux installation compares hashes for downloaded packages, I don't see how I as a user having more insight into whether or not the packages is corrupted/altered means I'm disempowered.
----
> Serving the content with HTTPS ought to ensure that
That's not what the article is talking about, the article is talking about code being served from a CDN. HTTPS will not protect you from a CDN tampering with your code.
Of course, all this presupposes that the user has to install the extension to use WhatsApp on the web, which isn't the case. However, the extension could theoretically be made mandatory if it contained a load of obfuscated code that the web app was dependent on. That would basically mean implementing a type of DRM in the extension, and maybe there is some way to use EME to achieve that at a lower level.
If a website ever started using techniques like that, then that would be the point at which to complain about disempowering users. Fortunately this plan doesn't do that, as you say, and merely allows users to optionally confirm that they are running the code they requested.