{Minutes} TTWG Meeting 2020-04-02

Thanks all for the extra long two part call today. Minutes can be found in HTML format at https://www.w3.org/2020/04/02-tt-minutes.html


In text format:

   [1]W3C

      [1] https://www.w3.org/


                Timed Text Working Group Teleconference

02 April 2020

   [2]Previous meeting. [3]Agenda. [4]IRC log.

      [2] https://www.w3.org/2020/03/26-tt-minutes.html

      [3] https://github.com/w3c/ttwg/issues/105

      [4] https://www.w3.org/2020/04/02-tt-irc


Attendees

   Present
          Andreas, Atsushi, Cyril, Gary, Glenn, Nick_Doty, Nigel,
          Pete_Snyder, Pierre

   Regrets
          -

   Chair
          Gary, Nigel

   Scribe
          cyril_, nigel

Contents

    1. [5]This meeting
    2. [6]IMSC 1.2
    3. [7]Note that the user can influence the document processing
       context
    4. [8]Address A11Y comments related to WCAG 2.1
    5. [9]imsc/rec
    6. [10]TTML2 2nd Edition Implementation Report
    7. [11]end of meeting
    8. [12]Meeting with PING

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 [13]https://github.com/w3c/imsc/pull/527


     [13] https://github.com/w3c/imsc/pull/527


   github: [14]https://github.com/w3c/imsc/pull/527


     [14] 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: [15]https://github.com/w3c/imsc/pull/526


     [15] 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

   <nigel> [16]https://github.com/w3c/ttml2-tests/blob/master/

   presentation/valid/ttml2-prstn-font-selection-strategy.xml

     [16] https://github.com/w3c/ttml2-tests/blob/master/presentation/valid/ttml2-prstn-font-selection-strategy.xml


   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> [17]https://github.com/w3c/ttml2/issues/1189


     [17] 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: [18]https://w3c.github.io/fingerprinting-guidance/


     [18] 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: [19]https://github.com/w3cping/

   font-anti-fingerprinting

     [19] 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 [20]https://‌github.com/‌w3c/‌imsc/‌pull/‌527||


     [20] https://github.com/‌w3c/‌imsc/‌pull/‌527||


   <nigel> s| [21]https://‌‌github.com/‌‌w3c/‌‌imsc/‌‌pull/‌‌527|

   https:XXgithub.comX‌‌w3cX‌‌imscXpullX527

     [21] https://github.com/‌‌w3c/‌‌imsc/‌‌pull/‌‌527|


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


    Minutes manually created (not a transcript), formatted by
    [22]scribe.perl version 114 (Tue Mar 17 13:45:45 2020 UTC).

     [22] https://w3c.github.io/scribe2/scribedoc.html