5 ms·

The potential for a domain to transfer ownership and still use the same paths, yet have different content seems incredibly unlikely. Like, it feels like you we

by tobz 10y ago

The potential for a domain to transfer ownership and still use the same paths, yet have different content seems incredibly unlikely. Like, it feels like you were trying to come up with potential issues for the sake of finding a way to say "see, this won't work!" :P The biggest reason to use this is for versioned resources. Things that will never change. Say I create a minified JavaScript file. Its MD5 hash is 123456789abcdef...., and so in the output file, the filename is "foo.123456789abcdef.js". If the file changes, the hash changes. If I request the version of the file with "123456789abcdef", I should get that one. Ignoring the unlikely potential for hash collisions, everything in this scenario is working as intended. There is no conceivable reason to ever want to change the content while keeping the same hash. Now, let's say that file, somehow, gets corrupted AND cached in your browser. I can't say I've ever seen something like this happen, but I suppose it's possible? I'd be very interested to hear if something like this is possible, to be honest. It seems like between TCP retransmissions and Content-Length, you would need some sort of subtle corruption that flips a bit and isn't corrected? EDIT: As Klathmon points out, Subresource Integrity is probably a better solution to "corrupted file in cache" scenarios. As it stands, if a file was corrupted on disk, let's say, but the ETag and/or the Last-Modified values were accurate, the origin would only ever respond back saying "nope, no changes! you seem to have the latest copy" and you'd still be stuck with the corrupted file. Only a hard reload/cache clear solves that.

JoshTriplett 10y ago
> The potential for a domain to transfer ownership and still use the same paths, yet have different content seems incredibly unlikely. More generally, many protocols (including basic email verification) break horribly when the assumption that domains last forever gets broken. Ideally, domains shouldn't expire, ever.
- toomuchtodo 10y ago
  We better get moved over to IPFS sooner than later then ;)
deleted 10y ago
[deleted]
rileymat2 10y ago
> The potential for a domain to transfer ownership and still use the same paths, yet have different content seems incredibly unlikely. index.html? favicon? There are a ton of duplicate paths.
- jakub_g 10y ago
  Of course. But no one sane would put 'Cache-Control: immutable' on `index.html`. It's to be used on `/js/lib/jquery-1.7.1.min.js` or `/js/mystuff-<sha1here>.js` or `/photos/mnbvcxzasdfghjklqqwertyuio1234567890.jpg`
  - detaro 10y ago
    If you can construct an attack out of it, relying on people doing sane things is dangerous... (I'm not sure this is interesting enough as an attack vector, but "but nobody would do that" is a bad answer a lot of the time)
  - kiallmacinnes 10y ago
    Nobody sane would, intentionally. But I'd bet the house on it happening by accident quite a bit. At a technical level, I like this idea. When used well, it makes sense to allow. It's hard to fault it without bringing in human error, politics, or economics. At a practical level... I can't wait to see what happens when a bug allows Facebook to serve this header on all pages, even for a few minutes. The most Facebook dependant folks around, those checking their phones every five minutes, will be stuck in a perpetual time freeze, unable to move forward ;). I also can't wait to see what happens when a government tries to ban a cache-control: immutable page. Or even what happens when, someday, Google is selling it's assets and gets to "google.com.". (Someday, itll happen - Google won't exist for all eternity)
    - jakub_g 10y ago
      Fully agree you have to be extra cautious and that in complex setups it can happen accidentally. But so can happen a myriad of other things: returning too long "Expires" value for some content (in months instead of days), misconfiguring ETags etc.
