Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mention fingerprinting vectors in privacy considerations. #1189

Closed
jyasskin opened this issue Dec 19, 2019 · 14 comments
Closed

Mention fingerprinting vectors in privacy considerations. #1189

jyasskin opened this issue Dec 19, 2019 · 14 comments
Assignees
Labels
agenda editorial pr merged privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. WR-pending
Milestone

Comments

@jyasskin
Copy link
Member

If TTML is implemented natively in a user agent, it could expose fingerprinting vectors that aren't otherwise exposed. The spec should mention this risk so native implementations know to make intentional choices. The things I noticed to call out are:

  • Anything that's "implementation dependent" might be a fingerprinting vector.

    • Many initial style values are defined by the specification, so they wouldn't reveal anything. However, <tts:color> and some others are described as implementation-dependent.
  • A user's preference for how fast they consume media (e.g. 2x vs 2.5x).

  • The request for timed text indicates the user's language (which is also exposed in other ways) and that the user wants captions or subtitles (which isn't).

  • The tts:fontFamily attribute could expose the system's fonts and should use the same restrictions as CSS.

  • The <audio> and <image> elements probably allow the server to detect the value of any <condition> expression. Many of the condition-functions seem to be already exposed by CSS media queries. The supports-functions probably don't expose any more than the UA string. So this may only be extra fingerprinting surface for UAs that aren't also general web browsers. However, if one of these functions exposes a user preference or device attribute, that would be extra fingerprinting surface.

  • ttp:clockMode==local probably reveals the local time zone, if only by the timing of embedded resource requests. ttp:timeBase==clock reveals clock skew in the same way.

  • If there's a way to pull out a display frame rate, that would also help fingerprinting.

@skynavga skynavga changed the title Mention fingerprinting vectors in privacy considerations Mention fingerprinting vectors in privacy considerations. Jan 10, 2020
@skynavga
Copy link
Collaborator

skynavga commented Jan 10, 2020

Just noting that all of the above comments except for the second to last (related to audio and image elements and the @condition attribute) pertain to TTML1 and TTML2 in general, and that the remaining comment pertains to TTML2 in general. Though not necessarily addressed individually, many of these comments are covered indirectly by the remarks found in TTML2 First Edition Appendix P Security and Privacy Considerations.

@nigelmegitt
Copy link
Contributor

Thanks for that @skynavga - I took an action to respond during last week's call, but I think you've said what I was going say, near enough.

@skynavga
Copy link
Collaborator

In that case, the only question that remains is how to label this issue and what (if any milestone to associate it with). Could you consider the possible WR-* labels and choose one as well as a milestone?

@nigelmegitt
Copy link
Contributor

I think we are saying we will consider an informative change to Appendix P to call out audio and image in conjunction with @condition at some point, possibly in Proposed Rec or in a later edition.

@skynavga
Copy link
Collaborator

That sounds reasonable. I shall create a 2ED-PR milestone and mark this as such for the time being.

@skynavga skynavga added this to the 2ED-PR milestone Jan 16, 2020
@skynavga skynavga self-assigned this Jan 16, 2020
@plehegar plehegar added the privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. label Feb 10, 2020
@skynavga skynavga modified the milestones: 2ED-PR, 2ED-CR2 Feb 19, 2021
@skynavga
Copy link
Collaborator

Resolved per WG resolutions and publishing of 2ED-CR2.

@nigelmegitt
Copy link
Contributor

@jyasskin please confirm that the merged change at #1203 that has now been published as CR2 does indeed represent an improvement.

@jyasskin
Copy link
Member Author

Thanks for pinging me.

#1203 is definitely an improvement, but it only addresses one of the possible vectors in the initial comment. I haven't done a full diff between the two editions, so I might have missed where the others are mentioned.

I do see, for example, "A content processor that downloads external resources during media playback indicates to the origin server of the resource the progress of the user's media consumption." in https://www.w3.org/TR/2021/CR-ttml2-20210309/#d3e59107, which waves toward the fingerprintable preference about playback speed, but it'd be nice to explicitly say how this is sensitive.

https://www.w3.org/TR/2021/CR-ttml2-20210309/#d3e59187 covers the user's preference for fetching captions or subtitles.

I don't see any mention of the "implementation dependent" properties or the clock attributes in the privacy section.

@css-meeting-bot
Copy link
Member

The Timed Text Working Group just discussed TTML2 Mention fingerprinting vectors in privacy considerations. #1189, and agreed to the following:

  • SUMMARY: @nigelmegitt to review the vectors in detail and propose how to resolve any gaps.
