search

privacycg / storage-access

The Storage Access API
https://privacycg.github.io/storage-access/
199 stars 26 forks source link

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

Closed KOLANICH closed 1 year ago

eligrey commented 2 years ago

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

Discrimination of functionality is the entire point of these APIs.

KOLANICH commented 2 years ago
  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 commented 2 years ago

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 commented 1 year ago

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.