Re: Security Use Cases - Very rough first draft

Leonard, I didn't mean to pick on PDF or Adobe Reader unfairly. As I see it
in gathering requirements for portable publications on the Web we would be
remiss not to carefully consider the incumbent portable document solution.
And I was mainly just pointing out, since Baldur's requirements (along with
other things he's written) seemed to portray scripting in offline documents
as something new and dangerous, that it's not new, and may not be any more
dangerous in a future PWP solution than it already is today. The details
don't really matter and i could have just as easily picked on Microsoft
Word since there's right now a serious malware crisis in DOCM files [1].

But if I wrote anything that's materially incorrect please let me know
where I went wrong.That there have been separate JS APIs in Adobe
Acrobat/Reader for general extensions, XFA and 3D is not internal Adobe
information: these APIs have been publicly documented ([2], [3], etc.) and
if APIs have been streamlined in recent years presumably that's public as
well so please correct me. And I thought I made it clear that the part
about 4 different JS interpreters co-residing in Adobe Reader was
historical... I certainly I make no claims to any current knowledge about
Adobe code internals. Anyway if you are claiming my note was "a whole lot
of INCORRECT" but are unwilling to say why, then I'm not the one who's
spreading "FUD".

Regardless, the big picture is it seems something we agree on: scripting
represents only one of many security threats in documents, particularly
those shared ad hoc between users.

As far as EPUB 3, you are probably right that since EPUB's use to date has
been limited, and primarily via commercial channels that check content en
route to distribution, there hasn't been a huge incentive of opportunity
for malware. Sadly, that is likely to change as we see, thanks to things
like Google Docs and other WP software exporting EPUB 3 and increasing need
for EPUB 3 to meet accessibility mandates.  So we should have even more
datapoints en route to fully achieving the PWP vision.

--Bill

[1]
http://www.healthcareitnews.com/news/massive-locky-ransomware-attacks-hit-us-hospitals

[2]
http://help.adobe.com/en_US/acrobat/acrobat_dc_sdk/2015/HTMLHelp/#t=Acro12_MasterBook%2FIntroduction_Help_TitlePage%2FAbout_This_Help.htm
[3]
http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/js_api_reference.pdf

On Sun, Aug 21, 2016 at 6:24 PM, Leonard Rosenthol <lrosenth@adobe.com>
wrote:

