Brief description: We're porting over a web extension which works as a new tab page and are facing some issues due to Storage access API on the new tab page. In the new tab page implementation, we currently render an iframe with authenticated user interactions and content. Since ITP would understandably block third party cookies here we reached out for Storage Access API to prompt the user and get permissions. However, as I understand, to prevent fingerprinting, the GUID of the extension page origin gets reset by the browser on every new browser launch. Considering that the new tab page for extensions has the same origin as the background page, when this origin gets reset behind the scenes for the new tab page, any storage API access grant by the user will be revoked when the browser is relaunched, instead of being retained for the next 30 days. Concern: Maintaining storage access grant against a GUID on the extension new tab page which changes on every browser launch leads to a bad UX where the user has to be prompted by the browser every time, instead of being able to promptlessly get access to Storage Access API on a user gesture after the first browser prompt. Proposal: StorageAccessAPI grants are tracked against the page origin by default. For extension schemes (safari-web-extension://) can we instead track them against the extension id which remains fixed across browser re-launches. How to repro this: - Start with any safari web extension as a starter template with a new tab page - On the new tab page, embed an iframe with your site origin. - In the Iframe on the new tab page, prompt the user for storage access after a user interaction and get storage access grant. This will lead to a browser prompt. - Visit another new tab, and request storage access on a user gesture, this time it will be granted promptlessly as expected. - Close and launch the browser again - Note that the frame in the new tab page now needs to prompt the user with a browser prompt again since the top frame origin has changed and storage access granted earlier no longer applies.
<rdar://problem/99428367>
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/.