Privacy and security changes

[mattgarrish]

This pull request comes from a response from @iherman to the email from @npdoty recorded in the chairs mailing list. His suggestion was to potentially make the privacy and security sections normative but ensure that they are only recommendations (almost all were).

I've gone through the three REC track documents and fixed them so that all applicable recommendations are now normative.

We will probably want to discuss this with the WG on a call before making this change, though.

The PR also fixes #2265 by noting under the malicious content heading that because we don't have a standard means of signing publications there isn't always a way to verify the integrity. I've also added a pargraph to the end of the recommendations to say that reading systems should treat unsigned content loaded by the user as untrustworthy. Improvements to the text welcome.

(If we decide not to incorporate the first part, I'll split the second out, but they're tightly bound to each other until we know which direction we're taking.)

---

💥 Error: 500 Internal Server Error 💥

PR Preview failed to build. (Last tried on Jun 7, 2022, 12:46 PM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 Spec Generator - Spec Generator is the web service used to build specs that rely on ReSpec.

🔗 Related URL

😭  Sorry, there was an error generating the HTML. Please report this issue!
Specification: http://labs.w3.org/spec-generator/uploads/a51ive?isPreview=true&publishDate=2022-06-07
ReSpec version: 32.1.8
File a bug: https://github.com/w3c/respec/
Error: Error: Evaluation failed: Timeout: document.respec.ready didn't resolve in 27539ms.
    at ExecutionContext._evaluateInternal (/u/spec-generator/node_modules/puppeteer/lib/cjs/puppeteer/common/ExecutionContext.js:221:19)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async ExecutionContext.evaluate (/u/spec-generator/node_modules/puppeteer/lib/cjs/puppeteer/common/ExecutionContext.js:110:16)
    at async generateHTML (/u/spec-generator/node_modules/respec/tools/respecDocWriter.js:221:12)
    at async toHTML (/u/spec-generator/node_modules/respec/tools/respecDocWriter.js:92:18)
    at async Object.generate [as respec] (file:///u/spec-generator/generators/respec.js:15:44)
    at async file:///u/spec-generator/server.js:247:48

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

[mattgarrish]

• EPUB 3.3:
  • Preview
  • Diff
• EPUB Reading Systems 3.3:
  • Preview
  • Diff
• EPUB Accessibility 1.1:
  • Preview
  • Diff

[dauwhe]

I think this reads much better now, in addition to being a stronger statement about privacy. Thanks!

[iherman]

The issue was discussed in a meeting on 2022-05-26

List of resolutions:

• Resolution No. 1: Approve PR 2297.

View the transcript

1.1. Making statements normative.

See github pull request epub-specs#2297.

Dave Cramer: one of the key elements of the feedback was that most of our security and privacy section was non-normative, and Nick thought it should be.
… this PR makes that change so that many of the things we discussed non-normative have become normative, but still SHOULD.
… reading through this PR, it seems to be a better statement of our values and the importance of privacy and security.

Matt Garrish: this also addresses concern re. unsigned epubs and whether RS can trust such epubs.
… not sure how to phrase, because unsigned doesn't necessarily mean untrustworthy.
… language now gives a lot of leeway to RS.
… can't necessarily be enforced, but still good practice that we are now throwing our weight behind.

Dave Cramer: still significant progress versus previous versions of epub on this.

Wendy Reid: we can't merge anything right now because we have it set so that it auto publishes after a merge.
… we need to figure out if we need a new snapshot.

Proposed resolution: Approve PR 2297. (Wendy Reid)

Dave Cramer: +1.

Matt Garrish: +1.

Matthew Chan: +1.

Dan Lazin: +1.

Toshiaki Koike: +1.

Wendy Reid: +1.

Shinya Takami (高見真也): +1.

Brady Duga: +1.

Masakazu Kitahara: +1.

Resolution #1: Approve PR 2297.

[iherman]

Status comment: merging this PR depends on the admin question on whether making this update should be done through the publication of a new CR snapshot or whether it is o.k. to merge it as is, yielding a CR draft.

@plehegar ?

[npdoty]

I think the normative recommendations and the recognition of the security/privacy risks from integrity/authenticity are improvements. Thanks.

[iherman]

First reactions from #2297 (comment) indicate that merging this PR would indeed require a new CR snapshot.

On the other hand, some of the new, security related issues (#2324, #2323, #2322, #2321, #2320) may lead to additional changes to the security/privacy sections, some of them may even be normative changes (like #2324) which means a new CR snapshot anyway. My proposal would be to do all the editorial changes on the branch behind this one (e.g., create PR-s against https://github.com/w3c/epub-specs/tree/editorial/issue-2265) and, when we get to an equilibrium point, publish this one as a snapshot (after a sync with the main branch).

@mattgarrish @wareid @dauwhe @shiestyle

[plehegar]

Status comment: merging this PR depends on the admin question on whether making this update should be done through the publication of a new CR snapshot or whether it is o.k. to merge it as is, yielding a CR draft.

@plehegar ?

Changes can always be done through a CR draft. Whether this would also require a CR snapshot depends on whether the changes are substantive, with implications on the IP. The sections on security and privacy are reclassified as normative with this pull request. However, because the section only list SHOULD and SHOULD NOT statements, it does not seem to impact implementation requirements. So, on a first pass analysis, I think we would not need to publish yet another CR snapshot before moving beyond CR.

[iherman]

@plehegar thanks. That certainly simplifies our life.

However, just one more thing: we plan to have a proposal that would be a normative change: instead of a SHOULD NOT we plan to say MUST NOT use the file scheme URLs in EPUB. Following your logic, that can also be published (if the WG approves the change, that is) without going through a snapshot, can't it? It certainly is not an IP issue and, in our estimation, it does not affect current deployment.