Re: privacy review notes on EPUB 3.3

On Wed, May 4, 2022 at 5:52 PM Matt Garrish <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