13:13:18 <RRSAgent> RRSAgent has joined #epub
13:13:18 <RRSAgent> logging to https://www.w3.org/2022/06/17-epub-irc
13:13:19 <Zakim> RRSAgent, make logs Public
13:13:21 <Zakim> please title this meeting ("meeting: ..."), ivan
13:13:34 <ivan> ivan has changed the topic to: Meeting Agenda 2022-06-17: https://lists.w3.org/Archives/Public/public-epub-wg/2022Jun/0010.html
13:13:35 <ivan> Chair: dauwhe
13:13:35 <ivan> Date: 2022-06-17
13:13:35 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2022Jun/0010.html
13:13:35 <ivan> Meeting: EPUB 3 Working Group Telco
13:44:52 <dauwhe> dauwhe has joined #epub
13:52:05 <mgarrish> mgarrish has joined #epub
13:53:03 <ivan> ivan has joined #epub
13:57:37 <zheng_xu> zheng_xu has joined #epub
13:58:37 <dauwhe> present+
13:58:41 <dauwhe> Zakim, who is here?
13:58:41 <Zakim> Present: dauwhe
13:58:43 <Zakim> On IRC I see zheng_xu, ivan, mgarrish, dauwhe, RRSAgent, Zakim, github-bot, jcraig, npd, `join_subline, hober, florian
13:58:46 <zheng_xu> present+
13:59:09 <MasakazuKitahara> MasakazuKitahara has joined #epub
13:59:16 <MattChan> MattChan has joined #epub
13:59:19 <MasakazuKitahara> present+
13:59:35 <toshiakikoike> toshiakikoike has joined #epub
13:59:45 <toshiakikoike> present+
14:00:25 <wendyreid> wendyreid has joined #epub
14:00:26 <MattChan> present+
14:00:42 <wendyreid> present_
14:00:49 <wendyreid> present+
14:00:53 <ivan> present+
14:01:02 <ivan> present+ mgarrish
14:01:07 <mgarrish> present+
14:01:11 <ivan> present+ brady
14:01:19 <MattChan> scribe+
14:01:23 <ivan> present+ toshiakikoike
14:01:27 <duga> duga has joined #epub
14:01:29 <ivan> present+ avneesh
14:01:32 <duga> present+
14:01:36 <AvneeshSingh> AvneeshSingh has joined #epub
14:01:41 <AUbbink> AUbbink has joined #epub
14:01:44 <ivan> present+ AUbbink
14:01:46 <AvneeshSingh> present+
14:02:13 <ivan> present+ charlesL
14:02:17 <dauwhe> https://github.com/w3c/epub-specs/issues/2322
14:02:21 <MattChan> TOPIC: Malicious Symbolic Links in EPUB
14:02:24 <CharlesL> CharlesL has joined #epub
14:02:29 <CharlesL> present+
14:03:14 <MattChan> dauwhe: this was raised as possible security issue as a way to create links to the local fs. Because these things are OS dependent, we have been working on how to define this requirement, and how stringent to be. Also investigating how epubcheck can help
14:03:21 <dauwhe> q?
14:03:23 <duga> q+
14:03:23 <dauwhe> https://github.com/w3c/epub-specs/issues/2322#issuecomment-1157847432
14:03:25 <dauwhe> ack du
14:04:06 <ivan> github-bot, bye
14:04:06 <github-bot> github-bot has left #epub
14:04:09 <MattChan> duga: the SHOULD NOT is a little weird because the purpose of SHOULD is that 'we don't think you should do this, but there are exceptional cases where it might make sense'
14:04:18 <dauwhe> q?
14:04:37 <mgarrish> q+
14:04:46 <dauwhe> ack mg
14:04:50 <MattChan> ... we're using it to me 'we're not sure how to express this so we'll just say SHOULD NOT'
14:05:13 <MattChan> mgarrish: why not make it make it a MUST NOT and accept that epubcheck can't catch everything?
14:05:22 <dauwhe> q?
14:05:29 <ivan> q+
14:05:52 <MattChan> duga: problem with a MUST is that we are trying to define behaviour over an undefined concept, so it's hard to put normative statements around that
14:05:55 <dauwhe> ack iv
14:06:22 <MattChan> ivan: agreed. I've tried to find language to fit this, but I couldn't.
14:06:54 <MattChan> ... I would love to say 'MUST NOT' but not sure how to define the prohibited behaviour
14:07:10 <MattChan> ... and I agree that using SHOULD NOT is vague for the same reasons
14:07:15 <duga> q+
14:07:19 <dauwhe> ack dug
14:07:23 <dauwhe> q+
14:07:59 <MattChan> duga: this isn't a real problem, there aren't a lot of epubs with symlinks in it. If you do put symlink it, your epub will probably break on most RS.
14:08:31 <MattChan> ... real risk here is that someone finds out that there is a key secret file in a RS, and they make an epub with a symlink to the file, and then exfiltrate the data
14:08:46 <MattChan> ... we just want to make sure RS devs know that this is a threat
14:08:58 <dauwhe> ack da
14:09:00 <MattChan> ... in practice, people aren't doing this
14:09:24 <MattChan> dauwhe: and we're already catching some of this. I tested this in an epub, and epubcheck threw an error
14:09:50 <MattChan> ... so even if we can't define these things, they don't match the signature of the things we do allow
14:10:21 <MattChan> mgarrish: you could set the symlink as a data file to prevent it from being checked, but if someone is up to no good there isn't a guaranteed way to find it
14:10:41 <MattChan> dauwhe: i could see it being done accidentally, like if you had an alias on your desktop and accidentally put it in your epub
14:10:57 <MattChan> ... i'm also okay with doing this even if we don't have an iron clad definition of what it is
14:12:08 <ivan> Proposed: proceed as described in https://github.com/w3c/epub-specs/issues/2322#issuecomment-1157847432 and then close the issue
14:12:33 <dauwhe> +1
14:12:35 <wendyreid> +1
14:12:36 <ivan> +1
14:12:36 <duga> +1
14:12:37 <MasakazuKitahara> +1
14:12:38 <MattChan> +1
14:12:38 <zheng_xu> +1
14:12:39 <toshiakikoike> +1
14:12:49 <CharlesL> +1
14:13:29 <ivan> resolved: proceed as described in https://github.com/w3c/epub-specs/issues/2322#issuecomment-1157847432 and then close the issue
14:13:43 <dauwhe> https://github.com/w3c/epub-specs/issues/2320
14:13:46 <MattChan> TOPIC: Consider security implications of URI schemes
14:14:00 <Jen_G> Jen_G has joined #epub
14:14:04 <Jen_G> Present+
14:14:13 <MattChan> dauwhe: not sure what to do here because having a mailto: link is a pretty ordinary thing
14:14:21 <dauwhe> q?
14:14:22 <MattChan> ... but the fact that these can be abused is a problem
14:14:38 <MattChan> ivan: we might be getting into the same problem as with symlinks if we try to be precise about it
14:14:43 <mgarrish> q+
14:15:04 <MattChan> ... we found some, like file: that we definitely want to avoid, but not sure how to make a general statement about this
14:15:04 <duga> q+
14:15:26 <MattChan> ... other than maybe 'be careful about which URI schemes you use'
14:15:48 <MattChan> ... for example, you don't want to open up the discussion about bitcoin here
14:15:51 <dauwhe> ack mg
14:16:36 <MattChan> mgarrish: we made the change a few weeks back that remote resources should be referenced by HTTPS, for other URI schemes, they will probably spawn some other app (dailing app, mail client)
14:16:36 <dauwhe> q+
14:16:51 <MattChan> ... not sure this is our problem to solve, feels like we are going a little far afield
14:16:55 <dauwhe> ack du
14:17:00 <MattChan> ... new schemes come up all the time
14:17:35 <MattChan> duga: i think we've already fixed this. 1. URI schemes that are used internally - resolved with banning file: and HTTPS, 2. URI scheme that goes to another app
14:17:46 <MattChan> ... you may not recognize that a link is of this 2nd type
14:18:10 <MattChan> ... but we've added a suggestion that links external to the epub trigger notification to user
14:18:22 <MattChan> ivan: not sure that that 2nd part is in the spec yet
14:18:44 <MattChan> duga: okay, then let's recommend a 'hey, you're leaving our secure space now' to external links
14:18:51 <MattChan> ... that would solve this problem
14:19:30 <MattChan> ... most apps are good about this. They won't automatically take an action when they open.
14:19:33 <dauwhe> ack da
14:19:57 <MattChan> duga: i think informing user and getting consent is key here, not worrying about technical details
14:20:07 <MattChan> mgarrish: I don't recall this being in the spec
14:20:19 <MattChan> ivan: yes, we discussed this in a prior meeting
14:20:29 <MattChan> mgarrish: but not in the security section currently
14:21:04 <MattChan> s/duga: i think informing/dauwhe: i think informing
14:21:50 <MattChan> ivan: is this going to be a SHOULD or a MUST?
14:22:15 <MattChan> duga: SHOULD. Preserves the ability for user consent to be subject to a global allow
14:22:18 <wendyreid> Proposed: Recommend the user SHOULD be given notification about links and their destination as part of RS recommendations, close issue 2320
14:22:19 <dauwhe> +1
14:22:20 <CharlesL> +1
14:22:21 <toshiakikoike> +1
14:22:22 <wendyreid> +1
14:22:22 <mgarrish> +1
14:22:23 <duga> +1
14:22:24 <MattChan> +1
14:22:26 <AUbbink> +1
14:22:28 <zheng_xu> +1
14:22:30 <ivan> +1
14:22:31 <MasakazuKitahara> +1
14:22:40 <wendyreid> RESOLVED: Recommend the user SHOULD be given notification about links and their destination as part of RS recommendations, close issue 2320
14:22:45 <MattChan> ivan: mgarrish can you find where we want to put this?
14:23:17 <dauwhe> https://github.com/w3c/epub-specs/issues/2317
14:23:29 <MattChan> TOPIC: Reading system requirement to resolve property datatype values
14:23:49 <MattChan> wendyreid: i attempted to write some tests about the property datatype values
14:24:00 <MattChan> ... these can appear in 2 places: OPF and content documents themselves
14:24:12 <MattChan> ... applies to any of the vocab, e.g. dc
14:24:29 <MattChan> ... the way it is currently worded in spec, we are expecting RS to resolve those prefixes to URLs
14:24:45 <MattChan> ... e.g. a11y would resolve to an expanded URL that takes you to a fragment
14:24:58 <MattChan> ... 'RS must resolve this to a URL'
14:24:58 <ivan> q+
14:25:27 <MattChan> ... but how to tell if RS is doing this in a test? Also, are RS really doing this? Because RS just needs to tell what kind of property it is
14:25:33 <dauwhe> ack iv
14:25:51 <MattChan> ivan: it is clearly something that is sneaking into the spec from the RDFa world
14:25:55 <mgarrish> q+
14:26:05 <MattChan> ... which says that every property that you use must be identifiable by an URI
14:26:23 <MattChan> ... what these prefixes do is to abbreviate those URIs
14:26:49 <MattChan> ... I tried testing by saying that if RS really did this, then I would be able to use the full URI wherever I would use the prefixed version, and the behaviour would be the same
14:26:59 <MattChan> ... and all RS I tried failed on this test
14:27:23 <MattChan> ... so we have functionality here that is already heading towards under-implemented path unless we change it
14:27:38 <MattChan> ... essentially the whole prefix mechanism becomes unnecessary
14:28:07 <MattChan> ... i don't think the package document is suitable for RDFa anyway
14:28:21 <MattChan> ... maybe content document might be RDFa-able
14:28:42 <MattChan> mgarrish: the package document was supposed to be RDFa-lite
14:28:56 <laurent_> laurent_ has joined #epub
14:29:09 <MattChan> ... so RDFa was an underpinning, but my understanding was that we were never requiring RS to process as RDFa
14:29:27 <MattChan> ... so if you wanted to treat them as just tokens, you could
14:29:53 <MattChan> ... to me i don't know if this requirement for RDFa processing should be a SHOULD or even a MAY
14:30:10 <MattChan> ... what we do have is the way that you should do the processing if you wanted to do that
14:30:27 <MattChan> ... I think we should make that distinction clear
14:30:36 <dauwhe> q?
14:30:39 <MattChan> ivan: okay, so the operative thing is to make that clarification
14:30:40 <dauwhe> ack mg
14:31:18 <MattChan> mgarrish: we've never had a statement that you must expand all data types. But somehow we say that you must support the mechanisms
14:31:39 <MattChan> ivan: there are a number of places in the spec where we say "if there is no prefix, then use this URL"
14:31:49 <MattChan> ... those statements would have to be clarified or changed then
14:32:12 <MattChan> ... so we wouldn't just be changing the vocab section
14:32:28 <MattChan> mgarrish: i'd have to review the spec
14:32:45 <wendyreid> https://w3c.github.io/epub-specs/epub33/rs/#sec-vocab-assoc
14:32:51 <MattChan> ... it should be like everything else in the spec i,e. 'if you are doing it, then here are the mechanisms'
14:33:02 <MattChan> wendyreid: i think all the MUSTs are there, but they are all MUSTs
14:33:22 <MattChan> ... these are all meant to be testable, and i have yet to find a way to test them
14:33:47 <MattChan> ... so maybe we don't have an action today, other than giving mgarrish time to review?
14:34:56 <dauwhe> https://github.com/w3c/epub-specs/pull/2330
14:34:57 <MattChan> TOPIC: Changed the RS section on i18n
14:35:49 <MattChan> ivan: this is a general problem. In the RS spec, we have a general statement of the sort 'RS MUST treat HTML or CSS etc. as conforming to those other specs'
14:36:11 <MattChan> ... and we decided that all our testing concentrates on those things that epub spec adds
14:36:57 <MattChan> ... but there are some statements in i18n section (e.g. xml-lang, dir) where we are creating tests for features specified in HTML
14:38:19 <MattChan> ... the PR changes i18n section so that only the additional features are subject to normative statements
14:39:03 <MattChan> ... similarly, there is another issue. Daniel, who is now running our tests on Thorium, says that we should not put the acid test in the test suite since it will fail all the time
14:39:32 <MattChan> ... there we make a general statement that RS should implement CSS, but then later we say that RS MUST implement CSS in such and such a way
14:39:51 <MattChan> ... these latter normative statements are really superseded by other specs
14:40:20 <MattChan> ... I would propose to allow merging this PR about the changes to i18n now, and then review the rest of the spec to see how pervasive this sort of issue is in other sections
14:41:10 <wendyreid> Proposed: Merge PR 2330, review remainder of specification for similar issues
14:41:18 <dauwhe> +1
14:41:18 <wendyreid> +1
14:41:19 <toshiakikoike> +1
14:41:19 <mgarrish> +1
14:41:20 <CharlesL> +1
14:41:21 <MattChan> +1
14:41:24 <duga> +1
14:41:24 <MasakazuKitahara> +1
14:41:25 <zheng_xu> +1
14:41:29 <ivan> +1
14:42:23 <wendyreid> RESOLVED: Merge PR 2330, review remainder of specification for similar issues
14:42:53 <MattChan> ivan: if we find additional similar things, then we should come up with a PR with all those changes. e.g. Including the one about the acid test
14:43:11 <MattChan> TOPIC: AOB?
14:43:27 <ivan> q+
14:43:31 <dauwhe> ack iv
14:43:55 <MattChan> ivan: the Thorium team is probably the first to systemically go through the tests
14:44:13 <MattChan> ... out of the 100s we currently have, they have 30-40 with which they have problems
14:44:24 <MattChan> ... they will raise issues for those where they have problems
14:44:37 <MattChan> ... there are some features that Thorium just does not implement
14:45:44 <MattChan> ... the other thing is that I have reached out to the Chinese team. Tried to get our Chinese colleagues to reach out to Xiaomi to see if they will participate in our tests
14:45:54 <MattChan> ... also we are still missing test from the test suite
14:45:59 <MattChan> ... we need more test contributors!
14:46:22 <MattChan> ... e.g. how would you make a general test on disallowing file: URLs?
14:46:35 <MattChan> ... if you can find a general way to do that, I would be grateful
14:47:01 <MattChan> dauwhe: okay, thank you everyone for being here
14:47:07 <CharlesL> CharlesL has left #epub
14:47:08 <MattChan> ... we will see everyone next time
14:47:28 <ivan> rrsagent, draft minutes
14:47:28 <RRSAgent> I have made the request to generate https://www.w3.org/2022/06/17-epub-minutes.html ivan
14:48:20 <ivan> zakim, end meeting
14:48:20 <Zakim> As of this point the attendees have been dauwhe, zheng_xu, MasakazuKitahara, toshiakikoike, MattChan, wendyreid, ivan, mgarrish, brady, avneesh, duga, AUbbink, AvneeshSingh,
14:48:23 <Zakim> ... charlesL, Jen_G
14:48:23 <Zakim> RRSAgent, please draft minutes
14:48:23 <RRSAgent> I have made the request to generate https://www.w3.org/2022/06/17-epub-minutes.html Zakim
14:48:25 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
14:48:28 <ivan> rrsagent, bye
14:48:28 <RRSAgent> I see no action items