From c9fd7d7665d6f2f9ab8af0aa57ac04d1fd6d8ac3 Mon Sep 17 00:00:00 2001
From: Matt Garrish
Date: Fri, 20 May 2022 09:11:34 -0300
Subject: [PATCH 1/2] remove unnecessary recommendation about access to
persistent storage from unrelated documents; add authoring recommendations
not to store sensitive user data in persistent storage or to encrypt it if it
must be stored
---
epub33/core/index.html | 17 +++++++++++++++--
epub33/rs/index.html | 20 +++++++++-----------
2 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/epub33/core/index.html b/epub33/core/index.html
index bba8a6b05..8dc1d6222 100644
--- a/epub33/core/index.html
+++ b/epub33/core/index.html
@@ -9423,10 +9423,20 @@ Recommendations
creators should also allow users to opt out of tracking, when feasible, and provide users the
ability to manage and delete any data that is collected about them.
- Content authors also need to consider the inadvertent collection of information about users. Linking
- to content on a publisher's web site, or remotely hosting resources on their servers, can lead to
+
EPUB creators also need to consider the inadvertent collection of information about users. Linking to
+ content on a publisher's web site, or remotely hosting resources on their servers, can lead to
profiling users, especially if unique tracking identifiers are added to the URLs.
+ When collecting and storing user information within an EPUB publication (e.g., through the use of cookies and web
+ storage [[?html]]), EPUB creators need to consider to potential for data theft by other EPUB
+ publications on a reading system. Although [[epub-rs-33]] introduces a unique origin requirement for EPUB publications,
+ which limits the potential for attacks, older reading systems may allow all EPUB publications access
+ to the same persistent storage. Consequently, EPUB creators SHOULD NOT store sensitive user data in
+ persistent storage. If EPUB creators must store sensitive data, they SHOULD consider encrypting the
+ data to prevent trivial access to it in the case of an exploit.
+
When publishers and vendors must use digital rights management schemes, they should prefer schemes
that do not utilize or transmit information about the user or their content to external parties to
perform encryption or decryption.
@@ -11503,6 +11513,9 @@ Change log
>Working Group's issue tracker.
+ - 20-May-2022: Add recommendation not to store sensitive user data in persistent storage, and to
+ encrypt it if there is no other choice. See issue 2264.
- 17-May-2022: Added an index of terms. See issue 2260.
- 12-Apr-2022: Added note about complexities of escaping from nested escapable structures and updated
diff --git a/epub33/rs/index.html b/epub33/rs/index.html
index f3248e663..330e97c0e 100644
--- a/epub33/rs/index.html
+++ b/epub33/rs/index.html
@@ -1152,8 +1152,8 @@
Cascading Style Sheets (CSS)
-
MUST support [[truetype]],
- [[opentype]], [[woff]], and [[woff2]] font resources referenced from
- @font-face
rules
+ [[opentype]], [[woff]], and [[woff2]] font resources referenced from @font-face
rules
[[css-fonts-4]].
-
@@ -1278,15 +1278,9 @@
Scripting
Local storage
-
- Scripts may save persistent data through cookies and web
- storage [[html]], but reading systems MAY block such attempts.
- Reading systems that allow users to store data
- MUST ensure they do not make that data available to other unrelated documents (e.g., ones
- that could be spoofed). In particular, checking for a matching document identifier (or
- similar metadata) is not a valid method to control access to persistent data.
-
+ Reading systems MAY block scripts from saving persistent
+ data through cookies and web storage [[html]].
Reading systems that allow local storage [[html]] SHOULD
provide methods for users to inspect or delete that data.
@@ -2544,6 +2538,10 @@ Change log
>Working Group's issue tracker.
+ - 20-May-2022: Removed the recommendation to prevent access to persistent storage from "unrelated
+ documents". This recommendation conflicts with, and is made redundant by, the unique origin
+ requirement introduced in this revision. See issue 2264.
- 17-May-2022: Added an index of terms. See issue 2260.
- 31-Mar-2022: Moved custom attribute authoring requirements to the authoring specification. Added
From 8babf6c299b5f8ef93cde270b741a3f750525193 Mon Sep 17 00:00:00 2001
From: Matt Garrish
Date: Sun, 22 May 2022 07:13:32 -0300
Subject: [PATCH 2/2] updated wording per feedback
---
epub33/core/index.html | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/epub33/core/index.html b/epub33/core/index.html
index 8dc1d6222..47c659f34 100644
--- a/epub33/core/index.html
+++ b/epub33/core/index.html
@@ -9432,10 +9432,11 @@
Recommendations
storage [[?html]]), EPUB creators need to consider to potential for data theft by other EPUB
publications on a reading system. Although [[epub-rs-33]] introduces a unique origin requirement for EPUB publications,
- which limits the potential for attacks, older reading systems may allow all EPUB publications access
- to the same persistent storage. Consequently, EPUB creators SHOULD NOT store sensitive user data in
- persistent storage. If EPUB creators must store sensitive data, they SHOULD consider encrypting the
- data to prevent trivial access to it in the case of an exploit.
+ which limits the potential for attacks, there is still a risk that reading systems will allow EPUB
+ publications access to shared persistent storage (e.g., older reading systems that have not been
+ updated and non-conforming newer reading systems). Consequently, EPUB creators SHOULD NOT store
+ sensitive user data in persistent storage. If EPUB creators must store sensitive data, they SHOULD
+ encrypt the data to prevent trivial access to it in the case of an exploit.
When publishers and vendors must use digital rights management schemes, they should prefer schemes
that do not utilize or transmit information about the user or their content to external parties to