Re: privacy review notes on EPUB 3.3

On the issue of the normative statements vs. the current status as well as what we can control: I wonder whether the following compromise approach is acceptable:

- the relevant sections are NOT marked as informative
- we only use SHOULD statements and no MUST statements for what we choose to emphasize in those sections

This approach would give, hopefully, a significantly more weight to our statements than they have today and, for the cases where this is feasible, we can also create tests and add it to our test suite (it already includes tests for SHOULD statements, ie, it is well prepared for that). On the other hand, we avoid the sticky question on what should we do if we declare a feature a MUST but we cannot fulfill the exit criteria (per the usual approach those features should be removed from the spec or marked as explicitly under-implemented per our own agreement, neither of the two sound like a good idea).

Nick, what do you think?

Ivan



> On 11 May 2022, at 02:04, Nick Doty <ndoty@cdt.org> wrote:
> 
> On Wed, May 4, 2022 at 5:52 PM Matt Garrish <matt.garrish@gmail.com <mailto:matt.garrish@gmail.com>> wrote:
> Hi Nick,
> 
> 
> 
> > These sections are marked as non-normative, but then include lots of normative language. I understand from the conformance sections that you don't intend that text to have the meaning of RFC 2119. However, I am concerned by this as a confusing trend
> 
> 
> 
> Right, W3C has adopted RFC 8174. I can kind of appreciate why, given the contortions mocked by RFC 6919 <https://datatracker.ietf.org/doc/rfc6919/>. 😉
> 
> 
> Yes, that is also part of my concern here. Whether the words are in all caps or not, it does seem like we're often saying, you really shouldn't do this, but we know you will anyway. Moreso, I'm concerned that it could also be interpreted as: we'll make no attempt to fix it and you won't even have to pretend or assert that you aren't doing the wrong thing.
> 
> More seriously, we’ve tended not to enforce requirements that can’t be tested and/or are going to be implementation specific. Just as an example, an EPUB publication can’t enforce that a publisher obtain consent to collect data prior to a user opening it. We know you should do it, but when we’ve made these sorts of statements normative in the past they’ve been called “aspirational”. Similarly, a reading system should allow users to control any information collected, but there’s no single solution to the problem.
> 
> 
> 
> I don’t personally have an issue with these being stated in normative terms, but I don’t have enough experience with W3C standardization process to know if they’d raise flags as being underspecified if we did.
> 
> 
> I think non-normative language can still be valuable: in particular, we can try to be clear about who has the responsibility to do what to protect the user, even if we can't currently specify it in a normative and interoperable way. And it can be a useful marker for future work, to be clear that these privacy issues haven't yet been directly resolved yet, but there are expectations for how they're used and there may be changes in the future to limit their invasiveness or insecurity.
> 
> There may also be cases where requirements are testable and could be made normative, even if they haven't typically been easily included in automated test suites.
> 
> > The rs and a11y specs note cases where certain behavior might violate privacy laws … I don't think that should be the motivation for protecting user privacy
> 
> 
> 
> Right, it’s not even necessary in the accessibility spec to cite privacy laws as it’s not adding anything. I’ll have to go back and see what the RS spec says.
> 
> 
> 
> > External resources should be loaded securely, for example over HTTPS.
> 
> 
> 
> This sounds like a useful restriction.
> 
> 
> 
> Apologies for being selective and brief in my comments, as I’m on the road right now. It would probably help to get your concerns into the github tracker rather than discuss over email. I’ll try and do that when I have a minute.
> 
> 
> I've opened #2263, #2265, #2266 for the security issues. #2264 for the mostly editorial issue on unrelated documents. #2267 for the privacy laws editorial issue.
> 
> I think we should re-open 1876, 1872 and 1875, and that 1872 (normative changes might be necessary) and 1875 (might just be non-normative changes but not sure) should be marked as privacy-needs-resolution. My github account doesn't have authority to do that, though, but I've marked need-resolution in the linked horizontal review tracking issues.
> 
> Hope that helps,
> Nick


----
Ivan Herman, W3C
Home: http://www.w3.org/People/Ivan/
mobile: +33 6 52 46 00 43