search

WICG / portals

A proposal for enabling seamless navigations between sites or pages
https://wicg.github.io/portals/
Other
947 stars 66 forks source link

Summarize the rationale for non-interactive portals. #186

Closed jeremyroman closed 4 years ago

jeremyroman commented 4 years ago

ptal

jeremyroman commented 4 years ago

@lucasgadani wdyt?

jakearchibald commented 4 years ago

@domenic

let's do no manual wrapping for Markdown?

[cough] or anywhere

jakearchibald commented 4 years ago

@jeremyroman

I wonder if it's better to frame this around preventing communication with the document while it's nested in another page?

they are expected to often be partially or fully offscreen, scaled, faded or otherwise styled in a way that makes them unnatural to interact with directly.

We don't prevent interaction with iframes or other DOM elements in these cases.

Additionally, we expect many web pages to allow themselves to be loaded in a portal for the purposes of facilitating a seamless transition, but be concerned about clickjacking and similar attacks from an embedder who may not be fully trusted.

Non-interactive portals can also leak data via click-jacking. Eg, if the portaled page contained a button that was in a particular place due to the user's logged in status, or something else identifiable, the parent page could detect a click in that area and learn something.

It feels like the actual protection is the lack of storage access & communication, and no-interactivity is part of that.

jeremyroman commented 4 years ago

@jeremyroman

I wonder if it's better to frame this around preventing communication with the document while it's nested in another page?

they are expected to often be partially or fully offscreen, scaled, faded or otherwise styled in a way that makes them unnatural to interact with directly.

We don't prevent interaction with iframes or other DOM elements in these cases.

I'm not proposing that it be triggered by those cases, but rather that <portal> elements are more likely to be used in manners in which interaction is not expected or desirable. It is probably not useful or desirable to interact with a form fields in a <portal> that is tiny, sliding around, off-screen, etc., and I would expect portals to be doing that more often than iframes, and more generally be more likely to be used for the purpose of preloading or previewing content than to implement an interactive widget as part of the containing page. If so, that makes non-interactivity a more reasonable default.

Additionally, we expect many web pages to allow themselves to be loaded in a portal for the purposes of facilitating a seamless transition, but be concerned about clickjacking and similar attacks from an embedder who may not be fully trusted.

Non-interactive portals can also leak data via click-jacking. Eg, if the portaled page contained a button that was in a particular place due to the user's logged in status, or something else identifiable, the parent page could detect a click in that area and learn something.

It feels like the actual protection is the lack of storage access & communication, and no-interactivity is part of that.

I didn't mean to imply that this gave immunity against attacks, just that it mitigated certain classes of them.

The discussion of storage access and communication doesn't yet exist here AFAIK (though I can leave a TODO to reference it when it does, if you'd like). Interactivity might be categorized as a side channel for that purpose, but to my mind that isn't the only justification for this position.

jeremyroman commented 4 years ago

made some changes in response to this feedback; ptal?