14:36:35 <RRSAgent> RRSAgent has joined #epub
14:36:35 <RRSAgent> logging to https://www.w3.org/2022/01/14-epub-irc
14:36:37 <Zakim> RRSAgent, make logs Public
14:36:39 <Zakim> please title this meeting ("meeting: ..."), dauwhe
14:36:50 <dauwhe> meeting: EPUB 3 Working Group Telecon
14:36:52 <dauwhe> chair: dauwhe
14:43:38 <ivan> ivan has joined #epub
14:43:58 <ivan> zakim, start meeting
14:43:58 <Zakim> RRSAgent, make logs Public
14:43:59 <Zakim> please title this meeting ("meeting: ..."), ivan
14:44:30 <ivan> ivan has changed the topic to: Meeting Agenda 2022-01-14: https://lists.w3.org/Archives/Public/public-epub-wg/2022Jan/0000.html
14:44:31 <ivan> Chair: dauwhe
14:44:31 <ivan> Date: 2022-01-14
14:44:31 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2022Jan/0000.html
14:44:31 <ivan> Meeting: EPUB 3 Working Group Telco
14:44:31 <ivan> Regrets+  toshiaki
14:52:39 <Karen> Karen has joined #epub
14:56:04 <tzviya> tzviya has joined #epub
14:58:47 <ivan> present+
14:58:51 <dauwhe> present+
14:59:00 <ivan> present+ avneesh
14:59:12 <MasakazuKitahara> MasakazuKitahara has joined #epub
14:59:24 <MattChan> MattChan has joined #epub
14:59:25 <MasakazuKitahara> present+
14:59:43 <ivan> present+ george
14:59:51 <Jen_G> Jen_G has joined #epub
14:59:54 <avneeshsingh> avneeshsingh has joined #epub
14:59:59 <Jen_G> Present+
15:00:00 <tzviya> present+
15:00:00 <avneeshsingh> present+
15:00:05 <ivan> present+ tzviya
15:00:05 <ivan> present+ rickj
15:00:07 <ivan> present+ laura
15:00:08 <Jen_G> Present+
15:00:20 <ivan> present+ wendyreid
15:00:41 <GeorgeK> GeorgeK has joined #epub
15:00:42 <LauraB__> LauraB__ has joined #epub
15:00:57 <MattChan> present+
15:01:20 <ivan> present+ aimee
15:01:25 <gpellegrino> gpellegrino has joined #epub
15:01:29 <MattChan> scribe+
15:01:30 <GeorgeK> present+
15:01:31 <duga> duga has joined #epub
15:01:33 <LauraB__> present+
15:01:38 <ivan> present+ charles
15:01:40 <duga> present+
15:01:40 <gpellegrino> present+
15:01:43 <rickj> rickj has joined #epub
15:01:52 <rickj> present+
15:02:06 <ivan> present+ ben
15:02:15 <ivan> present+ billk
15:03:35 <ivan> present+ victoria_lee
15:04:04 <CharlesL> CharlesL has joined #epub
15:04:13 <dlazin> dlazin has joined #epub
15:04:13 <CharlesL> present+
15:04:25 <ivan> present+ dlazin
15:04:29 <MattChan> dauwhe: today we have 3 issues which were all filed by TAG, but all on the same theme of privacy and security
15:04:34 <victoria> victoria has joined #epub
15:04:42 <BenSchroeter> BenSchroeter has joined #epub
15:04:48 <BenSchroeter> present+
15:04:52 <ivan> Topic: TAG's Privacy and Security comments
15:04:57 <MattChan> ... that was the main concern of PING of TAG, that we have not said much about the threat model involved in epub, about handling PII
15:05:02 <dauwhe> https://github.com/w3c/epub-specs/issues/1957
15:05:05 <MattChan> ... our goal is to address these
15:05:12 <MattChan> TOPIC: TAG Review Issues
15:05:42 <MattChan> dauwhe: this first issue is about PII, could we do something to discourage collection of PII, can we recommend RS are clear with customers about what is being collected?
15:05:50 <dauwhe> https://github.com/w3c/epub-specs/wiki/Privacy-and-Security-for-EPUB3
15:06:07 <Bill_Kasdorf_> Bill_Kasdorf_ has joined #epub
15:06:10 <MattChan> ... wendyreid wrote a summary of the issues for us, and some of our possible responses
15:06:21 <Bill_Kasdorf_> present+
15:06:40 <victoria> present+
15:06:42 <ivan> q+
15:06:56 <MattChan> ... the industry has seemed to settle on policy of user agreements, but the general public is probably not aware of how much information in being collected in this process
15:07:03 <dauwhe> ack ivan
15:07:07 <wendyreid> q+
15:07:47 <MattChan> ivan: just to make it clear from the w3c point of view is that we need to provide a section that documents problems and guidelines for what authors and RS should do to address the problems
15:08:06 <dauwhe> ack wen
15:08:07 <avneeshsingh> +1 Ivan
15:08:10 <MattChan> ... there is no requirement to change the spec
15:08:21 <MattChan> wendyreid: i can give us an overview
15:08:57 <MattChan> ... the way I have written this is that because we are talking about privacy and security, there are two parts to each of content authors and rs
15:09:14 <MattChan> ... for both security and privacy, i wanted to lay out our objectives
15:09:49 <MattChan> ... preserve confidentiality, content integrity, transparency
15:10:39 <MattChan> ... threat modelling for content: falsification of creator information, remote resources, etc.
15:11:05 <dlazin> q+
15:11:39 <MattChan> ... recommendations (mostly around privacy aspect): protect users from threats, avoid collection of data, "content processors" should be careful
15:11:46 <dauwhe> q?
15:12:21 <dauwhe> ack dl
15:12:34 <MattChan> ... for RS threats and recommendations are also set out, with threats like rs spoofing
15:12:54 <dauwhe> https://github.com/w3c/epub-specs/issues/1959
15:13:06 <MattChan> dlazin: from disclosure point of view, Apple now requires that apps have a user data collection "nutrition label" in the app store
15:13:41 <MattChan> ... not all rs are apps (i.e. some are stand alone devices), but this means that there are already some higher level requirements in many cases
15:13:59 <MattChan> ... but also, the most common RSes come pre-installed on device, not via app store
15:14:01 <rickj> q+
15:14:01 <dauwhe> q+
15:14:17 <duga> q+
15:14:33 <dauwhe> q-
15:14:39 <MattChan> wendyreid: other considerations like CCPA also come into play here, but these recommendations apply to
15:14:54 <dauwhe> ack ric
15:15:04 <MattChan> dlazin: we could model our response based on apple's list of things they do with user data
15:15:24 <MattChan> rickj: the more specific we get with the current state of things, the more revs of this we will have to do
15:15:38 <dauwhe> q+
15:15:45 <dauwhe> ack dug
15:15:53 <MattChan> ... so we should err on the side of common sense, and maybe reference other places that deal with this sort of thing, but not get too specific
15:16:09 <ivan> q+
15:16:23 <MattChan> duga: we should focus on epub, even though rs do lots of things that don't specifically have to do with epub format
15:16:53 <MattChan> ... odd for an epub format spec to try to tell rs what to do with other formats, or as a UA generally
15:17:17 <wendyreid> PING Target Privacy Threat Model: https://w3cping.github.io/privacy-threat-model/
15:17:38 <MattChan> ... also, the rs privacy policy doesn't apply to the publisher - e.g. if a publisher includes a tracking pixel, rs can't control that
15:18:05 <MattChan> dauwhe: the industry has gotten in trouble before - e.g. ADE sending unencrypted user information back to Adobe
15:18:27 <MattChan> ... i looked up the policies of a few major epub retailers
15:18:49 <MattChan> ... e.g. Apple says they anonymize everything, but Kobo doesn't
15:18:57 <wendyreid> q+
15:19:07 <ivan> ack dauwhe
15:19:13 <dauwhe> ack iv
15:19:14 <MattChan> ... so I'm a little less concerned with how other specs handle privacy, because there are specific user expectations about privacy when it comes to books
15:19:19 <rickj> q+
15:19:48 <MattChan> ivan: we have 2 specs, content and rs. And wendyreid separated the threat model into these 2 parts.
15:20:14 <MattChan> ... in the rs part, we already say things about origin and other security related policies, so we aren't complete silent
15:21:03 <MattChan> ... indeed there are areas where spec is silent, but the general expectations that a user should have over privacy are probably in scope
15:21:04 <dauwhe> ack wen
15:21:11 <dauwhe> https://html.spec.whatwg.org/multipage/webstorage.html#privacy
15:21:48 <MattChan> wendyreid: one thing that separates us from general web browser is that there are book related affordances that RS are expected to do for user, but some of these rely on collection of user data
15:22:00 <MattChan> ... but users don't think this way, they just expect that these features are there
15:22:16 <MattChan> ... e.g. collection of data for annotations, could syncing
15:22:38 <MattChan> ... so we would be doing our due diligence by providing some guidance to implementers
15:23:08 <MattChan> ... the reality is that these recommendations aren't normative anyway, but we are being good global citizens by doing so
15:23:13 <dauwhe> ack ric
15:23:19 <GeorgeK> q+
15:23:37 <MattChan> rickj: as a reminder, the epub marketplace is also the dominant format for education, an the customer is not the user. It's the institution.
15:23:57 <tzviya> q+ to say that epub is not that different from the web
15:23:58 <dauwhe> ack geo
15:24:02 <MattChan> ... so we need to be careful when we say things that affect that use case
15:24:21 <MattChan> GeorgeK: there are also rs that track the individual student and how much time they spend reading, progress, etc. and report back
15:24:29 <ivan> q+
15:24:29 <MattChan> ... and many times teachers and parents can see that info
15:25:08 <dauwhe> ack tz
15:25:08 <Zakim> tzviya, you wanted to say that epub is not that different from the web
15:25:11 <MattChan> ... i wonder if one of our suggestions would be to have the privacy policy available in a rs, e.g. in the help section, or if there is anything in the content that is phoning home, then it would be the publisher who informs people about that
15:25:30 <ivan> present+ hadrien
15:25:59 <MattChan> tzviya: we need to keep in mind that we tend think of epubs as separate from the web, but there are a lot of websites that do similar things. We're not that different
15:26:38 <MattChan> ... but the "nutrition label" might solve the problem, by clarifying the user's position without scaring them
15:26:58 <MattChan> ... better than a user agreement, where user knows that they just have to click to agree or else the app won't work
15:28:11 <MattChan> ivan: UX people have come up with a vocab that describes the a11y issues that might be present in a given book, can we do something similar?
15:28:28 <MattChan> ... but most of the privacy issues are on the rs side rather than the content side, so it may not be that helpful
15:28:31 <dauwhe> q?
15:28:38 <ivan> ack ivan
15:28:39 <dauwhe> ack iv
15:29:05 <gpellegr_> gpellegr_ has joined #epub
15:29:33 <MattChan> ivan: since wendyreid has already started, I think this text should become part of the spec
15:29:56 <MattChan> ... so next step should be to open a PR to incorporate it
15:30:03 <zheng_xu> zheng_xu has joined #epub
15:30:11 <zheng_xu> present+
15:30:15 <wendyreid> q+
15:30:25 <dlazin> q+
15:30:25 <MattChan> ... re. applications disclosing privacy features in general, maybe we should incorporate the labels that we want RS to provide
15:30:27 <dauwhe> ack wen
15:30:51 <MattChan> wendyreid: I considered including specific examples of data collection behaviours, or how to communicate to users when these things happen
15:31:33 <Hadrien> Hadrien has joined #epub
15:31:51 <MattChan> ... but I being specific might lead people to think that the examples constitute a closed list, when the recommendations are more like principles
15:31:56 <Hadrien> present+
15:32:00 <dauwhe> ack dl
15:32:06 <MattChan> s/but I/but I thought that
15:32:18 <MattChan> dlazin: do we know what the TAG wants? or can we ask?
15:32:44 <MattChan> ... most specs don't touch this. Really we just want to satisfy them.
15:32:50 <tzviya> q+
15:32:52 <ivan> q+
15:32:58 <dauwhe> q+
15:33:05 <dauwhe> ack tz
15:33:19 <MattChan> ... can they give us an example of what other specs have done in response to similar concerns. Rather than producing something on our own and risking it not being what they want
15:33:25 <Hadrien> q+
15:33:57 <MattChan> tzviya: privacy is increasingly important now. We're not just doing this to check off the privacy review box
15:34:08 <ivan> Examples for privacy section: https://www.w3.org/TR/did-core/#privacy-considerations and for security section: https://www.w3.org/TR/did-core/#security-considerations
15:34:16 <dauwhe> ack iv
15:34:28 <MattChan> ivan: the DID spec recently addressed similar privacy concerns
15:34:51 <MattChan> ... i.e. what implementors should be aware of when they try to implement, what privacy pitfalls are they likely to encounter, etc.
15:35:10 <MattChan> ... we also went through a similar process with audiobooks and pub manifest
15:35:27 <wendyreid> https://www.w3.org/TR/audiobooks/#security-privacy <-- quite minimal
15:35:43 <gpellegrino> gpellegrino has joined #epub
15:35:48 <wendyreid> https://www.w3.org/TR/pub-manifest/#security-privacy <-- more informative
15:35:51 <MattChan> ... i don't quite agree that we're just doing this to satisfy TAG
15:36:28 <dauwhe> ack dau
15:36:29 <MattChan> dauwhe: I can reply in the issues with a link to the document that we already have?
15:36:31 <dauwhe> ack ha
15:36:36 <MattChan> ivan: we'll let them know once we have a PR
15:37:08 <tzviya> q+
15:37:19 <MattChan> Hadrien: we have very very different rs, and for some of them, the fact that rs need to be distributed already applies some requirements (e.g. apps distributed via app store)
15:37:26 <MattChan> ... similar thing will happen with Play store
15:37:56 <MattChan> ... but no analogy process on the web - maybe just a privacy section of the page
15:38:09 <dauwhe> q?
15:38:20 <dauwhe> ack t
15:38:22 <MattChan> ... we could have best practices section about what to disclose to users, but not sure we can go much further than that
15:38:47 <ivan> q+
15:39:00 <dauwhe> ack iv
15:39:02 <tzviya> Web Authentication has several sections on privacy https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations-authenticator, https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations-client, https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations-rp
15:39:15 <MattChan> tzviya: Web Auth has several sections on policy that might be similar to what we need
15:39:25 <wendyreid> q+
15:39:31 <MattChan> ivan: i wonder whether there are things specific to security that we need to call out
15:39:54 <MattChan> ... we know most of rs have been quite averse to using scripts, some don't allow it at all
15:39:59 <MattChan> ... mostly due to security concerns
15:40:18 <MattChan> ... so having a fairly good idea of why rs shouldn't allow scripts might be helpful
15:40:34 <dauwhe> ack we
15:40:43 <MattChan> ... maybe say that content authors should really consider whether they need to include scripts in their content
15:41:34 <dauwhe> q+
15:41:41 <ivan> q+
15:41:42 <MattChan> wendyreid: i think the best we can do is identify some common threats that arise because of the way the spec is written, and the way content is likely to be written
15:42:18 <GeorgeK> q+
15:42:18 <MattChan> ... in terms of recommendations, we could recommend virus checking as part of ingest, checking origin or links
15:42:36 <MattChan> ... security is tricky because we can make recommendations, but it will ultimately come down to the authors
15:43:00 <MattChan> dauwhe: one of the big problems with security is that Hachette might write the script, but then Google executes it, knowing nothing about it
15:43:11 <dauwhe> ack dau
15:43:13 <dauwhe> ack iv
15:43:40 <MattChan> ivan: you could say that a content creator on the web writes scripts, and then the browser has to execute it
15:43:55 <MattChan> ... but for ebooks, once you put something in content, those books won't be automatically updated
15:44:19 <MattChan> ... so a malicious script could stay other there for a very long time, whereas on a website, the content can be updated
15:44:53 <MattChan> ... the fact that the book becomes its own entity is a difference between book and website - might be worth pointing out, as a reason not to include scripts
15:45:06 <rickj> q+
15:45:11 <Karen> Karen has joined #epub
15:45:19 <dauwhe> ack ge
15:45:28 <MattChan> ... e.g. old versions of incorporated js libraries incorporated in ebooks
15:45:31 <CharlesL> q+
15:45:56 <MattChan> GeorgeK: what a user is reading is certainly private. Governments knowing what people are reading is something we should point out
15:46:12 <dauwhe> ack ri
15:46:14 <MattChan> ... whether or not people are using assistive tech is also sensitive, we should call that out
15:46:50 <MattChan> rickj: perhaps we don't bifurcate by content and rs, but rather content creation and distribution channel
15:46:54 <dauwhe> q?
15:47:00 <dauwhe> ack ch
15:47:27 <MattChan> CharlesL: the other thing is that the content creator could have done everything right, and then someone in the middle injects malicious code into the epub and repacks it
15:47:40 <MattChan> ... right now we don't have anything to do with signing ebooks, etc.
15:47:47 <Hadrien> q+
15:47:52 <dauwhe> ack ha
15:47:56 <MattChan> ... so it really falls onto whoever is ingesting this at the end to make sure the content is safe
15:48:14 <MattChan> Hadrien: the top reason why rs don't like js in content is that it can mess with what rs does
15:48:45 <MattChan> ... rs will most likely always inject js to get desired result, which js in content can mess up
15:48:56 <dauwhe> q?
15:49:01 <duga> q+
15:49:15 <dauwhe> ack du
15:50:30 <MattChan> duga: we don't do js because of security, and because it's a pain. When a rs implements something in the webview they are limited in the resources they have available. But a browser operates at a higher level
15:51:34 <MattChan> ... in terms of serving content, when Hachette writes a book with a script, it's different whether that script is run via rs or via browser. When run via rs, the origin is Google.
15:51:48 <dauwhe> q?
15:51:49 <MattChan> ... very different security and privacy model
15:51:57 <dauwhe> q?
15:52:04 <dlazin> q?
15:52:08 <ivan> q+
15:52:18 <dauwhe> ack iv
15:52:51 <zheng_xu> q+
15:52:58 <MattChan> ivan: about signatures on epubs, there could be. Would it be a good thing to say in spec that we suggest that publishers make sure of signatures
15:53:33 <MattChan> ... of course, all the intermediates that modify content during ingestion will be against that, but there are all sorts of technology out there for providing signatures
15:53:39 <dauwhe> ack zh
15:53:54 <Hadrien> q+
15:54:23 <MattChan> zheng_xu: i was talking in mini-app CG yesterday, and their zips have a signature
15:54:24 <dauwhe> ack H
15:54:30 <MattChan> ... maybe we can incorporate something similar
15:54:47 <MattChan> Hadrien: we have signatures.xml in OPF, but how to use it was not defined
15:55:17 <zheng_xu> q+
15:55:19 <MattChan> ivan: agree that some infrastructure is already there, but probably too early to try to standardize anything
15:55:25 <CharlesL> +1 to looking into signing of the EPUB maybe a Community Group task to investigate?
15:55:43 <MattChan> ... but we can recommend that industry start to look into using it, which we might try to standardize in a future revision of epub
15:56:06 <MattChan> Hadrien: i think its more likely to happen if a major player in the industry starts requiring signatures - it's a chicken and egg situation
15:56:08 <dauwhe> ack zh
15:56:59 <MattChan> zheng_xu: for epub nobody really understands how to use signature
15:57:07 <dauwhe> q+
15:57:10 <MattChan> ... once use cases are clearer, then we can start to standardize
15:57:52 <Bill_Kasdorf_> should we be incubating signatures in the CG?
15:57:57 <MattChan> dauwhe: sounds like we have stuff to do
15:58:06 <MattChan> ... polish wendyreid's text and get it in PR
15:58:10 <MattChan> ... notify TAG re. same
15:58:20 <MattChan> ... research re. use cases of signing epubs
15:58:33 <zheng_xu> Bill_Kasdorf_: yes I feel like so
15:58:33 <MattChan> ... (alternatives to what we already have with XML signatures?)
15:58:55 <MattChan> ... and hopefully we can help wendyreid with PR
15:59:13 <MattChan> wendyreid: i think mgarrish is working on the PR piece, but we can help if he needs us to
15:59:27 <MattChan> dauwhe: okay, thanks everyone, we'll see you next week!
15:59:28 <ivan> rrsagent, draft minutes
15:59:28 <RRSAgent> I have made the request to generate https://www.w3.org/2022/01/14-epub-minutes.html ivan
15:59:39 <LauraB__> LauraB__ has left #epub
16:00:11 <ivan> zakim, end meeting
16:00:11 <Zakim> As of this point the attendees have been ivan, dauwhe, avneesh, MasakazuKitahara, george, Jen_G, tzviya, avneeshsingh, rickj, laura, wendyreid, MattChan, aimee, GeorgeK, LauraB__,
16:00:14 <Zakim> ... charles, duga, gpellegrino, ben, billk, victoria_lee, CharlesL, dlazin, BenSchroeter, Bill_Kasdorf_, victoria, hadrien, zheng_xu
16:00:14 <Zakim> RRSAgent, please draft minutes
16:00:14 <RRSAgent> I have made the request to generate https://www.w3.org/2022/01/14-epub-minutes.html Zakim
16:00:17 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
16:00:21 <Zakim> Zakim has left #epub
16:00:35 <ivan> rrsagent, bye
16:00:35 <RRSAgent> I see no action items