Matthias247 10y ago
I don't want to come up with potential issues just for the sake of preventing this. But it's my job as an engineer to think about all potential issues and to avoid them as long as possible. And I'm not directly involved in this topic here or in the web in the large, but I just read this and have wondered if this is fully thought through or not and asked therefore. Of course domain changes are unlikely. But nevertheless they are possible in our system and we have to cope with it. I just googled subresource integrity and it doesn't seem like an appropriate solution for this scenario. This would mean a new domain owner would need to generate those for ALL his links - just to be sure that the previous site didn't mess anything up. This means at first extra work and second you wouldn't even know for how long you need this (until all previous users have visited the new site). There would be even possibilites for major annoyancies, if a previous site owner put that feature on things like index.html before owner change - just to avoid that visitors see the new page as long as possible.
- tobz 10y ago
  I mean, you could say the same thing about HSTS and key pinning. Domain changes hands, but "oops", HSTS was set and the old keys were pinned. Is that actually a problem? No, it's not. Similarly, as the owner of a new domain, why would I want the old content? The only reason I can think of is that I brought a company outright, or something. In that situation, if I don't want to change the content, everything still works. If I want to change it, and they did something stupid -- like unversioned paths using this proposed flag -- then yeah, I'm in a weird spot. That seems like the most trivial and unlikely of scenarios, though. It requires such a complex chain of events to occur. I think it's safe to say that malicious usage of the flag is entirely out of scope when considering the validity of it, again, because it requires a contrived situation.

by tobz 10y ago

JoshTriplett 10y ago

> The potential for a domain to transfer ownership and still use the same paths, yet have different content seems incredibly unlikely. More generally, many protocols (including basic email verification) break horribly when the assumption that domains last forever gets broken. Ideally, domains shouldn't expire, ever.

toomuchtodo 10y ago
We better get moved over to IPFS sooner than later then ;)

deleted 10y ago

[deleted]

rileymat2 10y ago

> The potential for a domain to transfer ownership and still use the same paths, yet have different content seems incredibly unlikely. index.html? favicon? There are a ton of duplicate paths.

jakub_g 10y ago
Of course. But no one sane would put 'Cache-Control: immutable' on `index.html`. It's to be used on `/js/lib/jquery-1.7.1.min.js` or `/js/mystuff-<sha1here>.js` or `/photos/mnbvcxzasdfghjklqqwertyuio1234567890.jpg`
- detaro 10y ago
  If you can construct an attack out of it, relying on people doing sane things is dangerous... (I'm not sure this is interesting enough as an attack vector, but "but nobody would do that" is a bad answer a lot of the time)
- kiallmacinnes 10y ago
  Nobody sane would, intentionally. But I'd bet the house on it happening by accident quite a bit. At a technical level, I like this idea. When used well, it makes sense to allow. It's hard to fault it without bringing in human error, politics, or economics. At a practical level... I can't wait to see what happens when a bug allows Facebook to serve this header on all pages, even for a few minutes. The most Facebook dependant folks around, those checking their phones every five minutes, will be stuck in a perpetual time freeze, unable to move forward ;). I also can't wait to see what happens when a government tries to ban a cache-control: immutable page. Or even what happens when, someday, Google is selling it's assets and gets to "google.com.". (Someday, itll happen - Google won't exist for all eternity)
  - jakub_g 10y ago
    Fully agree you have to be extra cautious and that in complex setups it can happen accidentally. But so can happen a myriad of other things: returning too long "Expires" value for some content (in months instead of days), misconfiguring ETags etc.

Matthias247 10y ago

I don't want to come up with potential issues just for the sake of preventing this. But it's my job as an engineer to think about all potential issues and to avoid them as long as possible. And I'm not directly involved in this topic here or in the web in the large, but I just read this and have wondered if this is fully thought through or not and asked therefore. Of course domain changes are unlikely. But nevertheless they are possible in our system and we have to cope with it. I just googled subresource integrity and it doesn't seem like an appropriate solution for this scenario. This would mean a new domain owner would need to generate those for ALL his links - just to be sure that the previous site didn't mess anything up. This means at first extra work and second you wouldn't even know for how long you need this (until all previous users have visited the new site). There would be even possibilites for major annoyancies, if a previous site owner put that feature on things like index.html before owner change - just to avoid that visitors see the new page as long as possible.

tobz 10y ago
I mean, you could say the same thing about HSTS and key pinning. Domain changes hands, but "oops", HSTS was set and the old keys were pinned. Is that actually a problem? No, it's not. Similarly, as the owner of a new domain, why would I want the old content? The only reason I can think of is that I brought a company outright, or something. In that situation, if I don't want to change the content, everything still works. If I want to change it, and they did something stupid -- like unversioned paths using this proposed flag -- then yeah, I'm in a weird spot. That seems like the most trivial and unlikely of scenarios, though. It requires such a complex chain of events to occur. I think it's safe to say that malicious usage of the flag is entirely out of scope when considering the validity of it, again, because it requires a contrived situation.