privacy/security review of IMSC 1.2

Hi PING and TTWG folks,

I reviewed IMSC 1.2 for privacy- and security-relevant changes from IMSC 1.1. I think there are issues with TTML that would also apply to IMSC 1.2, regarding secure transports and font fingerprinting. Many of those fingerprinting-related issues were raised previously by Jeffrey Yasskin in his review in November.

PING has a call this Thursday if it would be useful to discuss these items synchronously. Or I’m happy to talk via email or a separate call in case it would be useful to hash out details outside the group call setting.

Hope this helps,
Nick

Some background:

PING had a call and provided some privacy review comments for TTML2 (1st Edition) in July 2017 [0] and November 2017 [1] and again on a Working Draft of TTML2 2nd Edition in November 2019 [2]. It's not clear from the email thread from November 2019 whether the comments that Jeffrey provided were resolved, but this issue on fingerprinting vectors [3] remains open on TTML2 (2nd Edition) (currently a Candidate Recommendation) and it sounds like the WG will resolve it at a later milestone just by noting the fingerprinting vectors in a non-normative appendix, rather than limiting the risk via design changes.

The particular spec under review here is IMSC 1.2 [4]; these are the profiles of TTML for text-only and image-only captions and subtitles for media. The Timed Text Working Group is interested in publishing a CR shortly, and note that they believe there should not be particular security or privacy issues beyond TTML2 [5]. It appears that IMSC 1.2 refers to and subsets TTML 2 (1st Edition) and *not* TTML 2nd Edition (which Jeffrey reviewed in November as noted above); I'm not sure why, but I assume the TTWG has reasons for maintaining these in parallel, despite the confusion for reviewers like us.

Like other privacy reviewers of TTML in the past, I'm not at all expert in timed text. As far as I know, TTML is not widely implemented in Web browsers and I'm not sure if I've ever used it personally. "Content processors" which do parse and render TTML documents loaded over the Web may have many similar properties to the Web privacy model we wish to promote in Web browsers, but I don't know much about common implementations.

## Significant changes in imsc 1.2

The authors note that the significant changes here are primarily the ability to indicate a particular font, loaded from an external resource, for rendering the text captions or subtitles.

### fonts are external resources

There are potential privacy issues in loading external resources, as noted in TTML2 (1st Edition) [6]: depending how fetches are handled by the content processor, this can "[indicate] to the origin server of the resource the progress of the user's media consumption." This is noted by reference so I'm not sure any changes are needed here.

### loading resources over insecure transport

The example suggests loading the external font resource over HTTP. Using insecure transports threatens the integrity of the content displayed to the user: even if the video and the TTML file are both delivered over HTTPS, loading a font over HTTP could lead to corruption or insertion of a misleading translation of the content. This would presumably also apply to image captions and subtitles loaded from external resources. We should note secure transport as a security and privacy issue in TTML 2 and TTML 2 (2nd Edition) and reference that from IMSC 1.2. That change could be: 1) requiring secure transport; 2) prohibiting mixed content; or 3) non-normatively noting the risks to confidentiality and integrity. 

It would be a good practice to use HTTPS as the scheme in examples throughout the specs.

### font fingerprinting

As Jeffrey noted in his November review, the use of the font matching algorithm from CSS Fonts Level 3 also introduces the fingerprinting issues with font selection. Inferring the list of installed fonts is a large fingerprinting vector and one where work is currently underway to mitigate the fingerprinting risk.

I'm less clear on whether the origin server can determine which font is selected by a content processor or what the rendered text looks like, which is the mechanism that creates the fingerprinting risk in the Web case. (Can the origin server obtain the rendered text in any way? Can it see the height or size of the region? Are there conditional requests based on which fonts are available or if a region is overflowed?) It would be useful for detailing the security and privacy properties whether origin servers had access to presented timed text beyond the loading of external resources. The risk wouldn't be greater for rendering IMSC profile documents more than TTML2 documents in general, but it would be new compared to IMSC 1.

## Summary

* I agree that there aren't large changes from the previous version of IMSC. 

* Noting the privacy and security impacts of secure transports seems like a clear improvement that can be made to this spec and to other TTML specs. 

* There are potential fingerprinting risks, when using just IMSC or using TTML more widely, and we'd need more info to detail whether users can be identified (and by whom) based on fingerprinting from TTML rendering.


[0] https://github.com/w3c/ttml2/issues/405
[1] https://github.com/w3c/imsc/issues/280
[2] https://lists.w3.org/Archives/Public/public-privacy/2019OctDec/0050.html
[3] https://github.com/w3c/ttml2/issues/1189
[4] https://w3c.github.io/imsc/imsc1/spec/ttml-ww-profiles.html
[5] https://lists.w3.org/Archives/Public/public-web-security/2020Feb/0002.html
[6] https://www.w3.org/TR/2018/REC-ttml2-20181108/#d3e56804


PING, this is my review for https://github.com/w3cping/privacy-reviews/issues/2

Received on Monday, 16 March 2020 21:26:34 UTC