{Minutes} TTWG/PING meeting 2020-07-28

Thanks to all who attended yesterday's joint meeting to try to resolve w3c/ttml2#1202<https://github.com/w3c/ttml2/issues/1202>.

Our next step is to complete the changes we have consensus for, in TTML2 2nd edition, and beyond that, to look for more comprehensive mitigations in a future iteration of the specification.

Minutes can be found in HTML format at https://www.w3.org/2020/07/27-tt-minutes.html


In text format:

   [1]W3C

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


Timed Text Working Group + Privacy Interest Group joint Teleconference

27 July 2020

   [2]Agenda. [3]IRC log.

      [2] https://github.com/w3c/ttml2/issues/1202

      [3] https://www.w3.org/2020/07/27-tt-irc


Attendees

   Present
          Andreas, Atsushi, Glenn, Nigel, Philippe, Pierre, Sam

   Regrets
          -

   Chair
          Nigel

   Scribe
          nigel

Contents

    1. [4]General PING documentation
    2. [5]CSS font-matching algorithm may introduce fingerprinting
       issues w3c/ttml2#1202

Meeting minutes

  General PING documentation

   Glenn: Want to make sure we raise the general issue about a
   lack of PING documentation
   … on this area instead of a one-off basis.

   Sam: What need are the two documents [questionnaire + one other
   not scribed] not meeting?

   Glenn: I have not reviewed those.

   Pierre: The questionnaire is a questionnaire.
   … What would be awesome in my mind is something like the APA's
   concrete guidelines.

   Sam: Have you looked at the fingerprint guidance document?

   Pierre: Yes, I didn't recall it addressing this issue.
   … It would be really good if there were a single consistent
   document that does 90% of the
   … work to minimise the work of authors and the guesswork.

   Sam: And the questionnaire left you guessing too much?

   Pierre: As evidenced by this long thread.

   Sam: Not sure, seemed like the breakdown was at a different
   layer, on normative requirements
   … and testing.

   Pierre: If there was a general document, we could point to that
   and say "do that".
   … For accessibility for example, we don't repeat the
   requirements, but interpret them in the
   … context of TTML.
   … I'm just contrasting the process.

   Sam: Sure, okay, I will take that, not sure what I'll do with
   it, but look again and see if we
   … can do better in what we're providing for you.
   … Glenn, since you raised it, i'd encourage you to look at both
   documents.

   Glenn: I think the point is we don't want to repeat the
   information that is in the guidance
   … document and if the information in there is not complete or
   adequate, then to the extent
   … that it is general purpose and cannot cover our specific
   application area, we don't want to
   … be in the business of figuring that language out.
   … And we don't want to prevent you from making normative
   statements in your domain
   … where in our domain we want to qualify how we make use of our
   requirements.

   Sam: We may have different visions.

   Glenn: It's the reality of how we interact with different
   groups.

  CSS font-matching algorithm may introduce fingerprinting issues
  w3c/ttml2#1202

   Nigel: I think it would be useful to remind ourselves what the
   objectives are.

   Sam: Not opposed, but we may be able to address the two core
   issues without rehashing
   … everything.

   Nigel: Summarising those two core issues.

   Glenn: I think we have a higher level issue. The Group has a
   consensus to move ahead
   … with what we have right now; the problem Sam is to convince
   us to change our consensus

   Nigel: [interrupts as Chair] we're here to try to come to a
   resolution that has no objections.

   Philippe: What are the technical issues?

   Glenn: We cannot add a normative requirement that we cannot
   test.
   … The request is to normatively require implementers specifying
   how they make use of
   … installed fonts and if they are allowed to be used by the
   implementation for the purpose
   … of processing TTML content.
   … In all the TTML technology to date we place no constraints
   whatsoever on any use of
   … fonts. The specification has no concept of what fonts are
   available on the system.
   … Similarly to how a CSS implementation does not know what
   fonts are on the system,
   … it has font family names and those are mapped through some
   black box process that is
   … part of the implementation to font resources.
   … Recently we provided an explicit binding to downloadable
   fonts from font family names.

   <plh> [6]https://www.w3.org/TR/

   ttml2/#embedded-content-vocabulary-font

      [6] https://www.w3.org/TR/ttml2/#embedded-content-vocabulary-font


   Glenn: Even in that case it is still a black box in the sense
   that an implementation is free to map
   … font family names to any resource it wants to even in the
   presence of downloaded font
   … resources. The implementation is part of the document
   processing context which is
   … unspecified and out of the scope of the specification,
   traditionally. We have never tried
   … to undertake to define the document processing context in the
   way that, say, HTML5
   … tried to define the browser, e.g. fetch semantics and privacy
   considerations around those
   … fetch semantics. All those have been part of the
   implementation out of scope of the TTML
   … specification. This has been the first request to treat this
   in a normative fashion.

   Andreas: I think you started the right way Nigel in asking
   about the objectives, and that's
   … where we should start. We want to satisfy the objectives of
   PING, rather than being
   … lost in a formal discussion. Overall I have read from the
   comments that what you want to
   … do is guide implementers to make the right choice and protect
   the privacy of the user.
   … From the thread there is no dispute about the recommendation,
   just about the formal
   … expression of that recommendation. Nick Doty proposed a
   "should" keyword, which is
   … a recommendation, and he said that it would be good to add
   that a processor should not
   … dereference external font resources conditionally. There is
   argument about using normative
   … language, but not about using some text.
   … One proposal is to define the same meaning with a phrasing
   like "it is recommended not to..."
   … that would mean the same thing, but not be normative language
   formally.
   … I wanted to know how this relates to the objectives of PING.

   Glenn: [very quickly] I want to point out that we have a
   precedent of using SHOULD and
   … SHOULD NOT in non-normative parts of the specification, in
   Notes. As it turns out, we
   … can use those keywords in non-normative text and I have no
   objection to doing that.

   Sam: Thank you Andreas for answering the question I wanted to
   ask. It is good to know that
   … we are agreed on the outcome and are just discussing the way
   that we express it in the
   … specification.

   Philippe: Not all of the assertions in specifications can be
   tested. It is pretty common in
   … our specifications, mainly because we cannot properly test
   it. For example HTML is a
   … prime example about that, like chapter 5 was untested and is
   impossible to test. That was
   … about loading pages.
   … So the idea of a MUST that is untestable will not shock me or
   the Director. You just have
   … to explain the reason why you don't have a test.
   … The pull requests we have usually say you should have an
   accompanying test, these days,
   … or an explanation for why not.
   … I understand that the request is to prevent fingerprinting
   based on installed fonts by
   … getting an implementation to dereference the font URLs.
   … As an implementer I would like to know that I would put users
   at risk if I blindly
   … dereference fonts.
   … Even if we cannot test this normative statement it is still
   guidance we would like to give
   … to implementers.

   Nigel: I think this is about conditional deferencing

   Philippe: No, dereferencing a unique URL will identify you
   uniquely. You don't have to use cookies

   Pierre: 2 things. First, for the record, my objection to the
   proposed MUST language is that
   … we are really at the 11th hour, and as Philippe just
   mentioned there may be other
   … privacy considerations that should be taken into account. By
   rushing this we are likely
  … to make mistakes, and we should try to do it completely and
   properly in the next
   … iteration. I agree with Philippe that it is important to
   identify for implementers the
   … pitfall. I think the mitigation may not be the right one. I
   think we are trying to do too
   … much too quickly and will do more harm than good. Instead we
   should highlight the
   … pitfalls to implementers and put our thinking caps on and
   think about full mitigation
   … in the next revision. Thanks.

   Glenn: My point is that traditionally in specification areas we
   want to separate mechanism
   … from policy. What we're doing here is mixing up the two. To
   put something Pierre said
   … in more formal terms, we are putting both in one statement
   without carefully distingiushing
   … between them. The TTML mechanism is formally defined as a
   black box in the control
   … of the implementer. Potentially we are talking about imposing
   policy on the semantics
   … of that black box, which is an external behaviour.
   Formalising policy around that and
   … separating it out in an appropriate way is going to take time
   and we are not going to
   … do it quickly. It is for certain that we are not going to get
   it right in the context of the
   … current language in appendix P. That's why I was suggesting
   to Sam that if PING had a
   … document that describes a formalism for mechanisms that could
   be referenced by
   … other specifications that make use of such semantics and
   formalise policies in a coherent
   … way it would save a lot of nailbiting and gnashing of teeth
   in meetings like this. I continue
   … to hold my position that this is not the time or place to
   make the changes being proposed.

   <Zakim> weiler, you wanted to ask about 11th hour and for
   specifics about the harm PAL envisions

   Sam: I have a couple of responses to Pierre. You say "11th
   hour". At what point did you
   … enter the 11th hour? When would this have been more timely?

   Pierre: FPWD maybe?

   Sam: Can you throw a year or a date at it?
   … I'm wondering if the Dec 2019 PING review was already 11th
   hour?

   Pierre: Not sure where we're going with this. This was a small
   tweak. Some features were
   … deferred to a later edition because they were too late. It's
   not saying it's not a worthwhile
   … thing, just it is not a good match for this edition, without
   prejudice.

   Glenn: We introduced downloadable fonts a couple of years ago.

   Sam: Re the harm. I heard Pierre say this could do more harm
   than good. I'm puzzled by
   … that, wondering what harm is done by saying, now, "you
   SHOULD" mitigate this.

   Pierre: The suggestion is a SHALL not a SHOULD.

   Sam: I thought it was a SHOULD.

   Pierre: That makes a big difference in my mind. I don't have an
   objection to SHOULD.

   Andreas: Quickly, also concerning that point, what we are
   talking about is not a SHALL or
   … a SHOULD, but if it is normative language or not. What Nick
   proposed was a SHOULD.
   … That's an important point.

   Pierre: I still think it is a bad idea but if it is a SHOULD
   then it can be ignored.

   Andreas: Not getting caught up on procedure, we have the same
   objections, and need to
   … find some middle ground, not necessarily the optimal
   solution.
   … Two ways to do it:
   … 1. Normative language "SHOULD". It is often overread
   unfortunately.
   … I would say if you highlight it with non-normative language
   it may get more attention
   … for the developers to follow it, which should be our goal.
   … At the moment, our question is how to give implementers best
   guidance, and then what
   … we can do more. I think we should be able to find a solution
   on this call.
   … 2. was using non-normative language saying the same with
   non-normative language.

   Philippe: I heard plenty of good things here. We are talking
   about maintaining a Rec here.
   … The feature is not new - it was shipped in 2018 as a Rec. We
   should maintain our
   … specification and not block on a single issue. That's my
   philosophy on that.
   … Andreas is right - the only question is whether we should
   have a normative SHOULD or not.
   … I think Glenn and Pierre mentioned they could accept it.
   … Sam, at the end of the day, how much does it matter to PING?
   … Ideally we should be pointing to a document about
   dereferencing URLs, obviously we can
   … not do that right away, anyway, that's what I heard that I
   liked.

   <Zakim> plh, you wanted to talk about timing, dereferencing

   Glenn: I wanted to clarify that SHOULD/SHOULD NOT language can
   be made normative
   … or non-normative. Right now, in Appendix P, which is
   non-normative annex describing
   … privacy and security terms. I would object to changing the
   status to normative.
   … I do not object to using SHOULD or SHOULD not in the current
   non-normative appendix P.

   Nigel: Can I check in with Sam if Andreas's proposed "strongly
   encouraged not to" is okay?

   Sam: In the issue?

   [7]Andreas's proposal

      [7] https://github.com/w3c/ttml2/issues/1202#issuecomment-648721821


   Sam: I don't think I care one way or the other, if you want to
   express it this way.
   … In general, Philippe says he is not sure what the PING thinks
   about normative mitigations.
   … We have made a clear statement a year or so on W3C website,
   that we want privacy
   … mitigations to be normative at the same level of the spec
   that is defining the problem.
   … Hiding the language in a non-normative section seems
   inappropriate. Taking out
   … the SHOULD I can cope with.

   Andreas: I also wanted your view on the solution. Are you
   saying that if we put it in this
   … non-normative section this would be okay with you?

   Sam: No, I'm saying I want it to be normative, and if it is in
   a different section then so be it.

   Andreas: I would like you to reconsider this, it is about
   objectives not strict policies, because
   … otherwise we cannot find a solution. We can say this is not a
   perfect solution for the spec,
   … and if we put this in there now we are not hiding it, but
   explaining it. TTML is very big,
   … it is hidden everywhere or nowhere. Then the second step is
   to find a solution after that.
   … We all say the problem is not solved by this sentence alone.
   … We need both parties, and better investigation. We are not
   privacy experts, and PING are
   … not TTML experts. If we, after this publication, try to find
   a way to properly work out a
   … solution like Pierre proposed, that would help the cause much
   more than blocking each other.
   … I'm sure you don't want to block us, but I think working on
   it more later would help.

   Sam: I'm a fan of that, but want to come back to objectives
   rather than strict policies.

   <Zakim> weiler, you wanted to react to atai

   Sam: Other than what I've read in the WG I don't understand the
   group's objections.
   … I think they were about making it normative and being 11th
   hour.

   Pierre: On this topic it is not clear to me if a solution would
   be only to dereference to
   … trusted servers, or other mitigations.

   Sam: Ok, going back to the harm framing, is there harm from
   mandating this mitigation now in this spec now knowing
   … that we will come back to it later.

   Pierre: The harm is mandating a solution that is not the only
   one.

   Nigel: testability is really important to me. The TTWG has
   decided not to add untestable normative statement
   … the env is which TTML is used is broader than the typical Web
   … eg TTML in DVB, for pushing fonts in receivers
   … so not a traditional back channel
   … those systems have no privacy impact whatsoever
   … so we could be overwriting too much

   Philippe: Until we go to the Director we don't know the answer.
   … I don't want PING to ask the Director to override the TTWG
   because noone wants
   … that to happen. I understand why TTWG doesn't want the
   normative statement, and I
   … don't want this to be on the Director's desk as an issue.

   <plh>

   <plh> A content processor SHOULD NOT dereference external font
   resources conditionally on the presence of user-installed
   fonts, where that dereferencing could reveal information about
   the user's system or fingerprint the user.

   <plh> ]]

   Philippe: Pierre made the point that Nick's proposed wording is
   too restrictive in its solution.
   … Can we make it less restrictive? Can we ask to consider the
   privacy implications on the user,
   … say?

   Sam: I think that's why we have SHOULD not MUST.

   Pierre: To be fair it's also making this text normative.
   … Those two things together are where the divergence of opinion
   is.

   Glenn: My opposition is that the requirement to state a policy
   is wrong, and this is a policy.

   [scribe cannot hear Glenn's audio clearly]

   Andreas: I think Pierre had to leave.

   <glenn> I am opposed to dictating a policy. Period.

   Philippe: I would suggest if we have not got an agreement, I
   would advise TTWG to go
   … as far as they are willing to go, potentially this is already
   the case, and unfortunately
   … we would potentially have to go to the Director. Since you
   are willing to do something,

   <glenn> I can accept making a non-normative policy
   recommendation.

   Philippe: it would be good to at least do that and go as far as
   you are willing to go.

   Sam: I hear you (Glenn) that the WG has consensus not to do
   normative. While WG may have
   … consensus, the consortium as a whole may not. The Director
   may judge that the W3C
   … does not have consensus, so I may see the Director's role as
   being a bit different.

   Philippe: Let's not put the Director into an ivory tower.
   … The absence of consensus -> the spec stays as is.

   Andreas: I think it is okay what you say Philippe that TTWG
   goes back and thinks about

   <glenn> TTML2 1ED is already published without any policy
   recommendation, normative or not.

   Andreas: the possible solution, but I would also like to appeal
   to Sam to think about that too so
   … that we are coming together. The worse is that we are
   spending time on formal
   … solutions and not really addressing the problem. I think both
   solutions are equally as good
   … or as bad as each other. If both groups can think about
   solutions and PING can reconsider,
   … that would be good. If both camps are just trying to push a
   strict policy then it is really
   … difficult.

   <weiler> what risk?

   <weiler> we've already agreed to SHOULD instead of MUST. What
   is the risk? or harm?

   <glenn> We only agree to making SHOULD/SHOULD NOT in a
   non-normative section.

   Nigel: Attempting to summarise, we have not really managed to
   go back to 1st principles
   … and objectives, but maybe we do understand those better.

   <glenn> One reason is because normative SHOULD and SHOULD NOT
   statements have testing impact.

   <glenn> While non-normative ones do not.

   Nigel: However I think the best thing we can do is, as Philippe
   suggested, to make as much
   … progress as we can, and proceed on that basis, and work more
   on this in the future.

   [Sam drops off the call]

   Philippe: I can understand the TTWG's perspective here and
   recognise that TTWG does
   … understand Sam's and PING's points. In the absence of
   consensus, the status quo is what
   … is in effect, which is what was in the Rec in 2018.

   Nigel: Thank you everyone, I will make a comment on the issue
   summarising this call,
   … and will publish the notes. Sorry for running 10 minutes
   over. [adjourns meeting]


    Minutes manually created (not a transcript), formatted by
    [8]scribe.perl version 121 (Mon Jun 8 14:50:45 2020 UTC).

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