Privacy and DRM

[wareid]

From the PING review:

What are the privacy impacts of DRM and how can they be mitigated? EPUBs are regularly distributed (after purchase, or perhaps more accurately, paying for limited license to read) with the contents fully encrypted and mediated by a DRM system (in particular, Adobe Digital Editions).

While this spec does not directly standardize DRM of EPUB files, it does design the file and package format in order to facilitate the DRM encryption of every file within the EPUB package. From the design of this specification, users cannot typically look at the table of contents or the stylesheet of a purchased ebook.

DRM and DRM licensing also effectively prevent user transparency into the privacy properties of the EPUB file itself: users cannot inspect the EPUB files that they read, cannot use open source software to analyze them, cannot customize software to limit how resources or loaded or information about them is shared.

https://cdt.org/wp-content/uploads/copyright/20060907drm.pdf
https://www.w3.org/TR/encrypted-media/#privacy
https://www.w3.org/2001/tag/doc/ethical-web-principles/#multi

[iherman]

The issue was discussed in a meeting on 2021-10-26

• no resolutions were taken

View the transcript

1.2. DRM and obfuscation

See github issue #1873, #1874.

Wendy Reid: next, DRM and obfuscation.
… is obfuscation only for fonts? No. It can also be applied to images, I believe. But most common use-case is for fonts.
… the obfuscation is done primarily by tools.

Dave Cramer: not aware of real world use of obfuscation aside from fonts.
… adobe was heavily involved in original epub. They were concerned about fonts easily accessed from the epub package..

Nick Doty: the obfuscation can be undone easily though.

Dave Cramer: some font vendors have told me that even these very ineffective means are good because then they can say that if you work around them then you violated DMCA etc..
… the legal case is clearer.
… this is anecdotal only. As a publisher we've not obfuscated fonts..
… but i'm open to discussion of whether we need this or not.

Rick Johnson: not a single title in our 2mm title inventory with font obfuscation included.

Wendy Reid: obfuscation tends to break things in RS.

Nick Doty: I'm not sure the goal of making it easier to sue the user is important.

Wendy Reid: DRM is tricky because the spec does not specify the DRM to be applied.
… there are a number out there, with the most popular being Adobe DRM.
… though implementation is also platform specific.
… in our charter we've said that we are not going to talk about DRM, which also complicates things.

Brady Duga: i think you can only obfuscate fonts.
… boils down to whether or not the publisher's license of the font allows it to be used in ebook or not.
… it appears to be okay to font vendors as long as font can be embedded.
… removing this may limit fonts that publishers can use.
… but this was also written before WOFF was a thing.
… so i'm open to recommending WOFF, but leaving it open to RS to do this (esp. for backwards compat).

Nick Doty: deprecating the feature would be helpful in terms of the risk of expanding user-agent-implemented obfuscation to other w3c work.

Rick Johnson: my opinion is that we shouldn't address this in spec.

Matt Garrish: we've never wanted to go into DRM implementation in spec.

Samuel Weiler: but you have the have the hooks for it in the spec, even if you aren't fully specifying the DRM.
… so we care about this.

Nick Doty: and the hooks make it so that the full contents of files are encrypted, rather than some smaller subset.

Tzviya Siegman: epub exists in an ecosystem that has been around for a long time. If we took out those hook we would be ceding our standard to a world that would not accept the lack of it.

Wendy Reid: we wouldn't have the support of most of the publishing industry, RS would be happy, and retailers would also be impacted.

Nick Doty: I think our goal in doing a privacy review is to note the current privacy situation and the potential harms.
But we could also consider harm reduction or mitigation, as W3C has done in the past about DRM.

Dave Cramer: I might disagree. If we took this out of the spec, would this change anything in practice?.
… as far as i know every epub created is done without DRM, because DRM is the responsibility of retailer rather than publisher.
… so removing from spec would not change this.
… and the DRM that exists and is being used may or may not rely on the hooks in the spec.

Matt Garrish: i agree with dauwhe. It doesn't break anything if we take this out..
… it might just make things more difficult for implementors.
… we'd need more information certainly, but not sure that anything breaks by taking this out.

Wendy Reid: okay, good points everyone. This is something we need to assess as part of our privacy threat model.

[iherman]

Whilst DRM is not mentioned in the EPUB specs, the "hook", that is commonly referred to in this discussion, is in §6.1.5.2.2 Encryption File. During the joint call with the PING IG it was proposed to simply remove this from the (normative sections of) the standard.

However, I wonder whether that is appropriate. Indeed, encryption.xml can, and is, used for DRM. But that is not the only usage. The specification allows a selective encryption of some EPUB content for which there may be legitimate use cases if one moves beyond the traditional books. For example, I can imagine legal documents, contracts, etc., that are exchanged between parties and whose parts are encrypted, much like one can set a password on a PDF file. To do that, encryption.xml becomes an important hook for interoperability.

Also, @npdoty raised, in his mail, whether an EPUB content can be signed or not. I am not an expert whether the current encryption.xml is enough to properly be used for the possibility of signing (part of) an EPUB content but, if not, we may want to look at the full section and review it (by possibly extend it) to allow for other legitimate usages of encryption in relation with EPUB content.

(Obviously, for, e.g., the signing example, the ultimate question is whether the reading systems would use such features, and that is unclear. We may want to formulate these things in a non-normative section.)

[danielweck]

@iherman :

the signing example, the ultimate question is whether the reading systems would use such features, and that is unclear. We may want to formulate these things in a non-normative section

EPUB 3.3:

https://w3c.github.io/epub-specs/epub33/core/#sec-container-metainf-signatures.xml

Adding a digital signature is not a guarantee that a malicious actor cannot tamper with an EPUB Publication as Reading Systems do not have to check signatures.

