23:35:41 RRSAgent has joined #epub 23:35:41 logging to https://www.w3.org/2022/06/09-epub-irc 23:35:44 RRSAgent, make logs Public 23:35:45 please title this meeting ("meeting: ..."), dauwhe 23:35:56 Meeting: EPUB 3 Working Group Telecon 23:36:00 chair: dauwhe 23:50:41 mgarrish has joined #epub 23:57:32 BenSchroeter has joined #epub 23:59:09 MattChan has joined #epub 23:59:13 MasakazuKitahara has joined #epub 23:59:18 present+ 23:59:27 present+ 23:59:49 wendyreid has joined #epub 00:00:05 present+ 00:00:09 toshiakikoike has joined #epub 00:00:10 present+ 00:00:20 present+ 00:00:54 present+ 00:01:14 hello++ 00:01:16 present+ 00:01:18 duga has joined #epub 00:01:27 present+ 00:01:30 scribe+ 00:03:21 dauwhe: in our last meeting we discussed the paper written by EU security researcher who were looking at security issues in various RS 00:03:33 ... wendyreid invited them to guest at our meeting last week 00:03:46 https://github.com/w3c/epub-specs/issues/2324 00:03:52 ... interesting discussing ensued, with some recommendations. Today we try to work thru some of those issues. 00:03:57 TOPIC: Disallowing File URLs 00:04:13 dauwhe: I can't think of good reason to have these, but a lot of good reasons to prohibit them 00:04:22 q? 00:04:29 q+ 00:04:38 q+ 00:04:50 ack d 00:05:23 duga: yes, sounds good. File URLs seem to be interoperable. What file would you load from an epub? 00:05:46 BenSchroeter: most common thing i've seen is youtube videos, but those aren't file URLs, right? 00:06:16 duga: depends on how the epub is created. Could be a link to youtube, or link to external resource that plays in your epub, but neither of those are file URLs 00:06:28 ack be 00:06:44 dauwhe: file URL goes against idea that epub should be self contained, you don't want epub author to look at your files in your local machine 00:06:58 BenSchroeter: when Play gets file URL what happens? 00:07:43 duga: probably gets stripped on the server, but probably gets intercepted and rejected. We might try to open it in the browser, but then the browser would probably reject it 00:08:07 ... there are also a lot of origin issues with file URLs 00:08:19 https://github.com/w3c/epub-specs/pull/2329 00:08:20 dauwhe: I propose we forbid file URLs 00:08:26 duga: there's already a PR open for that 00:08:27 +1 00:08:42 +1 00:08:49 Proposed: Remove file URLs, merge PR 2329 and close issue 2324 00:08:56 +1 00:08:59 +1 00:09:03 +1 00:09:04 +1 00:09:08 +1 00:09:10 +1 00:09:31 RESOLVED: Remove file URLs, merge PR 2329 and close issue 2324 00:09:33 +1 00:09:54 https://github.com/w3c/epub-specs/issues/2323 00:09:59 TOPIC: Recommendation to frequently update reading system engines 00:10:14 q+ 00:10:27 dauwhe: recommend RS should update their distributed devices and apps regularly 00:10:35 ack wen 00:10:36 ... not sure if this will change behaviour of RS vendors 00:11:03 q+ 00:11:12 q+ 00:11:14 ack du 00:11:26 wendyreid: i like the spirit of this recommendations, but it doesn't seem testable or enforceable. Also not sure if it will happen, as updating these things is more fraught than necessary 00:12:12 duga: it might be out of your control. Google has a browser based version, so if user updates their browser, then RS is updated. Android update will update the browser. 00:12:36 ... Google can't make Apple update embedded hardware 00:12:40 ... recommendation won't change that 00:12:41 ack mg 00:12:47 q+ 00:13:11 ack be 00:13:25 mgarrish: this is kind of like a recommendation that RS vendor who abandon support should pull their app from circulation 00:14:06 BenSchroeter: similarly, we could also recommend that users update their browsers too 00:14:31 dauwhe: yeah, and HTML spec doesn't recommend that users update browser 00:15:11 shiestyle has joined #epub 00:15:23 wendyreid: I think this came up specifically in reference to kindle software using old webkit, similarly difficult to update on old Linux devices 00:15:43 present+ 00:15:52 dauwhe: I think there are RS where even if they wanted to update some components it is not possible, codebase is too old, original devs are gone 00:16:14 duga: I know people who update webview and it's really really hard to do it without breaking things 00:16:49 dauwhe: another factor is that you have the ability to mitigate some of these issues in different ways 00:17:08 ... given that these are complicated systems, its not just the rendering engine that controls user experience 00:17:20 ... not seeing a lot of appetite for this 00:18:09 Proposed: Close issue 2323 as won't fix 00:18:13 +1 00:18:13 +1 00:18:15 +1 00:18:17 +1 00:18:17 +1 00:18:17 +1 00:18:21 +1 00:18:21 +1 00:18:26 RESOLVED: Close issue 2323 as won't fix 00:18:29 +1 00:18:46 https://github.com/w3c/epub-specs/issues/2322 00:18:52 TOPIC: Adding malicious symbolic links to an EPUB application 00:19:39 dauwhe: symbolic link outside the epub pointing to local fs, should we discuss this in threat model and/or explicitly disallow 00:19:51 ... not sure how this would be done in practice 00:20:01 q? 00:20:01 duga: there is a parameter to include symlink in zip 00:20:07 dauwhe: yes, -y 00:20:29 ... but i didn't get a chance to try this 00:20:33 q+ 00:20:36 ... should we add the idea to the threat model? 00:20:36 ack d 00:20:39 wendyreid: i think so 00:21:17 duga: this one is more obscure, easy for people not to think of this. So maybe just a notice to watch out for this, and similar threats of files referencing other files 00:21:26 ... and this wouldn't be a MUST or a SHOULD? 00:21:49 mgarrish: could it be a MUST though? "RS must not preserve symbolic link when unpacking" something like that 00:22:13 q+ 00:22:19 duga: it depends on the fs, the OS... not sure how I would tell people not to do this, and I don't want to limit this to the way you would do it using zip 00:22:41 ack b 00:22:47 dauwhe: and if you have a really bad RS that allows scripting, and the script asks the local fs to do stuff 00:23:02 BenSchroeter: is epubcheck looking into this issue? 00:23:22 mgarrish: romain is looking into whether epubcheck could detect such symlinks 00:24:06 Proposed: Add symbolic links to the threat model, investigate whether EPUBCheck can detect symlinks 00:24:11 +1 00:24:12 +1 00:24:12 +1 00:24:13 +1 00:24:14 +1 00:24:15 +1 00:24:15 +1 00:24:16 +1 00:24:17 +1 00:24:30 RESOLVED: Add symbolic links to the threat model, investigate whether EPUBCheck can detect symlinks 00:25:31 https://github.com/w3c/epub-specs/issues/2321 00:25:40 TOPIC: Should a RS require user consent to use scripting? 00:26:14 q? 00:27:00 wendyreid: mixed feelings. Yes we should be asking for user consent if the script is taking info out of the epub, but i've seen more epubs that use js innocuously to animate things, and I don't want to scare users 00:27:12 dauwhe: we use it in cookbooks to make a timer in the corner 00:27:27 ... i don't think a blanket consent is warranted 00:28:06 ... we already rely on HTML-like things, and things like geolocation already recommend user consent. So we are covered for those 00:28:43 duga: what about tracking external media on every page? No scripting is involved, but no consent there? 00:29:26 mgarrish: the network activity part of it is the more dangerous thing 00:29:58 ... the question of how to attain consent while not blasting users with notifications is a difficult question 00:30:13 dauwhe: it leads to the web situation where 100x a day you get a cookies pop-up 00:30:20 ... i don't really want to perpetuate that model 00:30:33 wendyreid: it is worth having something about this, because it is a true threat 00:31:11 ... something like "RS should warn a user when something is going to activate network activity" 00:31:33 ... this is more rare 00:32:09 q+ 00:32:13 ... and we could keep the wording of the recommendation loose enough so that RS can decide whether it is a blanket consent, or epub by epub 00:32:21 dauwhe: what do we have on network activity right now? 00:32:39 wendyreid: nothing specific 00:33:10 BenSchroeter: how would you word it so that your average user would really understand what they are consenting to? "Network activity"? I wouldn't expect people to understand 00:33:13 ack ben 00:33:26 https://w3c.github.io/epub-specs/epub33/rs/#sec-epub-rs-network-access 00:33:53 wendyreid: like the MacOS approach: "always load links from this source" sort of thing 00:34:05 ... not usual pattern to the average user 00:34:14 If reading system developers allow network access, it is RECOMMENDED both that they: 00:34:14 notify users when network activity occurs; and 00:34:14 let users block access to the network (e.g., disable network access for the reading system globally or for a particular EPUB publication). 00:34:37 duga: but a Zoom link, for example, is the user clicking on a link. What if the user just turns a page and a video auto-plays? 00:34:53 ... I think the user should get a prompt if the video is remote 00:35:42 ... user is not expecting a turning a page could communicate to another party 00:36:03 wendyreid: we have recommendation re. consent to network access 00:36:17 dauwhe: going stricter than what we have could be hard 00:36:30 s/a turning a page/turning a page 00:38:15 Proposed: Close issue 2321, no change to current statement on network activity 00:38:24 +1 00:38:25 +1 00:38:27 +1 00:38:28 +1 00:38:29 +1 00:38:29 +1 00:38:29 +1 00:38:34 +1 00:38:38 RESOLVED: Close issue 2321, no change to current statement on network activity 00:38:49 duga: it's not that user consent to scripting goes to far, it's that the real threat is network activity 00:38:58 s/goes to far/goes too far 00:39:26 TOPIC: AOB? 00:40:54 dauwhe: okay, then thanks everyone. We'll see you all soon! 00:41:08 Zakim, end meeting 00:41:08 As of this point the attendees have been MasakazuKitahara, BenSchroeter, wendyreid, MattChan, toshiakikoike, dauwhe, mgarrish, duga, shiestyle 00:41:10 RRSAgent, please draft minutes 00:41:10 I have made the request to generate https://www.w3.org/2022/06/09-epub-minutes.html Zakim 00:41:13 I am happy to have been of service, dauwhe; please remember to excuse RRSAgent. Goodbye 00:41:17 Zakim has left #epub 00:41:23 RRSAgent, bye 00:41:23 I see no action items