Add consideration for font fingerprinting

[palemieux]

Closes #1202

[nigelmegitt]

I've added this to the agenda for this week's call at w3c/ttwg#118. I believe the main outstanding questions we need to resolve, from this pull request, are:

1. Change the title of the "Font Matching" section to "Font Detection" as per https://github.com/w3c/ttml2/pull/1203#discussion_r409704111
2. How best to articulate that other detections may be possible using the condition attribute, as per https://github.com/w3c/ttml2/pull/1203#discussion_r411271787

[nigelmegitt]

For the discussion on Thursday, my hope is that we can agree to change "Font Matching" to "Font Detection" as per Nick's comment.

I also hope we can get to agreement on whether the use of the condition attribute provides any further ability to detect fonts. If we agree that it does not, then I will be happy to proceed with the current pull request. Then, consequently, I would like to know if the media queries available via the condition attribute are considered a fingerprinting risk by PING. If not, then no further action need be taken. However if they are, then I would like to learn more about this, since it seems to me that exactly the same risk must exist in CSS, and therefore there may be some off the shelf potential mitigations available.

More information about the potential concern: the condition attribute supports queries including media queries. All the external resource elements, audio, image, source etc support this condition attribute. Therefore it would be possible, while processing a TTML2 document, to request a URL from a remote origin based on the result of a media query, thus providing information to that origin. This is effectively the same functionality as CSS Media Queries provides – see https://drafts.csswg.org/mediaqueries-4/#priv-sec and https://github.com/w3c/csswg-drafts/issues/3488 for example. The CSS3 Media Query Rec at https://www.w3.org/TR/css3-mediaqueries/ from 2012 does not include any security and privacy section.

[css-meeting-bot]

The Timed Text Working Group just discussed Add consideration for font fingerprinting w3c/ttml2#1203, and agreed to the following:

• RESOLUTION: Rename "Font Matching" to "Font Detection".
• RESOLUTION: Detections based on condition attribute need not be factored into this pull request.

The full IRC log of that discussion

<nigel> Topic: Add consideration for font fingerprinting w3c/ttml2#1203
<nigel> github: https://github.com/w3c/ttml2/pull/1203
<nigel> Nigel: 2 things outstanding.
<nigel> .. 1. Change "Font Matching" title to "Font Detection"
<nigel> .. Any views against calling the section "Font Detection"?
<nigel> Glenn: Fine with me
<nigel> Pierre: No objection, and I'm happy for me or someone else to make that change.
<nigel> .. I can do it right now.
<nigel> RESOLUTION: Rename "Font Matching" to "Font Detection".
<nigel> Nigel: The next one is about other detections using `condition`.
<nigel> .. First question: any counter-views to my recent conclusion that condition does not
<nigel> .. provide any further ability to detect fonts than what is already written in this pull request?
<nigel> Glenn: Note we can conditionalise on user's preference for language, which may not apply
<nigel> .. to, say, CSS media queries.
<nigel> Pierre: Yes, you could conditionalise an image based on someone's user preference so
<nigel> .. you could determine user preference based on the request for an image.
<cyril> RRSAgent, pointer
<RRSAgent> See https://www.w3.org/2020/06/04-tt-irc#T15-14-16
<nigel> Glenn: It would have to be heuristic based and it is possible to fail a variety of modes.
<nigel> Pierre: Yes, and it doesn't change my overall perspective that trying to solve this complex
<nigel> .. topic that potentially requires coordination, normatively, at the last minute, would lead to
<nigel> .. a mistake.
<nigel> .. I would keep it simple.
<nigel> Nigel: I don't think I'm not suggesting a normative change.
<nigel> Pierre: I don't object to adding condition but someone would have to propose the text.
<nigel> Glenn: My preference would be to defer treating condition, which is something Nigel
<nigel> .. raised. If we try to agree on it now then we need language, and agreement on it, and
<nigel> .. that will open up the discussion further. This feeds into Pierre's point that it is a wider
<nigel> .. broader issue and we're likely to get it wrong if we address it at the last minute.
<nigel> Pierre: We could make a generic statement. As soon as a document allows access to external
<nigel> .. resources the fingerprinting risk increases.
<nigel> Glenn: That depends on the delivery mechanism, a prepackaged carousel vs on demand.
<nigel> .. It depends on the context to know if it is an issue.
<nigel> Pierre: Yes and on top of that the particular implementation provides heuristics.
<nigel> Glenn: That's why I think it's in the application environment, outside the scope of TTML.
<nigel> Nigel: Focusing tightly on this pull request, is there some additional fingerprinting risk
<nigel> .. for font matching derived from condition?
<nigel> Glenn: I pointed out that user preference language can be used, which can be used to make
<nigel> .. decisions about font defaulting.
<nigel> .. Let's say the user's default is Mongolian, for example. An implementation might look at
<nigel> .. the font list and throw out any fonts that don't support Mongolian, for example, and never
<nigel> .. do fetches on them.
<nigel> Nigel: And that would be caused by the condition attribute and not by the font element?
<nigel> Glenn: Let's say you conditionalised a style element or declaration based on user language
<nigel> .. preference and then that style happens to be the one that specifies a fontFamily attribute.
<nigel> .. You might have different values for fontFamily depending on the condition.
<nigel> Nigel: And that's independent of font, so you could do the same thing based on fetching
<nigel> .. any external resource even not a font, also based on the user's language preference.
<nigel> Glenn: Correct.
<nigel> .. Resource fetching is a known mechanism for communicating usage back to a server.
<nigel> .. Non-resource-fetching semantics such as presentation without fetching would have
<nigel> .. no route back to the server.
<nigel> Nigel: My conclusion is that there may be a need for a new issue or pull request related
<nigel> .. to condition but it should not block this pull request. Is that correct?
<nigel> Glenn: No objections from me.
<nigel> Pierre: I agree too.
<nigel> RESOLUTION: Detections based on condition attribute need not be factored into this pull request.
<nigel> Nigel: Then thank you Pierre for volunteering to update the pull request for the section
<nigel> .. title, when that's done I think we can go ahead and merge.

[nigelmegitt]

@samuelweiler @npdoty The TTWG has consensus to merge this PR. Are you in agreement that it resolves the issue to the best that we can get to at this stage? This does not prejudice us against making more normative statements in future editions, should we get agreement to do so.

[skynavga]

Per https://github.com/w3c/ttml2/pull/1203#issuecomment-638923838 (see last sentence), we have approvals and consensus for merging.

[nigelmegitt]

Per #1203 (comment) (see last sentence), we have approvals and consensus for merging.

@skynavga That was a TTWG resolution, but in https://github.com/w3c/ttml2/pull/1203#issuecomment-638984684 I asked for the non-TTWG members who raised/commented on the issue for their view, with the intent of not merging before we had confirmation. If there are further comments we may now need to open a new pull request and review cycle: I had been hoping to avoid that; it may still not be needed of course.

[samuelweiler]

@samuelweiler @npdoty The TTWG has consensus to merge this PR. Are you in agreement that it resolves the issue to the best that we can get to at this stage? This does not prejudice us against making more normative statements in future editions, should we get agreement to do so.

No. As in https://github.com/w3c/ttml2/pull/1203#discussion_r438418061, I think a normative mitigation is in order.