A Plan for Improving JavaScript's Trustworthiness on the Web (cloudflare.com)
(Sunday October 19, 2025 @10:34PM (EditorDavid)
from the JavaScript-considered-harmful dept.)
- Reference: 0179832416
- News link: https://developers.slashdot.org/story/25/10/20/005250/a-plan-for-improving-javascripts-trustworthiness-on-the-web
- Source link: https://blog.cloudflare.com/improving-the-trustworthiness-of-javascript-on-the-web/
On Cloudflare's blog, a senior research engineer shares a plan for " [1]improving the trustworthiness of JavaScript on the web ."
"It is as true today as it was in 2011 that [2]Javascript cryptography is Considered Harmful ."
> The main problem is code distribution. Consider an end-to-end-encrypted messaging web application. The application generates cryptographic keys in the client's browser that lets users view and send [3]end-to-end encrypted messages to each other. If the application is compromised, what would stop the malicious actor from simply modifying their Javascript to exfiltrate messages? It is interesting to note that smartphone apps don't have this issue. This is because app stores do a lot of heavy lifting to provide security for the app ecosystem. Specifically, they provide integrity , ensuring that apps being delivered are not tampered with, consistency , ensuring all users get the same app, and transparency , ensuring that the record of versions of an app is truthful and publicly visible.
>
> It would be nice if we could get these properties for our end-to-end encrypted web application, and the web as a whole, without requiring a single central authority like an app store. Further, such a system would benefit all in-browser uses of cryptography, not just end-to-end-encrypted apps. For example, many web-based confidential LLMs, cryptocurrency wallets, and voting systems use in-browser Javascript cryptography for the last step of their verification chains. In this post, we will provide an early look at such a system, called [4]Web Application Integrity, Consistency, and Transparency (WAICT) that we have helped author. WAICT is a W3C-backed effort among browser vendors, cloud providers, and encrypted communication developers to bring stronger security guarantees to the entire web... We hope to build even wider consensus on the solution design in the near future....
>
> We would like to have a way of enforcing integrity on an entire site, i.e., every asset under a domain. For this, WAICT defines an integrity manifest , a configuration file that websites can provide to clients. One important item in the manifest is the asset hashes dictionary , mapping a hash belonging to an asset that the browser might load from that domain, to the path of that asset.
The blog post points out that the [5]WEBCAT protocol (created by the Freedom of Press Foundation) "allows site owners to announce the identities of the developers that have signed the site's integrity manifest, i.e., have signed all the code and other assets that the site is serving to the user... We've made WAICT extensible enough to fit WEBCAT inside and benefit from the transparency components." The proposal also envisions a service storing metadata for transparency-enabled sites on the web (along with "witnesses" who verify the prefix tree holding the hashes for domain manifests).
"We are still very early in the standardization process," with hopes to soon "begin standardizing the integrity manifest format. And then after that we can start standardizing all the other features. We intend to work on this specification hand-in-hand with browsers and the IETF, and we hope to have some exciting betas soon. In the meantime, you can follow along with our [6]transparency specification draft,/A>, check out the open problems, and share your ideas."
[1] https://blog.cloudflare.com/improving-the-trustworthiness-of-javascript-on-the-web/
[2] https://web.archive.org/web/20200731144044/https://www.nccgroup.com/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/
[3] https://en.wikipedia.org/wiki/End-to-end_encryption
[4] https://github.com/beurdouche/explainers/blob/main/waict-explainer.md
[5] https://securedrop.org/news/introducing-webcat-web-based-code-assurance-and-transparency/
[6] https://github.com/rozbb/draft-waict-transparency
"It is as true today as it was in 2011 that [2]Javascript cryptography is Considered Harmful ."
> The main problem is code distribution. Consider an end-to-end-encrypted messaging web application. The application generates cryptographic keys in the client's browser that lets users view and send [3]end-to-end encrypted messages to each other. If the application is compromised, what would stop the malicious actor from simply modifying their Javascript to exfiltrate messages? It is interesting to note that smartphone apps don't have this issue. This is because app stores do a lot of heavy lifting to provide security for the app ecosystem. Specifically, they provide integrity , ensuring that apps being delivered are not tampered with, consistency , ensuring all users get the same app, and transparency , ensuring that the record of versions of an app is truthful and publicly visible.
>
> It would be nice if we could get these properties for our end-to-end encrypted web application, and the web as a whole, without requiring a single central authority like an app store. Further, such a system would benefit all in-browser uses of cryptography, not just end-to-end-encrypted apps. For example, many web-based confidential LLMs, cryptocurrency wallets, and voting systems use in-browser Javascript cryptography for the last step of their verification chains. In this post, we will provide an early look at such a system, called [4]Web Application Integrity, Consistency, and Transparency (WAICT) that we have helped author. WAICT is a W3C-backed effort among browser vendors, cloud providers, and encrypted communication developers to bring stronger security guarantees to the entire web... We hope to build even wider consensus on the solution design in the near future....
>
> We would like to have a way of enforcing integrity on an entire site, i.e., every asset under a domain. For this, WAICT defines an integrity manifest , a configuration file that websites can provide to clients. One important item in the manifest is the asset hashes dictionary , mapping a hash belonging to an asset that the browser might load from that domain, to the path of that asset.
The blog post points out that the [5]WEBCAT protocol (created by the Freedom of Press Foundation) "allows site owners to announce the identities of the developers that have signed the site's integrity manifest, i.e., have signed all the code and other assets that the site is serving to the user... We've made WAICT extensible enough to fit WEBCAT inside and benefit from the transparency components." The proposal also envisions a service storing metadata for transparency-enabled sites on the web (along with "witnesses" who verify the prefix tree holding the hashes for domain manifests).
"We are still very early in the standardization process," with hopes to soon "begin standardizing the integrity manifest format. And then after that we can start standardizing all the other features. We intend to work on this specification hand-in-hand with browsers and the IETF, and we hope to have some exciting betas soon. In the meantime, you can follow along with our [6]transparency specification draft,/A>, check out the open problems, and share your ideas."
[1] https://blog.cloudflare.com/improving-the-trustworthiness-of-javascript-on-the-web/
[2] https://web.archive.org/web/20200731144044/https://www.nccgroup.com/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/
[3] https://en.wikipedia.org/wiki/End-to-end_encryption
[4] https://github.com/beurdouche/explainers/blob/main/waict-explainer.md
[5] https://securedrop.org/news/introducing-webcat-web-based-code-assurance-and-transparency/
[6] https://github.com/rozbb/draft-waict-transparency
Road to insanity (Score:2)
by WaffleMonster ( 969671 )
Reference from the wayback machine lists three issues I could discern.
Lack of a secure random, implementation of a insecure password authentication scheme and caching.
This new document is gibberish: "By designing integrity and transparency together, we can make the web more trustworthy, ensuring that all users can rely on security-critical sites to deliver the code they promise, consistently and visibly."
"Users visiting sites need to be sure that the content they are getting has not been tampered with by an
DRM.js (Score:2)
by devslash0 ( 4203435 )
So their answer to trustworthiness is effectively a DRM scheme. This will go down well, I'm sure.
you already lost (Score:2)
by diffract ( 7165501 )
If you find yourself aiming to improve people's trust instead of making the language itself secure, you know you already lost
Better idea. (Score:5, Insightful)
Phase out JavaScript.
Re: (Score:3)
With the direction things are headed, we're probably more likely to see a return of Shockwave or Flash
Re: (Score:2)
The web was more fun when Flash was around.
Re: (Score:2)
At least there's no more "under construction" pictures of half made websites. Commercialization is complete and gone are the hobbyists. Coincidentally everything is enshitified (or maybe no coincidence).
Re: (Score:2)
If that's true, there sure are a [1]lot of people wasting their time creating "under construction" templates [duckduckgo.com].
[1] https://duckduckgo.com/?t=ftsa&q=under+construction+web&ia=web
Re: Better idea. (Score:2)
That's quite a while ago. Commercialization of the web was complete by 2005, I'd say, sound about right ? We were were arguing about whether it was safe to put your credit card number into a webpage at first.
"Under construction" animated gifs surely died before that. Fun times :-)
Re: Better idea. (Score:2)
Was it really? I'm guessing you were a graphic artist? Flash wasn't the web, it was a binary program. You can do more and better things with css for a long time now.
Not that I want things flying around and squawking on a web page, but flash *was* fun. Managers and graphic artists loved it, but it wasn't very good for anything but games or entertainment.
Re: (Score:2)
It appears you don't even know what flash was. Replacing it took far more than CSS.
Re: Better idea. (Score:2)
Add to it that there are different web browsers with different behaviors. With AI browsers then it's possible that they look at your traffic and leaks private information.
Re: (Score:3)
At least, remove JavaScript's ability to communicate with anything other then the originating web server. JavaScript, as a part of a web page has some uses for offloading processing from the back end server. And that is all it should be used for.
I load a web page by opening an SSL connection. I download some HTML, style sheets and whatnot through that connection. I can also download some JavaScript through that same pipe and execute it locally. But it should never be more than an extension of that page. An
Re: Better idea. (Score:3)
you're confusing a scripting language with a script, executed by a browser... so your barking under the wrong tree
Re: (Score:2)
I could extend this principle to any script or executable run by a browser. Which is what I assume is meant by "on the Web".
Re: (Score:2)
"I can also download some JavaScript through that same pipe and execute it locally. But it should never be more than an extension of that page."
What's a page?
"But it should have no ability to open its own connections and negotiate its own encryption with third parties. It should have no concept of the outside network beyond the server from which it came."
That would work great with websockets. Won't be asking you for architectural advice.
Re: Better idea. (Score:2)
I could accept reading data from approved sources, but in most cases it's something the originating server could do.
Re: (Score:2)
What would you replace it with? Just static pages? How is that an improvement?
JavaScript has delivered on the unfulfilled promise of Java: a programming language that runs literally everywhere. As a software developer, it lets me write once, run anywhere: any browser, any manufacturer's device. Why is that bad?