EPUB 3 Working Group Telco — Minutes

Date: 2021-02-11

See also the Agenda and the IRC Log


Present: Masakazu Kitahara, Dave Cramer, Toshiaki Koike, George Kerscher, Gregorio Pellegrino, Matthew Chan, Ivan Herman, Juliette McShane, Matt Garrish, Bill Kasdorf, Avneesh Singh, Charles LaPierre, Tzviya Siegman, Ken Jones, Ben Schroeter, Brady Duga

Regrets: Wendy Reid, Laura Brady


Chair: Dave Cramer

Scribe(s): Matthew Chan


1. EPUB a11y FPWD

Avneesh Singh: yesterday we had a11y TF call in which we approved going to FPWD
… here is the current drafts:

Avneesh Singh: See The core document.

Avneesh Singh: See The techniques document.

Avneesh Singh: there were 2 changes requested before we go to FPWD

Matt Garrish: clarification of EUAA requiring Level AA for some requirements
… other one is the acknowledgements in the list of contributors
… so all the changes have been addressed

Avneesh Singh: i think we are at the minimum level where we can go to FPWD
… a11y TF has already voted to allow this
… we leave it to the chair to put it to the rest of the wg
… first change was editorial improvements

Charles LaPierre: See Changes on the core document.

Charles LaPierre: See Changes on the techniques document.

Avneesh Singh: when we went through ISO we made certain changes which have now been added back
… and there were minor changes that we made to align a11y spec with reqs of EUAA
… additionally, question was how to align spec with WCAG 2.0, and what to do with existing docs
… we resolved to point to latest WCAG at this time, but for backwards compat, we allow people to refer to 2.0
… similarly, we strongly recommend Level AA, but Level A is okay
… epubs are not website, do not want to break backwards compatibility
… success criteria 1.1.1
… publishers found it difficult to provide extended desc
… at the time, we said that alt-text would be sufficient
… but at this point, publishers have gotten comfortable with a11y, and now TF has voted to be completely aligned with 1.1.1 of WCAG
… these are the high level changes

George Kerscher: re EUAA, DRM cannot interfere with a11y
… in the previous version that was a informative note, and this is now a requirement

Matt Garrish: it was a req that we moved into a note for ISO
… we just moved it back

Dave Cramer: any other questions or comments?
… does the WG need to resolve to published this Ivan?

Ivan Herman: we are talking about publishing 2 docs, yes? The FPWD for rec track, and the note (i.e the techniques)
… this needs to be made clear in the resolution then
… we have to have a separate resolution that once published we want these docs to run under echidna

Proposed resolution: publish FPWD of a11y spec (rec track) and a11y techniques (note) (Dave Cramer)

Charles LaPierre: question for ivan: is there any indication on the document itself?
… the both look identical from the top

Ivan Herman: from the style point of view yes, but the status section distinguishes them

Tzviya Siegman: in response to charles, the process cg is working on some new formatting

Dave Cramer: all in favour +1 please

Ivan Herman: +1

Ben Schroeter: +1

Matt Garrish: +1

Juliette McShane: +1

Charles LaPierre: +1

Avneesh Singh: +1

Tzviya Siegman: +1

Brady Duga: +1

Ken Jones: +1

George Kerscher: +1

Bill Kasdorf: +1

Matthew Chan: +1

Gregorio Pellegrino: +1

Toshiaki Koike: +1

Masakazu Kitahara: +1

Resolution #1: publish FPWD of a11y spec and a11y techniques note

Proposed resolution: use echidna to publish specs and notes (Dave Cramer)

Matt Garrish: +1

Proposed resolution: use echidna to publish a11y spec and a11y techniques (Dave Cramer)

George Kerscher: +1

Ivan Herman: +1

Matthew Chan: +1

Ben Schroeter: +1

Bill Kasdorf: +1

Tzviya Siegman: +1

Charles LaPierre: +1

Avneesh Singh: +1

Gregorio Pellegrino: +1

Juliette McShane: +1

Brady Duga: +1

Masakazu Kitahara: +1

Resolution #2: use echidna to publish a11y spec and a11y techniques

Ivan Herman: i will start up the request for publication this weekend or monday
… expect that the publication will happen Tuesday a week

