Re: [w3ctag/design-reviews] Portals (#331)

So one of the recent additions to the explainer was:

> ### How does this work in browsers that restrict third-party cookies?
> 
> We imagine that in such cases, the browser would provide functionality for gaining access to first-party cookies (and other storage) at the author's request after activation. For instance, the browser could allow using the [Storage Access API](https://webkit.org/blog/8124/introducing-storage-access-api/) for this purpose.

This doesn't seem sufficient for anything that works by keying storage to the pair of the toplevel origin and the frame origin (known as "double-keying").  I'm not sure which (if any) browsers use double-keying today for which kinds of storage, but it's certainly been something that's been discussed in the past.

This would break double-keying because it would transition script from being in one pair to another, and allow matching the storage from one to the storage from another.

I don't see an obvious solution to this within the double-keying model.

-----

Additionally, I still don't think the explainer answers the key question of *how* this differs from `iframe`.  To consider a *few* of the *many* possible examples:  Is the document in the portal able to request permissions?  Does feature-policy delegation from the containing document still matter?  What about the various mechanisms referenced in the first two comments of w3ctag/design-principles#41?

I don't think we necessarily expect complete answers at this stage of the design, but if not answers it would be good to at least understand your current intentions and how you plan to make those decisions.

-----

I agree that using a new element name rather than an attribute is convenient since it means you don't have to worry about the portal-ness changing dynamically; however, there are certainly other ways to restrict dynamic changes.  And it still seems quite concerning given how much this has in common with `iframe`.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/331#issuecomment-472227849