Conversation
|
What's the motivation behind privacy-preserving rendering of subtitles and captions not taking into account user preferences? As I understand it, WebVTT rendering done by the UA or OS is already supposed to be privacy-preserving, and the current design choice is that there are no Web APIs for querying user preferences or for extracting styling choices from the rendered captions. It seems odd that privacy-preservation should have a negative impact on accessibility settings that aren't exposed to pages. (aside: I actually don't think the argument for prohibiting Web APIs for accessing user settings holds up any more, but that's a whole different discussion) |
|
This is a rendering mode that allows for arbitrary read back. Maybe instead of calling it privacy-preserving we should call it "read-back rendering mode". |
|
That would be a lot clearer, yes, seems like I got a whole different impression from the name alone. Not sure if this PR is the right place for the discussion (please point me to the right place: there's no linked issue), but since I'm here: Is this related to test drivers/engines? I'd expect test engines, when inspecting rendering results, to be able to choose whether to use this "read-back rendering mode" or to be able to read back the result rendered with a provided context of specific user settings. |
foolip
changed the title
|
After discussion with @annevk on chat I'll rename it "read-back-allowed rendering" since read back might not actually happen. |
annevk
added
topic: canvas
security/privacy
The test drivers/engines is an interesting point we had not considered. We have thought to refer to read-back-allowed in the SVG spec, where there are issues with SVG-as-Image used as an image source in a canvas and the related tainting behavior. |
| <span>rules for updating the display of WebVTT text tracks</span>. <ref>WEBVTT</ref></p> | ||
|
|
||
| <p>During <span>read-back-allowed rendering</span>, <code>video</code> elements whose <span>media | ||
| data</span> is <span>CORS-cross-origin</span> must not be rendered.</p> |
There was a problem hiding this comment.
CSS specs already use the term "not rendered" to specifically mean "acts like display:none". (See Images, where it's a condition, and Grid, where it's an effect like you're doing here.)
Is this what we want? If so, we can just copy Grid's wording and say ", as if it were display: none".
This has layout effects, so if we instead want it to just not paint, we should use a different term to avoid the clash, and specify "as if it were opacity: 0".
Alternately, I think previous proposals in this space made them paint as solid opaque black, so the hole was observable and obvious in debugging.
| data</span> is <span>CORS-cross-origin</span> must not be rendered.</p> | ||
|
|
||
| <p>During <span>read-back-allowed rendering</span>, controls, subtitles and captions must not be | ||
| rendered.</p> |
There was a problem hiding this comment.
And same here obvs. Note that, while CORS-violating images still leak sizing info, so observing the geometry via other layout effects doesn't leak any further info, this isn't necessarily true for these elements. Dunno if you can use anchorpos to observe their geometry indirectly, but if we assume that someday you can, this would be an info leak. We probably do mean "as if display:none" here, at least for subs/captions, then? They float on the video so there's no layout side-effects from making them not render boxes.
Probably also useful to clarify that this applies to these elements even on non-CORS-cross-origin videos, just to contrast it with the preceding bullet point.
|
|
||
| <p>During <span>read-back-allowed rendering</span>, <code>img</code> and <code>input</code> | ||
| elements whose <span>current request</span>'s <span data-x="img-req-data">image data</span> is | ||
| <span>CORS-cross-origin</span> must not be rendered.</p> |
There was a problem hiding this comment.
Use the same clarification that you apply to replaced elements here.
|
|
||
| <p>During <span>read-back-allowed rendering</span>, user agents are <span>expected</span> to act | ||
| as if the <code data-x="selector-visited">:visited</code> <span>pseudo-class</span> does not | ||
| match.</p> |
There was a problem hiding this comment.
Instead, point to https://drafts.csswg.org/selectors/#link and say that UAs must preserve privacy for :link/:visited in the same way that they do in other contexts.
|
|
||
| <h4>Summary</h4> | ||
|
|
||
| <!-- NON-NORMATIVE SECTION --> |
There was a problem hiding this comment.
Then obvs update this informative section to match whatever changes are made above.
|
Ah here we go, the term we want to lean on for "not rendered" is instead "invisible", from Display 4. Not painted, not hit-tested, etc. |
5 participants
(See WHATWG Working Mode: Changes for more details.)
/index.html ( diff )
/infrastructure.html ( diff )
/rendering.html ( diff )