EPUB 3 Working Group Telco — Minutes

Date: 2021-09-16

See also the Agenda and the IRC Log


Present: Masakazu Kitahara, Wendy Reid, Dave Cramer, Toshiaki Koike, Shinya Takami (高見真也), Matthew Chan, Matt Garrish, Brady Duga, Dan Lazin, Murata Makoto

Regrets: Ben Schroeter


Chair: Dave Cramer

Scribe(s): Matthew Chan


1. PING Meeting

Dave Cramer: as part of horizontal review I worked on security and privacy questionnaire
… requested review from PING, and they put us on their schedule
… wendyreid and dauwhe joined that meeting
… they expressed significant concerns in two areas. One is remote resources. Given that an ebook with remote resources then whoever hosts the remote resource knows I’m reading that book.
… two concerns with scripting in general. Malicious script could send info back to a website if not blocked
… on a more general level, the differences between epub and web were concerning to PING
… no clear idea of origin
… they feel users don’t know that RS may be tracking behaviour
… a lot of concern around user knowledge and expectations
… supposedly web users are supposed to understand 1st party vs 3rd party, the nature of the URL, etc.
… PING will have a bunch of notes for us, which will raise spec issues

Wendy Reid: this doesn’t need to happen today, but we have to discuss remote resources at the very least

Brady Duga: this is not surprising. we’ve not had a processing model, we’ve not described transports that we use for content
… PING is look at this as if we are part of the web browser, or part of the web
… but there’s not reason that has to be the case. RS can be unconnected
… so a lot of these concerns don’t apply to epubs

Dave Cramer: PING mentioned that there’s no way for user to know that content has not been unadulterated since it came from the publisher. But in fact, you CAN be confident that RS has probably done a bunch of things to it

Wendy Reid: right, epub just doesn’t fit into the same model
… in particular the thing with remote resources, e.g. Hachette could host a remote resource that is accessed by an epub, and the user would not know they are accessing a Hachette server
… and that’s fair, but most people also don’t know who they’re buying their books from

Brady Duga: and also, how is that different from the Web? e.g. tracking pixels

Dave Cramer: wendyreid and I were trying to describe epub as it exists in today’s world, but its true that we tend not to think along the lines of how could a malicious actor abuse this technology stack
… we’ll probably have to return to this topic on future calls

Dan Lazin: what is PING expecting from us? Do we have to adhere to some policy by some date?

Matt Garrish: I remember going over some of this before, and we do say that there should be ways of alerting users to scripting and to disable it
… but are we expected to begin prescribing UI?

Wendy Reid: we’ll probably need to come up with some sort of solution (e.g. change to spec) that satisfies PING to the point where they are willing to sign off on it
… just like a11y, or i18n horizontal review
… they might say that they want to change something, and we can counter with a compromise

2. Processing of Navigation Documents

See github issue #1793.

Dave Cramer: issue is that nav is an HTML document, but also meant to be processed by RS
… RS may use it and turn it into something unlike HTML, i.e. without markup

Murata Makoto: I find that best practice is to use text only in nav
… i am curious to know what happens when nav contains bidi?
… will it be converted to bidi in unicode?
… from bidi markup

Shinya Takami (高見真也): why does DAISY JP want to restricting rendering of nav?

Murata Makoto: I don’t want to restrict

Dave Cramer: maybe just include a note to warn that html markup could break

Brady Duga: we hope that bidi is resolvable via unicode. We haven’t gotten very many complaints, so if it breaks, its breaking in very few cases

Murata Makoto: so those who create nav should make sure that their nav can be correctly rendered by major RS

Brady Duga: yes, always advisable. Some of these edge cases can be solved, but we haven’t done it because no publisher has raised a strong issue about this
… and we haven’t heard much about ruby in toc
… but maybe that’s because JP publishers are tired of raising this issue
… but if more publishers complain we will take that into account
… for ruby we could put the ruby text in parentheses after the base text

Shinya Takami (高見真也): many RS don’t use rendering systems for toc, so publishers will not strongly request richly decorated tocs
… i would leave the spec as it is for epub 3.3

Dave Cramer: i’m getting the sense that murata is okay with the change in language introduced by ivan

Murata Makoto: yes, okay by me

Proposed resolution: Close issue 1793 (Wendy Reid)

Wendy Reid: +1

Dave Cramer: +1

Toshiaki Koike: +1

Shinya Takami (高見真也): +1

Matthew Chan: +1

Masakazu Kitahara: +1

Murata Makoto: +1

Brady Duga: +1

Resolution #1: Close issue 1793

3. Multiple Roles

See github issue #1782.

Dave Cramer: about package metadata. someone proposed that we be able to assign multiple roles to a person using a comma separate string of different roles
… but we don’t think we want to get involved in parsing
… but you can already assign multiple roles to a person in the current spec
… and i’m not aware of many RS that even present this information to user
… so i would close this issue

Proposed resolution: Close issue 1782 as won’t fix. we (Wendy Reid)

Matt Garrish: agreed. If we come up with a micro-syntax for the meta tag that could open up a bunch of issues. The one property per tag is a simple system that works.

Proposed resolution: Close issue 1782 with maximum prejudice (won’t fix) (Wendy Reid)

Dave Cramer: +1

Brady Duga: +1

Shinya Takami (高見真也): +1

Matt Garrish: +1

Matthew Chan: +1

Toshiaki Koike: +1

Wendy Reid: +1

Resolution #2: Close issue 1782 with maximum prejudice (won’t fix)

4. Can you TTS an image?

Dave Cramer: this is on the agenda, but its closed already
… so we’re good here

Wendy Reid: thanks to mgarrish’s editorial wizardry

Matt Garrish: i was just waiting for some feedback from marisa

5. AOB?

Dave Cramer: okay, thank you everyone for this productive meeting
… we’ll see many of you next week

6. Resolutions