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

@cynthia To expand on this a bit: 

The portal host can send any information it wants to the `<portal>`, either by encoding it in the URL, or by sending it via `postMessage()`, since it has access to `postMessage()` the guest browsing context. This could include the URL of the page, or a logged in user ID.

Why is that a problem?

Many browsers deny access to cookies and other state in a third-party context, including cross-origin `iframe`s. Safari has done so for a long time, and continues to expand those protections with various forms of partitioning and complete blocking. Firefox is moving in this direction as well.

So if a site passes info to an `<iframe>` in a browser with tracking protection, the origin inside the frame won't be able to associate that with a tracking cookie. For example, if a social or video embed is also a very popular site that many users are logged into, it won't be able to associate this page visit (or whatever other info got passed) with your login cookie.

Per @lucasgadani, the plan for `<portal>` is that content inside the portal gets full access to state and storage. This would completely break that privacy protection. If browsers implemented this proposal, and if embeds switched from iframe to portal embedding, they could completely bypass tracking protection and would once again be able to freely track users across the web.

(This concern does not apply to browsers that lack any built-in on-by-default tracking protection, such as Chrome.

-- 
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-462022648