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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Aug 25 02:01:02 PDT 2022


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

            Bug ID: 244330
           Summary: Storage access grant is lost on new tab page as
                    extension origin GUID gets refreshed on every launch
           Product: WebKit
           Version: Safari 15
          Hardware: All
                OS: macOS 12
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Frames
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: vsr4493 at gmail.com

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.

-- 
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/20220825/839f29b9/attachment-0001.htm>


More information about the webkit-unassigned mailing list