Meeting minutes
This meeting
Nigel: Today, we have a few IMSC issues, TTML2 IR, and starting at 1600 UTC, a joint
… session with some members of the PING.
nigel: pierre are you able to join for the 2nd hour?
pal: yes
nigel: any AOB?
IMSC 1.2
nigel: there were a couple of editorial PRs
… probably better to run them on the call
… I added them to our agenda
Note that the user can influence the document processing context
gitub https://github.com/w3c/imsc/pull/527
github: https://github.com/w3c/imsc/pull/527
nigel: if you go the PR, the preview and diff now appeared
… there is one note added to the D.2 appendix: MAUR considerations
… I provided some review comments that are now resolved
… I just want to make sure that more people look at it
pal: ideally the main commenter
… I don't think we can merge this until the main commenter's review
nigel: we need to make sure we have consensus among us also
… if it sounds good, we'll just go ahead with this text
… I'll go back to the APA
pal: we actually need them to participate
… I'm not happy merging this until we have clear feedback from them
nigel: agree, we can prompt the person or the group with the text that we agree on
… the commenter who raised it is W3C staff
atsushi: my personal opinion would be to ping them on GitHub
glenn: I would recommend closing due to lack of response
nigel: I will reach out to the commenter
nigel: nobody seems to have any other comment on it
SUMMARY: TTWG is happy with the current proposal and would like review by APA WG @michael-n-cooper
Address A11Y comments related to WCAG 2.1
github: https://github.com/w3c/imsc/pull/526
nigel: this PR is closing a couple of things
pal: I think there are things we need to talk about
pal: there is the issue raised by the APA related to updating reference to WCAG 2.1
… that's issue
… and also rewriting appendix D.1
… and reference success criteria instead of interpreting and indicate how to best address them with IMSC
… in the process of doing this, Nigel raised the question on an example provided in Appendix D.1
… Nigel reviewed it, suggested some changes
… I went back in time to find the history of this paragraph
… many eons ago
… I'm really reluctant to change it
… because we spent so much time on it and it's only an example
… my preference would be to add one more example
nigel: I'm not sure how it came as part of my review
… maybe because the changes are big
… I think the text came from J Birch after some debate
pal: What I've done editorially is to label it as an example
… if there is another example, we should add it
… but we should not touch the example anymore
nigel: it wasn't very clear what functional information means
… it doesn't seem to mention that you can use styling attributes to achieve the same thing
… it does not refer to using ttm:role to identify the kind of thing that the text is representing
… simply leaving the text as is in the PR and adding another example could work
pal: I'm happy to review proposed example
nigel: I will provide one
nigel: I like the "suggestion" feature in the current PR, it's a new GitHub feature
pal: I have a question out to the commenter
… I have asked a question on issue 521 and 522, 21 days ago and still waiting
nigel: we can't proceed because we are waiting for some answer
pal: 524 we said we will not make changes for it, we should close it
nigel: we can just leave that open because we took out the milestone
pal: so it's only 521 and 522 for which we are waiting for answers
nigel: back on 526, we have a way forward to resolve my comments
… I encourage everybody to have a look at it
… I think it will resolve the APA comments
pal: it could be a good template to solving the PING comments
… if they could come up with guidelines
… that we can reference
nigel: agree
imsc/rec
nigel: we had a conversation about it last week
… atsushi needed to take that to the team
… and I wanted to know where we are
atsushi: I thought to ask next week
nigel: because of our decision policy?
atsushi: I thought this was a recommendation from someone that we need to be secure on it
nigel: it's true that with our decision policy, someone could comment on it, but unlikely
atsushi: I was advised to wait some time after request to setup some difference link
… to avoid misoperation on our W3C systems side
… maybe Philippe's suggestion
nigel: I did not notice this
… if you need time before making the change, fine but let us know
atsushi: could happen next week
nigel: sounds good
TTML2 2nd Edition Implementation Report
nigel: there has been some activity by Glenn
… I did some review
… we are moving forward
… no particular test need agenda time
glenn: the only one that might is the one on line height and font strategy
nigel: 252
glenn: the previous one having to do with fontStrategySelection, a presentation test
… that was put in TTML2 1ed
glenn: it's about the impact of font strategy selection on line height
nigel: and that previous test has a description
… and because there is combined character it would be clear what will happen
glenn: that test that preexisted and this one rely on something that cannot be interoperably tested
nigel: in the original test, we made the assumption that the default font did not support combining characters
… we never verified that such a font exists
glenn: you had asked if we could construct such a font
… technically, yes, but that is some work
… I haven't signed up for
nigel: I've never done such things
… we should be reaching out to Vlad
glenn: there are tools in the Adobe Font Toolset that I've used in the past
… there are ASCII representation of the OpenType font that you can create
… and use these tools to "compile" the font
… I haven't signed up for the time to do that
glenn: the impetus is on the implementer to do that as part of their test setup
nigel: by relying on a font provided with an implementation, we can go ahead with this test
… in the same way that we did the 1st edition test on font selection strategy
… there is an action to adjust the test still
… that's marked in the issue
… line break present so that line height can be verified
… it would be good that having done that your implementation passes
glenn: other than that I don't have other comments
end of meeting
nigel: we have no other business
… let's end this part of the meeting
… 5 min break until we start
Meeting with PING
<nigel> Gary leaves, Nick and Pete arrive
nigel: Thank you again for the feedback you gave us on IMSC
… we could look at the details of the specific issues
… one thing that came through is
… that if there is a privacy issue of fetching things on the web
… why is that issue specific to IMSC
pal: Nigel posed the problem correctly
<npdoty> I’d be interested to learn about the accessibility approach as well, just as we are learning the most productive ways to conduct horizontal reviews and address those issues
pal: there is a generic privacy and security issue
… true across most if not all W3C specifications
… it'd be a lot better if these generic considerations were captured in a single document
… so that other don't repeat the same text, the same mitigation, ...
… has there been a discussion to have a generic document, just like APA WG did for accessibility?
pete: PING has authored a questionnaire
… and a fingerprinting guideline document
… because we are an interest group
… we cannot make anything normative
… it's very difficult to speak in very general case
… because many specs are different
pal: reading the long threat, is that the vulnerability that has been identified here is a generic fetch vulnerability
npdoty: there is maybe a more general threat
… we do have documentation in the fetch spec for that
… but more specifically, because of font and implementation of fallbacks
… you can learn information about a client
… that's fairly specific to TTML
pal: and CSS
npdoty: maybe CSS (but have a different way of specifying) and HTML
… we need to understand how fallback are done
… if you just used CSS, then there would not be any need to document anything
pal: the corollary to that is: is it the only issue identified?
npdoty: Jeffrey did a review of TTML
<npdoty> https://github.com/w3c/ttml2/issues/1189
npdoty: don't remember which edition
nigel: TTML2 2nd edition
npdoty: he opened an issue with a series of fingerprinting versions
… and in the process we opened secure transport issues
pal: should we do it in TTML?
npdoty: I opened the issue on IMSC because there was a change compared to the previous edition
… but it'd be good in TTML
nigel: we had some other feedback about accessibility from APA
… and they produce a set of requirements, the MAUR,
… and we had a section restating that, and based on the feedback we received
… we will change that to say: given requirement X, this is how you can do it in IMSC
… it'd be great to have privacy requirements
… and we would say how to achieve them in IMSC
… if we had an ability to do that, that would be super useful
… don't know if this is applicable to Privacy
npdoty: that would be a good goal
… ongoing work in the PING is trying to get more granular and specific
… if we can define that precisely, it would be easier for other specs
… we are not yet quite at that level of precision
… the document I edited gives guidelines to evaluate and some indication on how to mitigate
… but different specs have different ways of solving the problem
… we were not sure how IMSC fits in the web platform
… is it implemented by a Web browser, follows same origin ...
pal: you're going to find implementations that span the whole range
… from polyfills to embedded devices and web platform
glenn: the answer depends who you ask
… the browser community, like Google, that it's not part of the Web platform, for historical reasons
… the response to that is that for people who need to use TTML in the web, they have to use polyfills
… or use server-side mechanisms
pal: it's broader than that
… there are Android native apps
glenn: yes, wide range of responses
nigel: I agree
… different people define the web platform differently
pal: the pragmatic issue we have is
… if we agree on the attack vector (fetching)
… fetching taking into account locally installed fonts
… the next step is what are the mitigations
… what do we write in the spec
… point to "Mitigating ..."
… how do we close this issue?
pes: deciding on mitigation, we can provide guidance
… but it takes the expertise of this group to decide
… you can look at the CSS WG response
… it's a little bit outside of PING jurisdiction
pal: from an editor standpoint, we need to close the issue
… what would it take to close it to your satisfaction
npdoty: we have 3 issues open
… 2 on TTML and 1 on IMSC
… I agree with Pete that since you understand the diverse set of implementations
… you're in the best place to decide on the mitigation
… a good goal would be to have similar mitigation to what we are working on in CSS
… or at least point to that
… we don't want to have to be in the situation where this is solved in CSS and not in TT
… we have seen that in other groups
pal: this document is going to rec soon
… where is the concrete mitigation we can point to?
npdoty: you can choose one from the CSS WG
… or if you are not ready, just note that for implementers
… so that they know about that
pal: I'm looking for a reference
<npdoty> re: mitigating browser fingerprinting, guidance doc is: https://w3c.github.io/fingerprinting-guidance/
nigel: thanks for the link
nigel: is there a specific place in the CSS thread to point to
pes: no, the thread is not done, so nothing to point to
<npdoty> draft proposal to eliminate font-fingerprinting is ongoing here: https://github.com/w3cping/font-anti-fingerprinting
pes: I don't think there is a solution that you can point to
… it's not a copy/paste answer
nigel: the question about whether there is a vector here seems to come from the notion that the decision to fetch a remote font resource or not
… is conditional on installed font
… but in TTML and IMSC that semantics is not defined
… my assumption had been that if some text in a document makes use of a matching font which points to an external URL
… unconditionally, regardless of what is installed, the implementation must fetch it
… it might not be clear in the text
<npdoty> yes, that sounds like a feasible mitigation
nigel: but if it were, would that solve the concern ?
<Zakim> nigel, you wanted to mention the idea that we don't allow font fetching to be conditional at all in TTML2 and IMSC
<pes> (im just agreeing with nick)
pal: on the specific proposed mitigation
… I'm not sure that sufficient or wise because that would prevent caching
nigel: I did not say anything about caching
… cache is not relevant for fingerprinting but maybe I'm wrong
pal: the second you share any resource you give information to an attacker
… could be as subtle as timing, location ...
… not sure there is a silver bulllet, specific to IMSC
glenn: were you asking if we made lazy vs eager fetching in the spec would be a solution?
nigel: not sure I would characterize it as lazy vs. eager
<npdoty> unconditional as opposed to conditional
nigel: when you would do it is different from if you do it
nigel: in CSS, the font might not get fetched if installed
… but in TTML, we would dereference and use that, no dependency on installed font
glenn: I can't imagine that we would specify that
cyril: It could be a note to implementers,
… saying that if they are worried about fingerprinting then they could do that.
Glenn: Sure.
<npdoty> that’s true right now, but it’s not described, so implementers would have to discover the problem and the mitigation all individually
Glenn: I would object to trying to nail that down in the spec.
<pes> privacy is not an issue that can be pitched to implementors; w3c specs need to be private by default / definition
Glenn: I would not object to adding informative language, but getting
… agreement on that language might be problematic.
… We could always give carte blanche to any informative language because
… it doesn't matter, but on the other hand we've spent months
… on informative language in other cases.
Nigel: To clarify, Glenn, you would object to language that prohibits
<npdoty> not lazy vs eager, but unconditional vs conditional (as in nigel’s proposed mitigation)
Nigel: conditionally dereferencing on the basis of installed fonts?
Glenn: I'd object to normative language that nails down fetching semantics.
… I would also require careful scrutiny about referencing anything from CSS WG,
… and check if it has buy-in from browser vendors.
Cyril: 2 points.
… 1. If we want to be pragmatic and publish, maybe one proposal.
… Would it be acceptable to move this IMSC issue to TTML2 so we can address all
… the privacy issues in the context of TTML2 in general?
… 2. More broadly, this group also defines WebVTT so should we have a generic
… timed text privacy document and refer to it from all the specs?
<cyril> ack
Glenn: Could we publish that as an informative note? Doing so would take some time
… and would delay matters. That may be something for 3rd Ed for TTML2.
… We could only make small tweaks to 2nd Ed in whichever appendix it is.
… If you wanted something that all the docs refer to informatively you could publish
… a WG Note.
Pete: I take the point that every network request reveals something about the
… requestor, but there's a difference. For an image file, your browser doesn't check
… to see if it is present.
… In this case whether or not the browser makes the request reveals something about
… the environment. It's more specific than just network requests are revealing.
… I can understand why this is frustrating to the group, but if your spec is producing a
… new way to get fonts relative to the rest of the web platform then it is your responsibility
… to define the privacy aspects of the functionality.
… In general informative text is not a satisfactory way to address privacy concerns
… for exactly the reason stated, that they don't make any requirements on implementations.
Nick: To expand on Pete's second point there, we're coming back to the same question
… we had earlier on about what the level of innovation is compared to the rest of
… the web platform. I've heard some suggestions that these things are generic, so we should
… just do whatever everyone else does, but also suggestions that behaviour about how
… the markup is used will not be defined, or that we will not refer to CSS.
… I guess that will be a regular question that comes up - is this relying on CSS and Fetch
… or if it is not then it will need separate review.
… I do think there are different levels of mitigation.
… The first might be noting it so implementers are aware of the risks based on how
… the implementation is done, but I think Pete is wise to point out that we have had
… problems arising from that. That would be the first step though.
Pierre: My proposed course of action is a) move this issue to TTML2 because it is not
… specific to IMSC. And my proposal in TTML2 would be to note the potential privacy
… issue introduced by resource fetching, specifically font fetching, and suggest one
… potential mitigation, which is to suggest unconditional fetching. I'd like to hear if
… anyone strongly objects to this.
<cyril> cyril: I agree
Nigel: I agree
<pes> I object to non-normative mitigations
Glenn: As long as that's a mitigation suggestion up to the implementer that's fine.
<pes> for the reason stated here, that “non normative text doesnt matter” (someone in this groups on words)
Glenn: The other comment I had earlier for Pete was in response to requiring it to be normative,
… I firmly believe that W3C does not implement these specifications, and it does not
… certify implementations or test implementations. It does not mandate behaviour
<pes> thats WHATWG
Glenn: or these sorts of things, so I would certainly not agree with what you said about
… making these sort of things normative.
… Different groups in W3C might have different positions or opinions, but TTWG has
… defined a markup language that has been widely adopted in various industries.
… The web platform has at various points made use of TTML and many other industries
… have also, and have chosen to create other specifications adding further normative
… language about the use of TTML. If others want to add normative requirements in other
… specifications then they can do so. One has to make layering and abstraction decisions
… about where to put such language. So far we have not done so in TTML and I don't expect
… to in the future. That's my current opinion.
Pete: Not sure how to respond - W3C is a member org and our HR role is to make sure
… that things stay private!
<npdoty> that discussion can be ongoing, but I hope we don’t get to the general practice of having a separate spec for the privacy-preserving way of implementing each spec
Pete: More constructively perhaps, in the spec, if you say that when being implemented,
… as part of the web platform, then it should do X, Y and Z things to resolve fonts, and
… should not create new privacy harming paths, and when implemented as part of other
<pes> i second nicks point above
Pete: platforms it should do what those platforms do to preserve privacy.
Pierre: As Glenn pointed out it is going to be very hard for the TTML spec to tell browsers
<pes> is your group defining functionality that browsers are supposed to implement?
Pierre: what do. We can try to suggest mitigations, but I don't think it is realistic.
Glenn: We can put generic language suggesting something of that sort.
<npdoty> I’d be +1 on moving the issue to ttml, since it applies to ttml as well. i might recommend that imsc refer to the ongoing issue
Pierre: That was my recommendation, to clearly state the attack vector but it is not
… reasonable for us to tell web browsers normatively what to do.
… Even if I agreed with that, I don't think it's realistic.
<npdoty> isn’t it common to define conformance criteria for implementations?
Pete: In the last few moments I am suddenly confused. If it is not expecting web browsers
… to implement then we should say do what they do.
Glenn: We don't say anything about web browsers.
Pete: I thought the uncertainty was it seems to be a new way of resolving fonts.
Pierre: If it is implemented in a browser, why would it do anything other than what
… browsers do. One implementation of IMSC is a polyfill.
Pete: The only ask is to take a particular path when implementing through CSS or whatever
… else. It seems important that if people are polyfilling into web browsers they should do it correctly.
… You could either polyfill via the fetch engine and request fonts or go through CSS and
… request fonts that way.
Pierre: So the mitigation is?
Pete: My suggestion is to be specific about whether to implement polyfills through fetch or CSS.
… Then we can assess it.
Pierre: We can't assess all the implementations. Realistically we can't mandate all the
… ways they are implemented.
Glenn: For example you might use an implementation that converts to SVG and doesn't
… use CSS at all.
Pierre: Exactly. That's why we can say "here's the attack vector" and propose one kind of
… mitigation and recommend people use systems that have existing mitigations, but we
… can't go down the path of exploring all possible mitigations.
Pete: PING's remit is to address what is implemented in browsers.
… When it is implemented in browsers then it needs to say how it is implemented in browsers.
Pierre: Like in the case of Firefox, native C++ implementations?
Pete: Exactly.
Glenn: We don't define implementations period.
Pierre: Do you see that being useful in general, to say something specifically about how browsers should implement something in TTML?
Pete: I can't say that specifically, but what browsers do is the meat and potatoes of W3C.
<pes> i said _primarily_ concerned about browsers :)
Pierre: But WHATWG.
<npdoty> thanks, nigel, for chairing us and helping us to communicate
<npdoty> we have some different backgrounds and assumptions, so I know that isn’t always easy
Nigel: We're out of time here. I think we have managed to communicate something about
… what would help in terms of HR, and some proposed first steps for resolving the open
… issues on IMSC and TTML2.
… Thank you to Nick and Pete for joining us and helping us through this. It's been
… an energetic conversation!
Pierre: I will take the action to move the IMSC issue to TTML2 and propose a pull request.
Nigel: Thank you.
… Let's take those first steps and come back round to this as we need to.
… Thanks again everyone. [adjourns meeting]
<nigel> s|gitub https://github.com/w3c/imsc/pull/527||
<nigel> s| https://github.com/w3c/imsc/pull/527| https:XXgithub.comXw3cXimscXpullX527
<nigel> s/s|/sX
Apologies for the last three entries above - I don't know why those commands failed, but I'm giving up and leaving them in for now, hopefully to edit out later somehow!