DAPT 2023-07-31 / 2024-11-07 > 2025-01-07

[nigelmegitt]

We prefers groups to run a self-review around the time of FPWD. See https://w3ctag.github.io/security-questionnaire/.

If you still want us to review your spec, please provide the information below.

In the issue title above add the document name followed by the date of this request.

• name of spec to be reviewed: Dubbing and Audio description Profiles of TTML2
• URL of spec: https://www.w3.org/TR/2023/WD-dapt-20230801/ - this is the dated version as requested, but since it is in WD, we may make changes to the undated version from time to time: it is not expected that they will impact on this review though.
• Does your document have an in-line Security Considerations section, ideally one separate from the Privacy Considerations? Yes
• Do you need a reply by a particular date? Ideally in time for us to consider the response at TPAC 2023.
• Please point to the results of your own self-review (see https://w3ctag.github.io/security-questionnaire/) - https://github.com/w3c/dapt/wiki/Considerations-for-the-Privacy-and-Security-Reviews
• Where and how to file issues arising? Please raise issues on https://github.com/w3c/dapt/issues
• Pointer to any explainer for the spec? https://github.com/w3c/dapt/wiki/DAPT-Explained - also the Introduction can be used as a form of Explainer.

Other comments:

We have built, actually or conceptually, on previous privacy reviews for TTML2 and IMSC to inform this.

[nigelmegitt]

Hey there, would appreciate an update on the likely timeline for this please, on behalf of TTWG.

[himorin]

@simoneonofri WG is waiting for your comment on security consideration section. Please give us any comment if you find.

[himorin]

hi @simoneonofri , may I ask about current status of this review request?

[simoneonofri]

Hello @himorin, @nigelmegitt,

First of all, thank you for your patience!

I've read the questionnaire, and considering it's a file format, with @innotommy, we've come up with a Threat Model for File formats:

• PLS: Parsing/Loading/Serializing
• CD: Compression/Decompression
• EEC: Embed Executable Code (e.g., scripts)
• LER: Links and external resources
• MM: Metadata manipulation
• DI: Data Integrity

You have already identified an issue related to embedding javascript into data: in the Questionnaire (EEC) and referencing the TTML2 Security and Privacy Section, so "importing" their Threat Model, so two questions (if you want to discuss this with an issue in your report):

• A specific one: is the data: issue related exclusively to DAPT or TTML2?
• A generic one: scrolling through the model above, are there items not considered? For example, the integrity?

Let me know if you prefer to discuss here or in a dedicated issue in your repo.

Thank you,

Simone

[nigelmegitt]

Hi @simoneonofri thank you for the review.

I am not sure what you mean about "embedding javascript into data:" - the point in the questionnaire (question 7) is that if implementations are written in javascript then they are likely to use underlying platform functionality to dereference any data: URLs into usable resources.

There is nothing in TTML2 or DAPT that supports execution of any javascript within the payload of data: URLs. Although TTML2 supports font resources in data: URLs (and font resources contain specialised code blocks), there is no requirement for support of those resources in DAPT.

I would suggest that DAPT's dependency on XML, the payload syntax constraints in DAPT and TTML, and the validation semantics of both, are adequate to conclude that data integrity has been considered.

[cconcolato]

My attempt at responding to @simoneonofri's questions:

is the data: issue related exclusively to DAPT or TTML2?

The data: feature is already part of TTML2. DAPT is just making use of it in the ways defined by TTML2.

A generic one: scrolling through the model above, are there items not considered? For example, the integrity?

PLS: Parsing/Loading/Serializing

DAPT is based on TTML2, which is based on XML, so the security concerns regarding PLS are those of XML languages.

CD: Compression/Decompression

I don't know if we should consider base64 encoding as a CD mechanism. In any case, base64 support is a feature of TTML2, nothing new in DAPT. Generally, I would say there is no specific CD consideration in DAPT. There could be CD considerations in the transport layer, like HTTP Transfer encoding but that is not specific to DAPT.

EEC: Embed Executable Code (e.g., scripts)

DAPT (and TTML2) does not allow embedding of executable code.

LER: Links and external resources

DAPT reuses the features of TTML2 that allow linking to external resources. It does not define any new one. The only use of TTML2 linking feature is for audio as indicated in the current Privacy section of the spec.

MM: Metadata manipulation

Can you elaborate on what this means?

DI: Data Integrity

Can you elaborate on what this means?

[himorin]

@simoneonofri thank you for your review and comments, I believe all questions are answered, and please let us know if you are satisfied or not. In addition to @nigelmegitt 's comment about data:, <data> of DAPT refers to TTML one, which is defined as <uri> to be resolved as xsd:anyURI, and its use is strictly limited as Data.class based on XML data model. Also in security and privacy consideration in TTML2 has a note that no script language in this area.

For 6 items from Threat Model, thank @cconcolato for giving analysis of DAPT, and it seems these items are better to be integrated into self-review material. I suppose it's still early phase for rebooted security group, but WGs would be happy to hear about any plan to update questionnaire with recent security considerations.

[simoneonofri]

ere is nothing in TTML2 or DAPT that supports execution of any javascript within the payload of data: URLs. Although TTML2 supports font resources in data: URLs (and font resources contain specialised code blocks), there is no requirement for support of those resources in DAPT.

@nigelmegitt thank you for the clarification :)

