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

My comments:

-----Original Message-----
From: Jonas Sicking [mailto:jonas@sicking.cc] 
Sent: 19 November 2009 10:11
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.

[DAVID] ...apart from your example below?

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.

[DAVID] Completely agreed - and the reason why? They don't understand
(or care). Allow someone else to provide that for the user.

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.

[DAVID] See above

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.

[DAVID] I would expect that you would do this as a matter of course
anyway as part of the security lifecycle. However a side-benefit from
your argument would be that policy would therefore help reduce your
maintenance?

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.

[DAVID] Strange argument this one, so you're complaining about
protecting your users. However, I see where you are coming from, perhaps
policy could help ;-)

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

[DAVID] So the problem couldn't be solved without significant effort so
it was avoided? This a risk-avoidance strategy, rather than
risk-management - it works sometimes but you can't do it for everything.
That would be like having agoraphobia to avoid being run over by a bus. 

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.


[DAVID] Great, I hope that your experiences can be contributed back here
if possible?

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

/ Jonas

Received on Thursday, 19 November 2009 11:03:56 UTC