[css-view-transitions-2] security/privacy considerations with cross-origin css

[noamr]

#8048 and linked feature suggest to expose certain information about the navigation (navigation type, previous/next URL) to CSS, e.g. in the form of media queries.

Some security concerns about it that should be discussed and resolved:
As a general rule we don't consider 3rd party CSS as "safe", it can already exfiltrate a lot of information and alter the behavior of the page. However, it is still handled differently than scripts, e.g. style-src and script-src are separate directives.

When exposing navigation type and previous/next URL to CSS, we give CSS direct observation into the cross-document world.
The threat model: An existing 3p CSS would now be able to exfiltrate (e.g. by an invisible background image) information about the referrer of its host document.

We should resolve how much this should be a constraint and affect our design, if at all. If we decide that this is not a problem, great!

One potential mitigation would be to have some kind of HTML opt-in to make CSS "navigation aware", to avoid making these changes something that affects existing sites.

[khushalsagar]

The features which need navigation specific CSS can be done using script:

• Customize based on destination URL: The user navigates from a list to a details page. The transitioning element needs to be the list item whose details page is the navigation target. You can do that using the navigate event which provides you the destination URL.

     navigation.addEventListener("navigate", (event) => {
         if (isUrlForItem1(event.destination.url)
            item1.style.viewTransitionName = "hero-image";
     });

  The same use-case applies when going back from the details page to the list. The new Document needs to know the source URL. Not sure if this is doable using the Navigation API but we can add that (same-origin only).

• Customize based on navigation type: Author doesn't want to do a View Transition for reload. You can do that using navigationType on the navigate event.

The motivation for navigation specific CSS is to enable handling these use-cases declaratively. This was highlighted during the TAG review. @LeaVerou @atanassov FYI.

So I think we should figure out how to securely allow navigation specific CSS. Just want to make it explicit, 3rd party JS is already assumed to have these capabilities and we're not trying to protect against that.

Other than the blanket html opt-in idea above, one other option is to limit navigation specific CSS to stylesheets which are same-origin. We already know the source of a stylesheet. If its fetched from a cross-origin link, then navigation specific CSS is ignored by default. Unless the author adds an opt-in, for example :

<link rel="stylesheet" href="styles.css" navigation-css="enabled">

So its an html opt-in but lets the author decide which stylesheets are opted-in. In case some site is using a trusted cross-origin domain for stashing their resources.

[noamr]

Related issues: #5092 and #5136.
/cc @arturjanc @mikewest

[arturjanc]

Will this feature respect the Referrer Policy (specifically, the current default value of strict-origin-when-cross-origin) and not expose the referring URL on cross-origin navigations unless a page relaxes its Referrer Policy?

If so, then my guess is that this is relatively low-risk* and might not need an explicit opt-in. If not, then this would be problematic -- and in that case even an opt-in might not be sufficient because this API would give the destination the ability to learn potentially sensitive information about the embedding page which we don't want to reveal.

[*] The reason this seems low risk is that any CSS that can use at-rules can also use selectors and has the ability to learn information about the structure of the page, attribute values, etc. Learning the origin of the referring page or the destination of a navigation sounds like a less scary capability than what's already possible, even if it technically exposes additional information.

[noamr]

Will this feature respect the Referrer Policy (specifically, the current default value of strict-origin-when-cross-origin) and not expose the referring URL on cross-origin navigations unless a page relaxes its Referrer Policy?

Absolutely.

If so, then my guess is that this is relatively low-risk* and might not need an explicit opt-in. If not, then this would be problematic -- and in that case even an opt-in might not be sufficient because this API would give the destination the ability to learn potentially sensitive information about the embedding page which we don't want to reveal.

[*] The reason this seems low risk is that any CSS that can use at-rules can also use selectors and has the ability to learn information about the structure of the page, attribute values, etc. Learning the origin of the referring page or the destination of a navigation sounds like a less scary capability than what's already possible, even if it technically exposes additional information.

Great! I wasn't sure if it was more/less scary, but it seemed like "different" information that's usually not exposed to CSS.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-2] security/privacy considerations with cross-origin css, and agreed to the following:

• RESOLVED: Document security and privacy concerns into the spec, encourage more reviews.

The full IRC log of that discussion

<fantasai> noamr: This goes back to ? and raised bigger question
<fantasai> noamr: basically allows a third-party CSS to ? opt into transitions
<fantasai> noamr: if we add MQ that decides things based on incoming URLs, which not proposed yet, but it's coking
<fantasai> noamr: it could allow the third-party CSS to know thigns about the incoming URL
<fantasai> noamr: and it was a general issue about how do we view third-party CSS in terms of security
<fantasai> noamr: it does seem it's not safe, but safety is not a boolean
<fantasai> noamr: I opened this issue to get some guidance on it
<fantasai> astearns: anyone with guidance to share?
<fantasai> khush: Fwiw we got a comment from security review which is that it's OK, since author is opting in to loading the third-party CSS
<fantasai> khush: already some amount of trust there
<fantasai> astearns: author of the page that you're navigating to is opting into loading third-party CSS by saying view transitions are OK?
<fantasai> khush: if opt-in is in CSS, and you're embedding a third-party stylesheet, could become an issue
<fantasai> khush: e.g. third-party transition could opt you into having transitions
<TabAtkins> I agree with the security person's comment - if we continue to respect existing Referer policy then what's left is fine
<astearns> fantasai: you probably have to trust a lot for a bunch of other things if you are loading third-party CSS
<fantasai> fantasai: e.g. third-party CSS can make you load fonts that you wouldn't otherwise load
<fantasai> noamr: allows third-party CSS to know things that they didn't know before
<TabAtkins> q+
<fantasai> khush: e.g. could load resources based on what page you were navigating from
<fantasai> khush: even if same-origin
<fantasai> khush: so I don't think you're going to learn new information
<fantasai> khush: Question was if you load third-party CSS, do you expose things that the third party wouldn't have been able to know.
<astearns> ack TabAtkins
<fantasai> TabAtkins: I agree with the security comment, as long as we respect existing referrer policy and don't expose to the new page
<fantasai> TabAtkins: then what's left is fine
<fantasai> TabAtkins: if you're allowing something that allows running @rules from third-party, already allowing them to p0wn your page
<TabAtkins> astearns: we should document this in the SEcurity section of VT spec
<fantasai> astearns: I think proposed resolution is to document security/privacy concerns and continue getting reviews
<fantasai> RESOLVED: Document security and privacy concerns into the spec, encourage more reviews.