Add consideration for font fingerprinting

[palemieux]

Closes #1202

[npdoty]

There was a suggestion in the past call that this could be a normative mitigation rather than just an example. E.g.

A content processor SHOULD NOT dereference external font resources conditionally on the presence of user-installed fonts, where that dereferencing could reveal information about the user's system or fingerprint the user.

Just a suggestion. Using SHOULD NOT might provide the flexibility for processor implementations that don't have end user privacy concerns, while still detailing an effective interoperable mitigation.

[skynavga]

We can't use SHOULD NOT in an informative appendix.

[npdoty]

Right, the suggestion was to include a normative mitigation. If the group wanted to do that, then this appendix could be changed to be normative, or the requirement would be added elsewhere.

[skynavga]

Note that there are likely to be objections to introducing any normative language at this juncture of the process. Of course, such changes could be entertained at a different point in future processes.

[samuelweiler]

@skynavga What is the substance of those potential objections?

[skynavga]

@samuelweiler since I will be the source of the objection, I can explain: there are two arguments, one technical, and another non-technical; the former is that any normative requirement or recommendation we could make in this regard would be untestable, since dereferencing occurs in the context of the application processing environment, which is wholly outside the scope of TTML; whether an implementer chooses to dereference an external font in the presence of a user installed font is a question for the implementor and not for TTML as we have specified it to date; TTML does not define the implementation with respect to resource fetch semantics or the privacy considerations the implementer ultimately decides to adopt; all we can do is take note of privacy issues, without going as far as making recommendations (SHOULD or SHOULD NOT); the second argument is based on process: namely, we (as a group) already decided not to introduce substantive changes after CR unless there was a clear technical breakage in a feature introduced in this CR; the subject of this issue is not related to any change introduced in TTML2 2nd Edition; existing privacy considerations in TTML are cast as non-normative, and I expect it to stay that way; lastly I should note, however, that my objecting will not necessarily prevent the group from adopting a normative change if the group chooses to override my objection; my counsel will be that such a change is ill-advised, unnecessary, and untestable;

[samuelweiler]

@skynavga Thank you for the explanation. The untestable argument does not sway me. A normative mitigation is in order here. Similarly, I am unpersuaded by the process argument. "We've always done it this way" doesn't fly with me as an excuse.

[skynavga]

@samuelweiler I'm not trying to persuade you of anything. You asked for the reason, and I gave you my answer. The current consensus of the WG is reflected in #1203 (comment).

[nigelmegitt]

@samuelweiler In my view testability is a Process requirement, or very close to it: in order to exit CR, implementability must be demonstrated, and that is in general done with tests. If we put untestable normative requirements into the spec then we can never demonstrate implementability. I will object to any change that prevents CR exit.

(background) In the past couple of years TTWG introduced a working practice of accompanying all substantive spec changes with tests at the time those spec changes are introduced, both so that the test suite does not lag behind the spec (making CR exit speedier) and so that the WG can better understand the intent of the spec change.

In this case the proposed normative change does affect semantics not defined by TTML, and writing a test for the change would be extremely challenging.

On the process point, I am less clear than @skynavga that the review scope is limited to changes introduced in this CR. I'm happy to be reminded, but I don't recall agreeing that, or making that part of the review request. I also think it is entirely reasonable for new issues to be raised against the spec, regardless of when they were introduced; however it is also reasonable for TTWG to defer issues raised against parts of the spec that were not changed by this CR.

[skynavga]

I accept the proposed changes as indicated here. I object to any further change that introduces the phrases "should" or "should not" or otherwise has the effect of changing this language and/or Appendix P to normative status.

[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 Add consideration for font fingerprinting #1203 (comment)
2. How best to articulate that other detections may be possible using the condition attribute, as per Add consideration for font fingerprinting #1203 (comment)

[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 w3c/csswg-drafts#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 #1203
<nigel> github: https://github.com//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 #1203 (comment) (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 #1203 (comment) 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 #1203 (comment), I think a normative mitigation is in order.