Meeting minutes
Privacy and Security Review
wendyreid: privacy and security review have been merged and submitted.
ivan: note to ourself,we have done what we are supposed to, wait for comments from other groups
Annotations Progress Check
wendyreid: we've made a lot of progress, but there are still some gaps before sending to review.
wendyreid: we should plan two months not more if we want to achieve review by the end of our charter.
wendyreid: privacy and security for annotation will be a burden, accessibility too probably, the topic comes with high complexity.
laurentLM: I see no difficulty to solve open issues in the next month. We've discussed language and text direction so internationalisation should be ok. We use json so I am not worried.
ivan: less optimistic by nature. There are terms and objects not defined, not complicated ones but to be defined. Json schema is an empty section. We can try to say this is json so privacy security and accesisbility are covered by this spec. But we might be asked to give some reading suystem considerations on safe and robust implementation.
ivan: we may want to add asecurity section, even non normative, it's often done this way.
gautierchomel: Are we talking about having the document ready for security/privacy review by end of May or everything by end of May?
wendyreid: draft of the document by end of may so we can start the review process.
wendyreid: for EPUB, we did a risk assesment, I would suggest to follow that path. That's a way to raise questions . What happen is someone use anotations for injection? What about an EPUB silently leaking infos? We may have no response but at least knowing the risks and informing them.
ivan: two timelines: may to start the review and all testings done before january. We need to think about how to test, that would be complexer than for EPUB. At the moment I am not sure how to test annotations.
gautierchomel: I think that I would be happy to start the risk assessment for annotations, we have some experience since we implemented in Thorium, I can propose some first draft, should I do it in an issue or elsewhere?
… I have some ideas about how to test
… we've tested them for Thorium desktop, I have some ideas
wendyreid: in terms of testing, we need individual tests, as well as exemples embedded in an EPUB vs separate file
laurentLM: this sounds like testing the RS, not the spec.
wendyreid: short reminder, for each MUST in the spec we need a test. Two implementations to pass. We create the files, RS are invited to test.
ivan: an ebook for each MUST statement is a mean, we can work differently and asses different parts with one file. One important feature, is the interchange format, we do not define how RS do that, we have to proof that a RS can export the annotations in the format we specify and that a RS can import it.
ivan: we should concentrate on the interexchange
LaurentLM: I agree with that, one annotation file with different types inside might be sufficient to proove we can import and export it.
LaurentLM: let's solve issues one by one to make sure we have a good draft. There are 10 plus a PR. I have also to add a section on metadata. I will do that before the weekend.
sueneu: happy to help if there something I can do to share pressure.
LaurentLM: having implementations would be great! even from this beta. It's a few steps to align Thorium and Readium implementations but we definitely want other RS to jump in.
Aligning text-style properties - w3c/epub-specs#2971
wendyreid: RS have to deal with dark mode, color contrast, high contrast, etc. i feel we should clarify that "yelow" note does not mean the note must use Yellow CSS color.
LaurentLM: Agree, I will add this as a clear statement.
sueneu: may we use IDs instead of color names ?
ivan: maybe we should use different wording, let's say "yellowish" instead of "yellow" to avoid confusions.
LaurentLM: I don't see a clash, yellow is not a term invented by css, they just use it to qualify a color code. We don't do HTML, we do JSON, so I would prefer to use normal color, witha note that it is defining a range of colors. In our review, all RS use similar colors, yellow, blue, magenta, a set of meaningfull color. Let's not reword but instead have a clear statement. Yellow existed before css.
ivan: agree not to use HEX color codes, it's a name, acting like an ID, we don't specify what color should a RS apply to Yellow.
wendyreid: also we don't want to test exact color code used by RS, we cannot impose them a color pattern that may not fit in theyre designs. The name acts as a group or a tag.
GeorgeK: redlining is a publishing use case, stroke and red usually means a correction to do. We understand that with words. All of us in the industry.
<sueneu> GeorgeK +1
LaurentLM: that's it, color name is a semantic, the appearence of it has not to be defined at a standard level.
ivan: let's see how we word that in a PR.
AOB?
LaurentLM: I have some comments, I'll do them in the PR.