johannhof
commented
1 year ago This feels like a browser-specific issue for WebKit (and maybe Firefox). I'm not sure off-hand why extension state would have to be partitioned (though there may be a good reason), and losing storage (access) because of regenerating GUIDs also seems like a needlessly bad developer experience. I would encourage you to file bugs with the implementations.
I don't think that web standards integrate with extensions to the extent that we can specify any consistency here, though. Maybe a non-normative note?
CC @bvandersloot-mozilla @johnwilander
annevk
Hi, I wanted to get some inputs on using Storage access AP on browser extension pages such as the "new tab page". Detailing the scenario and concern here.
Scenario
When using an extension to control the "new tab page", the page would have an origin such as "safari-web-extension://GUID" and "moz-extension://GUID" for Safari and Firefox respectively. Our use-case is to render an iframe inside this page with its own contents and interactions.
Concern
For authentication we break out of the iframe to a first party page where the cookies are set, but the cookies for this iframe are partitioned so they are not attached to any requests initiated from the frame.
As a workaround we considered using the Storage Access API to prompt the user for access. This access however, gets revoked when the browser is re-launched since the GUID for the extension page is refreshed and the page ends up with a different origin.
From other issues I see Webkit refreshes the GUID on every browser launch to prevent fingerprinting, but this is indirectly also making Storage Access API unusable on these pages to access cookies from iframes.
Any thoughts on making the storage access grant independent of the page origin and instead track it against the extension id for these kind of pages?