3 ms·

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

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.

CGamesPlay 6y ago
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.
strogonoff 6y ago
> 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?
- progval 6y ago
  If they can modify the integrity hash on your site, then they can probably modify anything else on your site.
  - strogonoff 6y ago
    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.
  - CGamesPlay 6y ago
    GP is presumably referring to the integrity hash on the installation instructions, not on my website.

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.

CGamesPlay 6y ago

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.

strogonoff 6y ago

> 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?

progval 6y ago
If they can modify the integrity hash on your site, then they can probably modify anything else on your site.
- strogonoff 6y ago
  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.
- CGamesPlay 6y ago
  GP is presumably referring to the integrity hash on the installation instructions, not on my website.