4 ms·

> instant.page’s script is hosted serverless with Cloudflare Workers so that there’s no server to hack into. There are a lot of reasons that this software is "

> instant.page’s script is hosted serverless with Cloudflare Workers so that there’s no server to hack into. There are a lot of reasons that this software is "safe" but this absolutely isn't one of them and highlights to me as a potential user that you haven't thought through your thread model. The subresource integrity line should absolutely be the headline here.

dieulot 6y ago
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.
forty 6y ago
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"
- deleted 6y ago
  [deleted]
- waterhouse 6y ago
  > 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.

dieulot 6y ago

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.

forty 6y ago

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"

deleted 6y ago
[deleted]
waterhouse 6y ago
> 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.