4 ms·
I agree that immutable seems like a better solution. But it still puts a little too much trust in the urls not breaking and puts an unnecessary onus solving a s
by benjaminjackman 10y ago
I agree that immutable seems like a better solution. But it still puts a little too much trust in the urls not breaking and puts an unnecessary onus solving a solved problem. Immutable resources should be referred to by some straightforward variaton of a hash of the immutable bytes that form their content. Its similar to how git works for example. [1]
So what does this look like in practice? rather than serve a your css as
<link rel="stylesheet" type="text/css" "ref="https://example.com/styles/site.css"/>
you'd instead use something like[2]:
<link rel="stylesheet" type="text/css" "ref="sha256:abc123..."/>
And all the resources could be verified for integrity after being downloaded and trivially changed thereafter.
For privacy concerns, the url provides the additional feature of sandboxing the content via the origin access controls. As a step 2 addition the urn could still contain the current url style as an optional suffixed parameter, which if provided the browser would use to sandbox that particular hash to that site as a provider of it. Referring to that hash from a site that has not previously provided the data would fail, unless the site is able to either prove that has the data by resending it, or rehashing it some way.
1: I don't mean to be pedantic but a lot of people don't understand that you can take any number of bytes, compute a 256 or 512 bit cryptographic hash for it, and be guaranteed of a longer than the lifetime of the universe level small chance of ever finding any other bytes that produce the same 256 or 512 bit number, even when trying as hard as you can with all the resources you can muster.
2: There are several different ways to do the addressing for the content (magnet uris, IPFS univeral hashes etc). The browser vendors ought to pick one and move on.
- benmaurer 10y agoWe discussed this approach -- one difficulty with it is that the website often doesn't know the hash of the resource. For example, imagine a server that takes urls of the from images.fbcdn.net/abc124.jpg/200x200 and dynamically resizes the image to 200x200 px. It it is impossible to know what the hash of this resource will be without calculating it beforehand. The subresource integrity spec supports cases where the developer is able to calculate the hash beforehand
- benjaminjackman 10y agoI hadn't considered dynamic urls as the dominant use case. But I can certainly see the importance in handling them as well. To me that feel like a function memoization problem (e.g. this example was a function of 2 parameters, height and width). For that case passing along cache-control: immutable, integrity: sha-abc123 headers in the response feels like the best current solution. Though it would be nice to somehow have the url self-descriptively assert its purity. Something to the effect of saying `I don't have the content-hash for this now but whatever i return is going to be immutable`, rather than having to muck around in the web-server protocol layer to assert that fact via cache-control: immutable. I think fundamentally the metadata on whether a particular url is immutable/pure or not, should be self evident, rather than buried in as an implementation detail in the response's http header.
- dfabulich 10y agoDid Google debate this proposal on their bug DB anywhere? Do you know how/why they settled on their chosen approach as opposed to Firefox's "immutable" CC header?
- timdorr 10y agoYour proposal already exists. It's called Subresource Integrity: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... For instance, here are the tags for Bootstrap: <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css" integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u" crossorigin="anonymous"> <script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js" integrity="sha384-Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa" crossorigin="anonymous"></script>
- benjaminjackman 10y agoHeh, I linked the same proposal in a sister thread. I am aware of it, however it's for verifying the integrity of some resource at some url. It falls a bit short of what I'd like to see which is to serve items by the hash of their content, which I am also aware is basically IPFS. So overall I would propose to drop the notion of location all together and just serve items by their integrity hash along with an fallback location which will typically be a classic http[s]:// url. Ideally in the future I will be able to copy-paste those urn's into my browsers address bar and have them resolve right to the resource which will involve the browser either serving from it's local sha store or using the fallback url. In the future when some sort of IPFS or other federated resource by sha provider takes hold then the fallback urls will become less and less needed. To me it's just about making the links themselves be self-descriptive enough to allow them to truly become immutable and then, eventually, more efficiently served.