The full IRC log of that discussion <nigel> Topic: TTML2 Mention fingerprinting vectors in privacy considerations. #1189
<nigel> github: https://github.com//issues/1189
<nigel> Nigel: This issue has been closed, but was closed without confirmation from the issue raiser that they were satisfied.
<nigel> .. @jyasskin responded to say that he considers some parts of the original issue not to have been addressed.
<nigel> .. The original analysis from Glenn was that most of the issues are already in TTML1 and several are covered in general by the
<nigel> .. appendix on security and privacy considerations.
<nigel> .. What we need to decide is if we think the current text is adequate given this Horizontal Review comment, or if we can and should
<nigel> .. call out specific possibilities as per the issue.
<nigel> .. I'd suggest if we do call out the possibilities we do them as "for example" style notes.
<nigel> .. Any views?
<nigel> .. Looking at the current CRS Privacy section, I think some of the vectors are already covered but maybe not in detail.
<nigel> .. I'll go through each of the listed vectors and show where it is, or if it is not mentioned, and come up with a proposal for addressing the resulting gaps.
<nigel> .. Make sense?
<nigel> Pierre: I suspect we're going to have this discussion again where the commenter wants us to be more explicit than we have wanted to be in the past.
<nigel> .. I'm not sure how we resolve it. It is a larger architecture issue. What you're proposing is a good idea, but we have to be prepared to
<nigel> .. have the broader discussion again about whether every single W3C specification has really specific implementation recommendations or
<nigel> .. if there should be a central spec.
<nigel> Nigel: I'm comfortable listing the considerations that apply specific to the domain of TTML, and I don't think this issue is asking for more than that.
<nigel> SUMMARY: @nigelmegitt to review the vectors in detail and propose how to resolve any gaps.
<nigel> Nigel: I will also reopen this issue.

@nigelmegitt
Copy link
Contributor

I have reviewed the vectors described in the issue as per my action and concluded:

Color preference

The fact that default values for color are implementation dependent does not in itself provide any information. There is no mechanism defined in TTML for querying the used value of color. If some implementation uses e.g. Javascript and CSS, then of the resolved value of the color property returned by getComputedStyle() is the used value, however there is no requirement to use such a technique, and it is out of scope of TTML2 to cover those details, which themselves are features of other W3C specifications.

No action to take.

Playback speed preference

Already covered in P.3 Resource Fetching

No action to take.

Language and need for captions preference

Already covered in P.9 Privacy of Preference

No action to take.

Font Family

Discussed extensively and covered in P.10 Font Detection

External resource fetching exposing <condition> results

Partially covered in P.7 Access to Processing State, but could be strengthened

ACTION: Add to P7 that if conditions expose user preference or device attribute then this increases the fingerprinting surface.

clockMode could reveal fingerprinting vector of time zone or clock skew

This is not explicitly covered.

ACTION: Add a note about this P.3 Resource fetching.

display frame rate as fingerprinting vector

There is no such mechanism. By reference, media queries are supported, but there is no media query for frame rate. However all media queries are delegated, and this could be made clearer.

ACTION: Add a note to P.7 noting that the set of media queries is defined externally and that any privacy concerns listed there could be applied here too.

@css-meeting-bot
Copy link
Member

The Timed Text Working Group just discussed Mention fingerprinting vectors in privacy considerations. w3c/ttml2#1189, and agreed to the following:

  • SUMMARY: @nigelmegitt listed the proposed changes and highlighted them to the group for consideration
The full IRC log of that discussion <nigel> Topic: Mention fingerprinting vectors in privacy considerations. #1189
<nigel> github: https://github.com//issues/1189
<cpn> scribe+ cpn
<cpn> Nigel: I've reviewed the fingerprinting vectors just before today's meeting
<cpn> ... I came up with 3 actions, all to add notes to the Privacy section
<cpn> ... [describes the actions in https://github.com//issues/1189#issuecomment-829305696]
<cpn> Glenn: Do any of those involve change to the font fingerprinting text?
<cpn> Nigel: No, they're just adding points to P7 and P3. It doesn't modify P10
<cpn> Nigel: I'm happy to draft a PR, unless someone else wants to
<nigel> scribe: nigel
<nigel> SUMMARY: @nigelmegitt listed the proposed changes and highlighted them to the group for consideration

nigelmegitt added a commit that referenced this issue May 12, 2021
Fulfils the actions described at #1189 (comment) by noting:

* Fingerprinting via clock skew and time zone
* Increased fingerprinting surface of external resource fetching in combination with condition
* Potential for future media queries to reveal additional information.
@nigelmegitt
Copy link
Contributor

I've opened #1231 to fulfil the actions listed at #1189 (comment)

@css-meeting-bot
Copy link
Member

The Timed Text Working Group just discussed Mention fingerprinting vectors in privacy considerations. w3c/ttml2#1189, and agreed to the following:

  • SUMMARY: Group to review as per normal process
The full IRC log of that discussion <nigel_> Topic: Mention fingerprinting vectors in privacy considerations. #1189
<nigel_> github: https://github.com//issues/1189
<nigel_> Nigel: Just to note I opened a pull request for this yesterday.
<nigel_> -> https://github.com//pull/1231 Pull Request: Add further fingerprinting considerations #1231
<nigel_> Nigel: That's open for review, please take a look.
<nigel_> .. The original commenter, Jeffrey Yasskin, gave a thumbs-up to the analysis I did 2 weeks ago, and this pull request implements that.
<nigel_> .. I see Glenn has already approved it.
<nigel_> .. It'd be good to get this merged in our normal 2 week period if we can to get this done and dusted.
<nigel_> SUMMARY: Group to review as per normal process

@skynavga
Copy link
Collaborator

Closed after 2nd merge.

himorin pushed a commit to himorin/ttml2 that referenced this issue Jul 14, 2021
Fulfils the actions described at w3c#1189 (comment) by noting:

* Fingerprinting via clock skew and time zone
* Increased fingerprinting surface of external resource fetching in combination with condition
* Potential for future media queries to reveal additional information.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
agenda editorial pr merged privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. WR-pending
Projects
None yet
Development

No branches or pull requests

5 participants