14:02:09 RRSAgent has joined #epub 14:02:09 logging to https://www.w3.org/2021/02/26-epub-irc 14:02:11 RRSAgent, make logs Public 14:02:12 please title this meeting ("meeting: ..."), ivan 14:10:34 dauwhe has joined #epub 14:11:08 dauwhe has changed the topic to: https://lists.w3.org/Archives/Public/public-epub-wg/2021Feb/0016.html 14:12:14 ivan has changed the topic to: Meeting Agenda 2021-02-26: https://lists.w3.org/Archives/Public/public-epub-wg/2021Feb/0016.html 14:12:15 Chair: wendy 14:12:15 Date: 2021-02-26 14:12:15 Agenda: https://lists.w3.org/Archives/Public/public-epub-wg/2021Feb/0016.html 14:12:15 Meeting: EPUB 3 Working Group Telco 14:12:15 Regrets+ tzviya 14:44:04 Karen has joined #epub 14:57:06 MattChan has joined #epub 14:57:26 wendyreid has joined #epub 14:57:31 dkaplan3 has joined #epub 14:58:53 MasakazuKitahara has joined #epub 14:59:01 present+ 14:59:03 present+ 14:59:07 LauraB__ has joined #epub 14:59:08 present+ MattChan 14:59:11 present+ 14:59:14 present+ dauwhe 14:59:23 present+ 14:59:27 present+ avneeshsingh 14:59:48 toshiakikoike has joined #epub 14:59:55 George has joined #epub 14:59:56 present+ george 15:00:08 present+ 15:00:17 present+ florian 15:00:17 present+ 15:00:28 present+ laura 15:00:36 mgarrish has joined #epub 15:00:47 avneeshsingh has joined #epub 15:00:52 present+ billk 15:01:22 present+ 15:01:57 CharlesL has joined #epub 15:02:01 present+ 15:02:08 Bill_Kasdorf_ has joined #epub 15:03:25 present+ 15:03:34 present+ awad 15:03:41 present+ 15:04:00 BenSchroeter has joined #epub 15:04:01 scribe+ 15:04:10 present+ 15:04:20 present+ gpellegrino 15:04:28 gpellegrino has joined #epub 15:04:32 present+ mgarrish 15:04:34 present+ 15:04:37 dauwhe: we have lots of horizontal review to do 15:04:39 present+ 15:04:48 ... re. the security and privacy self-questionnaire 15:04:52 present+ brady 15:04:56 duga has joined #epub 15:04:56 ... eventually we need TAG review of our spec 15:04:58 present+ BenSchroeter 15:05:01 present+ 15:05:27 ... i'm hoping to get advice from them esp. question of origin and how epub security fits into web security model 15:05:29 https://github.com/dauwhe/epub-specs/blob/73ccdf946f426521834e0993e8d667d92ba7881c/epub33/explainers/EPUB33-explainer.md 15:05:42 ... i started answering the questionnaire 15:06:06 ... getting some feedback from you all would be REALLY helpful 15:06:19 ... Ivan has already made some helpful comments 15:06:29 q+ 15:06:50 TOPIC: TAG Explainer 15:06:59 duga: what is our timeline for review of this doc? 15:07:03 q+ 15:07:03 dauwhe: not clear 15:07:07 ack duga 15:07:17 ... i just wanted to get started, get a handle on the extent of potential work required 15:07:25 ack ivan 15:07:31 juliette_mcshane has joined #epub 15:07:32 ivan: we are always asked to come in as early as possible 15:07:33 present+ 15:07:41 Teenya has joined #epub 15:07:53 ... there is normally a problem with groups coming in close to CR and only realizing that they have issues there 15:08:01 ... that is why I started i18n so quickly 15:08:02 present+ (apologies for lateness) 15:08:19 ... if we can submit a first round to them for review within 1 mth or 6 wks that would be good 15:08:30 dauwhe: and we're talking about CR in november, and its already feb 15:08:39 ... ivan does it make sense to go thru the questions on this call? 15:08:52 ivan: i think we have some ppl on the call who have not been with us before? 15:09:21 dauwhe: okay, let's try to get through a few of these 15:09:49 ... Q1 1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary? 15:10:01 ... questionnaire seems to be kind of web-centric 15:10:09 ... but we try to work around that 15:10:13 q+ 15:10:18 q+ 15:10:21 ... i tried to mention some of the kinds of info that RSes seem to collect 15:10:24 ... e.g. reading position 15:10:28 q+ 15:10:31 ... highlights, notes, bookmarks 15:10:40 ... which books are finished 15:10:45 ... what else? 15:10:46 ack mg 15:11:02 mgarrish: i don't know that anything is missing, but is this really in scope? The spec doesn't really define this behaviour 15:11:05 q+ 15:11:18 q+ 15:11:22 ... what are we supposed to be listing for this question? 15:11:33 ... do we have to be able to point to where in the spec we are mandating each of these things? 15:11:42 ... or just list whatever a RS could possibly do? 15:11:53 dauwhe: this is our first interaction with W3C as formal WG 15:12:01 ... i think we need to cast as wide a net as possible 15:12:23 ... don't want to draw narrow boundaries 15:12:32 ... want to give TAG as much info as possible to make an informed decision 15:12:38 q+ 15:13:11 ... then if TAG says not to worry about something, then okay 15:13:20 ack dug 15:13:23 ... rather than to have them caught off guard 15:14:02 duga: listing all the things that a web browser could do in a specific spec (e.g. flexbox) would seem odd 15:14:38 ... similarly, listing everything RSes can do seems like it would be similar 15:14:54 ... a lot of these features we don't require 15:15:19 ... publishers are also users 15:15:34 present+ garth 15:15:35 ... the metadata that they put in, they intend to be made available on the net 15:15:45 ack Ben 15:15:53 ... it seems obvious that this would be the case 15:16:30 BenSchroeter: when we talk about the info that can be collected and other users who may be interested in said info, one of the most important is educational market 15:16:42 ... they like student engagement info 15:17:00 ack ivan 15:17:06 ... so we might think about including schools in the category of interested users 15:17:11 q? 15:17:20 ivan: at the end of the day, we will have to add a privacy and security section 15:17:30 ... look at other specs, these sections are not normally normative 15:18:06 ... they say, you have this technology, and hopefully you've done everything in your power to avoid security and privacy issues, but implementers should be aware that these certain issues exist 15:18:48 ... but this kind of info that any reasonable person authoring an epub should realize that these are things that can happen when their publication gets to an RS 15:18:59 ... these are the sorts of things we should keep in mind 15:19:16 ... the TAG may ask us whether we've done what we can to avoid certain problems 15:19:34 ... e.g. discussion we had last week about origin, that is a step in the right direction 15:19:43 q+ 15:19:44 ack Geor 15:19:53 ... but the final outcome is a section that contains informal warnings 15:20:25 George: for AT, dyslexic students will also want to track how quickly they are reading, how much read aloud features are being used 15:20:40 ... one library tracks the books i've downloaded and reports back to me what books i've read 15:20:43 q+ 15:20:45 ... great feature, as long as it stays private 15:20:48 ack Bil 15:21:13 q+ 15:21:16 Bill_Kasdorf_: i just want to be clear, when the TAG does this review of spec, are they critiquing what is in the spec, or suggesting additions that need to be made to spec? 15:21:20 ivan: it will be both 15:21:32 ack mg 15:21:52 mgarrish: maybe it would help to separate what we know are features of the spec, vs things that RSes do that are not in spec 15:22:01 ... so ppl don't think that everything is being dictated by spec 15:22:14 ack avn 15:22:23 ... e.g. give them a list of things to consider that are not directly in our control, just FYI 15:22:34 +1 to Matt G 15:22:53 avneeshsingh: as an example, re. geopositioning info, one can say this is a security hole, but many things that an RS does cannot be controlled by the spec 15:23:05 ... so I second Matt G's idea 15:23:06 ack Ch 15:23:29 https://w3ctag.github.io/explainers 15:23:30 CharlesL: in the personalization tf, we went through TAG review, but they want it in a very specific format 15:23:48 ... this link is template that they want for explainers 15:23:56 ... important that we use their format 15:24:06 ... saying this from experience 15:24:16 dauwhe: right, good point 15:24:28 q? 15:24:31 ... right now this is a very work in progress attempt to think through the relevant points 15:25:23 ... "Is this spec exposing the minimum amount of info...?" 15:25:25 ... probably 15:25:31 present+ hadrien 15:25:39 ... "How do we deal with sensitive info?" 15:25:54 ... there was a comment that the fact you are reading a particular book can be highly sensitive info 15:26:05 q+ 15:26:10 ack Bil 15:26:11 ... we should be clear about that, but again, the spec doesn't discuss sharing of this sort of info 15:26:37 Bill_Kasdorf_: it occurs to me that we're actually working on 2 specs? Update of epub core, and epub RS? 15:26:54 ... how does this affect that RS? Maybe that's where a lot of stuff comes to surface 15:26:58 q+ 15:27:03 q+ 15:27:25 q- 15:27:27 dauwhe: epub is currently described in 2 specs, but i don't want to have a separate security and privacy questionnaire for each of them 15:27:37 ... there are so many ways that they interact 15:27:45 q+ to discuss indirect information gathering 15:27:46 ack Ben 15:27:48 ... it feels like it would be more of an artificial distinction to me 15:28:04 BenSchroeter: i don't think the question of what books i'm reading has anything to do with the format of the book etc. 15:28:19 ... that's more down to what company i've go through to get the book 15:28:35 ack duga 15:28:35 duga, you wanted to discuss indirect information gathering 15:28:38 ... the formatting of the book itself doesn't add vulnerability 15:28:56 duga: one thing, the unique identifier is an interesting tracking vector 15:29:06 s/vector/mechanism 15:29:26 ... the other thing is, about portrait and landscape 15:29:37 ... we do that by just looking at the aspect ratio 15:29:58 ... but if you have scripting in the book, you could examine the book to figure out things indirectly 15:30:17 ... e.g. examining the book to deduce what the device orientation is 15:30:31 q+ 15:30:38 ... e.g. if someone has extremely large font size, then an inference could be made that user is low vision 15:30:38 ack ivan 15:31:11 ivan: to pick on the last one, in every script which is like an HTML script, can it find out what font is used, or what size, without any further ado? 15:31:25 duga: it depends... would have to look at what we expose from the RS object 15:31:51 ... WE don't support scripting, so I don't deal with this very often 15:32:13 ... but it really depends on how the RS does font stuff 15:32:24 ivan: could you do the same in browser? 15:32:29 dyslexic font could expose sensitive information? 15:32:52 duga: you can absolutely tell. E.g. by measuring a range with a known size, 15:33:07 ivan: so maybe there is a danger, but epub doesn't exacerbate this 15:33:54 duga: not necessarily. There are ways that we handle things that are not necessarily the same as in a browser 15:34:16 q? 15:34:16 ... e.g. we allow users to choose font via CSS, not sure if this is a thing is browsers 15:34:34 ... Ivan's point is good, but it requires further study 15:34:36 q? 15:34:45 q+ 15:34:51 ack george 15:35:00 ... to make sure we're not caught by any backdoor ways that user info could be revealed/deduced 15:35:18 George: i'm wondering about Microsoft's immersive reading experience in edge and office products 15:35:26 ... are they encountering the same kinds of issues that we have 15:35:45 ... where they may understand a lot more about the person that we would typically think 15:35:52 ... so the issues we're facing may not be unique to us 15:36:00 q+ 15:36:09 ack dug 15:36:18 dauwhe: there are certainly a lot of surprising security vulnerabilities 15:36:50 duga: I just checked whether Chrome is reporting updated computed sizes when I control+plus, and we don't 15:36:56 ... but this is something an RS would do 15:37:12 q+ 15:37:16 ack ivan 15:37:37 ivan: we do say in the document that each epub instance should be viewed as having its own origin 15:38:03 ... i am not sure that we also say that the same document read on two different occasions should have two different ones 15:38:19 dauwhe: we don't say that, that would prevent many useful features 15:38:24 ivan: then we should specify that 15:38:50 ... on the other hand, the point of each epub being its own origin is currently non-normative 15:38:58 dauwhe: good point 15:39:39 Topic: WCAG 3 15:39:39 Scribe's note: About was in relation to Q8 of the questionnaire 15:39:48 dauwhe: i propose we move on 15:39:54 https://www.w3.org/2021/02/23-pbg-video.html 15:40:02 TOPIC: WCAG 3.0 15:40:12 wendyreid: we had a meeting within the publishing BG 15:40:24 ... the link above is to the video of the presentation 15:40:32 could you also provide a link to her slides? 15:40:42 ... the meeting covered an overview of changes in WCAG 3.0 15:40:52 ... they are looking for first round of feedback by today end of day 15:41:02 ... epub is specifically called out 15:41:22 ... they are looking for assistance to make the parts concerning epub as consistent as possible 15:41:39 q? 15:41:44 q+ 15:41:51 dauwhe: any questions or comments? 15:41:54 ack geor 15:42:17 George: when we provide feedback to them, does each individual person provide their comments? 15:42:24 ... or do we as a group agree on comments? 15:42:45 wendyreid: its fine to offer comments as an individual 15:43:03 George: i'm just afraid that my comments will be interpreted as representing the WG 15:43:16 ... and I can just clarify that my comments are my own 15:43:18 q+ 15:43:25 ack avn 15:43:43 avneeshsingh: to provide a little bit of an overview, the current draft is not entirely settled 15:43:53 ... a lot of discussion will still take place 15:44:02 ... but a lot of the high level framework is in place 15:44:18 ... so current comments about high level is most helpful right now 15:44:50 q? 15:44:58 ... as we get further on, we can work out more of the details with WCAG tf 15:45:15 TOPIC: Open issues 15:45:29 https://github.com/w3c/epub-specs/issues/1380 15:45:48 dauwhe: this is about rendition:align-x-center 15:46:01 ... the intent was that this would be used to center title pages in Japanese books 15:46:08 ... so that everything would be in center of viewport 15:46:24 ... issue here is that this is a bit of metadata that does not make sense as global metadatda 15:46:35 ... but the spec seems to allow it 15:47:04 ... should we fix this by prohibiting it as global? 15:47:07 q+ 15:47:13 ack Garth 15:47:14 q+ 15:47:15 ... there does seem to be some interest in deprecating it entirely 15:47:47 Garth: we (Google) don't implement it 15:48:14 q+ 15:48:18 ack duga 15:48:52 ... if you had a landscape image in fixed layout, it seems to me that there could be a use case for the global setting 15:49:13 duga: you said earlier that there have already been other ways to address the use case of japanese title pages 15:49:19 ... not sure that this is the case 15:49:29 ... i'm currently dealing this an issue report about this right now 15:50:36 ... the experts in Japanese rendering would currently say that there is not real CSS solution to this, but only after a great deal of specific research 15:50:41 ack mg 15:50:59 mgarrish: its not possible for this to be a global property right now 15:51:19 ... because there are no defined values for it currently 15:51:25 q? 15:53:33 scribe+ 15:54:02 dauwhe: We do have the datapoint that a careful reader of the spec was unsure that this could be a global property 15:54:15 MattChan_ has joined #epub 15:54:15 ... that's some evidence that an editorial note or tweak is needed 15:54:48 mgarrish: I have no issue sticking a note in 15:54:57 ... we can't actually have a global property, it's impossible 15:55:20 dauwhe: Let's close the issue and have a separate discussion about whether it should be deprecated 15:55:28 ... we're poitentially running into not having 2 implementations 15:55:34 ... making this an at-risk feature 15:56:01 https://github.com/w3c/epub-specs/issues/1295 15:56:03 ivan: Minutes are sufficient 15:56:10 dauwhe: Let's discuss 1295 15:56:28 ... package metadata, according to the spec we need to trim leading and trailing whitespace 15:56:38 ... the INFRA spec does have instructions on this 15:56:56 ... it would be a step in the right direction to define the trimming as described in the INFRA spec 15:57:08 ... this is separate to a discussion on whitespace within the strings 15:57:24 ... there is a major RS that ignores this requirement 15:57:25 q? 15:57:35 LauraB__ has left #epub 15:57:40 q+ 15:57:41 Garth: What is the proposed change? 15:58:00 dauwhe: Could it be as simple as linking the word "trim" to the INFRA spec? 15:58:08 ack ivan 15:58:18 ivan: We can normatively refer to the INFRA spec 15:58:40 ... we can close by referring to it 15:58:45 dauwhe: Cool! 15:58:56 ... that's all for today 15:59:00 CharlesL has left #epub 15:59:34 WillAwad: [Introduces himself] 16:01:12 CharlesL has joined #epub 16:01:46 Will from Newgen is a GCA Benetech Approved Vendor as well! 16:02:11 dkaplan3 has left #epub 16:02:18 Teenya: {shows off cute dog] 16:02:22 rrsagent, draft meeting 16:02:22 I'm logging. I don't understand 'draft meeting', ivan. Try /msg RRSAgent help 16:02:35 CharlesL has left #epub 16:02:51 zakim, end meeting 16:02:51 As of this point the attendees have been MasakazuKitahara, ivan, MattChan, wendyreid, dauwhe, LauraB__, avneeshsingh, george, toshiakikoike, florian, billk, dkaplan, CharlesL, 16:02:54 ... awad, Bill_Kasdorf_, BenSchroeter, gpellegrino, mgarrish, brady, duga, juliette_mcshane, (apologies, for, lateness), garth, hadrien 16:02:54 RRSAgent, please draft minutes 16:02:54 I have made the request to generate https://www.w3.org/2021/02/26-epub-minutes.html Zakim 16:02:56 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 16:03:00 Zakim has left #epub 16:03:59 rrsagent, bye 16:03:59 I see no action items