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.

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

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