Super cookie issue

[feross]

From the Known Weirdness section:

Sites could bill “save as…” like “download…” but then be able to retain access to it Could exacerbate super cookie issue from above

Seems like this could be easily solved by clearing the file reference when cookies are cleared. Chrome already bundles a bunch of other settings into the clear cookies item: "Cookies and other site and plugin data"

Sure this is another possible type of cookie, but it's not better at tracking users than existing cookies are.

[drufball]

That's actually a really good point! Especially if we're requiring sites to persist the reference by storing it in IDB or something. We would get this behavior by default.

[kenchris]

I guess you could also warn the user if a certain file/folder has been shared with more than N sites and ask for additional permission.

As Mike West long term would like to get rid of cookies, I wonder what he feels about this @mikewest

[mikewest]

I guess you could also warn the user if a certain file/folder has been shared with more than N sites and ask for additional permission.

It's not clear that this addresses the concern. I don't think folks are worried about sites sharing identifiers through the file, but sites using the file as an identifier with a lifetime distinct from the site's other identifiers (cookies, localStorage, etc).

Breaking the link between the site and the file when the rest of the site's data is cleared seems like a reasonable mitigation of that risk. I think I agree with @feross that this doesn't seem to provide any additional capabilities above and beyond cookies (aside, of course, from the file access in the first place).

As Mike West long term would like to get rid of cookies, I wonder what he feels about this

We should get rid of cookies. But whatever we're left with will have the same characteristics insofar as we'd bundle it together with the rest of the site's data. Chrome, at least, tries to bundle these concepts up together, as it's unlikely to be helpful to ask users to make decisions about specific aspects of a site's data (localStorage vs IndexedDB, etc).

[mkruisselbrink]

Yeah, we definitely want to make sure to revoke a sites access to all files when storage for the site is cleared. For file-picker selected files where you can only retain access by storing the reference in IDB we of course get that for free, but if we end up with more powerful APIs that let a site get access to certain native files without file pickers we might have to be more careful.

Of course APIs like "give me all the font files" provide lots of finger printing opportunities as well, but that is kind of the point. Browsers just have to be careful how and when they grant such permissions.

[inexorabletash]

Just a note for readers: there should be nothing specific about IDB here, it's just one API that lets you persist serializable things. There are others, e.g. History.pushState(). All of those would need to be cleared to revoke access, but any such storage would need to be cleared "with the rest of the site's data" (per @mikewest) anyway.

[mkruisselbrink]

#135 tracks clearing up the spec text a bit around this, but I think this is already sufficiently addressed.