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

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.
>
> --------------------------------------------
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Received on Monday, 17 October 2016 16:09:14 UTC