Haha this is really good :) I was never fond of this "serverless" naming, precisely because it could lead people to believe that there where actually no servers, but I had never seen such a good example of it :)

Oh and guess what, not only there are servers, but other people can run code on the same server as your code is running. Doesn't feel as safe suddenly ;)

Alternative phrasing: "This is hosted on Cloudflare Workers, and Cloudflare engineers are probably doing a better job running my code securely than I would"

> I was never fond of this "serverless" naming, precisely because it could lead people to believe that there where actually no servers

Agreed. I think "server-agnostic" or "server-oblivious" would have been a better name.

It’s useful for the ~.4% of browsers that will execute a module script without checking its integrity. But I do indeed intend to put more emphasis on SRI in the future.

I encourage you to think through some ways that an attacker would compromise my service and how your service is a gateway to that compromise. Notably, "serverless" doesn't mean anything to the consumer of your service--it has always just meant "somebody else's server". So, why don't you talk on this page about how your Cloudflare account has a very strong password and 2factor enabled? It doesn't make sense because it doesn't cover the threat model for me, which is that somebody--you, Cloudflare, Saudi hackers--compromises the server.

One thing you may have meant by "serverless" is that you don't use a database / don't collect data on users. This is another angle you might want to use to highlight the safety of using your service.

> It’s useful for the ~.4% of browsers that will execute a module script without checking its integrity.

What if someone modifies not only the script, but also integrity hashes in snippets on your site?

If they can modify the integrity hash on your site, then they can probably modify anything else on your site.

Of course. The topic at hand, though, is browsers executing untrusted scripts. A wise attacker will leave the rest of the site intact to make the deface less noticeable.

Defacing capability can be used to change the integrity hash—how it appears to the users (other developers) in snippets—to match maliciously modified script, making it trusted.

End developers using this library would thus, at their own accord, include URL to altered script and its hash in their pages by copy-pasting a snippet from the defaced landing page, satisfying browser integrity checks.

A subtle change like that is unlikely to be noticed by end developers, who would have to count on library site maintainers to have mechanisms in place to notice such an attack promptly and (perhaps more importantly) to not suppress the news about the incident.

GP is presumably referring to the integrity hash on the installation instructions, not on my website.