RE: DAP and security (was: Rename "File API" to "FileReader API"?)

Hi Jonas,

Well, great thanks for the very exhaustive report.
It seems we will have to think a lot in DAP.

Thanks,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: Jonas Sicking [mailto:jonas@sicking.cc]
Sent: Thursday, November 19, 2009 11:11 AM
To: Marcin Hanclik
Cc: David Rogers; Maciej Stachowiak; Dominique Hazael-Massieux; Robin Berjon; public-device-apis@w3.org; public-webapps WG
Subject: Re: DAP and security (was: Rename "File API" to "FileReader API"?)

On Thu, Nov 19, 2009 at 1:08 AM, Marcin Hanclik
<Marcin.Hanclik@access-company.com> wrote:
> Hi Jonas,
>
> I think that it all depends on the user or the abstraction that we seem to have about the user.
>
> We can take the analogy to the operating system.
> OS may e.g. not be writable for the user, may have pre-defined active firewalls etc.
> The user then may not access some sites, may not install any native app etc.
> The OS or PC is a kind of a toy or a kiosk.
>
> Later, the user switches off firewalls, gets admin rights, installs apps that have access to the file system etc.
>
> I think that the same principle is being applied to the browser world.
> Policy is to make it all easier and more comprehensible.
> The default settings within a browser could e.g. disable directory walking and file writing. But if the user changes the settings (and is warned about the potential security risks when switching some protection off), then it is up to the user and she/he takes over the responsibility.
> The abstraction of the security concerns within a policy may allow delegation of the security to some third parties.

I doubt that we'd spend time on implementing a feature that is
disabled by default out of security considerations.

First of all it'd basically not be worth our time since very few users
change default settings. This is magnified by the fact that very few
websites would use such a feature (since, again, few users change
default settings), so we wouldn't really be improving the web a whole
lot.

Second, users would inevitably turn the feature on without realizing
what security implications it has, meaning that we put a group of
users at risk.

Third, we'll have to spend efforts maintaining the code, even though
it benefits only a small number of people. For example if a buffer
overflow bug is found we'll have to treat that as as serious of a bug
as a overflow in normal on-by-default code. Up to and including
engineering efforts to fix the bug, QA efforts to test the fix,
release resources to spin a new emergency release, and marketing
efforts asking people to upgrade.

I can draw a couple of real-world analogies. In Thunderbird (the email
reader from mozilla), there is support for enabling javascript in
emails. This support is turned off by default. However many people
turn it on, without realizing that this means that someone that sends
you an email can see if you forward this email to anyone, and see what
comments you are adding to that email. All they wanted was javascript
for some other, much more secure, use case.

Additionally, we've having to release *many* security updates
specifically to account for the minority of people that turn on
javascript. We're currently on security update number 23. If we didn't
bother making updates when only people that had turned on javascript
were affected, we would have had a fraction as many updates.

As a result, the next major version of thunderbird is removing the
ability to turn on javascript completely. Not even a hidden preference
exists.


Similarly, there was a preference in Firefox 3 that allowed
XMLHttpRequest to load resources from any site without any security
restrictions. Originally the preference had been added for no
particular reason; "why not, it's disabled by default". And intended
to be enabled only on a per-site basis. However due to how some
security architecture works it was possible to set a default behavior
that applied to all sites.

Eventually developers found this preference (how, i do not know, we
never had documentation for it) and word spread through blogs that
switching this pref was useful during development and testing [1].
What these people didn't realize is that switching this pref means
that any website you go to can read your creditcard numbers and bank
statements if you happen to be logged in to your bank. Or your emails
if you happen to be logged in to gmail. So switching that pref
essentially handed all the personal information you store on the web
to any evil site you visit.

Once I noticed that that pref existed I removed it.


Ultimately I don't really have anything against security policies in
principal. However when looking at implementing an API in firefox
we'll definitely be reviewing the API in the light of the default
policy used by Firefox. If the API doesn't make sense from that point
of view I don't see us implementing it.

[1] http://blog.dirolf.com/2007/06/enabling-cross-domain-ajax-in-firefox.html

/ Jonas

________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Thursday, 19 November 2009 10:25:23 UTC