23:34:59 <RRSAgent> RRSAgent has joined #epub
23:34:59 <RRSAgent> logging to https://www.w3.org/2022/05/26-epub-irc
23:35:01 <Zakim> RRSAgent, make logs Public
23:35:02 <Zakim> please title this meeting ("meeting: ..."), dauwhe
23:35:10 <dauwhe> Meeting: EPUB 3 Working Group Telecon
23:35:16 <dauwhe> Chair: Dave Cramer
23:49:44 <mgarrish> mgarrish has joined #epub
23:57:27 <shiestyle> shiestyle has joined #epub
23:58:56 <toshiakikoike> toshiakikoike has joined #epub
23:59:04 <toshiakikoike> present+
23:59:18 <dauwhe> present+
23:59:25 <MattChan> MattChan has joined #epub
23:59:46 <MasakazuKitahara> MasakazuKitahara has joined #epub
23:59:52 <MasakazuKitahara> present+
23:59:57 <MattChan> present+
00:00:14 <wendyreid> wendyreid has joined #epub
00:00:44 <shiestyle> present+
00:00:54 <wendyreid> preent+
00:00:57 <wendyreid> present+
00:01:09 <mgarrish> present+
00:01:10 <MattChan> scribe+
00:03:00 <MattChan> dauwhe: welcome all to this post-CR meeting
00:03:09 <MattChan> ... this means that our highest priority is testing
00:03:22 <MattChan> ... but we also have some issues around privacy and security
00:03:34 <MattChan> ... which we will discuss today
00:03:37 <dauwhe> https://github.com/w3c/epub-specs/pull/2297
00:03:39 <MattChan> TOPIC: security and privacy - Making statements normative
00:04:08 <MattChan> dauwhe: one of the key elements of the feedback was that most of our security and privacy section was non-normative, and npd thought it should be
00:04:10 <dlazin> dlazin has joined #epub
00:04:17 <dlazin> present+
00:04:29 <MattChan> ... this PR makes that change so that many of the things we discussed non-normative have become normative, but still SHOULD
00:04:53 <dauwhe> q?
00:04:54 <MattChan> ... reading through this PR, it seems to be a better statement of our values and the importance of privacy and security
00:05:31 <duga> duga has joined #epub
00:05:48 <duga> present+
00:06:06 <MattChan> mgarrish: this also addresses concern re. unsigned epubs and whether RS can trust such epubs
00:06:23 <MattChan> ... not sure how to phrase, because unsigned doesn't necessarily mean untrustworthy
00:06:37 <MattChan> ... language now gives a lot of leeway to RS
00:06:54 <MattChan> ... can't necessarily be enforced, but still good practice that we are now throwing our weight behind
00:07:28 <MattChan> dauwhe: still significant progress versus previous versions of epub on this
00:07:54 <MattChan> wendyreid: we can't merge anything right now because we have it set so that it auto publishes after a merge
00:08:03 <MattChan> ... we need to figure out if we need a new snapshot
00:08:33 <dauwhe> q?
00:08:41 <wendyreid> Proposed: Approve PR 2297
00:08:45 <dauwhe> +1
00:08:47 <mgarrish> +1
00:08:47 <MattChan> +1
00:08:47 <dlazin> +1
00:08:49 <toshiakikoike> +1
00:08:49 <wendyreid> +1
00:08:49 <shiestyle> +1
00:08:58 <duga> +1
00:09:03 <MasakazuKitahara> +1
00:09:31 <wendyreid> RESOLVED: Approve PR 2297
00:09:38 <dauwhe> https://github.com/w3c/epub-specs/issues/2263
00:09:42 <MattChan> TOPIC: security and privacy - External Resources should be loaded securely
00:09:45 <dauwhe> https://github.com/w3c/epub-specs/pull/2299
00:09:52 <MattChan> dauwhe: this issue comes with this PR
00:10:05 <MattChan> ... this is around remote resources, and recommended that they be served over HTTPS
00:10:17 <MattChan> ... avoiding person in the middle and other such network attacks
00:10:20 <dauwhe> q?
00:10:24 <dlazin> q+
00:10:34 <dauwhe> ack dl
00:10:34 <wendyreid> ack dlazin
00:10:46 <MattChan> dlazin: my only concern is the PR itself is not super clear in its language
00:10:55 <MattChan> ... "RS may not load resources"
00:11:06 <MattChan> ... what we mean is there is a chance RS may not load
00:11:19 <MattChan> ... I'll do a pass
00:11:51 <MattChan> dauwhe: this is SHOULD level, so would we test whether a remote resource is served via HTTP, and that would result in a warning from epubcheck?
00:12:12 <MattChan> mgarrish: yes, that is what I would expect
00:12:23 <MattChan> dauwhe: this could affect existing content, but I expect it would be rare
00:12:35 <MattChan> mgarrish: generally the direction of the web is HTTPS too
00:13:04 <MattChan> ... this will cause some warnings, but security outweighs. We should move in the direction of the web
00:13:19 <MattChan> dauwhe: using backwards compat as reason not to fix security issue isn't where we want to be
00:13:36 <dauwhe> q?
00:13:37 <wendyreid> Proposed: Approve PR 2299, close issue 2265
00:13:41 <duga> +1
00:13:45 <wendyreid> +1
00:13:45 <shiestyle> +1
00:13:46 <MattChan> +1
00:13:46 <MasakazuKitahara> +1
00:13:47 <dlazin> +1
00:13:50 <dauwhe> +1
00:13:51 <toshiakikoike> +1
00:13:52 <mgarrish> +1
00:13:59 <wendyreid> RESOLVED: Approve PR 2299, close issue 2265
00:14:42 <dauwhe> https://github.com/w3c/epub-specs/issues/2265
00:14:50 <MattChan> TOPIC: Security and privacy - Authenticity and Integrity checks
00:15:20 <MattChan> dauwhe: we did add a section about this in the previously approved PR 2297
00:15:24 <dauwhe_> dauwhe_ has joined #epub
00:15:36 <MattChan> ... XML does support signing of the epub
00:16:06 <duga> q+
00:16:16 <dauwhe> ack du
00:16:19 <MattChan> ... so there is a mechanism for this, but i'm not aware of an epub RS that supports signing or that would alert end user/do something else if faced with signed epub where signature is invalid
00:17:02 <MattChan> duga: an attacker could just resign the epub with their own signature. RS can't know what signature should be
00:18:20 <MattChan> dauwhe: so should we just note that we have a signature capability, but given the nature of epub it is tough to ascertain a chain of trust even though it is possible on the web?
00:18:26 <MattChan> duga: the PR itself looks fine
00:19:29 <MattChan> ... we have to resolve all issues not right? and the raiser must be happy with resolution? This is part of CR transition?
00:19:32 <MattChan> wendyreid: yes
00:20:11 <MattChan> ... we can close the issue, and then make sure that PR gets an okay from security and privacy reviewers
00:20:26 <dauwhe> https://github.com/w3c/epub-specs/issues/2266
00:20:35 <MattChan> TOPIC: Security and privacy - Review of issues in “Reading Between the Lines"
00:20:48 <dauwhe> https://lirias.kuleuven.be/retrieve/616428
00:21:01 <MattChan> dauwhe: this is a paywalled academic paper, link is to the author's own website
00:21:32 <MattChan> ... they tested close to 100 epub RS, with some automated tests of security issues (e.g. scripting). Concluded with a few recommendations on how to change the spec
00:21:37 <MattChan> ... I've looked at it briefly
00:22:14 <MattChan> ... we were talking earlier about remote resources, but it seems that we allow use of local resources, which may be a significant security hole
00:22:45 <MattChan> ... it also mentioned that half of RS that supported js supported geolocation, etc.
00:23:11 <MattChan> ... they say it wasn't mentioned in spec, but it should be covered by our recommendation for soliciting user consent
00:23:26 <dlazin> q+
00:23:27 <MattChan> ... I think several of us need to review issues raised in it
00:23:41 <MattChan> wendyreid: mgarrish gave good summary of points in issue
00:24:16 <MattChan> ... authors make some suggestions around the support of js and that the spec should specify no access to local file system
00:24:20 <duga> q+
00:24:33 <MattChan> ... but we've always strayed from explicitly telling RS how to build an RS
00:24:33 <mgarrish> q+
00:24:58 <MattChan> ... their points are valid, and the RSes features should take those issues up
00:25:09 <MattChan> ... rather than changes that should be made in the spec itself
00:25:12 <dauwhe> ack dlazin
00:25:21 <MattChan> s/RSes features/RSes featured
00:25:36 <MattChan> dlazin: should we invite them to give us a presentation and some recommendations?
00:25:55 <MattChan> dauwhe: i like the idea of having a dialog with them. They seem interested and knowledgeable
00:26:02 <MattChan> wendyreid: I also like the idea
00:26:08 <MattChan> dauwhe: good topic for next chairs call
00:26:11 <dauwhe> ack du
00:26:20 <MattChan> duga: +1
00:26:51 <MattChan> ... also re access to file system, does that mean you can't access the epub? Difficult not to be overly broad in prohibitions
00:27:09 <dauwhe> ack mg
00:27:25 <MattChan> mgarrish: this is why I didn't try to write a PR to answer this one
00:27:35 <MattChan> ... their main point of contention is file: URLs right?
00:27:45 <MattChan> ... we can block those in authoring without breaking epub
00:27:52 <MattChan> ... trickier on RS side
00:28:09 <MattChan> ... we talk in theory about how file: URLs could be used, but does anyone even do this in reality?
00:28:29 <dauwhe> <xi:include href=file:://usr/passwd>
00:28:29 <MattChan> ... if there was a way to block that I personally wouldn't take issue, but the language would be tricky from RS perspective
00:28:39 <dauwhe> q?
00:28:45 <MattChan> wendyreid: I've found the authors of the paper online
00:28:53 <MattChan> dauwhe: that's a great way forward on this issue
00:29:13 <MattChan> ... we could probably learn from each other
00:29:45 <dauwhe> https://github.com/w3c/epub-specs/pull/2301
00:30:00 <dauwhe> https://github.com/w3c/epub-specs/issues/2264
00:30:23 <MattChan> TOPIC: Security and privacy - Persistent storage security
00:30:29 <MattChan> dauwhe: about unrelated documents
00:30:45 <MattChan> mgarrish: this is about two requirements that were still in the spec, but which are no longer applicable
00:31:06 <MattChan> ... i.e. language around each document being treated as its own domain
00:31:43 <MattChan> ... if you absolutely need to use persistent storage, then we recommend you encrypt instead of storing as plaintext
00:32:27 <MattChan> dauwhe: a lot of people have done proofs of concept of drafting epubs that can read data from local storage created by a different epub
00:32:48 <MattChan> mgarrish: not sure if js encrypting is trivial to break or not, but at least we are saying to pay attention to this
00:33:23 <MattChan> ... we also recommend just not storing sensitive data in the first place, if you don't have to
00:33:49 <wendyreid> Proposed: Approve PR 2301, close issue 2264
00:33:55 <dauwhe> +1
00:33:55 <mgarrish> +1
00:33:56 <duga> +1
00:33:57 <shiestyle> +1
00:33:58 <wendyreid> +1
00:33:58 <dlazin> +1
00:33:59 <toshiakikoike> +1
00:34:01 <MattChan> +1
00:34:01 <MasakazuKitahara> +1
00:34:15 <wendyreid> RESOLVED: Approve PR 2301, close issue 2264
00:34:46 <dauwhe> https://github.com/w3c/epub-tests/pull/148
00:34:49 <MattChan> TOPIC: Testing - standardize formatting of mol-navigation
00:35:15 <MattChan> dlazin: this is a discussion of a comment in the PR
00:35:47 <MattChan> ... this was a test for MO, and this was a test for a MUST within the MO section (which is a should)
00:36:18 <MattChan> ... Ivan has created a way to filter should tests, so that, for example, a tester could say 'i'm not worried about these should tests'
00:36:45 <MattChan> ... but in order for us to determine whether the spec is implementable, the MUSTs within the should sections are still important
00:36:58 <MattChan> ... we need to have 2 independent implementations of these MUSTs too
00:37:27 <MattChan> ... so what is the purpose of marking some tests as should, and based on the answer to same, how do we treat MUSTs in should sections?
00:38:02 <MattChan> dauwhe: do we have this problem on a higher level? If we allow possibility of audio only RS, then anything related to visual only is not required
00:38:30 <MattChan> dlazin: that's the opposite of this, because those tests would not be marked as shoulds, and could not be accidentally filtered out
00:38:48 <MattChan> dauwhe: so in some sense we may need to leave it up to the RS dev, e.g. if the RS in question doesn't support MO
00:38:52 <dauwhe> q?
00:39:18 <MattChan> mgarrish: so we're concerned about how to handle filtering? Can Ivan just fix this in the filtering script?
00:39:50 <MattChan> dlazin: I think its what is the purpose of marking a test as a should test? Are we telling RS tester not to worry about this? Or are we telling Director not to worry about this?
00:40:09 <duga> q+
00:40:12 <MattChan> ... I think purpose of our tests is CR. So I would think we do NOT mark such tests as should tests
00:40:26 <MattChan> ... maybe we should defer this until Ivan is here, this isn't urgent
00:40:27 <dauwhe> ack duga
00:40:53 <MattChan> duga: yes, fine to defer. But it seems these tests are going to be marked as MUSTs because they ARE MUSTs.
00:41:00 <MattChan> ... otherwise they would just be SHOULD in the spec
00:41:26 <MattChan> wendyreid: I would be more worried about this if it wasn't in a feature like MO that is already fairly well supported
00:41:49 <MattChan> ... could some of the more technical features of MO be at risk? Sure. But the core feature of MO I'm not worried about
00:43:26 <MattChan> dlazin: hearing duga's reply, and no disagreements, I'm tending towards not flagging them as should tests. I don't think Ivan feels strongly, but we can follow up with him next meeting
00:43:40 <MattChan> wendyreid: I'll wait for the PR for us to resolve
00:43:52 <MattChan> TOPIC: AOB?
00:44:12 <MattChan> duga: don't accidentally sign up for the wrong TPAC conference
00:44:34 <MattChan> wendyreid: there's a name conflict. 2 conferences named TPAC in Vancouver in the same time
00:44:46 <MattChan> s/in the same time/at the same time
00:45:50 <MattChan> dlazin: within a few days W3C will link us to a block of discount TPAC hotels
00:46:11 <MattChan> dauwhe: the information is forthcoming
00:48:08 <MattChan> ... okay, that wraps us up, thanks everyone!
00:48:32 <dauwhe> zakim, end meeting
00:48:32 <Zakim> As of this point the attendees have been toshiakikoike, dauwhe, MasakazuKitahara, MattChan, shiestyle, wendyreid, mgarrish, dlazin, duga
00:48:34 <Zakim> RRSAgent, please draft minutes
00:48:34 <RRSAgent> I have made the request to generate https://www.w3.org/2022/05/26-epub-minutes.html Zakim
00:48:37 <Zakim> I am happy to have been of service, dauwhe; please remember to excuse RRSAgent.  Goodbye
00:48:41 <Zakim> Zakim has left #epub
00:48:42 <dauwhe> rrsagent, bye
00:48:42 <RRSAgent> I see no action items