23:21:38 RRSAgent has joined #epub 23:21:38 logging to https://www.w3.org/2021/02/18-epub-irc 23:21:43 Zakim has joined #epub 23:21:54 Meeting: EPUB 3 Working Group Telecon 23:26:25 Date: 2021-02-18 23:26:29 Chair: Dave Cramer 23:26:53 dauwhe has changed the topic to: https://lists.w3.org/Archives/Public/public-epub-wg/2021Feb/0009.html 23:53:48 wendyreid has joined #epub 23:56:09 zakim, start meeting 23:56:09 RRSAgent, make logs Public 23:56:10 please title this meeting ("meeting: ..."), wendyreid 23:56:19 MattChan has joined #epub 23:56:23 meeting: EPUB 3 WG Telco February 18 2021 23:56:27 chair: wendyreid 23:56:33 date: 2021-02-18 23:57:04 agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2021Feb/0009.html 23:57:18 present+ 23:58:50 toshiakikoike has joined #epub 23:59:00 present+ 23:59:22 MasakazuKitahara has joined #epub 23:59:38 leonardr has joined #epub 23:59:47 present+ 23:59:52 present+ 23:59:55 present+ 00:00:10 shiestyle has joined #epub 00:00:38 BenSchroeter has joined #epub 00:01:08 marisa has joined #epub 00:01:28 present+ 00:01:33 present+ 00:02:21 present+ 00:02:31 mattg has joined #epub 00:02:37 duga has joined #epub 00:02:45 present+ 00:04:03 scribe+ 00:04:08 present+ 00:04:28 TOPIC: Republish Core and RS 00:04:48 wendyreid: we just voted to publish FPWD of a11y and techniques note 00:05:00 ... but we also want to republish the other two pieces 00:05:17 Proposal: Publish new drafts of the EPUB 3.3 Core and Reading Systems documents 00:05:28 +1 00:05:28 +1 00:05:28 +1 00:05:31 +1 00:05:31 +1 00:05:32 0 00:05:32 +1 00:05:34 +1 00:05:48 Resolved: Publish new drafts of the EPUB 3.3 Core and Reading Systems documents 00:06:04 TOPIC: Remaining i18n issues 00:06:13 https://github.com/w3c/epub-specs/issues/1508 00:06:17 wendyreid: 2 i18n issues remain after the review 00:06:49 https://github.com/w3c/epub-specs/issues/1509 00:06:54 dauwhe: the two issues are pretty intertwined 00:07:24 ... i18n should require valid lang tags 00:07:45 ... there is a formal grammar which describes the formal structure of language tags 00:07:55 ... so, well, formedness 00:08:01 I believe that lang is ISO 3166 00:08:14 mgarrish: we enforce well formed, but nothing about validity 00:08:31 dauwhe: a valid tag is one which matches the actual languages 00:08:51 ... so should we require lang tags to be valid? 00:09:02 ... and what should RS do when faced with invalid lang tag? 00:09:09 q+ 00:09:19 ... not want to make requirement more stringent 00:09:24 ... hard to check validity of lang tags 00:09:33 ... its a list of strings that changes over time 00:09:40 ... burden on epubcheck 00:09:57 q+ 00:10:05 ... also, there could be existing epub with well formed but invalid lang tags - a change could cause those epubs to fail epubcheck 00:10:14 https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/lang - BCP-47 00:10:19 ... should having a valid lang tag just be a best practice? 00:10:36 ... so epubcheck would just flag it as an informative warning 00:10:43 leonardr: 00:10:48 ack leonardr 00:10:56 leonardr: here's the info in the link 00:11:19 ... BCP-47 is the technical spec, you can validate against that if you want 00:11:24 ack MattChan 00:11:28 ... but i think we should do what HTML does, no more, no ness 00:11:28 ack mattg 00:11:49 mgarrish: some of this came up in epubcheck itself, when someone complained that there was no check for lang validity 00:12:23 ... also, the epubcheck folks seemed to say that it would be a hard thing to implement 00:12:41 ... and unless there is some critical function, a RS is going to ignore this 00:12:54 ... and there are currently no critical functions that rely on this very general metadata 00:12:55 q+ 00:13:09 ... nothing bad comes of this lang tag not being specified properly 00:13:18 q+ 00:13:21 ... in pub manifest we said that well-formedness is good enough 00:13:40 s/well, formedness, well-formedness 00:14:00 wendyreid: also, we'd run into issues with testing this if we wanted to make this stricter 00:14:29 s/well, formedness/well-formedness 00:14:30 ack wendyreid 00:14:33 ack dauwhe 00:14:52 dauwhe: matt has more or less convinced me that this isn't broken 00:14:58 q+ 00:15:07 +1 to not broken 00:15:12 q+ 00:15:14 .. the costs of fixing it are higher than the purely theoretical benefits of conforming to broadly worded i18n guidelines 00:15:20 ack mattg 00:15:27 ... i propose that we close this without fixing 00:15:57 ack BenSchroeter 00:16:02 mgarrish: something like WCAG could have stricter rules about lang tags, but for us its not a critical piece of metadata 00:16:13 BenSchroeter: i like the idea of doing some sort of warning in epubcheck 00:16:26 marisa_ has joined #epub 00:16:30 ... also, i don't want to tell RS what to do in general 00:16:41 ... RS want to be as lax as possible when it comes to what they will ingest 00:17:02 ... they don't want to keep content authors off their RS 00:17:18 Proposal: Close issue 1509 with no action 00:17:22 +1 00:17:24 +1 00:17:25 +1 00:17:28 +1 00:17:29 +1 00:17:31 +1 00:17:33 +1 00:17:39 +1 00:17:57 Resolved: Close issue 1509 with no action 00:17:58 dauwhe: for 1508 (i.e. question of what RS should do with well-formed but invalid lang tag) 00:18:00 +1 00:18:16 ... there was a suggestion that the RS treat the lang as "und" (i.e. undefined) 00:18:21 q? 00:18:26 q+ 00:18:30 q+ 00:18:36 ... that to me is a satisfactory solution to this somewhat theoretical problem 00:18:50 +1 00:19:18 Proposal: Close issue 1508, add text to RS specification instructing reading systems to treat a poorly-formed language tag as "und" (undefined) 00:19:21 ack mar 00:19:36 q+ 00:19:49 ack duga 00:19:54 s/well-formed but invalid/poorly-formed 00:20:07 duga: is this yet another untestable assertion? 00:20:14 ... should we tell RS what to do with this at all? 00:20:34 q+ 00:20:37 q+ 00:21:22 ack mattg 00:21:37 mgarrish: i suggested the und thing because i thought we'd done this in pub manifest as well 00:22:00 ... but i think we actually went back and decided to remain silent on it 00:22:17 ack dauwhe 00:22:18 ... "we're not going to define what it means for the RS" 00:22:35 dauwhe: testing it would require reading the minds of the RS 00:22:48 ... what we're actually using the lang tag for is trying to guess at page progression direction? 00:23:08 ... how would we know if the RS is actually doing this? 00:23:11 ack BenSchroeter 00:23:20 +1 to sleeping Ivan... 00:23:20 ... so maybe another "close, won't fix"? 00:23:40 q+ 00:23:41 BenSchroeter: if we feel the RS wants some sort of guidance we could change the proposal to say "suggest" 00:23:47 q+ 00:23:49 ... but i'm also happy to drop it 00:23:53 ack dauwhe 00:23:57 q- 00:24:03 ack mattg 00:24:19 mgarrish: i think there's something worrisome about RS determining lang for the author 00:24:25 q+ 00:24:32 marisa has joined #epub 00:24:37 ... i'd rather RS do nothing 00:24:57 ack dauwhe 00:25:14 dauwhe: would also add that RS don't seem to be looking for guidance 00:25:25 Proposed: close issue 1508, won't fix 00:25:30 +1 00:25:33 +1 00:25:34 +1 00:25:34 +1 00:25:34 +1 00:25:40 +1 00:25:52 +qw-cj 00:26:01 Resolved: close issue 1508, won't fix 00:26:01 +1 00:26:06 ack w 00:26:20 TOPIC: Origin, cont'd 00:26:23 https://github.com/w3c/epub-specs/issues/873 00:26:29 wendyreid: this is continuing from last week's meeting 00:26:47 https://github.com/w3c/epub-specs/issues/1156 00:26:55 dauwhe: i think most of the discussion is in issue 1153 00:27:18 ... we've struggled with how to specify scripting in epub 00:27:41 ... we've gotten lots of questions from outside the group about how our security model ties in with the security model of the rest of the web 00:27:48 ... we have non-normative text in the spec 00:28:04 ... leonard has mentioned the concept of security boundaries, with origin being main boundary in web world 00:28:13 ... my opinion is that the text we currently have is wrong 00:28:18 q+ 00:28:24 ... boundary should be around the epub and not the content document 00:28:38 ... e.g. where content documents within an epub want to share a resource 00:29:09 ... also, origin is more the concept we're going for, not domain (which is what we currently reference) 00:29:28 ... could we say that each epub should be an opaque/unique origin 00:29:43 ... even if not particularly testable, at least it is a stake in the ground 00:29:50 ... re. how we are trying to fit into the web security model 00:29:59 ack leonardr 00:30:40 leonardr: the thing that is most problematic is the difference between actually doing this in a browser with a content hosted on a real domain vs doing this on a device (mobile, desktop, etc.) 00:30:48 ... in the device scenario the RS can completely control the origin 00:30:55 ... the RS sets up the origin 00:31:21 ... so your statements about every epub being its own RS can be done on device, but you can't do that on the web 00:31:38 q+ 00:31:46 ... so controlling scripts within the context of an origin makes sense in the device scenario, but not in the web scenario 00:31:56 ... that's the main issue 00:31:58 ack dauwhe 00:32:03 dauwhe: i hear you 00:32:43 ... in the RS i'm aware of that are web-based, there is a pretty big disconnect between what you see in the URL bar and what is actually happening inside the RS 00:32:50 q+ 00:32:59 ... is it reasonable to ask the RS to follow a stricter set of rules than would be required by the generic web security model 00:33:40 ... say Hachette decided to put all their books on a domain, I think its reasonable to say that if an RS were to do that they need to architect it so that all books aren't on the same origin as each other 00:33:53 ack leonardr 00:33:54 ... i see this as adding requirements to implementation if the implementation happens to be web-based 00:34:03 leonardr: the problem is that you can't do that 00:34:16 ... we tried to do that with sub-origins, but that hasn't been touched since 2017 00:34:27 ... never implemented seriously 00:34:49 ... never made it through the webapp sec WG 00:35:07 ... in your example, all your epubs are origined off the same thing, they would all share the same localstorage etc. 00:35:50 ... if those are all your books, that's fine, but once that content goes outside, there's no guarantee that books from different publishers won't be able to see each other 00:36:07 dauwhe: could you solve that problem with different subdomains for each title? 00:36:21 leonardr: yes, but only in a world where all the epubs come from the same publisher 00:36:41 ... e.g. an epub from patreaon uploaded to dropbox or onedrive 00:36:56 ... that book would have access to all of dropbox 00:37:16 dauwhe: you're kind of creating a non-conforming RS in this example 00:37:35 leonardr: that would make all web-based RS non-conforming 00:37:50 wendyreid: I think dropbox actually does have an ebook reader.... 00:38:00 leonardr: they're probably taking advantage of no scripting then 00:38:08 q? 00:38:18 wendyreid: i think the solution that most RS have come to is just to avoid scripting entirely 00:38:24 ... easiest way out of the origin problem 00:38:33 leonardr: that doesn't solve other things, e.g. referencing 00:38:44 ... trying to reference a font or other resource inside that domain as a relative link 00:39:02 ... nothing prevents referencing outside the epub at that point (e.g. ../../) 00:39:05 q+ 00:39:31 ack duga 00:39:36 ... and assuming this is served via HTTPS, that gives it a lot more privileges than an non-secure URL 00:39:44 duga: this really seems like a scripting issue 00:39:56 ... you have to make sure you don't access things you don't own 00:40:00 q+ 00:40:03 ... but that isn't an origin issue, that a rights access issue 00:40:25 ... the real problem is storing cookies, and then someone else's book accessing it 00:40:39 ack dauwhe 00:40:50 dauwhe: Jiminy has real world examples of this sort of stuff 00:41:02 ... e.g. an epub in ibooks that goes and finds info about other books 00:41:09 ... is there anything in the spec right now that says that's bad? 00:41:12 q+ 00:41:16 ack duga 00:41:27 duga: maybe? It depends on the RS and the content 00:41:47 ... e.g. RS for a school, where every student shares every book, that would be okay 00:41:55 q+ 00:42:09 ... one book might want to check how far a student got in another book 00:42:23 ... i.e. not a bad idea in ALL cases 00:42:24 ack leonardr 00:42:59 leonardr: if, say, you're building your own software and documents, and you control the entire system there's no reason why you wouldn't want to do it that way 00:43:11 dauwhe: one thing to do is go back to our current language 00:43:26 ... do we still want to say that every content document in the same epub should belong to a different domain? 00:43:53 leonardr: can probably change that so that each epub is its own origin, like you said earlier 00:44:12 mattg: the original wording came at a time when we were just starting to open epub to scripting 00:44:20 ... we were designing it to be as restrictive as possible 00:44:49 ... we've tried to dodge this in the past by limiting where scripting is allowed 00:45:24 dauwhe: to me i feels like a little bit of progress if we relax the current language to say "per epub" instead of "per content document" 00:45:40 q+ 00:45:44 ... this leaves us vulnerable to intra-epub security issues 00:45:52 ack duga 00:45:56 ... but that really seems like more of an authoring problem than a problem with the spec 00:46:19 duga: right now the spec is more restrictive, but we're already finding examples IRL where RS are not honoring it 00:46:30 q+ 00:46:33 q+ 00:46:37 ... from testing perspective, its not clear how this would be implemented 00:46:41 ack mattg 00:47:01 mattg: depends where we are going with this 00:47:10 ack leonardr 00:47:11 ... right now that section is only informative, so that's fine 00:47:22 ... if we change the section to be normative, then yes, that might be an issue 00:47:22 q+ 00:47:25 ack dauwhe 00:47:50 dauwhe: given all that, should we take the baby step of updating the non-normative guidance that the boundary should be "per epub"? 00:47:55 ... consensus on this? 00:47:56 +1 00:47:56 +1 00:48:12 duga: does that include changing from "domain" to "origin"? 00:48:16 dauwhe: yes, i think so 00:48:34 ... stuff about port randomization scares me a little bit as someone who wants to do something useful with scripting 00:49:04 Proposed: Update the informative statement in the core specification about origin from "content document" to "EPUB", and "domain" to "origin" 00:49:07 +1 00:49:09 +1 00:49:10 +1 00:49:10 +1 00:49:11 +1 00:49:13 +1 00:49:30 +1 00:49:35 Resolved: Update the informative statement in the core specification about origin from "content document" to "EPUB", and "domain" to "origin" 00:50:51 wendyreid: that's everything that was on the agenda tonight 00:51:24 dauwhe: i think i do have an action item to talk to TAG about the general ideas around epub security 00:52:03 wendyreid: there is most likely going to be a special session at the business group next week about WCAG3 00:52:18 ... silver is going to be presenting to business group about WCAG3 00:52:29 ... extending the invitation here 00:52:39 ... i will send out meeting details on the mailing list 00:52:53 ... WCAG3 calls out epub as a standard several times 00:53:01 ... probably worth providing our feedback 00:53:16 ... meeting date is Tues 23, noon Boston time 00:53:28 s/Tues 23/Tues 23rd 00:53:35 wendyreid: AOB? 00:53:56 ... no? Thank you everyone, and thank you leonardr! 00:54:11 Chair: Wendy Reid 00:54:16 RRSAgent: draft minutes 00:54:16 I have made the request to generate https://www.w3.org/2021/02/18-epub-minutes.html dauwhe 00:54:21 rrsagent, make logs public 00:54:50 RRSAgent: bye 00:54:50 I see no action items