For what it's worth, I am not aware of any Readium-based reading system software that verifies per-resource signatures.

PS: EPUB encryption.xml is essential for EPUB DRM(s), but internally Readium abstracts away this XML syntax in favor of a more lightweight solution that also works well in the context of both Readium and W3C "Web Publications" (JSON serialization).

[llemeurfr]

Dave said: If we took this out of the spec, would this change anything in practice?

Well, if the specification of encryption.xml is taken out of the EPUB spec, it will have to find a place elsewhere, easy to find. Both Adobe Adept and Readium LCP (and certainly many others) use this hook, therefore RS implementers of one or the other need to find the specification. And moving it out of the spec should certainly not be considered as "deprecating the feature" by the way. Making it non normative in the spec may be an acceptable solution, as the hook defined by encryption.xml does not provide an end-to-end solution for protecting content.

Dave said: as far as i know every epub created is done without DRM, because DRM is the responsibility of retailer rather than publisher, so removing from spec would not change this.

EPUB is not "owned" by publishers: EPUB files are updated by retailers (the ones who apply a DRM at the request of publishers).

[iherman]

Making it non normative in the spec may be an acceptable solution, as the hook defined by encryption.xml does not provide an end-to-end solution for protecting content.

+1 to that. Actually, if it stays normative, not sure how we would test it...

[iherman]

The issue was discussed in a meeting on 2021-10-28

• no resolutions were taken

View the transcript

4.4. Privacy and DRM (issue epub-specs#1874)

See github issue epub-specs#1874.

Dave Cramer: what are the privacy concerns with DRM and how can they be mitigated:.

Wendy Reid: a concern they raised was that the user can't view source of an EPUB with DRM in the reading system like they can elsewhere on the web.
… we don't have a good way to address this because it manifests because of business reasons.

Dave Cramer: also not sure why privacy mitigation is to view source of complex computer files.

Brady Duga: we can take the DRM stuff out of the spec but it will have no effect on the world. Many reading systems don't use conventional DRM schemes.
… it's more a political than a practical issue. We could move it from the spec or a note..

Dave Cramer: but obfuscation relies on encryption.xml.

Dan Lazin: echoing that obfuscation uses encryption.xml.

Deborah Kaplan: if we punt on the political issue, then we can't talk about accessibility in DRM, which is a big problem.

Theresa O'Connor: primary purpose for spec is interoperability and primary audience is implementors. Not sure we are doing them any favors by removing this from the spec. Would rather acknowledge this.

Matt Garrish: encryption.xml is a W3C thing, so it would be weird to throw it out. we should let it slide..

Dave Cramer: there is an open source spec for EPUB designed for interoperability with DRM - DRM is important for library lending of eBooks too. I think I'm supportive of not backing away from our modest provisions to acknowledge how this technology is used in the real world..

Dan Lazin: is encryption.xml used in libraries?.

Brady Duga: yes.

Dan Lazin: so EPUB provides one way to provide DRM, but reading systems use their own anyway?.
… there are other ways to talk about encryption. Should we explore alternate ways to talk about obfuscation and DRM?.
… other purpose of the spec is to write down how stuff works..

Matt Garrish: do authors ever author in encryption.xml?.

Dave Cramer: it was always intended that reading systems would implement the DRM.

Theresa O'Connor: the document has authoring requirements that the tools that generate it need to follow.

Wendy Reid: we need to do some more investigation about this. Per our charter, DRM is supposed to be out of scope, but we also need to respond to horizontal review..

Dan Lazin: what section of the spec are we talking about? DRM is out of scope because it is not cross-compatible..

Dave Cramer: See relevant section of the spec.

Dave Cramer: intention was that you could buy an EPUB from one retailer and use it in another - but that never materialized.

Brady Duga: you can from GooglePlay Books even though it is DRM protected using Adobe.

Wendy Reid: Adobe DRM - you can download and sideload and share limited times but it authenticates everything (and breaks often).

[iherman]

The issue was discussed in a meeting on 2021-11-11

List of resolutions:

• Resolution No. 2: Close 1874; remove para from spec that contains "This version of the specification does not require a specific format for DRM information, but a future version might. ".

View the transcript

2. Privacy and DRM (issue epub-specs#1874)

See github issue epub-specs#1874.

Dave Cramer: next PING issue, there was some discussion earlier about ripping some of the DRM hooks out of the spec.
… general consensus was no, there are valid use cases, such as obfuscation.
… can't get right of encryption.xml, signing things could be useful.
… leaning towards recommending that we not change the DRM things that are already in the spec.
… does that seem reasonable?.

Matt Garrish: I found some old language about "future versions of spec might require specific format for DRM", so I'll probably just cut that.

Dave Cramer: yes.
… where did you see that?.

Matt Garrish: that was in core spec.

Proposed resolution: Close 1874; remove line from spec about "This version of the specification does not require a specific format for DRM information, but a future version might. ". (Dave Cramer)

Matt Garrish: might want to just cut that whole paragraph, the rest of it is pretty non-specific.

Proposed resolution: Cclose 1874; remove para from spec that contains "This version of the specification does not require a specific format for DRM information, but a future version might. ". (Dave Cramer)

Dave Cramer: +1.

Matthew Chan: +1.

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

Masakazu Kitahara: +1.

Toshiaki Koike: +1.

Matt Garrish: +1.

Brady Duga: +1.

Victoria Lee: +1.

Resolution #2: Close 1874; remove para from spec that contains "This version of the specification does not require a specific format for DRM information, but a future version might. ".

[mattgarrish]

Closing this issue per the resolution from the meeting referenced in the previous comment. The change was made in #1905