> Subresource integrity hash checks are supposed to let you pin a particular version of a webpage / webapp
I dont think that is true. Its called subresource integrity not resource integrity. I don't think pinning a specific top level resource was ever part of the goal.
> but the W3C managed to not let SRI work on bookmarks. If you could bookmark a specific version of a url with SRI, that would make so many problems go away.
I don't really think this makes sense in the context of how web browsers currently work. Are you proposing that users just unilateraly pin versions of websites?
The idea is that users could bookmark reviewed and vetted versions of websites / apps.
It won't work "unilaterally" for obvious reasons but there are lots of p2p, e2e, security and crypto type apps where creators would love to be able to reduce the degree to which infra like CDNs and hosting need to be trusted.
The "page level SRI" mechanism wouldn't even need to work that well (eg limited support for web features). If you could get a trusted "bootstrapper" to work with no software installation then you could do the rest of the trust chain in js "userland".
> It won't work "unilaterally" for obvious reasons but there are lots of p2p, e2e, security and crypto type apps where creators would love to be able to reduce the degree to which infra like CDNs and hosting need to be trusted.
If we are moving out of the http/web space into some sort of distributed protocol, just use magnet links, problem solved. Or some equivalant hash based content-addresable scheme. (How applicable depends on what space we are talking about)
I agree but now you are asking your users to either install an extension or download something.
What many people want is the convenience of http/web with the immutability of content addressing and the frustration of OP at the start of our thread is that SRI feels so close to being able to provide that but stops short.
This has been a really interesting discussion for me because I think you understand the use cases and alternatives but it seems like you don't agree that hash pinned / immutable web sites natively in the browser would enable many interesting use cases.
I think i don't like it if its implemented as metadata stored separately from the url. As a separate url scheme where the url scheme includes both the hash and the document location, i think it would be cool. Really that essentially comes down to supporting magnet links with the webseed (ws) parameter in browser. Which would be really cool.
Actually, a browser COULD implement subresource integrity for bookmarked urls - it would just require another field in the bookmark metadata. They could arrange for 'rightclick, save as bookmark' to pull the sri hash from the link and autocopy it into the bookmark.
#featurerequest
[pinning a specific top level resource] - You can include an SRI link on one of your pages that points to the top level index.html page on someone else's domain, and the browser will verify the pinned hash of the index.html file. Try it and see. If their index page also uses SRI to pin its own resources, the entire site is pinned.
[just unilateraly pin versions of websites?] - If the other website is advertising itself as 'not supposed to change', then yes, this is a way of confirming that it has not changed.
I dont think that is true. Its called subresource integrity not resource integrity. I don't think pinning a specific top level resource was ever part of the goal.
> but the W3C managed to not let SRI work on bookmarks. If you could bookmark a specific version of a url with SRI, that would make so many problems go away.
I don't really think this makes sense in the context of how web browsers currently work. Are you proposing that users just unilateraly pin versions of websites?