3 ms·

Trusting someone to honestly serve you a piece of html is an easier thing to develop and check. You can always save a copy of it to your machine and check it an

Trusting someone to honestly serve you a piece of html is an easier thing to develop and check. You can always save a copy of it to your machine and check it and run it from there. It's true that these are not great against a state level actor deliberately targetting an individual (but then, not much is), but e.g. in a lot of situations I would trust github to serve me unmodified html and s3 to store my encrypted data, where I might have not trusted a single entity to provide me with an integrated solution. It would be great though if a page could indicate that it is sensitive and then if the browser sees it change it pops up a message on the client giving the user a fingerprint and notifying them of the change.

yeukhon 10y ago
If I publish my application on GitHub, how can you know for sure I didn't make changes on the server side? Appearance looks the same m, hence why SRI only solves the front end trust, but the entire as a whole remains a blackbox, thus what previous OP meant.
- kybernetikos 10y ago
  Depends on the app. If you are making a storage app then you can do client side encryption so that it doesn't matter if s3 is compromised, they don't have access to your data. SRI means you don't have to worry about your js getting modified so all that's left is the html. My claim is that there are lots of situations where I can trust something to serve html honestly enough for my use. It is possible that my bias for web apps that connect to real services (of the sort a desktop app might) rather than as a thin veneer over a black box service gives us a different perspective. But I do ultimately agree that some support for enhancing trust in the initial html document should be built into browsers. I guess such a thing should involve being able to get a hash of the actually downloaded and running code and document and being able to postpone an update until I've had the opportunity to check it's legitimate.

yeukhon 10y ago

If I publish my application on GitHub, how can you know for sure I didn't make changes on the server side? Appearance looks the same m, hence why SRI only solves the front end trust, but the entire as a whole remains a blackbox, thus what previous OP meant.

kybernetikos 10y ago
Depends on the app. If you are making a storage app then you can do client side encryption so that it doesn't matter if s3 is compromised, they don't have access to your data. SRI means you don't have to worry about your js getting modified so all that's left is the html. My claim is that there are lots of situations where I can trust something to serve html honestly enough for my use. It is possible that my bias for web apps that connect to real services (of the sort a desktop app might) rather than as a thin veneer over a black box service gives us a different perspective. But I do ultimately agree that some support for enhancing trust in the initial html document should be built into browsers. I guess such a thing should involve being able to get a hash of the actually downloaded and running code and document and being able to postpone an update until I've had the opportunity to check it's legitimate.