[Webkit-unassigned] [Bug 244330] Storage access grant is lost on new tab page as extension origin GUID gets refreshed on every launch

[bugzilla-daemon at webkit.org]

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

--- Comment #5 from vsr4493 at gmail.com ---
Hey John, thanks for chiming in!

> We deliberately made the Storage Access API
> remember when the user opts in and don't prompt thereafter. If you are
> getting multiple prompts, please repro steps.

You're correct that Storage access is granted promptlessly when requestStorageAccess() is called for frames embedded in webpages like `example.com`.

This issue occurs with a safari web extension new tab page or any web extension pages in general since their origin is of the form `safari-extension://<GUID>`. Here, the GUID is updated on every browser relaunch.

IIUC ITP access grant is granted for (origin of the embedder page + the origin of the embedded frame). 
Since the origin of the embedder in this case is refreshed on every browser launch, any frames we embed will lose their storage access grant.

Repro steps overall:
- Install any Safari extension that renders an iframe with any external URL on the new tab page or any extension page
- Call `requestStorageAccess` within the iframe on user activation and grant access
- Restart the browser
- Call `requestStorageAccess` within the iframe on user activation again.

(Will share a sample extension that repros this in a follow-up.)


I'm curious if the following is feasible to make the UX frictionless:

1. As the extension is a privileged context, can ITP rules be relaxed for extension pages and third party cookies be allowed here without requiring StorageAccess API? Other browsers such as Firefox / Brave do this afaik with their respective third party cookie blocking mechanisms.

2. Can storageAPI access be granted passively if the user has already granted access for the frame origin + embedder origin previously? I see that Firefox has taken this approach to reduce UX friction in requiring another user prompt as of https://hacks.mozilla.org/2022/02/improving-the-storage-access-api-in-firefox/.

-- 
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/20230424/7f6b6471/attachment.htm>