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> 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?
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]