00:01:19 RRSAgent has joined #epub 00:01:19 logging to https://www.w3.org/2022/01/21-epub-irc 00:01:21 RRSAgent, make logs Public 00:01:22 please title this meeting ("meeting: ..."), wendyreid 00:01:28 meeting: EPUB3 WG Telco January 20 2022 00:01:34 date: 2022-01-20 00:01:37 chair: wendyreid 00:01:54 present+ 00:02:05 present+ shiestyle 00:02:10 present+ MasakazuKitahara 00:02:12 present+ 00:02:18 present+ 00:02:35 duga has joined #epub 00:02:40 present+ 00:02:52 MURATA has joined #epub 00:02:56 scribe+ 00:03:07 present+ 00:04:01 wendyreid: today we are going to continue discussion re. privacy and security sections that need to be finalized before CR 00:04:01 https://github.com/w3c/epub-specs/pull/1972 00:04:35 ... there is one change since the agenda was sent out - we now have PR for updates to privacy and security sections in both core spec and rs spec 00:05:15 ... we talked about the TAG issues in last week's meeting, but there may be implication for the issues raised by PING 00:05:44 TOPIC: PING Issues (with context from TAG) 00:05:50 dlazin has joined #epub 00:05:53 wendyreid: this 6 issues need to be satisfied before we can go to CR 00:06:01 ... they are similar to issues raised by TAG 00:06:40 ... the new PR includes the threat model for both core and RS, as well as high level epub specific recommendations to content creators and RS implementors about use of remote resources, data collection, etc. 00:06:58 ... have we missed anything? 00:07:21 q? 00:07:41 q+ 00:07:48 wendyreid: does that mean we have satisfied the PING issues? 00:07:52 ack duga 00:08:24 duga: i commented on one of the PING bugs, but we've had some developments since in, so those comments might not be relevant now 00:09:01 wendyreid: some issues are challenging to talk about - e.g. DRM. We didn't write the spec to cover DRM, so we can only make some general recommendations 00:09:15 ... ditto security aspects related to core web tech 00:09:52 ... maybe some additional notes we can make re. epub and relation to browsable web? 00:10:11 duga: do we say that when you open in its own browsing context we notify users that this is about to happen? 00:10:28 wendyreid: mgarrish has included a line about informing users that they are about to be taken somewhere 00:10:45 s/open in its own/open a link in its own 00:11:40 wendyreid: there is an open issue around information exposure and fingerprintability 00:11:48 https://github.com/w3c/epub-specs/issues/1872 00:12:00 ... we say not to collect data, and be clear about what you are doing with that data 00:12:01 AramZS_ has joined #epub 00:12:25 ... make sure you have permission to use author data 00:12:37 q? 00:12:47 s/what you are doing with that data/what you are doing with that data if you do collect it 00:13:17 wendyreid: currently none of our recommendations have to do with obfuscation 00:13:28 ... not sure if we are adding anything to the obfuscation section of the spec at this point 00:13:36 ... unclear how we would make that more robust 00:13:46 ... we don't have a better solution 00:14:10 duga: we do have better solutions, but there is existing content and existing RS that make use of existing obfuscation 00:14:17 ... it would hurt users to remove it at this point 00:14:34 dlazin: we would have issues with Adobe, they feel strongly about this 00:14:59 wendyreid: the bulk of our recommendations are about interactivity 00:15:03 ... not sure we could say more 00:15:25 ... re. self contained packages we could maybe elaborate, but i don't have strong feelings 00:15:41 ... and most of the concern was about the privacy model of the web, which we addressed earlier 00:15:52 dlazin: what is self contained package? 00:16:12 wendyreid: everything for a given epub is contained within its own package, does not depend on other epubs 00:16:24 ... which is good for privacy, but maybe we could highlight that more 00:16:41 dlazin: or encourage publishers to make sure that epubs are more self-contained (we allow remote resources) 00:17:22 ... e.g. DAISY accessibility hazards announce to a store that this epub may or may not meet your needs, so we could do similar metadata tagging re. privacy and security risks 00:17:38 ... but that might get into the territory of changing the spec 00:18:05 wendyreid: even the a11y metadata is contained in a separate spec (i.e. epub a11y spec) 00:18:20 dlazin: i'll maybe take this idea to the community group to develop 00:18:44 +1 to dlazin 00:18:51 wendyreid: from a business POV, there is a longevity benefit to a fully self-contained epub being a better product than an epub that has remote dependencies that may rot 00:19:29 dlazin: its only a shame that the a11y metadata is not used more by retailers 00:19:47 wendyreid: and it might only be relevant to power-users 00:19:59 q+ 00:20:06 ack shiestyle 00:20:10 ... places like VST, Redshelf, NNELs use it, but not as much in major retail - but it is becoming more common 00:20:50 shiestyle: our ebook store extract material from epubs before distributing to users. So metadata is relevant to retailers. Has merit for our business. 00:21:02 wendyreid: good topic for CG 00:21:19 ... okay, i'll urge anyone with an interest in privacy to review the PR 00:21:34 https://github.com/w3c/epub-specs/issues/1944 00:21:41 TOPIC: Bikeshed name for underimplemented features 00:22:21 wendyreid: we have the unique problem that this is a 20 y/o spec, but with some features that were either not implemented at all, or only rarely 00:22:30 ... so they technically do not qualify for rec track doc 00:23:03 stabilized? 00:23:10 ... but we can position those features in a special category that we don't want to remove from spec just yet, but which may not be supported 00:23:20 ... we just need to decide what to call this category 00:23:31 ... so we can refer to them in the CR transition document 00:23:56 dlazin: i think the correct name is 'at risk features'. Seems to include both new and old underimplemented features 00:24:11 wendyreid: 'at risk' is a conflict with technical terms used in the W3C process document 00:24:21 How about "frozen"? 00:24:22 dlazin: does this apply to both new and old underimplemented features? 00:24:32 present+ 00:24:36 wendyreid: we don't have anything new that is underimplemented 00:24:55 duga: not much is new at this point 00:25:04 wendyreid: i like frozen 00:25:25 MURATA: in ISO we use the term stabilized - i.e. we are not going to touch the spec 00:25:36 dlazin: 'legacy features'? 00:25:53 wendyreid: legacy is already used in the spec for features that are holdovers from EPUB2 - e.g. NCX 00:26:07 ... they should still be supported, but we don't encourage their use 00:26:39 duga: 'cutting edge' - because they are RELATIVELY new 00:27:18 wendyreid: the other part of the naming is that the name needs to be relatively well known 00:27:40 dlazin: okay, 'throwback' then? 00:27:57 ...'archived'? 00:28:31 ... the thing about frozen that i don't love is that it seems like we promise we aren't touching them, but we actually might polish them up in the future if an urgent need arises 00:28:37 wendyreid: 'parked'? 00:29:17 ... we don't want to discourage RS implementors from implementing these features, but we don't want authors to rely on them working 00:29:29 MURATA: 'unpopular' 00:29:56 wendyreid: there are popular ideas in this category that just never took over 00:30:09 dlazin: so just 'under implemented' then 00:30:57 s/MURATA:/shiestyle:/ 00:31:10 wendyreid: we are never going to test every RS, so when we say something is under implemented because it doesn't meet the W3C testing threshold, we don't really know 00:31:24 +1 to underimplemented 00:32:59 wendyreid: seems like maybe under implemented is our winner? 00:34:11 dlazin: the internet really thinks it should be hyphenated, but i like it with no hyphen (no space) 00:34:24 Proposed: Use the term "under-implemented" to describe features that do not meet the 2-implementor threshold for CR, but need to remain in the specification 00:34:26 u14d 00:35:04 dlazin: are we specifically saying that it doesn't meet 2? Or just that authors should not use these features because they are not used by the mainstream? 00:35:23 wendyreid: for the W3C priority of implementor doesn't matter 00:35:53 dlazin: for the benefit of our users should we use this category as a warning for features not in the mainstream? 00:36:00 +1 00:36:01 +1 00:36:01 +1 00:36:01 +1 00:36:02 +1 00:36:04 +1 00:36:06 wendyreid: not sure we should get into that, politics, etc. 00:36:07 +1 00:36:08 +1 00:36:15 RESOLVED: Use the term "under-implemented" to describe features that do not meet the 2-implementor threshold for CR, but need to remain in the specification 00:37:23 wendyreid: great, this will help us write our CR exit criteria 00:37:31 https://github.com/w3c/epub-specs/pull/1972 00:37:34 ... reminder re. reviewing PR about security and privacy 00:37:45 ... more comments the better, especially before PING and TAG get their hands on it 00:37:52 TOPIC: AOB? 00:38:09 wendyreid: great, thanks everyone! 00:38:25 ... see you all in a week or so! 00:38:54 zakim, end meeting 00:38:54 As of this point the attendees have been zheng_xu, shiestyle, MasakazuKitahara, MattChan, wendyreid, duga, MURATA, dlazin 00:38:56 RRSAgent, please draft minutes 00:38:56 I have made the request to generate https://www.w3.org/2022/01/21-epub-minutes.html Zakim 00:38:59 I am happy to have been of service, wendyreid; please remember to excuse RRSAgent. Goodbye 00:39:03 Zakim has left #epub 00:39:06 rrsagent, make logs public 00:39:30 rrsagent, make logs public 00:40:00 rrsagent, bye 00:40:00 I see no action items