search

w3c / webappsec-clear-site-data

WebAppSec Clear Site Data
https://w3c.github.io/webappsec-clear-site-data/
Other
19 stars 21 forks source link

Is registerProtocolHandler() affected? #37

Open annevk opened 7 years ago

annevk commented 7 years ago

Seems like registerProtocolHandler() should be "site storage" for the purposes of https://storage.spec.whatwg.org/#infrastructure and therefore get cleared?

(Got inspired by https://github.com/whatwg/html/issues/3043.)

domenic commented 7 years ago

Hmm, I wouldn't treat this as "data". It's more toward a bookmark, to me: I have configured my browser to give easy access to this site. I wouldn't expect clear-site-data to remove any bookmarks I have to the site. (Bookmarks aren't web-exposed, so this analogy is definitely not complete, but still.)

annevk commented 7 years ago

That makes it a bad analogy as I could generate unique URLs and thereby fingerprint you beyond removal of data.

domenic commented 7 years ago

I guess the problem is isProtocolHandlerRegistered() in that regard.

annevk commented 7 years ago

No, just triggering a click on something with the registered scheme and seeing which URL gets hit.

msramek commented 6 years ago

I see protocol handlers to be somewhere between what Clear-Site-Data calls storage, and navigator.permissions. It is a permission in the sense that it gives the website some sort of ability that the user might explicitly acknowledge, but it is more akin to storage in the sense that it can store a broader amount of data than just the boolean "permission granted or denied".

Permissions are currently out of scope of Clear-Site-Data (should they be?).

But @annevk is exactly right that the argument should not be about convenience, but rather the ability of websites to write and read arbitrary data. So protocol handlers should be in scope.

If we don't feel they belong to storage, we could just add them as a separate datatype.

annevk commented 6 years ago

Permissions should be out-of-scope I think. They're up to the user.

msramek commented 6 years ago

So, @mikewest , what do you think about adding a separate datatype for protocol handlers?

I think there is an agreement that we want to delete those, but they don't fit well into the existing datatypes.

Or we could try to squeeze them into storage, but then again we wanted to make storage more granular per other feature requests anyway, so I think a separate datatype is the best solution.

annevk commented 6 years ago

Is there an issue on making storage more granular? I'm curious why that's desirable.

dveditz commented 6 years ago

I guess the problem is isProtocolHandlerRegistered() in that regard.

Yes, but that has been removed from the spec. registerProtocolHandler() is back to feeling like a user-initiated (or at least consented) bookmark for me and shouldn't be cleared by Clear-Site-Data as cookies or storage.

annevk commented 6 years ago

There's still the

No, just triggering a click on something with the registered scheme and seeing which URL gets hit.

angle as I pointed out. Perhaps this could be avoided if we always made these top-level browsing context navigations into a new top-level browsing context, regardless of other attributes set?