Re: Security and Privacy Considerations section for WebVTT, comments please!!

We should turn this into a pull request on github. I think it's a great start!

Cheers,
Silvia.

On Sat, Nov 19, 2016 at 6:23 AM, David Singer <singer@apple.com> wrote:
> one minor clarification in response to feedback received
>
>> On Nov 15, 2016, at 11:33 , David Singer <singer@apple.com> wrote:
>>
>> Hi
>>
>> it’s way overdue for WebVTT to have a security and privacy considerations section.
>>
>> I have taken the TAG and PING questionnaires, and seen what they provoke, and then below I offer the beginning of a security and privacy considerations section.  Comments welcome.  I have cc’d the Privacy Interest Group (PING!) in case they have comments or suggestions.
>>
>> Most of these questions are more applicable to protocols than to formats, so I have answered them as not applicable (N/A).  Please chip in if you see something that I do not.
>>
>> Questions 3.x are from the TAG.  <https://www.w3.org/TR/security-privacy-questionnaire/>
>> Questions Px are from PING.  <https://www.w3.org/wiki/Privacy_and_security_questionnaire>
>>
>>       • 3.1 Does this specification deal with personally-identifiable information?
>>       P2 Does this specification collect personally derived data?
>>       P3 Does this specification generate personally derived data, and if so how will that data be handled?
>>       P7 Does the standard utilize data that is personally-derived, i.e. derived from the interaction of a single person, or their device or address?
>>
>> Only inasmuch as the desire for captions/sub-titlles (i.e. accessing the content at all) might indicate that the user wants/needs them.  No collection is performed.
>>
>>       • 3.2 Does this specification deal with high-value data?
>>
>> no
>>
>>       • 3.3 Does this specification introduce new state for an origin that persists across browsing sessions?
>>
>> no
>>
>>       • 3.4 Does this specification expose persistent, cross-origin state to the web?
>>
>> no
>>
>>       • 3.5 Does this specification expose any other data to an origin that it doesn’t currently have access to?
>>
>> no
>>
>>       • 3.6 Does this specification enable new script execution/loading mechanisms?
>>
>> It is possible to embed (and hence link to) CSS style sheets, so the security/privacy considerations of CSS apply, when the VTT user-agent supports CSS.  If there is a user-side style-sheet, it’s possible that it will be possible to detect that it is in effect.
>>
>> It is also possible to use VTT to pass cues that are ‘triggers’ to a script (though VTT does not, itself, provide the script). The security/privacy considerations of the script and scripting system then apply.
>>
>>       • 3.7 Does this specification allow an origin access to a user’s location?
>>       P4 Does this specification allow an origin direct access to a user’s location, and if so is that information minimized?
>>
>> no
>>
>>       • 3.8 Does this specification allow an origin access to sensors on a user’s device?
>>
>> no
>>
>>       • 3.9 Does this specification allow an origin access to aspects of a user’s local computing environment?
>>
>> See above under 3.6
>>
>>       • 3.10 Does this specification allow an origin access to other devices?
>>
>> no
>>
>>       • 3.11 Does this specification allow an origin some measure of control over a user agent’s native UI?
>>
>> Only inasmuch that captions/subtitles are presented.
>>
>>       • 3.12 Does this specification expose temporary identifiers to the web?
>>
>> no
>>
>>       • 3.13 Does this specification distinguish between behavior in first-party and third-party contexts?
>>
>> no
>>
>>       • 3.14 How should this specification work in the context of a user agent’s "incognito" mode?
>>       P5 How should this specification work in the context of a user agent’s "incognito" mode?
>>
>> Not applicable.
>>
>>       • 3.15 Does this specification persist data to a user’s local device?
>>
>> no
>>
>>       • 3.16 Does this specification have a "Security Considerations" and "Privacy Considerations" section?
>>       P1 Does this specification have a "Privacy Considerations" section?
>>
>> It will, once we have finished this
>>
>>       • 3.17 Does this specification allow downgrading default security characteristics?
>>
>> no
>>
>>       P6 Is it possible to spoof/fake the data being generated for privacy purposes?
>>
>> n/a
>>
>>       P8 Does the data record contain elements that would enable re-correlation when combined with other datasets through the property of intersection (commonly known as "fingerprinting”)?
>>
>> n/a
>>
>>       P9 Does the data record contain elements that would enable re-correlation when combined with other datasets through the property of intersection (commonly known as "fingerprinting”)?
>>
>> n/a
>>
>>       P10 Is the user likely to know if information is being collected?
>>
>> n/a
>>
>>       P11 Can the user easily, preferably through an element of the GUI, revoke consent granted to a particular feature?
>>
>> n/a
>>
>>       P12 Once consent has been given, is there a mechanism whereby it can be automatically revoked after a reasonable, or user configurable, period?
>>
>> n/a
>>
>>       P13 Does this standard utilize strong end to end encryption?
>>
>> The delivery protocol used is out of scope.
>>
>> * * * DRAFT * * *
>>
>> X Security and Privacy Considerations
>>
>> X.1 Text-based format security
>>
>> As with any text-based format, it is possible to construct malicious content that might cause buffer over-runs, value overflows (e.g. string representations of integers that overflow a given word length), and the like. Implementers should take care that over-long lines,  field values, or encoded values do not cause security problems.
>>
>> X.2 Styling
>>
>> VTT can embed style ‘snippets’, and they in turn can cause the loading of external style sheets
>
> through the use of a CSS “@import” rule
>
>> , in user-agents that support CSS.  Under these circumstances, the security and privacy considerations of CSS apply.  In addition, it is possible for a user-agent to offer user style-sheets, and their presence and nature might be detectable by scripts running in the same user-agent (e.g. browser). This might enable fingerprinting of the user or reveal aspects of the user’s preferences (e.g. the choice of a large font size and/or high-contrast colors might indicate a user with visual impairments).
>>
>> X.3 Scripting
>>
>> VTT does not include or enable scripting. However, it is possible to construct and deliver a file that is designed not to present captions or subtitles, but instead to provide timed input (‘triggers’) to a script system. A poorly-written script or script system might then cause security or other problems; however, this consideration really applies to the script system.  Because VTT supplies these triggers at their timestamps, a malicious file might present such triggers very rapidly, perhaps causing undue resource consumption.
>>
>> X.4 Privacy of preference
>>
>> A user-agent that selects, and causes to download or interpret a VTT file, might indicate to the origin server that the user has a need for captions or subtitles. That is a (small) piece of information about the user. However, the offering of a caption file, and the choice whether to retrieve and consume it, are better viewed as characteristics of the format or protocol which does the offer (e.g. the HTML <source> element), rather than of the caption format itself.
>>
>>
>>
>> David Singer
>> Manager, Software Standards, Apple Inc.
>>
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
>

Received on Monday, 21 November 2016 11:38:42 UTC