Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

requestStorageAccess and hasStorageAccess must not enable discrimination against the users who have rejected to provide unpartitioned access #103

Closed
KOLANICH opened this issue Apr 30, 2022 · 4 comments

Comments

@KOLANICH
Copy link

No description provided.

@eligrey
Copy link

eligrey commented Apr 30, 2022

Your request does not seem possible given the nature of these functions.

Discrimination of functionality is the entire point of these APIs.

@KOLANICH
Copy link
Author

  1. hasStorageAccess can be just eliminated while it's not too late. As an alternative solution, it should always return Promise.resolve(true).
  2. requestStorageAccess() should always fullfill no matter if the user has aggreed or rejected.

Of course site owners can implement the check on their side by creating unique identifiers and cross-origin smuggling them and communicating the info on backend side and checking whether the identifiers match the cookies. But I currently believe that at least this way the mere fact of presence of this API wouldn't facilitate discrimination: the routine described doesn't depend on the API presence.

@johannhof
Copy link
Member

I understand where you're coming from but this issue assumes default partitioning of 3rd party cookies, which is currently only done in Firefox, and they have indicated that they would prefer to align with Safari (and future Chrome) and start blocking by default. It's trivial to detect whether 3rd party cookies are blocked or not.

hasStorageAccess and rejecting requestStorageAccess provide utility to web developers that we shouldn't throw away when there's nothing to gain. Note that the information provided to web developers by these functions is already quite sparse as mentioned in #37 and in my opinion that's enough, too. If a party has enough motivation to discriminate against clients which are blocking 3PC there are, as you mention, only slightly more complicated ways to do so still (i.e. it doesn't have to be a unique identifier, just a cookie that the site knows will not be set in an embedded context).

@johannhof
Copy link
Member

I'm closing this, as we're quite seriously aware of this concern as evidenced in #60. There's work on #120 and I don't think we'll go any stronger than that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants