[Webkit-unassigned] [Bug 196490] Storage Access API: hasStorageAccess does not take into account unvisited state

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=196490

--- Comment #4 from John Wilander <wilander at apple.com> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190403/ca065b50/attachment-0001.html>