After giving storage access through the Storage Access API, I cleared all browser cookies. After clearing the cookies, hasStorageAccess() of my webpage in an iframe (unexpectedly) returns 'true', but setting cookies has no effect. This is fixed when I open the domain hosting the page on toplevel, and set any cookie (e.g. through document.cookie). Then, hasStorageAccess() within an iframe correctly returns 'false' again. I was expecting everything storage-related to be handled through the storage access API (i.e. hasStorageAccess() would return 'false', and requesting storage access would no longer require opening the page as a first party site and set a dummy cookie as it used to).
From an article on MDN, I get that storage access API may not be expected to work with sites the user hasn't interacted with as a first party site. This is quite painful, though: many services (such as learning tools) are embedded as iframes in other websites (such as learning management systems); the user may never interact with these services on a first-party basis, but these services require cookie storage for storing authentication. They're not interested in first-party storage, only iframe-local cookie storage, but since 2.1 (I'm guessing by dropping partitioning), no cookie storage is available at all to these kinds of services anymore until the user has first-party interaction with them. I was hoping that 'request first party storage' would be a workaround (albeit not very fun for users to always click a button when starting the process), but if you can't rely on that working in an iframe all the time either, this is a problem.
<rdar://problem/49565801>
(In reply to r+webkit from comment #0) > After giving storage access through the Storage Access API, I cleared all > browser cookies. After clearing the cookies, hasStorageAccess() of my > webpage in an iframe (unexpectedly) returns 'true', but setting cookies has > no effect. This is fixed when I open the domain hosting the page on > toplevel, and set any cookie (e.g. through document.cookie). Then, > hasStorageAccess() within an iframe correctly returns 'false' again. > > I was expecting everything storage-related to be handled through the storage > access API (i.e. hasStorageAccess() would return 'false', and requesting > storage access would no longer require opening the page as a first party > site and set a dummy cookie as it used to). What you are seeing is WebKit's 10+ years old cookie policy. A third-party resource without pre-existing cookies cannot set cookies. Each domain has to "seed" its cookie jar as first-party.
(In reply to r+webkit from comment #1) > From an article on MDN, I get that storage access API may not be expected to > work with sites the user hasn't interacted with as a first party site. > > This is quite painful, though: many services (such as learning tools) are > embedded as iframes in other websites (such as learning management systems); > the user may never interact with these services on a first-party basis, but > these services require cookie storage for storing authentication. They're > not interested in first-party storage, only iframe-local cookie storage, but > since 2.1 (I'm guessing by dropping partitioning), no cookie storage is > available at all to these kinds of services anymore until the user has > first-party interaction with them. > > I was hoping that 'request first party storage' would be a workaround > (albeit not very fun for users to always click a button when starting the > process), but if you can't rely on that working in an iframe all the time > either, this is a problem. This is by design. Over 90% of cross-site trackers are domain names that users have never seen or interacted with. Many news websites load subresources from 50-100 different 3rd-party domains. If we'd allow all these domains to prompt the user for cookie access, we'd see no end to the prompting. Therefore, the Storage Access API refuses to prompt the user for cookie access if the user has not interacted with the requesting domain as first-party. Revealing your domain as first-party website is a good thing. It makes the user aware of your existence. After the initial interaction with your domain as first-party website, successful use of the Storage Access API will refresh the timestamp of user interaction. At the heart of all of this lies the fact that cross-site trackers use the same technologies as legitimate websites and services. Therefore, we have to enforce requirements that are hard for cross-site trackers to meet but a lot easier for legitimate services to meet, such as getting user interaction as first-party website.
Resolving as behaves correctly/won't fix.