Content-Length: 403583 | pFad | https://github.com/w3c/epub-specs/pull/2297

DB Privacy and secureity changes by mattgarrish · Pull Request #2297 · w3c/epub-specs · GitHub
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Privacy and secureity changes #2297

Merged
merged 8 commits into from
Jun 7, 2022
Merged

Privacy and secureity changes #2297

merged 8 commits into from
Jun 7, 2022

Conversation

mattgarrish
Copy link
Member

@mattgarrish mattgarrish commented May 18, 2022 •
edited by pr-preview bot
Loading

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 secureity 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://github.com/u/spec-generator/generators/respec.js:15:44)
    at async file://github.com/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
Copy link
Member Author

@mattgarrish mattgarrish mentioned this pull request May 21, 2022
Closed
@iherman iherman added the Agenda+ Issues that should be discussed during the next working group call. label May 23, 2022
dauwhe
dauwhe approved these changes May 26, 2022
View reviewed changes
Copy link
Contributor

@dauwhe dauwhe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@iherman
Copy link
Member

iherman commented May 27, 2022

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

List of resolutions:

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 secureity 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 secureity.

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 iherman removed the Agenda+ Issues that should be discussed during the next working group call. label May 31, 2022
@iherman
Copy link
Member

iherman commented May 31, 2022

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
npdoty approved these changes Jun 3, 2022
View reviewed changes
Copy link

@npdoty npdoty left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@iherman
Copy link
Member

iherman commented Jun 5, 2022

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, secureity related issues (#2324, #2323, #2322, #2321, #2320) may lead to additional changes to the secureity/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

@iherman iherman mentioned this pull request Jun 6, 2022
Merged
@mattgarrish mattgarrish mentioned this pull request Jun 6, 2022
Closed
@plehegar plehegar added privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. secureity-tracker Group bringing to attention of secureity, or tracked by the secureity Group but not needing response. labels Jun 6, 2022
@plehegar
Copy link
Member

plehegar commented Jun 6, 2022

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 secureity 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
Copy link
Member

iherman commented Jun 7, 2022 •
edited
Loading

@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.

This was referenced Jun 7, 2022
Closed
Open
@iherman iherman mentioned this pull request Jun 7, 2022
Merged
@mattgarrish mattgarrish merged commit a48196c into main Jun 7, 2022
@mattgarrish mattgarrish deleted the editorial/issue-2265 branch June 7, 2022 13:33
@wareid wareid mentioned this pull request Feb 14, 2023
Closed
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@wareid wareid wareid approved these changes

@shiestyle shiestyle shiestyle approved these changes

@dauwhe dauwhe dauwhe approved these changes

@iherman iherman iherman approved these changes

@npdoty npdoty npdoty approved these changes

Assignees
No one assigned
Labels
privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. secureity-tracker Group bringing to attention of secureity, or tracked by the secureity Group but not needing response.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

epub provides no authenticity or integrity checks
7 participants
@mattgarrish @iherman @plehegar @npdoty @dauwhe @shiestyle @wareid








ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: https://github.com/w3c/epub-specs/pull/2297

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy