[css-view-transitions-2] Auto-generated names leak via animation name

[noamr]

By iterating over all of the document element's running animations and getting their name + pseudo-element, the author can match a pseudo-element to a name.

This is sometimes necessary, as the animation name is the only way to set an animation on a pseudo-element, and view transition pseudo-elements with the same class still have separate generated animations.

I believe that the value in obfuscating the generated view transition names is more trouble than its worth, and doesn't really work.
We should consider undoing the obfuscation and have these strings be explicit implementation-defined unguessable idents that can be used like any view-transition pseudo-element name.

@nt1m @bramus @vmpstr @fantasai

[bramus]

+1 on this, as per our internal discussion. This came to my attention when debugging https://cdpn.io/pen/debug/EaxpWyg/6639b89cea4958859d285316ad963a8f which uses view-transition-name: match-element.

While the name of the pseudo is obfuscated in animation.effect.pseudoElement (as per previous resolution), the generated name is leaking from various other places:

1. The tree in DevTools shows those generated names.
2. The generated UA stylesheet uses those generated names to target the pseudos.
3. The names are exposed through the generated animation-name values.

While DevTools could be adjusted to also expose match-element here (fixing 1), issue 2 and 3 can only be fixed by decoupling the generated animation name from the generated pseudo name and then doing some internal mapping.

I don’t think that the “fix for issues 2 and 3 would be helpful to authors, as it would result in the obfuscation becoming more of a hurdle than a feature:

1. Currently some authors are actively relying on there being a link between the generated animation name and the generated pseudo name. They use this to add extra animations, overwrite the generated keyframes for performance reasons, to derive the presence of pseudos without accessing the animation effect to read the name, or to do a getComputedStyle on a pseudo to read styles from it.
2. When further obfuscating, authors could still derive things by doing all sorts of crazy things: loop all animations, read their keyframes, get the matching pseudos based on the keyframes’ name, then get those pseudos their top/left values, and then try to match that with the all captured elements to find which one is which – I don’t think we want to push authors into that direction.

The easiest and most author-friendly solution is to revert the decision to obfuscate the generated name in the animation’s pseudoElement.

[nt1m]

Perhaps something prefixed with -ua- like the keyframes for VT. We should make sure to have a custom ident restriction to disallow -ua- prefixed names.

-ua-match-element-*
-ua-auto-*

Or something like that.

The * would be whatever the UA wants to use as identifier

[noamr]

Perhaps something prefixed with -ua- like the keyframes for VT. We should make sure to have a custom ident restriction to disallow -ua- prefixed names.

I'm not opposed to the restriction but also not sure if it is necessary, as long as the generated name is unguessable (UUID-based or some such).

-ua-match-element-* -ua-auto-*

It can also be -ua-*. But I agree with the general approach.

[nt1m]

Perhaps something prefixed with -ua- like the keyframes for VT. We should make sure to have a custom ident restriction to disallow -ua- prefixed names.

I'm not opposed to the restriction but also not sure if it is necessary, as long as the generated name is unguessable (UUID-based or some such).

Agreed

-ua-match-element-* -ua-auto-*

It can also be -ua-*. But I agree with the general approach.

Yeah I agree, since the elements targeted by match-element or auto can be the same.

[bramus]

So, to summarize, I believe we are proposing this:

1. Revert decision from 10978 to use match-element / auto in the Animations API when element identity is used. Instead, expose the generated name.
2. Exclude <custom-ident>s that start with-ua- as an authored value for view-transition-name.

[noamr]

So, to summarize, I believe we are proposing this:

1. Revert decision from 10978 to use match-element / auto in the Animations API when element identity is used. Instead, expose the generated name.

Yes, and assert that the strong needs to start with -ua-.

2. Exclude <custom-ident>s that start with-ua- as an authored value for view-transition-name.

Optionally. I didn't think this is required.

[bramus]

Agenda+’ing (async) to resolve on the following:

1. Revert decision from [css-view-transitions-2] How are auto-generated view-transition-names exposed in JS APIs #10978 that says we use match-element / auto in the Animations API when element identity is used. Instead, expose the generated name.
2. The generated name must start with -ua-.

If I’m not mistaken this matches with what WebKit/Safari already does. The second bullet is also what Blink/Chrome already does today.

I’ll file a separate issue about excluding <custom-ident>s that start with -ua- as an authored value for view-transition-name.

[astearns]

The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.

Proposed Resolution: Expose generated view-transition-names as -ua-<generated name>

[astearns]

RESOLVED: Expose generated view-transition-names as -ua-<generated name>