13:29:55 <RRSAgent> RRSAgent has joined #epub
13:29:55 <RRSAgent> logging to https://www.w3.org/2022/10/07-epub-irc
13:29:57 <Zakim> RRSAgent, make logs Public
13:29:59 <Zakim> please title this meeting ("meeting: ..."), ivan
13:30:13 <ivan> ivan has changed the topic to: Meeting Agenda 2022-10-07: https://lists.w3.org/Archives/Public/public-epub-wg/2022Oct/0000.html
13:30:14 <ivan> Chair: dauwhe
13:30:14 <ivan> Date: 2022-10-07
13:30:14 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2022Oct/0000.html
13:30:14 <ivan> Meeting: EPUB 3 Working Group Telco
13:30:14 <ivan> Regrets+ matthew, tzviya, toshiakitoike
13:40:30 <ivan_> ivan_ has joined #epub
13:52:33 <dauwhe> dauwhe has joined #epub
13:56:29 <dauwhe> Zakim, who is here?
13:56:29 <Zakim> Present: (no one)
13:56:31 <Zakim> On IRC I see dauwhe, ivan_, RRSAgent, Zakim, hober, github-bot, Github, npd, jcraig
13:58:03 <ivan_> present+ rickj
13:58:07 <ivan_> present+
13:59:06 <MasakazuKitahara> MasakazuKitahara has joined #epub
13:59:18 <MasakazuKitahara> present+
13:59:22 <dauwhe> present+
14:00:02 <ivan_> present+ dhall
14:00:09 <ivan_> present+ wendy
14:00:24 <romain> romain has joined #epub
14:00:40 <rickj> rickj has joined #epub
14:00:44 <wendyreid> wendyreid has joined #epub
14:00:47 <rickj> present+
14:00:54 <wendyreid> present+
14:00:58 <romain> present+
14:01:39 <ivan_> present+ bduga
14:01:51 <CharlesL> CharlesL has joined #epub
14:02:02 <CharlesL> present+
14:02:26 <dhall_> dhall_ has joined #epub
14:02:35 <dhall_> present+
14:03:02 <duga> duga has joined #epub
14:03:06 <duga> present+
14:03:10 <ivan_> present+ billk
14:03:12 <dauwhe> scribenick: dauwhe
14:03:18 <Bill_Kasdorf> Bill_Kasdorf has joined #epub
14:03:27 <gpellegrino> gpellegrino has joined #epub
14:03:40 <Bill_Kasdorf> present+
14:03:43 <dauwhe> wendyreid: first agenda item is viewport metadata
14:03:45 <ivan_> chair: wendy
14:03:53 <dauwhe> https://github.com/w3c/epub-specs/issues/2442
14:04:00 <gpellegrino> present+
14:04:06 <ivan_> topic: https://github.com/w3c/epub-specs/issues/2442
14:04:09 <dauwhe> romain: I had a late review of new viewport spec
14:04:19 <gpellegrino_> gpellegrino_ has joined #epub
14:04:19 <dauwhe> ... wondering if it was too strict
14:04:24 <ivan_> q+
14:04:24 <dauwhe> ... is it enough for reading systems?
14:04:32 <dauwhe> ... talking about viewports meta tag for FXL
14:04:48 <dauwhe> ... for reflowable we are covered (RS must ignore viewport)
14:04:58 <dauwhe> ... in FXL this is important because it sets ICB
14:05:05 <dauwhe> ... there's an EBNF grammar to defined
14:05:23 <dauwhe> ... it's more constrained than what's in the CSS draft it comes from
14:05:49 <dauwhe> ... it's more constrained than what browsers/reading systems can extract info from
14:05:55 <dauwhe> ... so should we relax the grammar a bit
14:06:08 <dauwhe> ... or further specify how reading systems should extract useful values from it
14:06:26 <dauwhe> ack iv
14:06:36 <MURATA> MURATA has joined #epub
14:06:57 <dauwhe> ivan_: to pick up on what romain said
14:07:12 <wendyreid_> wendyreid_ has joined #epub
14:07:14 <github-bot> github-bot has joined #epub
14:07:25 <dauwhe> ... the spec does say somewhere that if the viewport spec is wrong,,  it should use device height/width
14:07:29 <wendyreid_> q?
14:07:36 <dauwhe> ... it's not only strict, it
14:07:53 <romain> q+
14:07:58 <wendyreid> https://github.com/w3c/epub-specs/issues/2442
14:07:58 <wendyreid> q?
14:07:58 <hober> hober has joined #epub
14:08:05 <ivan_> https://github.com/w3c/epub-specs/issues/2442#issuecomment-1271300202
14:08:24 <dauwhe> ... for example Apple can make sense of an invalid viewport tag
14:08:48 <dauwhe> ... what I propose is to relax the requirement to use device sizes when there is a problem
14:08:57 <dhall_> q+
14:08:59 <dauwhe> ... and instead say the RS should warn the user/author
14:09:09 <dauwhe> ... and then it can do a best attempt to do something sensible
14:09:19 <dauwhe> ... it can try to extract a window size
14:09:38 <dauwhe> ... the only place where there's a different problem
14:09:51 <dauwhe> ... if you have a number of content files and forget to set the viewport for one of them
14:09:59 <dauwhe> ... today there is nothing there so you use device sizes
14:10:21 <dauwhe> ... the other possibility is to [1] warn user and [2] go back to previous spine element and use that viewport size
14:10:28 <dauwhe> q?
14:10:31 <wendyreid> ack romain
14:10:53 <dauwhe> romain: I agree that the spec already set that device height/width should be used when faced with an invalid value
14:11:03 <dauwhe> ... so maybe relaxing RS spec is the way to go
14:11:12 <dauwhe> ... I'm not convinced RSs should warn users
14:11:19 <wendyreid> +1
14:11:21 <wendyreid> q+
14:11:39 <dauwhe> ... if the reading system can do its best to render something, or make up a value that's good enough
14:11:47 <dauwhe> ... as transparently as possible
14:12:05 <ivan_> present+ makoto
14:12:07 <dauwhe> ... there's a caase with valid viewport but specifies the width several times
14:12:21 <dauwhe> ... this is valid per grammar but don't say if it should pick first/last/any
14:12:48 <dauwhe> ... do we need to say something in RS spec? If there's dupes then it becomes invalid?
14:12:58 <wendyreid> ack dhall_
14:13:07 <dauwhe> dhall_: I like your rec there
14:13:18 <dauwhe> ... I would lean toward should report errors to user
14:13:27 <dauwhe> ... some could be unrecoverable, like xml parsing errors
14:13:42 <dauwhe> ... or there could be dev mode and remotely inspect
14:13:50 <dauwhe> ... but most readers won't be interested
14:13:57 <dauwhe> ... so "should" warn the users
14:14:14 <dauwhe> ... on multiple width values, add something to spec to prefer first value found
14:14:20 <duga> q+
14:14:23 <romain> or even MAY warn the users
14:14:26 <dauwhe> .... separately, what to do when there isn't anything specced
14:14:37 <dauwhe> ... typically in FXL books you have the same page size throughout
14:14:54 <dauwhe> ... different page size present challenges to the RS
14:15:17 <dauwhe> ... I like the idea of falling back to the most recent valid viewport
14:15:38 <dauwhe> ... if nothing is defined, do you fall back to device dimensions or something else?
14:15:51 <dauwhe> ... because device dimensions change with orientation
14:16:06 <wendyreid> ack wendyreid
14:16:09 <dauwhe> ... and what happens when dimensions change?
14:16:30 <dauwhe> wendyreid: as much as i like the idea of warning the user
14:16:56 <dauwhe> ... in the real world of RSs, telling the user that something is wrong with their viewport isn't helpful. There's nothing they can do.
14:17:14 <ivan_> q+
14:17:19 <dauwhe> ... this puts an undue burden on the user
14:17:38 <dauwhe> ... I think this should be an epubcheck thing
14:17:48 <dauwhe> ... I like idea of preferring first value
14:18:08 <dauwhe> ... RSes do lots of things to optimize for speed when they render FXL
14:18:22 <dauwhe> ... we use first viewport value and don't reparse
14:18:33 <dauwhe> ... so we don't support changing viewport sizes
14:18:58 <CharlesL> q+
14:19:10 <wendyreid> ack duga
14:19:19 <dauwhe> duga: agree with David and Wendy
14:19:28 <dauwhe> ... I would not say should warn the user, it's a bad idea
14:19:35 <dauwhe> ... and these are often kid's books :)
14:19:54 <dauwhe> ... we have end users and publishers
14:20:03 <dauwhe> ... might be helpful to talk about these two groups
14:20:10 <dhall_> q+
14:20:13 <dauwhe> ... I want my publishers to know but not my users
14:20:23 <dauwhe> ... you can reject something with a bad viewport
14:21:08 <dauwhe> ... I'm agnostic on which to pick of multiple values
14:21:15 <wendyreid> ack ivan_
14:21:17 <dauwhe> ... I think we do support multiple page sizes
14:21:34 <dauwhe> ivan_: we have multiple viewports in the spec
14:21:57 <rickj> +1 to Brady (et. al.) and differentiating messaging between readers and publishers
14:22:05 <dauwhe> ... (different page sizes for different files)
14:22:09 <dauwhe> ... we can't change that
14:22:14 <dauwhe> ... if they don't implement that's ok
14:22:30 <dauwhe> ... for reporting, I understand that I don't want reports going to kid
14:22:38 <dauwhe> ... I like the safari analogy of David
14:22:57 <dauwhe> ... I wonder if we should say something in the spec
14:23:00 <dauwhe> q+
14:23:21 <CharlesL> q-
14:23:22 <dauwhe> ... from standards point of view it's ok to say reading systems should issue a warning
14:23:47 <dauwhe> ... matt and I can come up with a larger PR
14:23:53 <wendyreid> ack dhall_
14:24:21 <dauwhe> dhall_: when I think of users, do you think of author and publisher as the same user
14:24:26 <dauwhe> ivan_: we don't specify that
14:24:43 <dauwhe> dhall_: I can see a publisher being interested in results from epubcheck
14:25:09 <dauwhe> ... I can see that authors that write their own epubs wouold benefit from warnings from RS
14:25:15 <dauwhe> ... do we use term "May"?
14:25:17 <dauwhe> ivan_: yes
14:25:24 <wendyreid> ack dauwhe
14:25:26 <wendyreid> scribe+
14:25:44 <wendyreid> dauwhe: We're talking a lot about the situation where the author messed up the viewport
14:25:50 <wendyreid> ... what choices the RS has in that case
14:25:57 <wendyreid> ... this sounds like EPUBCheck's job
14:26:04 <wendyreid> ... is the viewport parse-able
14:26:13 <wendyreid> ... compatibility issues, maybe it's a warning
14:26:25 <wendyreid> ... seems wrong to put this on the end user
14:26:30 <dauwhe> q?
14:26:49 <dauwhe> wendyreid: if we reach any sort of consensus we don't want to put anything on the end user/reader
14:26:57 <duga> q+
14:27:14 <dauwhe> ... we do want to warn the content creator (publisher/author)
14:27:41 <dauwhe> ... maybe we want to increase robustness of the section
14:27:41 <Bill_Kasdorf> I would recommend "EPUB creator
14:27:55 <dauwhe> ... but we want requirements around validity of viewport
14:28:04 <dauwhe> ... RSes rely on epubcheck
14:28:07 <dauwhe> q?
14:28:09 <wendyreid> ack duga
14:28:19 <dauwhe> duga: +1 to using may instead of should
14:28:35 <Bill_Kasdorf> s/"EPUB creator/"EPUB creator" vs. "content creator" because the person writing the book created the content but not the EPUB/
14:28:45 <dauwhe> ... this section isn't a real world problem except there was no spec to reference
14:28:55 <dauwhe> ... we're not actually seeing real problems in FXL books
14:30:40 <dauwhe> CharlesL: Q about checking viewport on mobile devices
14:30:56 <dauwhe> dauwhe: viewport is property of EPUB not device, spec says how to adapt
14:31:34 <wendyreid> Resolution: Ivan to adjust language to reflect content creator/EPUBCheck responsibility for viewport
14:31:57 <ivan_> Topic: https://github.com/w3c/epub-specs/issues/2447
14:32:08 <dauwhe> Topic: XML Security and internal parsed entities
14:32:22 <dauwhe> MURATA: old issue; more than 20 years ago
14:32:39 <ivan_> https://github.com/w3c/epub-specs/issues/2433
14:32:44 <dauwhe> ... related to external parsed entities issue 2433
14:32:59 <dauwhe> ... this issue is about INTERNAL parsed entities
14:33:09 <dauwhe> ... doesn't use external identifiers or URLs
14:33:20 <dauwhe> ... these are defined in internal DTD subsets
14:33:31 <dauwhe> https://en.wikipedia.org/wiki/Billion_laughs_attack
14:34:00 <dauwhe> ... if an internal reference references a different internal reference, things can get out of hand quickly
14:34:28 <ivan_> q+
14:34:30 <dauwhe> ... some EPUB reading systems ignore rec of XML and ignore internal parsed entities. This is non-conformant but avoids security issue
14:34:43 <dauwhe> ... what should we do? Prohibit internal DTD subsets?
14:34:55 <dauwhe> ... which gets rid of internal parsed entities.
14:35:11 <wendyreid> ack ivan_
14:35:21 <dauwhe> ... can exissting RSes be destryeed by malicious content?
14:35:29 <dauwhe> ivan_: thanks Makoto for raising the issue
14:35:58 <dauwhe> ... the problem is that removing the possibility to use internal entities is something we can't do because of existing epub docs that might use this
14:36:07 <dauwhe> ... we cannot invalidate existing content per our charter
14:36:28 <ivan_> https://github.com/w3c/epub-specs/pull/2451
14:36:46 <dauwhe> ... as part of a pull request that makoto and I did together is a separate section
14:36:56 <dauwhe> ... in the security section of RS spec
14:36:57 <ivan_> https://raw.githack.com/w3c/epub-specs/makoto-xml-conformance-change/epub33/rs/index.html#security-privacy-recommendations
14:37:16 <dauwhe> ... which say that RS should be aware of this problem and should deal with it.
14:37:26 <dauwhe> q+
14:37:38 <dauwhe> ... so we should draw attention to the issue
14:37:39 <duga> q+ to ask about known solutions
14:37:41 <wendyreid> ack dauwhe
14:37:58 <wendyreid> dauwhe: I don't think we can or should forbid internal entities
14:38:10 <wendyreid> ... the problem has been around 20 years and EPUB is still functional
14:38:26 <wendyreid> ... it's a security vulnerability, we may need to warn people in our security section
14:38:42 <wendyreid> ... ordering RSs to follow a specific algorithm might be overkill
14:38:46 <wendyreid> ... let's warn people
14:38:58 <wendyreid> MURATA: Basically, not our problem
14:39:01 <dauwhe> MURATA: this is not our problem :)
14:39:07 <wendyreid> ack duga
14:39:07 <Zakim> duga, you wanted to ask about known solutions
14:39:08 <dauwhe> q?
14:39:35 <ivan_> q+
14:39:37 <dauwhe> duga: this is a known problem in XML. Are there known solutions?
14:39:48 <dauwhe> ... do they have mitigations? Like in libxml?
14:40:23 <MURATA> +q
14:40:24 <wendyreid> ack ivan_
14:40:31 <dauwhe> "Defenses against this kind of attack include capping the memory allocated in an individual parser if loss of the document is acceptable, or treating entities symbolically and expanding them lazily only when (and to the extent) their content is to be used."
14:40:38 <dauwhe> ivan_: makoto may know
14:40:58 <dauwhe> ... makoto made some sample epubs, and we tested them
14:41:05 <dauwhe> ... I tested on Thorium and iBooks
14:41:13 <dauwhe> ... both reacted by rejecting the EPUB
14:41:22 <dauwhe> ... without identifying the problem
14:41:41 <dauwhe> ... we suspect they don't accept internal entities
14:41:44 <dauwhe> q?
14:41:49 <wendyreid> ack MURATA
14:41:58 <dauwhe> MURATA: I'm not aware of general solutions
14:42:10 <dauwhe> ... XML WG was aware of this issue, but had no good solutions
14:42:43 <dauwhe> ... thorium doesn't reject publication, it ignores the entity but not the entire publication
14:42:50 <dauwhe> ... this behavior is non-conformant
14:43:28 <wendyreid> dauwhe: I don't think it's entirely fair to say that this implementation is non-conformant because it's not deploying my vulnerability
14:43:37 <wendyreid> ... not fair to RS
14:43:39 <wendyreid> q+
14:43:44 <wendyreid> ack wendyreid
14:43:45 <ivan_> q+
14:43:58 <dauwhe> wendyreid: it's like the viewport convo
14:44:05 <dauwhe> ... we want to avoid putting burdens on readers
14:44:32 <dauwhe> q+
14:44:45 <dauwhe> ... does the fail quietly solution work?
14:44:50 <dauwhe> ... is that a bad thing?
14:44:58 <dauwhe> ack iv
14:45:00 <wendyreid> ack ivan_
14:45:07 <dauwhe> ... I think because we are running out of time
14:45:13 <dauwhe> ... people should look at the PR
14:45:18 <dauwhe> ... there are other things in the PR
14:45:26 <dauwhe> ... then we move on
14:45:28 <wendyreid> https://github.com/w3c/epub-specs/pull/2451
14:45:28 <duga> q+
14:45:32 <wendyreid> ack dauwhe
14:45:43 <wendyreid> dauwhe: I think we add something to the security section
14:46:06 <wendyreid> ... it hasn't been a problem in the past, internal entities aren't usually a problem unless malicious
14:46:20 <wendyreid> ... what are the consequences of a malicious use
14:46:26 <wendyreid> ... the consequences seem small
14:46:41 <wendyreid> ... good enough to say "XML has a known vulnerability:
14:46:42 <dauwhe> ack dug
14:46:44 <wendyreid> ack duga
14:47:04 <dauwhe> duga: I agree putting this in the security section, maybe mentioning other xml vulnerabilityes
14:47:15 <dauwhe> s/vulnerabilityes/vulnerabilities/
14:47:38 <dauwhe> duga: any attack like this can jeapardize personal information
14:47:59 <dauwhe> ... although no one has bothered to do this
14:48:54 <wendyreid> dauwhe: Some of this is also outside the scope of the WG, we can't ask for people to patch the OS they are running dev machines one
14:48:59 <wendyreid> s/one/on
14:49:53 <dauwhe> wendyreid: consensus: let's look people look at Ivan's PR
14:49:56 <dauwhe> ... comment on it
14:50:25 <dauwhe> ... ten minutes remaining
14:50:32 <dauwhe> ... two more topics
14:50:39 <dauwhe> Topic: satellite specs
14:50:49 <dauwhe> ... some of these are in our w3c repo
14:50:54 <dauwhe> ... multiple renditions, CFI
14:50:57 <dauwhe> ... some aren't
14:51:05 <dauwhe> ... which might be a good thing
14:51:16 <dauwhe> ... we should pull in region-based navigation, which has implementations
14:51:27 <ivan_> q+
14:51:29 <dauwhe> ... are there any other that need attention?
14:51:46 <dauwhe> ... they will remain in idpf space if we don't move them
14:51:46 <duga> q+ to ask about CFI
14:51:50 <wendyreid> ack ivan_
14:51:54 <dauwhe> ivan_: we have to be precise
14:52:06 <dauwhe> ... should any of these be published as w3c note?
14:52:17 <rickj> q+
14:52:29 <dauwhe> .. CFI is in our space, I pulled in the existing idpf doc, turned into a format for w3c
14:52:35 <dauwhe> ... but it hasn't been published
14:52:43 <dauwhe> ... and we did have some discussion with brady etc
14:52:56 <dauwhe> ... publishing as a note would require a new section on the processing model
14:53:02 <dauwhe> ... it's more than editorial work
14:53:04 <wendyreid> ack duga
14:53:04 <Zakim> duga, you wanted to ask about CFI
14:53:27 <dauwhe> duga: we should pull over CFI, unless I have to do more work
14:53:41 <dauwhe> ... it is the one that always comes up
14:53:41 <dhall_> q+
14:53:50 <dauwhe> ack rick
14:53:56 <Bill_Kasdorf> Has the Locators group dealt with CFI?
14:54:12 <dauwhe> rickj: ignoring extra work, we're five years into w3c owning epub
14:54:20 <dauwhe> ... I still see articles linking to IDPF
14:54:39 <dauwhe> ... is there an arguement for moving them to the w3c domain ?
14:54:40 <wendyreid> ack dhall_
14:54:44 <dauwhe> q+
14:54:53 <dauwhe> dhall_: to comment on CFI, what's the remaining work?
14:55:05 <dauwhe> ... we could maybe get that work done
14:55:05 <ivan_> q+
14:55:07 <wendyreid> ack dauwhe
14:55:25 <wendyreid> dauwhe: Just to Rick's question, I still think there's no intention of shutting down IDPF web links
14:55:29 <wendyreid> ... bad web practice
14:55:35 <wendyreid> ... we have lots of pointers to W3C-land
14:55:41 <dauwhe> q?
14:55:42 <wendyreid> ... I certainly understand the problem
14:55:45 <dauwhe> ack iv
14:56:02 <dauwhe> ivan_: the epub cfi doc today is a spec of syntax
14:56:23 <dauwhe> ... what's missing is a processing model, of what the machine should do
14:56:32 <dauwhe> ... I cannot write that because I don't know enough
14:56:46 <dauwhe> ... if you want to write it I can bring it into the w3c world
14:56:53 <dauwhe> ... then it would be worth publishing
14:57:01 <dauwhe> duga: that's what needed
14:57:12 <dauwhe> ... I started to write that once and was told not to waste my time
14:57:26 <dhall_> q+
14:57:33 <wendyreid> ack dhall_
14:57:34 <dauwhe> ack dh
14:57:51 <dauwhe> dhall_: if there are examples of a parallel algo description that would help me
14:57:57 <dauwhe> ivan_: do you have that, brady?
14:58:03 <MURATA> Who uses EPUBCFI now?
14:58:11 <dauwhe> duga: I modelled it on something in html
14:58:14 <dauwhe> q?
14:58:44 <dauwhe> ivan_: we did processing for publication manifest
14:59:22 <ivan_> https://www.w3.org/TR/pub-manifest/#manifest-processing
14:59:31 <ivan_> zakim, end meeting
14:59:31 <Zakim> As of this point the attendees have been rickj, ivan_, MasakazuKitahara, dauwhe, dhall, wendy, wendyreid, romain, bduga, CharlesL, dhall_, duga, billk, Bill_Kasdorf, gpellegrino,
14:59:34 <Zakim> ... makoto
14:59:34 <Zakim> RRSAgent, please draft minutes
14:59:34 <RRSAgent> I have made the request to generate https://www.w3.org/2022/10/07-epub-minutes.html Zakim
14:59:36 <Zakim> I am happy to have been of service, ivan_; please remember to excuse RRSAgent.  Goodbye
14:59:38 <CharlesL> CharlesL has left #epub
14:59:41 <Zakim> Zakim has left #epub
15:00:35 <ivan_> rrsagent, bye
15:00:35 <RRSAgent> I see no action items