Re: TTML2 and questionnaire for Security and Privacy; for review.

I will remove it and use previous version

⁣Thierry MICHEL. ​

Le 21 oct. 2016 11:36, à 11:36, Nigel Megitt <nigel.megitt@bbc.co.uk> a écrit:
>Thanks Thierry, I think that's going further than we need. The question
>simply asks for the absence/presence of the section, which the previous
>answer in the thread answered fully. I would stay with the previous
>answer
>unless you have a reason for being more expansive - maybe you've
>discussed
>this within the team?
>
>Nigel
>
>PS apologies this fell off my radar and I should have raised it on the
>agenda for yesterday's meeting.
>
>
>On 17/10/2016, 17:08, "Thierry MICHEL" <tmichel@w3.org> wrote:
>
>>I propose to add the following wording in section 3.16 (from the IANA
>>registration.)
>>
>>As with other XML types and as noted in IETF RFC 7303, XML Media
>Types,
>>Section 10, repeated expansion of maliciously constructed XML entities
>>can be used to consume large amounts of memory, which may cause XML
>>processors in constrained environments to fail.
>>
>>In addition, because of the extensibility features for TTML and of XML
>>in general, it is possible that "application/ttml+xml" may describe
>>content that has security implications beyond those described here.
>>However, TTML does not provide for any sort of active or executable
>>content, and if the processor follows only the normative semantics of
>>the published specification, this content will be outside TTML
>>namespaces and may be ignored. Only in the case where the processor
>>recognizes and processes the additional content, or where further
>>processing of that content is dispatched to other processors, would
>>security issues potentially arise. And in that case, they would fall
>>outside the domain of this registration document.
>>
>>Thierry
>>
>>Le 17/10/2016 à 18:00, Thierry MICHEL a écrit :
>>>
>>> Hi,
>>>
>>> Bellow are latest updated responses for review regarding TTML2, to
>>> answer the Self-Review Questionnaire: Security and Privacy
>>> https://www.w3.org/TR/security-privacy-questionnaire/
>>>
>>> I have incorporated Mike's comments and the discussion during our
>last
>>> telecon.
>>>
>>> I have look for security issue in SMIL
>>> https://www.w3.org/TR/2008/REC-SMIL3-20081201/
>>>
>>> I couln't find any security issues mentioned.
>>>
>>> Looking at SVG 1.1 (Second Edition)
>>> https://www.w3.org/TR/SVG/single-page.html
>>>
>>> There is a section about security issues
>>> https://www.w3.org/TR/SVG/single-page.html#chapter-mimereg
>>> Security considerations:
>>>
>>> [ ...
>>>  Several SVG elements may cause arbitrary URIs to be referenced. In
>this
>>> case, the security issues of [RFC3986], section 7, should be
>considered.
>>>
>>> In common with HTML, SVG documents may reference external media such
>as
>>> images, audio, video, style sheets, and scripting languages.
>Scripting
>>> languages are executable content. In this case, the security
>>> considerations in the Media Type registrations for those formats
>shall
>>> apply.
>>>
>>> ..]
>>>
>>> Should we consider someting similar  for 3.6 question ?
>>>
>>>
>>>
>>> Thierry
>>>
>>> ----------------------------------------
>>>
>>> Questions to Consider:
>>> 3.1 Does this specification deal with personally-identifiable
>>>information?
>>> --> NO it doesn't.
>>>
>>> 3.2 Does this specification deal with high-value data?
>>> --> NO it doesn't.
>>>
>>> 3.3 Does this specification introduce new state for an origin that
>>> persists across browsing sessions?
>>> --> NO it doesn't.
>>>
>>> 3.4 Does this specification expose persistent, cross-origin state to
>the
>>> web?
>>> --> NO it doesn't.
>>>
>>> 3.5 Does this specification expose any other data to an origin that
>it
>>> doesn¹t currently have access to?
>>> --> NO it doesn't.
>>>
>>> 3.6 Does this specification enable new script execution/loading
>>> mechanisms?
>>> -->  This question as worded is ambiguous to us; is it only about
>script
>>> loading and script execution ?
>>> In our case, a TTML2 document in which a change in the value of an
>>> externally passed in parameter or a media query (for example) may
>cause
>>> a modification of behavior, and this may lead to the loading of
>external
>>> resources including audio, images etc, though excluding scripts. We
>do
>>> not consider "condition" mechanism to be a scripting language.
>>> TTML2 allows loading of resources, just not scripts, and has fetch
>>> semantics by the introduction of external resource loading. It also
>>> allows the addition of links on spans that can have hyperlinks.
>>>
>>> Futhermore <set> is arguably a (very specialized) script?
>>> Tthe animation vocabulary is declarative rather than procedural, it
>has
>>> generally been considered non-script (in SMIL, SVG, etc).
>>> @@@@@@@@@@@@@ to be finalized @@@@
>>>
>>> 3.7 Does this specification allow an origin access to a user¹s
>location?
>>> --> NO it doesn't.
>>>
>>> 3.8 Does this specification allow an origin access to sensors on a
>>> user¹s device?
>>> --> NO it doesn't.
>>>
>>> 3.9 Does this specification allow an origin access to aspects of a
>>> user¹s local computing environment?
>>> --> NO it doesn't.
>>>
>>> 3.10 Does this specification allow an origin access to other
>devices?
>>> --> NO it doesn't.
>>>
>>> 3.11 Does this specification allow an origin some measure of control
>>> over a user agent¹s native UI?
>>> --> NO it doesn't.
>>>
>>> 3.12 Does this specification expose temporary identifiers to the
>web?
>>> --> NO it doesn't.
>>>
>>> 3.13 Does this specification distinguish between behavior in
>first-party
>>> and third-party contexts?
>>> --> NO it doesn't.
>>>
>>> 3.14 How should this specification work in the context of a user
>agent¹s
>>> "incognito" mode?
>>> --> This specification has no impact on any incognito mode since the
>>> answer to all the questions about exposing details to origins are
>"No".
>>>
>>> 3.15 Does this specification persist data to a user¹s local device?
>>> --> User agents may choose to cache referenced external resources;
>this
>>> implementation detail is not covered by this specification and the
>>> specification makes no explicit requirement for caching or
>non-caching
>>> of any external resource.
>>>
>>> 3.16 Does this specification have a "Security Considerations" and
>>> "Privacy Considerations" section?
>>> --> YES it does. See the media type registration which is an
>integral
>>> part of it.
>>>
>>>
>>> http://www.iana.org/assignments/media-types/application/ttml+xml
>>>
>>> @@@@
>>> https://www.w3.org/TR/ttml-profile-registry/
>>>
>>>
>>> 3.17 Does this specification allow downgrading default security
>>> characteristics?
>>> --> NO it doesn't.
>>>
>>> --------------------------------------------
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>