George Kerscher: congrats avneeshsingh for getting this done

Avneesh Singh: congrats should go to the whole TF!

Charles LaPierre: Well done Avneesh, you deserve credit too!!!!

2. Origin

See github issue #873.

Dave Cramer: i don’t feel like we’re going to resolve on this today, but i think of this as one of the big issues around epub that we’ve been deferring
… epub is a heavy user of html and web tech, the web model and scripting revolves around the concept of origins
… but this is still poorly defined in epub.
… we have a statement in the spec:

Reading Systems need to behave as if a unique domain were allocated to each Content Document, as browser-based security relies heavily on document URLs and domains. Adopting this approach will isolate documents from each other and from other Internet domains, thereby limiting access to external URLs, cookies, DOM storage, etc.

Dave Cramer: first of all, i think the statement is problematic. Domain is not the right concept here
… should probably be about origin
… and the statement prevents different content docs in the same epub from using the same local storage
… probably not what we intended
… this is complicated. RS present content docs in really different ways
… iframes, served via file schemes, webviews in mobile OS
… depending on how RS is constructed, the rules could be different
… can also try to define how things should work in epub, but that puts more burden on the RS
… some of this already happens, i.e. the RS object must be injected into the doc in Readium so that scripts can get at it
… wonder what is possible for epub 3.3
… is it possible to be better than we are now? Can we agree on some principles?
… i.e. localStorage should work for all content documents in that epub, and that it should persist across OS

Ivan Herman: do we have a kind of proper overview of what happens in RS today?

Dave Cramer: See Issue comment by Daniel.

Ivan Herman: we should not reinvent the wheel if possible, just standardize or unify on what the practice is

Dave Cramer: comment describes some of what happens in one RS, the type of complexity that we face

Ivan Herman: is that in line with other RS?

Dave Cramer: less certain on that point

Brady Duga: preface, i am not an expert in this area
… but it strikes me as weird to talk about origin without understanding transfer protocol
… origin is where you got it from, but where that is could be any number of places
… without knowing that, how do you express what the origin is?
… we say content document because it is in keeping with individual file access for most browsers
… so for most browsers, the content doc is its own origin
… we would like the zip to be the origin, but most browsers don’t even open zip files
… the way we (Google) work is that we pull apart the epub
… and then there are also per browser complications (e.g. in Safari)
… on our android client we’ve also had issues with origin, e.g. where people make fonts apply to same origin
… we mainly try to just fix issues as we break in different browsers
… e.g. we don’t use local storage to save annotations
… there’s no easy answer to how to make epub fit into the browser security model

Dave Cramer: that was very helpful
… in terms of understanding the scope of the problem
… we have this web content, but it ends up in RS that we don’t have much information about
… how should we proceed here?
… e.g. keep old language, and see what happens when we go through security and privacy horizontal review?

Tzviya Siegman: i’m aware that the fetch API as supplanting CORS
… its a living standard and don’t know how widely adopted it is, and people are very excited about it

Dave Cramer: i think fetch is how things work now
… or at least how people write script now is oriented towards using fetch rather than older APIs

Brady Duga: i thought fetch still relies on CORS?
… like, a shared underlying mechanism?

Dave Cramer: yes, i think the concepts of origin and cross-origin are still there
… is this the kind of thing we can ask TAG about?
… this is the classic question of how does our tech fit into the larger web ecosystem
… exactly on topic for TAG

Ivan Herman: first of all, yes. I think we should ask. Sooner the better.
… when we ask, we have to be careful to be clear that per charter we are not to make radical changes to epub spec
… also, that although epub does allow the use of scripts, it looks at scripts with suspicion
… that may be where we end up
… it will take them a while to reply
… also, my mental model has always been that if i take an epub file, when i unzip it, i consider it as its own website on its own domain (e.g. localhost)
… what is wrong with that mental model
… if under this model, then origin is this localhost address, and things fall into place
… it becomes part of some sort of web with a temporary website
… where does this go wrong?
… as a sort of mental model

Dave Cramer: i’m not sure that mental model holds up when we are faced with the task of implementing an RS
… implementation details are RS specific, there are complications to using this model