> While I appreciate that Bill +1’d me on my P2P use case – it’s a bit
> problematic that he then went on to spread a whole lot of INCORRECT FUD
> (fear, uncertainty and doubt) about the PDF technology and Adobe’s
> implementation of same.
>
> Bill – while you certain had a significant hand in the early days of the
> technology, you haven’t been part of Adobe or the development of PDF for 6
> years now.  Things have moved beyond what you knew then and I would
> appreciate you sticking to things that you have an up to date knowledge
> source for.   And since isn’t the place for me to correct them, I will
> leave them for now. (though if anyone wishes to reach out to me in private,
> I am happy to answer).
>
> Now – back to the question/issue at hand – security in PWP.
>
> There is certainly no question that content with JavaScript (either
> included or referenced) has a greater security risk than content without it
> – it is actually just one aspect of issues that need to be considered
> around PWP security.  Even documents that have ZERO scripting can be
> security risks if they have external references – even to CSS or fonts or
> other types of content.  For that matter, as we’ve seen actually in the
> field, even a document that has all resources full embedded can be a
> security risk if an attacker is able to incorporate a malicious binary,
> such as a font.
>
> > I believe that today's EPUB 3 solutions built on OWP with its more
> well-defined security model and predominantly open source implementations,
>
> >is very arguably more secure than PDF, or at least there's no clear
> evidence that it's less secure.
>
> >
>
> I would put forth two comments here:
>
> 1 – EPUB has such a limited distribution and use in the world today that
> hackers don’t care about it.  Assuming that they did find one (or more)
> attacks using EPUB – the number of impacted users would be so small as to
> not make their investment worthwhile.  Hacking today is really a business
> with a standard ROI model.  It’s why the (“Big 3”) browsers as well as
> Adobe products have historically be the best targets – we have the widest
> distribution.   You never see attacks against Opera – because there is no
> ROI.  And only recently have they gone after companies such as FoxIt – and
> mostly because Chrome uses their engine.
>
> 2 – EPUB’s current “no scripting” and “fully self-contained” model have
> indeed served it well to be more secure than other solutions.  However, as
> we move away from those limitations to the areas that PWP brings us, it
> also means that those fences/walls will no longer be there to hold back
> potential attacks.  And worse, every attack vector available on the web is
> now also one for your publications.
>
>
>
>
>
> Leonard
>
>
>
>
>
> *From: *Bill McCoy <bmccoy@idpf.org>
> *Date: *Saturday, August 20, 2016 at 2:03 PM
> *To: *Ivan Herman <ivan@w3.org>
> *Cc: *Bill McCoy <whmccoy@gmail.com>, Baldur Bjarnason
> <baldur@rebus.foundation>, W3C Digital Publishing IG <
> public-digipub-ig@w3.org>
> *Subject: *Re: Security Use Cases - Very rough first draft
> *Resent-From: *<public-digipub-ig@w3.org>
> *Resent-Date: *Saturday, August 20, 2016 at 2:04 PM
>
>
>
> Even though it was not specifically a reply to my comment I want to +1
> Ivan's take on this.
>
>
>
> And I also want to +1 something Leonard said about ad hoc (P2P) use cases
> for sharing documents also being important, and to tease out an implication
> of that.
>
>
>
> PDF is of course the prevalent portable document format today, especially
> for P2P. And PDFs can contain active content - JavaScript - just like EPUBs
> and Web pages - and arguably that active content represents a far more
> dangerous security risk:
>
>
>
> - 99% of PDF rendering (gross estimate) is done via closed source
> solutions that aren't subject to objective security analysis or security
> vulnerability correction by third parties (unlike 3 out of the 4 top
> browser, including the browser engines built-in to both top mobile OS's)
>
>
>
> - the most widely used PDF implementation, Adobe Reader, has 3 different
> instantiations of JavaScript, each with their own set of unique APIs (at
> one point in the past 4 instantiations and at that time all different
> versions of the JS interpreter!)... these are for general JS code in the
> main context, for JS used with XML Forms Architecture (XFA) content, and JS
> used with 3D content.
>
>
>
> - the PDF specifications do not formally define the document execution
> life cycle or security model of executing script code in a rigorous way.
> For example while in Adobe Reader some (but not all) cases of remote
> network access from scripting in PDF produce user-visible warnings the
> behavior depends on preference settings which are application
> implementation details, not part of the PDF specification itself.
>
>
>
> - in particular in PDF there is no model of encapsulation of less trusted
> content inside a container of more trusted content, everything operates at
> the same (implicit) trust level.. Whereas for OWP, IFRAME et. al. provide
> an encapsulation model (further elaborated in EPUB with Embedded Scriptable
> Components).
>
>
>
> - https://www.cvedetails.com/vulnerability-list/vendor_id-
> 53/product_id-497/Adobe-Acrobat-Reader.html (enough said)
>
>
>
> I believe that today's EPUB 3 solutions built on OWP with its more
> well-defined security model and predominantly open source implementations,
> is very arguably more secure than PDF, or at least there's no clear
> evidence that it's less secure. Yet we very rarely hear publishers or end
> users distributing documents being seriously worried about scripting in
> PDFs (even if, objectively, they should be).
>
>
>
> Therefore I believe part of this is a marketing issue not a technical
> issue. As more and more of the online Web seems ridden with sketchy ads and
> malware, commercial publishers fear similar things happening with their
> premium paid content. That is not necessarily an irrational fear and I
> support that we should be taking security very seriously, but since at a
> technical level PDF sets a very low bar for PWP, which EPUB 3 may already
> have exceeded, we shouldn't presume that we have a technical disaster
> already on our hands,
>
>
>
> --Bill
>
>
>
>
>
> On Sat, Aug 20, 2016 at 12:22 AM, Ivan Herman <ivan@w3.org> wrote:
>
> (This not a reply on this mail specifically but rather on the  resulting
> thread… the result of being in a different timezone:-)
>
>
>
> I think that, at this point and mainly for the purpose of the UCR
> document, what we have to concentrate on is what extra security
> requirements PWP-s have over the general Web security aspect. I realize
> that Baldur's use cases are in this direction (thanks Baldur:-), but I also
> agree that, at this point, we should not, in this document, go into
> specific technical solutions; this is not the goal of the UCR (but will be
> the topic of a future Working Group if and when we get there).
>
>
>
> To put it another way: when I talk to my Web Application friends, I do
> tell them that publishers are more nervous about security than many other
> content providers on the Web, they are nervous of using Javascript for the
> these reasons, etc. I think these high(er) level fears and concerns, and
> their reasons, should be clearly spelled out in this document (and, for
> example, these *are* related to issues in this document, like the problem
> of origin; I guess it also goes for the integrity of the publication as a
> whole that gets copied around but is also, at the same time, possibly
> copyrighted, etc). Web Application people should understand that there is a
> community out there that may be more stringent in this sense. At the same
> time, Publishing people should understand that the PWP community does take
> these concerns seriously and it is not the intention of ignore them in a
> big and happy kumbaya with Web technologies. *This* is what the UCR
> document should reflect, without getting into the technical weeds…
>
>
>
> My 2 cents…
>
>
>
> Ivan
>
>
>
>
>
>
>
> On 19 Aug 2016, at 18:13, Bill McCoy <whmccoy@gmail.com> wrote:
>
>
>
> Most if not all of these requirements do not seem to be  specific to "Web
> Publications" as the term is defined by DPUB IG.
>
>
>
> It is of course true that publications must not compromise the basic
> security model of the Web.
>
>
> Unfortunately, the definition of that general security model and the
> associated runtime life cycle isn't entirely clear, especially when it
> comes to content and applications stored on / executing from local
> systems.  And I'm not sure it's the job of DPUB IG to attempt to define
> with precision that general model. Or, if we do take on the job of fully
> defining that security model, we should realize we aren't doing it just for
> "Publications" but really for Web content in general.
>
>
>
> https://www.w3.org/TR/runtime/ is for example recent work in this area
> started by the now defunct System Applications WG. Some  of this seems very
> applicable to Web Publications. That it's unfinished orphaned work is
> perhaps a warning sign that it may not be an easy job to take on but
> perhaps someone could adopt it (which may be preferable to starting over).
> Whether that's DPUB IG or a successor vs. say the Web Platform WG is
> another question... and I guess to me this is all logically part of the Web
> Platform itself.
>
>
>
> EPUB specifications to date have clearly punted on this but one reason was
> that we were hoping that work on Web Applications at W3C would be paving
> the way in terms of more rigorously defining the Web security model
> especially for offline/local content.
>
>
>
> --Bill
>
>
>
>
>
> On Fri, Aug 19, 2016 at 5:34 AM, Baldur Bjarnason <baldur@rebus.foundation>
> wrote:
>
> Security Use Cases - Very rough first draft
>
> Here it is on Google Docs:
>
> https://docs.google.com/document/d/1i8vm8cg5iqxWgpPFRR3Qae5loj-
> DWcrsbBUIf2IeGaU/edit?usp=sharing
>
> Let me know if you can’t access it and I’ll find another way to share it
> with the list or fiddle with the sharing settings on the document itself.
>
> It’s a very rough draft, half-baked, doesn’t conform to spec style or
> structure etc. etc.
>
> All of the links included are there more as informative references for
> context and will have to be turned into proper spec references or removed
> in a later draft.
>
> If the scenarios seem paranoid downers then bear in mind that my biggest
> worry while writing it is that I might not be paranoid enough.
>
> - best
> - Baldur Bjarnason
>   baldur@rebus.foundation
>
>
>
>
>
>
>
>
>
> ----
> Ivan Herman, W3C
> Digital Publishing Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
>
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>
>
>
>
>
>
>
>
> --
>
>
>
> Bill McCoy
>
> Executive Director
>
> International Digital Publishing Forum (IDPF)
>
> email: bmccoy@idpf.org
>
> mobile: +1 206 353 0233
>
>
>



-- 

Bill McCoy
Executive Director
International Digital Publishing Forum (IDPF)
email: bmccoy@idpf.org
mobile: +1 206 353 0233