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