[simoneonofri]

My attempt at responding to @simoneonofri's questions:

Thank you :)

is the data: issue related exclusively to DAPT or TTML2?

The data: feature is already part of TTML2. DAPT is just making use of it in the ways defined by TTML2.

Ok, so in the questionnaire it was an example, and for that in the current considerations there is a reference to the security considerations of TTML2. It's a “way” (profile) of using that format?

In this sense, does it add components/functionality? In general, adding features could introduce vulnerability issues. That's why I ask. If there are new threats/vulnerabilities/attacks that can be made through DAPT, compared to TTML2.

A generic one: scrolling through the model above, are there items not considered? For example, the integrity?

PLS: Parsing/Loading/Serializing

DAPT is based on TTML2, which is based on XML, so the security concerns regarding PLS are those of XML languages.

Ok, great, thanks for the explanation, so as @nigelmegitt writes, it might make sense to reference that potentially there are various attacks/vulnerabilities/branches derived from the use of XML, same as you wrote for TTML2.

CD: Compression/Decompression

I don't know if we should consider base64 encoding as a CD mechanism. In any case, base64 support is a feature of TTML2, nothing new in DAPT. Generally, I would say there is no specific CD consideration in DAPT. There could be CD considerations in the transport layer, like HTTP Transfer encoding but that is not specific to DAPT.

I agree that base64 is ecoding. Thank you for the analysis, I think this

EEC: Embed Executable Code (e.g., scripts)

DAPT (and TTML2) does not allow embedding of executable code.

Ok!

LER: Links and external resources

DAPT reuses the features of TTML2 that allow linking to external resources. It does not define any new one. The only use of TTML2 linking feature is for audio as indicated in the current Privacy section of the spec.

Okay, thanks for the explanation. One direction is to include elements to verify the integrity of external files, such as the SRI. Does that make sense? Otherwise, it's out of scope. I've seen several vulnerabilities exploited by audio libraries, but they don't depend on DAPT.

MM: Metadata manipulation

Can you elaborate on what this means?

Of course, if there is metadata present (I would tell you internal to this format if we are talking about an XML base), if yes, what happens if it is manipulated (dates, timestamps, authors, etc.), for example, there are some attacks done by altering not so much the file itself but its metadata (to give an example, it was common practice to insert malicious payloads inside EXIF data, as well as to use them to get information that is not strictly necessary).

DI: Data Integrity

Can you elaborate on what this means?

Yes, then, if there's a mechanism to check whether or not when the file gets to the processor, it's been altered or not. Or if that issue is maybe delegated to another level (e.g., transport)

[simoneonofri]

@simoneonofri thank you for your review and comments, I believe all questions are answered, and please let us know if you are satisfied or not. In addition to @nigelmegitt 's comment about data:, <data> of DAPT refers to TTML one, which is defined as <uri> to be resolved as xsd:anyURI, and its use is strictly limited as Data.class based on XML data model. Also in security and privacy consideration in TTML2 has a note that no script language in this area.

himorin thank you, yes I think with a few more messages (if we need to even make a short call), we can get a good result and then propose a standardized structure of the section.

For 6 items from Threat Model, thank @cconcolato for giving analysis of DAPT, and it seems these items are better to be integrated into self-review material. I suppose it's still early phase for rebooted security group, but WGs would be happy to hear about any plan to update questionnaire with recent security considerations.

You brought up a very good point. I've already opened an issue about that, obviously from the experience we're having from these early reviews. I would appreciate it if you would support the change. On facilitating the Threat Model, it's definitely a goal of SING.