14:21:51 <RRSAgent> RRSAgent has joined #epub
14:21:51 <RRSAgent> logging to https://www.w3.org/2022/01/28-epub-irc
14:21:52 <Zakim> RRSAgent, make logs Public
14:21:54 <Zakim> please title this meeting ("meeting: ..."), ivan
14:22:06 <ivan> Chair: dauwhe
14:22:06 <ivan> Date: 2022-01-28
14:22:06 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2022Jan/0008.html
14:22:06 <ivan> Meeting: EPUB 3 Working Group Telco
14:22:27 <ivan> ivan has changed the topic to: Meeting Agenda 2022-01-28: https://lists.w3.org/Archives/Public/public-epub-wg/2022Jan/0008.html
14:25:30 <tzviya> tzviya has joined #epub
14:53:52 <AramZS> AramZS has joined #epub
14:57:12 <dauwhe> dauwhe has joined #epub
14:58:15 <Ken_Jones> Ken_Jones has joined #epub
14:59:11 <MasakazuKitahara> MasakazuKitahara has joined #epub
14:59:13 <MattChan> MattChan has joined #epub
14:59:19 <MasakazuKitahara> present+
14:59:44 <dauwhe> present+
14:59:52 <tzviya> present+
14:59:54 <toshiakikoike> toshiakikoike has joined #epub
15:00:02 <toshiakikoike> present+
15:00:11 <MattChan> present+
15:00:34 <dlazin> dlazin has joined #epub
15:01:08 <Ken_Jones> present+
15:01:23 <CharlesL> CharlesL has joined #epub
15:01:55 <Bill_Kasdorf> Bill_Kasdorf has joined #epub
15:02:20 <MattChan> scribe+
15:02:54 <CharlesL> present+
15:03:41 <npd> npd has joined #epub
15:03:49 <duga> duga has joined #epub
15:03:53 <MattChan> dauwhe: the plan today is to go over the new security and privacy sections currently in a PR. Original text written by wendy, put into a PR by mgarrish
15:03:58 <duga> present+
15:04:01 <MattChan> ... opening the floor to comments
15:04:04 <dauwhe> https://pr-preview.s3.amazonaws.com/w3c/epub-specs/pull/1972.html#sec-security-privacy
15:04:11 <npd> present+
15:04:19 <MattChan> ... link to preview here
15:04:53 <MattChan> ... starts with an overview of what is unique about epub format, single file container, but using core web content
15:05:09 <MattChan> ... we inherent security and privacy issues from these core web content
15:05:35 <npd> (apologies, I got confused by that distinction and only read over the Reading System spec section last night)
15:05:55 <MattChan> ... based on feedback from PING and TAG we wrote up a threat model, list primary ways that users could be at risk
15:05:59 <BenSchroeter> BenSchroeter has joined #epub
15:06:12 <BenSchroeter> present+
15:06:19 <MattChan> ... e.g. remote resources, scripting, DRM, etc.
15:06:25 <zheng_xu> zheng_xu has joined #epub
15:06:30 <dauwhe> q?
15:06:39 <zheng_xu> present+
15:06:54 <MattChan> dauwhe: npd is this closer to what you were expecting to see?
15:07:02 <MattChan> npd: in short yes
15:07:16 <MattChan> ... list of threats is important
15:07:33 <MattChan> ... epub has a slightly different threat model then browser, so this is a good start
15:08:12 <MattChan> ... can we say what we want the threat model to be? What assurances do we want to provide to epub users? What is the privacy experience supposed to be like? Is it just like the web, or something different?
15:08:22 <MattChan> dauwhe: right, what are user expectations here?
15:08:28 <ivan> present+
15:08:38 <tzviya> q+
15:08:41 <dauwhe> q?
15:08:46 <MattChan> ... might be a difference between what we think is happening and what non-insider users are thinking is happening
15:08:59 <dauwhe> ack tz
15:09:08 <MattChan> npd: lessons from web model may or may not be transferrable here, different parties involved
15:09:45 <ivan> zakim, who is here?
15:09:45 <Zakim> Present: MasakazuKitahara, dauwhe, tzviya, toshiakikoike, MattChan, Ken_Jones, CharlesL, duga, npd, BenSchroeter, zheng_xu, ivan
15:09:47 <Zakim> On IRC I see zheng_xu, BenSchroeter, duga, npd, Bill_Kasdorf, CharlesL, dlazin, toshiakikoike, MattChan, MasakazuKitahara, Ken_Jones, dauwhe, AramZS, tzviya, RRSAgent, Zakim, ivan,
15:09:47 <Zakim> ... Karen, github-bot, bkardell_, `join_subline, hober, florian, jcraig, Joshue108
15:09:56 <MattChan> tzviya: in educational environments sometimes reading pace is tracked
15:10:02 <MattChan> ... users may not think about this
15:10:09 <ivan> present+ billk
15:10:23 <ivan> present+ makoto
15:10:30 <MattChan> ... can we bring this to light?
15:10:38 <dlazin> present+
15:10:47 <dlazin> q+
15:10:56 <ivan> present+ dlazin
15:11:08 <MattChan> dauwhe: there are times when RS keep close track of users for legitimate reasons - education being obvious case here, books with quizzes, etc.
15:11:15 <dauwhe> ack dl
15:12:01 <ivan> present+ ubbink
15:12:16 <npd> q+ on education
15:12:25 <MattChan> dlazin: in the recommendations section, maybe we can say "users' default expectation is that ebooks behave like print". We recognize legit reasons to deviate from this, but RS should declare to users when their behaviour intrudes on privacy more than tradition library book experience.
15:12:32 <MattChan> ... this wouldn't be normative, just recommendation
15:12:43 <ivan> present+ jeng
15:12:49 <dauwhe> q?
15:13:04 <dauwhe> ack np
15:13:04 <Zakim> npd, you wanted to comment on education
15:13:07 <MattChan> ... frame it like 'we don't have authority over this, but we are recognizing that ebooks come from a physical format with very specific user expectations attached'
15:14:11 <MattChan> npd: re. education use case, i would caution against the assumption that information collection for education is always beneficial
15:14:15 <tzviya> q+
15:14:29 <MattChan> ... cases where students are being coerced about type of book or technology they are made to use
15:14:40 <MattChan> ... students are a vulnerable population
15:15:05 <dauwhe> ack tz
15:15:06 <duga> q+
15:15:07 <MattChan> ... so useful to describe those uses cases, but not to make it seem like privacy is not important there
15:15:20 <dauwhe> ack du
15:15:50 <MattChan> duga: i think education is a bit of red herring. We track everyone (so do libraries, who know who has their books).
15:16:30 <MattChan> ... Google knows which books you own, which you read recently, etc. This is so that we can provide a reasonable UI. For ordering books in bookshelf, opening to last read, bookmarks, etc.
15:16:58 <dlazin> q+
15:17:00 <MattChan> ... everyone is being tracked, and it is necessary. Most people rely on these features.
15:17:06 <dauwhe> ack dl
15:17:20 <MattChan> dlazin: i think the difference there is that we have an ability to decide between local tracking and network tracking
15:18:30 <dauwhe> q+
15:18:37 <MattChan> ... there is a theoretical implementation where local tracking and network tracking user experience is less distinguishable
15:19:03 <dauwhe> ack dau
15:19:10 <MattChan> dauwhe: i know a common use case is users accessing their books on multiple devices, not sure how local tracking only would work with that use case
15:19:36 <npd> this is part of why it's useful to describe the privacy issues of the different actors. my browser knows what websites I've visited, but epubs have this additional step of, not just the reading software, but maybe also the bookstore
15:19:37 <MattChan> dlazin: yes. But there is a point at which we are making a decision between what we think user wants, and what they are willing to give away for it
15:19:38 <dauwhe> q?
15:19:59 <duga> q+
15:20:04 <dauwhe> ack du
15:20:13 <MattChan> ... we treat use data very carefully, and have decided to implement RS in this way. But we can't assume that other RS implementors take user data as seriously
15:20:32 <ivan> scribejs, set npd Nick Doty
15:21:01 <MattChan> duga: today users buy their books from their RS provider. So we need to track at least user purchases, which has to go off device. No good alternative
15:21:06 <dauwhe> q?
15:21:30 <MattChan> ... perhaps we can clarify when certain things happen off device. e.g. sideloading
15:22:06 <MattChan> ... we let users open epubs that we didn't buy from us, and when we do, we make it clear that you are uploading your epub to us from your device
15:22:11 <npd> "sideloading" is such an interesting term!
15:22:35 <npd> I think maybe it's a synonym for what we used to call "opening" or "loading" or "reading"
15:22:55 <MattChan> dauwhe: most of these interactions using web language are first party (e.g. it is the Google Play way of doing things)
15:23:10 <dauwhe> q?
15:23:11 <MattChan> ... in the general web model, this means that I'm trusting Google with certain things
15:23:31 <ivan> q+
15:23:34 <MattChan> ... but we've come up with a couple good ideas for adding to the section
15:23:42 <ivan> q-
15:24:10 <ivan> q+
15:24:13 <MattChan> npd: to add to that, i've heard from this group that there is interest in making epubs the sort of thing where you could buy epubs from one source, and open in an unaffiliated RS
15:24:38 <Bill_Kasdorf> q+
15:24:43 <MattChan> ... is there any movement towards this? Do we work towards this in this group, or would we do it somewhere else?
15:24:58 <duga> q+
15:25:09 <MattChan> dauwhe: many of us had hoped that this market would evolve differently than it did
15:25:16 <npd> maybe that's too general a question for spec work, but it's going to be pretty relevant for these privacy and interoperability questions
15:25:45 <dauwhe> ack iv
15:25:46 <MattChan> ... also we live in a universe where common RSes are made by Google, Apple, Amazon, so there are economic and political challenges beyond the reach of a W3C wg
15:25:59 <MattChan> ivan: let's put DRM aside for a moment
15:26:13 <MattChan> ... we are in a very reasonable state in this respect
15:26:30 <MattChan> ... non-DRMed epubs can be read in many different RS, without any technical tricks
15:26:43 <MattChan> ... and with some tricks I can even sideload into Kobo
15:27:00 <MattChan> ... epub gives you this interop. Even if it's not ideal.
15:27:15 <MattChan> ... this wg is trying to reduce interops issues, that's why we're doing testing
15:27:49 <MattChan> ... DRM makes life difficult in this respect. Most DRM is platform specific. But there are non-platform specific DRMs.
15:28:04 <dauwhe> q?
15:28:05 <MattChan> ... but DRM is outside of our purview
15:28:09 <dauwhe> ack Bill_
15:28:59 <MattChan> Bill_Kasdorf: VST and Redshelf receive content from all higher ed to be made available to students
15:29:15 <dauwhe> ack du
15:29:23 <MattChan> ... Bookshare does the same thing, but not in retail setting
15:29:30 <MattChan> ... this interop is enabled by epub
15:29:48 <ivan> q?
15:29:50 <ivan> q+
15:30:21 <MattChan> duga: until you can open your epub in your browser, epub will likely be used mainly for books. This has limited non-book use cases for epub
15:30:44 <dauwhe> ack iv
15:30:45 <MattChan> ... we allow users to download the epubs that they buy from us, but they would only do this if their epub isn't DRMed
15:31:11 <MattChan> ivan: i have quite a lot of legal books on my Mac that are not DRMed
15:31:37 <MattChan> ... re. the browser thing, there are browser extensions that are trying to enable this functionality
15:31:46 <dauwhe> q?
15:31:55 <MattChan> ... xiang is working on one such browser extention/application
15:32:05 <MattChan> ... epub interop is very high in our priorities
15:32:19 <MattChan> npd: appreciate that, thank you
15:33:07 <MattChan> ... the implication of that is that the privacy analysis should consider both the current state (i.e. vendor driven ecosystem), and the goal of user-side interop (notwithstanding DRM)
15:33:20 <dauwhe> https://pr-preview.s3.amazonaws.com/w3c/epub-specs/pull/1972.html#security-privacy-recommendations
15:33:34 <MattChan> dauwhe: we have some recommendations in the PR
15:34:15 <MattChan> ... and some practical steps (e.g. avoiding 3rd party resources, using https, ensuring the use of stable links)
15:34:33 <MattChan> ... do we need to go further in discouraging remote resources unless they are strictly necessary?
15:34:51 <tzviya> q+
15:34:56 <dauwhe> ack tz
15:35:28 <MattChan> tzviya: strictly necessary can mean different things to different people, so I hesitate to try to define it
15:35:59 <MattChan> ... e.g. in education space, what is necessary could differ based on whether epub is for 3rd grade or university student
15:36:13 <MattChan> ... no proposed language from me just now, I can think about it
15:36:22 <MattChan> npd: are the recommendations normative?
15:36:30 <MattChan> dauwhe: no, whole section is non-normative
15:36:44 <ivan> q+
15:37:02 <MattChan> npd: so are you telling authors not to do something? Or are you saying they probably will, but you would rather they didn't?
15:37:27 <duga> q+
15:37:48 <MattChan> dauwhe: it's hard for us to say 'don't use features that we've had in the standard for 20 years or your epub will be invalid'
15:37:51 <dauwhe> ack iv
15:37:59 <MattChan> ... especially given that users have provided consent for some of this
15:38:02 <npd> we've had, I would say, mixed results on putting considerations or requirements for content authors in w3c specifications
15:38:20 <MattChan> ivan: most of the specs that i've worked on in the past 20 years have had non-normative privacy and security sections
15:38:31 <MattChan> ... drawing user attention to things they may not have thought about
15:38:46 <MattChan> ... spec itself may have features that are normative (i.e. origin, etc.), but this section is non-normative
15:39:05 <duga> q-
15:39:06 <MattChan> ... use of term 'recommendation' may have been a mistake since it carries specific meaning in w3c process
15:39:11 <dauwhe> q?
15:39:18 <MattChan> ... leave it to the group whether to change use of this term
15:39:26 <MattChan> ... but yes, absolutely valid question
15:39:31 <ivan> q+
15:39:45 <dauwhe> ack iv
15:40:42 <MattChan> ivan: i am co-editor here, but i didn't write this. I'm anxious about having this discussion leading to specific action in editing this document. Anyone here willing to try to take this discussion and make it into changes to the PR?
15:41:13 <MattChan> dauwhe: maybe we can discuss this in the chairs call?
15:42:02 <MattChan> ... we need volunteer(s) to turn this discussion into changes into the text
15:42:07 <dauwhe> https://cdn.statically.io/gh/w3c/epub-specs/update/privacy-security/epub33/rs/index.html#sec-security-privacy
15:42:17 <MattChan> ivan: there are already a number of comments in the PR which I made a couple weeks ago
15:42:40 <MattChan> ... it would be good if those were discussed and adjusted/rejected, and then merged
15:42:47 <MattChan> ... the PR is getting big
15:42:58 <MattChan> ... too messy to track everything otherwise
15:43:24 <MattChan> ... and I don't want to edit my own suggestions, but either mgarrish or wendy should look at them before we go to the next round
15:43:33 <dauwhe> https://cdn.statically.io/gh/w3c/epub-specs/update/privacy-security/epub33/rs/index.html#sec-security-privacy
15:43:46 <MattChan> dauwhe: these are proposed changes to RS spec
15:44:10 <MattChan> ... again starting with an overview, a threat model (scripting, remote resources, user generated content, etc.)
15:44:19 <MattChan> ... and some related recommendations
15:44:25 <MattChan> ... any thoughts on the RS side?
15:45:23 <MattChan> zheng_xu: what was different between epub and android app? Is there a difference in perspective?
15:45:35 <MattChan> ... in terms of the content itself
15:46:04 <duga> q+
15:46:05 <MattChan> ... not the RS. In terms of the security and privacy considerations of the content itself
15:46:20 <ivan> q+
15:46:32 <MattChan> ... epub is a package of XML, but android app can access web too, etc.
15:46:32 <dauwhe> ack du
15:46:47 <MattChan> duga: significant difference is that epub involves 3rd party content
15:47:07 <MattChan> ... android app dev writing a game controls privacy aspects of the game
15:47:24 <npd> it's app stores within app stores
15:47:33 <MattChan> ... but with epub, Google has an app and a store, but the content comes from someone else
15:47:47 <MattChan> ... so what privacy and security issues exist around me displaying this epub in my app
15:48:10 <dauwhe> ack iv
15:48:13 <MattChan> ... given that I don't know exactly what the 3rd party content will do
15:48:21 <npd> q+ on normativity again
15:48:33 <MattChan> ivan: i think the big difference is the potential for author putting scripts into the content
15:48:49 <MattChan> ... if it was only HTML and CSS, then the security problems from RS point of view will be smaller
15:49:24 <MattChan> ... in the current PR, I asked whether we could put some guideline to the author to 'please use scripts only where strictly necessary'
15:49:37 <duga> q+
15:49:42 <MattChan> ... not sure how we would express this, but essentially that would be the message - keep it simple
15:49:57 <dauwhe> ack npd
15:49:57 <Zakim> npd, you wanted to comment on normativity again
15:50:00 <MattChan> ... if you make a mistake in your script, it will stay in the file (and out in the world) for years
15:50:08 <dauwhe> ack dug
15:50:27 <MattChan> duga: if you think scripting is your only remote code exploit, you will have a bad time. Many other things that can happen. But not using scripts is a start.
15:50:39 <dauwhe> ack npd
15:51:05 <MattChan> ntd: if this section isn't normative, why isn't it?
15:51:31 <ivan> q+
15:51:35 <dauwhe> ack iv
15:51:38 <MattChan> ... e.g. 'RS that allow local storage should allow users to view data' could be normative
15:51:58 <MattChan> ivan: the problem is that the current RS spec is exclusively related to how to render content of epub file
15:52:14 <MattChan> ... we say nothing about what RS user interface should behave
15:52:29 <MattChan> ... like how HTML spec says nothing about how browser UIs work
15:52:43 <MattChan> ... if we open that floodgate, there are other things that we would need to specify
15:52:58 <MattChan> ... e.g. we have in the spec a separate notion of navigation file (a table of contents)
15:53:21 <dauwhe> q+
15:53:36 <MattChan> ... we say the format of the toc, and where RS can find it, but we say nothing about how RS should do with that data, or how to display it to user
15:54:10 <MattChan> dauwhe: just because we make a few normative requirements on important issues, we don't have to decide everything
15:54:23 <tzviya> q+
15:54:30 <dauwhe> ack dau
15:54:33 <dauwhe> ack tz
15:54:34 <MattChan> ... e.g. for the nav file, we say that if RS displays nav file outside spine, then it can't show numbers by default on OL element
15:54:47 <MattChan> tzviya: some of the recommendations are easier to make normative than others
15:55:19 <dauwhe> q+
15:55:20 <MattChan> ... e.g. 'provide user indication that network activity is occuring' is more easily testable, could be normative
15:55:25 <MattChan> ... others are more vague
15:55:32 <duga> q+
15:55:41 <MattChan> dauwhe: it's worth seeing what could be done
15:55:48 <ivan> ack dauwhe
15:55:56 <dauwhe> ack du
15:56:02 <MattChan> ... seeing what RS would be likely be willing to implement
15:56:29 <MattChan> duga: in terms of easily testable, if you do something that would access the network but nothing comes up, does that mean that you failed the test? Or that your connection is bad?
15:56:41 <MattChan> ... so it is a little tricky to test some of these things
15:56:48 <MattChan> ... but i'm not against making some of these normative
15:57:04 <MattChan> ... but do we make them normative here, or normative somewhere else in spec and just reference them here
15:57:22 <MattChan> ivan: editorially it makes more sense to move the normative ones somewhere else (into a normative section)
15:57:37 <dauwhe> q?
15:57:56 <MattChan> dauwhe: we've uncovered a lot of things to think about, and a lot to do
15:58:39 <MattChan> dauwhe: thanks npd for joining, we appreciate your contributions
15:58:59 <MattChan> npd: i had an issue with the user agent string?
15:59:40 <MattChan> ... why was there an EPUBReadingSystem object? History of privacy issues related to this
15:59:44 <dlazin> q+
16:00:05 <MattChan> duga: the idea was that you could figure out which RS you were on, and behave accordingly
16:00:21 <MattChan> dlazin: but why do we have this if navigator.useragent already exists
16:00:30 <CharlesL> CharlesL has left #epub
16:00:38 <MattChan> ... and it might be because RS are built on top of other tech, like Chrome
16:01:01 <MattChan> ... so navigator.useragent returns Chrome, but EPUBReadingSystem returns the RS
16:01:20 <MattChan> npd: not sure it's necessary to have both of those, but we can take that offline
16:01:29 <MattChan> ... thanks for your explanations
16:01:47 <MattChan> ivan: there are already tests in these sections, so you can find out what the RS returns if the RS implements it
16:02:02 <MattChan> ... okay thanks everyone, this meeting is closed!
16:02:08 <ivan> rrsagent, draft minutes
16:02:08 <RRSAgent> I have made the request to generate https://www.w3.org/2022/01/28-epub-minutes.html ivan
16:02:58 <ivan> zakim, end meeting
16:02:58 <Zakim> As of this point the attendees have been MasakazuKitahara, dauwhe, tzviya, toshiakikoike, MattChan, Ken_Jones, CharlesL, duga, npd, BenSchroeter, zheng_xu, ivan, billk, makoto,
16:03:01 <Zakim> ... dlazin, ubbink, jeng
16:03:01 <Zakim> RRSAgent, please draft minutes
16:03:01 <RRSAgent> I have made the request to generate https://www.w3.org/2022/01/28-epub-minutes.html Zakim
16:03:04 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
16:03:06 <ivan> rrsagent, bye
16:03:06 <RRSAgent> I see no action items