Ivan Herman: at the moment we are silent on script behaviour aside from announcing scripts are present
… this may simply mean that we need to advise on how this model may impact the use of some scripts
… i would expect that most scripts would not be adversely affected

Dave Cramer: I think next step is reaching out to TAG
… this group doesn’t have the expertise on this subject
… i’ll take the lead on that
… reaching out to other members of the W3C

Tzviya Siegman: i can also help with that

Gregorio Pellegrino: question for ivan, if you open two epubs, do they run on the same host?
… if they do, then one can access the other
… or do you run different services for different open epubs?

Ivan Herman: yes, the second

Brady Duga: i think short answer, the mental model we’re discussing here is right - epub is website in a box
… when you open an epub, it is “served on its own domain” and another epub is its own other domain
… the difficulty is how to specify that in spec appropriate language that will work across all RS

Ivan Herman: i said localhost with a different port for each epub, so logically speaking, they would be independent
… apart from that, i agree
… instead of trying to specify all the details, we might want to say these are the consequences of this model in terms of scripting

Dave Cramer: i wonder if each epub should be its own opaque origin

Brady Duga: the other problem is that the epub often isn’t local, and the RS might actually be making calls to a server, and may not have control over what the URL is, what the port is, etc.
… not always true that you have a local file there

Dave Cramer: to get the results we want RS may have to do a lot of trickery to disguise how they actually implement things in order to present a unified experience

George Kerscher: do we need a normative/descriptive piece in our spec, and be silent on this otherwise
… this seems to minimize the risk of breaking things

Ivan Herman: we are pretty silent already
… on the one hand, we’d like to enable more scripting to allow more interactive books
… so we might not want to be completely silent
… and I understand that there are problematic cases under the model, but we should not try to specify all possible cases. There is no end to this.
… if it were the case that the model doesn’t fit what most people are doing, that’s another thing

Matt Garrish: to date we’ve left it to the RS to decide whether to support scripting, and to what extent

Tzviya Siegman: +1 to mgarrish

Dave Cramer: i don’t want to go backwards, saying nothing is problematic
… next step is still consulting with TAG

Avneesh Singh: +1 to consult to TAG now, to prevent problems at last minutes

Ivan Herman: will you put together something for TAG? Might be worth sharing with some implementers before you go to TAG

Action #1: ask TAG about scripting (Dave Cramer)

Tzviya Siegman: and I can help with that

Dave Cramer: maybe we can open an issue in our repo with the problem statement, to collect insight from this WG before we formally contact TAG

3. Security and Privacy Questionnaire

See github pull request #1511.

Ivan Herman: we have to put something about security and privacy in our recs, both in RS piece and content piece
… i’ve made a start
… we had this discussion in the context of publication manifest before
… i’ve made a PR
… what we do say right now is that the various security and privacy issues are mostly related to the content documents
… so whatever is implementers and content providers need to be concerned about are the same things that would apply to HTML, etc.
… just like with i18n, there are self-tests that the WG needs to provide
… so we should take these self-tests, and see whether they reveal anything that we need to consider
… like I did with i18n
… we would need someone with some expertise in this area to do the self-test

Tzviya Siegman: a lot of security questionnaire will be hard for us to answer

Dave Cramer: dealing with origin is kind of way of expressing our security concerns in a way that the larger web understands

Ivan Herman: i think many of the potential security and privacy issues are already handled by CSS and HTML
… we are not supposed to redo these things
… the question is whether the fact of packing things, adding metadata, etc. Do these things open new security and privacy issues?

Dave Cramer: Jiminy has found epub specific security bugs
… as a consequence of the package, and our uncertain relation to the web, there are additional issues
… this may need to remain an open question for now
… as we don’t have obvious experts within our own group

4. AOB?

Dave Cramer: thanks to everyone for progress on a11y piece
… and some long term problems that we’ve been wrangling for a while

Ken Jones: i was wondering whether there is any news on the fixed layout a11y piece?

Dave Cramer: i think that was happening in the CG
… the initial questions were going to be discussed in the publishing CG, but i don’t think they’ve gotten that far yet

Ivan Herman: i think the person most interested in driving that is Wendy

Ken Jones: will ask Wendy then

Dave Cramer: thanks for bringing that up

5. Resolutions

6. Action Items