Summary: | Storage access grant is lost on new tab page as extension origin GUID gets refreshed on every launch | ||
---|---|---|---|
Product: | WebKit | Reporter: | vsr4493 |
Component: | Frames | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW --- | ||
Severity: | Normal | CC: | bfulgham, jberlin, timothy, webkit-bug-importer, wilander |
Priority: | P2 | Keywords: | InRadar |
Version: | Safari 15 | ||
Hardware: | All | ||
OS: | macOS 12 |
Description
vsr4493
2022-08-25 02:01:02 PDT
To add to this, I believe the core issue here is that this is currently falsy: ``` chrome.permissions.contains({ origins: [`${self.origin}/`] }) ``` For its own origin, the extension should have permissions out of the box, so the permission check returning false here seems like a bug. Hi! Thanks for filing.
> bad UX where the user has to be prompted by the browser every time
Has this been your experience? 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.
(In reply to John Wilander from comment #3) > Hi! Thanks for filing. > > > bad UX where the user has to be prompted by the browser every time > > Has this been your experience? 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. Please *provide* repro steps. 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/. |