[reads epub 3.2 and 3.3 diff]

Dan: looking at security and privacy.. Tess will also have opinions. We need to schedule a f2f session

Amy: books spying on us? no thanks.

Tess: I have a meta question - first time epub has come to the tag for review - so this is an opportunity. All versions of epub since 3.0 have been tighlty scoped... not changing a lot of things. It's an ecosystem where you tend ot have low power devices - you want to be able to buy a book in the future and being able to read it - so backwards compatible. People buy digital books - so unlike browsers there's a responsibility - to be able to continue to read the book into the future. Since 3.0 the compat constraints have been really tight. If we did a full review from the ground up we might end up wasting their time... choices they've made that they are stuck with for compat reasons. Our first opportunity to be useful to them - so we should focus on things they can actually change.

Dan: we should focus on feedback where they can make changes...

Tess: where things have an impact...

Amy: most of the things that struck me were privacy & security related - a lot of their answers to the s&p questionnaire are "the spec says nothing about this" - but maybe in some cases the spec should say something about it. E.g. the question abut PII... could they write some guidance about how reading systems should be doing xyz... Seems like the direction of travel is to bring it closer to the web platform... gradually... could subvery user expectation... because ebooks are not websites... reading systems depending on the implementation could track users' IP address, location, etc... but they don't say anything about permission prompts or warnings...

Tess: permission prompt interesting to me –– when you turn a page in a book you're not expecting a modal dialog to interrupt you.

Amy: The e-reader should not be doing stuff that would warrent interrupting the user with a permission prompt.

Tess: when you load the web site or when the user is interacting with the web site - kind of the same - but for books you download the book and the reading system has an opportunity to inspect the book and figure out what permissions prompts it's going to need. One way would be to front load some of that... For example in an educational context - a digital text book that has excercises - you can fill them out and hit submit - submits to a server that checks your work. You would want a permission to access the network... vs when they're in the middle of the assignment... The baseline should be to not do stuff like that. But they should see the opportunity to be better than browsers... For browsers we have webapp manifest..

Amy: for localisation .. could be useful but also surveilance...

Tess: as an example - i hate it when i go to google in japan and it's in japanese instead of following my lang preferences.

Amy: a use case for an external system knowing where you are in a book for syncing across devices - but that comes with an external system knowing where you are in a book.

Tess: like scroll linking browsers... you can imagine a browser syncing that... User agents are reading system but there is an issue of trust...

Amy: the key for me is that it feels like a different set of expectations... a device that just reads books...

Tess: yes - low power devices ...

Dan: you can do something like that on samsung internet

Tess: reading systems are user agents. UA features to help people seem cool but ultimately the question of trust

Dan: feedback about questionnaire.. big chunk of work but we can do that to start.. We should take as guidence what Tess said that we should be giving useful feedback, not a full top to bottom review of the technology.

Tess: if 98% of oru review is things they can't revisit we wouldn't be providing value. Everything Amy already said can go into the issue.. a bunch of stuff unspecified in p&s

Tess: on their response to s&p questionnaire regarding the download of files -- https://github.com/w3c/epub-specs/blob/main/epub33/explainers/EPUB-33-security-privacy.md#17-what-should-this-questionnaire-have-asked - feels like if all user agents are doing something that spec says not to do then ... maybe they should say something else instead...

Hadley: Left this comment:

Looking at this in our W3CTAG breakout session.

Just noting that in two of the issues that @rhiaro opened, the working group minutes (mentioned in @iherman's reply) indicate that they are planning to address them and will get back to us.

And it doesn't look like there is any comment yet on the third: [TAG] Reading systems and permissions prompts #1958.

Amy: we've opened issues in their repo and they've discussed in their meetings, addressed some - they're listening but no action yet.

Dan: punt to plenary?

Thanks for the great work on the Privacy and Security sections. The threat models and mitigations now look very comprehensive, and we appreciate the effort that went into these.

I had [one question remaining around permission prompts](https://github.com/w3c/epub-specs/issues/1958), but this is not blocking.

Having completed our review, we are happy to see this move forward. Thanks!

Hadley: we looked in Feb.. of the issues we opened looks like they've addressed.. extesnive changes on S&P

Amy: they responded to the 3rd issue but only half. I read the S&P sections and felt they were good.

Sangwhan: they have an OCF defines layout of package. Defines format. Zip container. Why are they stuck in zip? Terrible for network.

Hadlety: existing implementations.

Yves: existing implementations.

Sangwhan: could there be a 2ndary container codec? That's why we're still stuck with GIF. We can ask. writes comment.

Amy: there's probably a decade of history.

we look through their issues

Amy: looks like they've responded well on Privacy & Security.

Hadley: we should write our list [suggestions] down [in our issue] - also could be helpful [to them] at re-chartering time.

Amy: i'd like to check up on that issue where they'd answer half of it - before I nicely ask for a response. Then if we think everything else is OK we can write a closing comment.

Dan: let's discuss and hopefully close at the plenary