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

[Marcin Hanclik]

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.

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.hanc...@access-company.com

-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Wednesday, November 18, 2009 9:15 PM
To: David Rogers
Cc: Maciej Stachowiak; Marcin Hanclik; Dominique Hazael-Massieux; Robin Berjon; 
public-device-a...@w3.org; public-webapps WG
Subject: Re: DAP and security (was: Rename File API to FileReader API?)

On Wed, Nov 18, 2009 at 5:27 AM, David Rogers david.rog...@omtp.org wrote:
 Hi Maciej,

 From my side I'd like to understand what your thoughts and proposals for 
 file writing security / policy would entail - would you defer the decision 
 responsibility to the user via a prompt?

From my point of view the answer is unfortunately there are no simple
answers, it's always a judgement call.

For example for the geolocation the security model is basically:

1. Page asks for user position
2. User is faced with a non-modal dialog where he/she can answer yes
or no, or simply ignore the dialog
3. Only if the user answers yes then the position is returned to the page.

In this case I think this was an acceptable solution.

If we added a directory API which gave access to a requested path on
the users hard drive we could use a similar security model:

1. Page asks user for permission to read/write to a specific
directory, say C:\
2. User is faced with a non-modal dialog where he/she can answer yes
or no, or simply ignore the dialog
3. Only if the user answeres yes a reference to the directory is
returned which the page can read from/write to.

This would *not* be an acceptable solution to me, despite being
basically identical to the geolocation case.

The reason is two-fold. I think it's easier to explain to the user
what the user is authorizing (your location), and if a user doesn't
understand and still clicks yes, it has less catastrophic results.

For the directory API though, it's much harder to explain the decision
to the user. What's the C:\ directory? What's the difference between
that and C:\Documents and Settings\Jonas Sicking\My Images? What's a
directory? Also, if a user clicks yes without understanding the
risks, that has catastrophic results if the directory in question is
C:\ and read/write access is granted.

When it comes to security dialogs, the basic rule to keep in mind is
Lots of people are not going to understand it and just click whatever
button they think will get stuff to work, or a random button.

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

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

[Marcin Hanclik]

Hi Maciej,

I think we should separate the policy definition from its application.
We could have a single policy abstraction for browsers/OS vendors and all 
others.
At the risk of oversimplification we could summarize that such abstraction is 
just a list of applicable security concerns.
In some environments some third parties could be responsible for policy 
application (corporate, walled garden etc) within a configurable runtime/OS/etc 
and in the others the policy could be hard-coded and not modifiable (e.g. in a 
freely downloaded browser the browser vendor applies the policy once and 
forever).
Still we could have the same security concerns.

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.hanc...@access-company.com

-Original Message-
From: Maciej Stachowiak [mailto:m...@apple.com]
Sent: Thursday, November 19, 2009 2:20 AM
To: Frederick Hirsch
Cc: ext Jonas Sicking; David Rogers; Marcin Hanclik; Dominique Hazael-Massieux; 
Robin Berjon; public-device-a...@w3.org; public-webapps WG
Subject: Re: DAP and security (was: Rename File API to FileReader API?)


On Nov 18, 2009, at 5:13 PM, Frederick Hirsch wrote:

 This is a good point, and an argument for policy rather than
 implicit user consent, if I'm not mistaken. It highlights that
 usability might also be an issue with the non-modal interaction
 model,  as well as not always be very meaningful (since I the user
 might have no idea what most directories are for or where to
 navigate). Arbitrary directory navigation for writing files is not a
 good idea.

policy is not a solution to the scenario Jonas posted either. Who is
going to define a home PC or Mac user's browser policy? The user
doesn't have the expertise to do it. There's no sysadmin to do it for
them. And browser/OS vendors should not be in the game of whitelisting
a specific set of sites for extra access.

Regards,
Maciej


 More importantly we have to be careful with analogies.


 regards, Frederick

 Frederick Hirsch
 Nokia



 On Nov 18, 2009, at 3:14 PM, ext Jonas Sicking wrote:

 On Wed, Nov 18, 2009 at 5:27 AM, David Rogers
 david.rog...@omtp.org wrote:
 Hi Maciej,

 From my side I'd like to understand what your thoughts and
 proposals for file writing security / policy would entail - would
 you defer the decision responsibility to the user via a prompt?

 From my point of view the answer is unfortunately there are no
 simple
 answers, it's always a judgement call.

 For example for the geolocation the security model is basically:

 1. Page asks for user position
 2. User is faced with a non-modal dialog where he/she can answer yes
 or no, or simply ignore the dialog
 3. Only if the user answers yes then the position is returned to
 the page.

 In this case I think this was an acceptable solution.

 If we added a directory API which gave access to a requested path on
 the users hard drive we could use a similar security model:

 1. Page asks user for permission to read/write to a specific
 directory, say C:\
 2. User is faced with a non-modal dialog where he/she can answer yes
 or no, or simply ignore the dialog
 3. Only if the user answeres yes a reference to the directory is
 returned which the page can read from/write to.

 This would *not* be an acceptable solution to me, despite being
 basically identical to the geolocation case.

 The reason is two-fold. I think it's easier to explain to the user
 what the user is authorizing (your location), and if a user doesn't
 understand and still clicks yes, it has less catastrophic results.

 For the directory API though, it's much harder to explain the
 decision
 to the user. What's the C:\ directory? What's the difference
 between
 that and C:\Documents and Settings\Jonas Sicking\My Images?
 What's a
 directory? Also, if a user clicks yes without understanding the
 risks, that has catastrophic results if the directory in question is
 C:\ and read/write access is granted.

 When it comes to security dialogs, the basic rule to keep in mind is
 Lots of people are not going to understand it and just click
 whatever
 button they think will get stuff to work, or a random button.

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

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

[Marcin Hanclik]

Hi Adam,

Abstracting the problem doesn't make the security challenges
any easier.
I agree.
The implementations still need to properly code the abstractions, and 
additionally have to properly capture the application of the policy. So the 
work virtually doubles.
The only difference / advantage of having the abstraction is that the way of 
operation is configurable.
That's what the policy is in the nutshell.

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.hanc...@access-company.com

-Original Message-
From: Adam Barth [mailto:w...@adambarth.com]
Sent: Thursday, November 19, 2009 8:42 AM
To: Marcin Hanclik
Cc: Maciej Stachowiak; Dominique Hazael-Massieux; Robin Berjon; 
public-device-a...@w3.org; public-webapps WG
Subject: Re: DAP and security (was: Rename File API to FileReader API?)

On Wed, Nov 18, 2009 at 6:16 AM, Marcin Hanclik
marcin.hanc...@access-company.com wrote:
 The first step is to have the security concerns.
 The widget environment, BONDI etc. then encode them somehow (e.g. as device 
 capability, feature etc.) creating an abstraction.
 In case of the browser, those concerns seem to be simply coded in the browser.
 Still the concerns remain and are handled.
 The widgets spec try to abstract them in order to give the freedom either to 
 the end user, administrator, operator or any other party. Alternatively they 
 could be simply hard-coded in the webruntime.  So the issue is only who is 
 able to specify whether the policy is applied, the concerns are still there.

I'm skeptical that this approach will lead to a secure API for file
access.  Abstracting the problem doesn't make the security challenges
any easier.  The reason the HTML file upload control has been such a
successful secure API for reading files is because the security issues
are specifically *not* abstracted.  The entire API is designed around
the security considerations and eliciting user consent in a
easy-to-understand way.

I suspect we'll need a similarly clever API design to address the
security challenges of letting web content write to the user's file
system.

Adam



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.

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

[Dominique Hazael-Massieux]

Le jeudi 19 novembre 2009 à 22:39 +1300, Robert O'Callahan a écrit :
 The abstraction of the security concerns within a policy may
 allow delegation of the security to some third parties.
 
 There are usually no third parties to delegate to.

That’s true to a certain extent, but a reason for that might well be
that the Web platform hasn’t left enough room for third parties in that
realm.

One could very well imagine that by allowing a certain level of
abstraction in security concerns, we would allow businesses to offer
guarantees against data-loss or data-thief if the user install a
third-party extension that would check Web sites based on a number of
their security aspects.

I’m pretty sure I don’t like all the implications of such a system, and
I’m generally rather in the skeptic side when it comes to the use of a
full-blown policy framework for the Web; but I don’t think it’s fair to
conclude that it is not useful simply based on the fact that it hasn’t
been put to use yet, esp. if it’s currently difficult or impossible to
put it to use.

Dom

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

[Robert O'Callahan]

On Thu, Nov 19, 2009 at 10:52 PM, Dominique Hazael-Massieux d...@w3.orgwrote:

 Le jeudi 19 novembre 2009 à 22:39 +1300, Robert O'Callahan a écrit :
  There are usually no third parties to delegate to.

 That’s true to a certain extent, but a reason for that might well be
 that the Web platform hasn’t left enough room for third parties in that
 realm.

One could very well imagine that by allowing a certain level of
 abstraction in security concerns, we would allow businesses to offer
 guarantees against data-loss or data-thief if the user install a
 third-party extension that would check Web sites based on a number of
 their security aspects.


Businesses could offer that today, as a Firefox extension for example. There
are actually a lot of security toolbar extensions, but they tend to offer
advice rather than enforcement and they don't offer any guarantees. (
http://groups.csail.mit.edu/uid/projects/phishing/chi-security-toolbar.pdfhas
an interesting analysis (albeit slightly dated).)

Rob
-- 
He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all. [Isaiah
53:5-6]

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

[Jonas Sicking]

On Thu, Nov 19, 2009 at 1:08 AM, Marcin Hanclik
marcin.hanc...@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

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

[Marcin Hanclik]

Hi Robert,

Thanks for the report!

This model generally does not work on the Web.
What about: “This model generally have not yet worked on the Web”?
Maybe we do not know.
Let’s assume I am an advanced user and I want to create a system that allows me 
to write to arbitrary files and dirs on my PC from the web page, e.g. a walled 
garden solution.
Then I can either take Fx sources, add the APIs, compile and use it, or take 
binary Fx as is, configure the policy and use it.

Taking the analogy to the OneWeb principle [1] (I found that there is also 
OneWeb™) we specify the general security concerns, but their handling would be 
different in various environments (e.g. based on applied policies).

Forcing users to make decisions they do not want to make or cannot make is a 
failure.
I am not sure whether anyone is forcing the user.
The policy may be such that it prompts the user (forces her/him) or it may 
enable/disable the functionality.
If the user does not want to make the decision, then she/he will not 
re-configure the browser.

I think that the API (file walking) selected as the initial example is quite 
unfortunate.
We may really want to disable access to some parts of the file system, for all 
(the policy could say that “C:\Windows\*” is not writable at all).
To overcome this, we may focus on gallery API that could be a selected area 
within a file system.
Then the policy is less about enabling something critical (access to 
“C:\Windows\System”) and more about limiting access to something what we could 
think is generally available.
Let’s take another example then: Bluetooth API.
Some people may want it to be accessible always and the others would like to 
limit that (for any reason).

There are usually no third parties to delegate to.
I have an impression that mobile operators and vendors (i.e. those who want to 
write the actual policies) are eager to take the responsibility.
But I cannot speak for them.

Thanks,
Marcin

[1] http://www.w3.org/TR/mobile-bp/#OneWeb

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com
From: rocalla...@gmail.com [mailto:rocalla...@gmail.com] On Behalf Of Robert 
O'Callahan
Sent: Thursday, November 19, 2009 10:40 AM
To: Marcin Hanclik
Cc: Jonas Sicking; David Rogers; Maciej Stachowiak; Dominique Hazael-Massieux; 
Robin Berjon; public-device-a...@w3.org; public-webapps WG
Subject: Re: DAP and security (was: Rename File API to FileReader API?)

On Thu, Nov 19, 2009 at 10:08 PM, Marcin Hanclik 
marcin.hanc...@access-company.commailto:marcin.hanc...@access-company.com 
wrote:
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.

This model generally does not work on the Web. Few users understand settings or 
potential security risks and even fewer care. Lots of studies have shown this 
(e.g. see 
http://groups.csail.mit.edu/uid/projects/phishing/chi-security-toolbar.pdf). 
Forcing users to make decisions they do not want to make or cannot make is a 
failure.
The abstraction of the security concerns within a policy may allow delegation 
of the security to some third parties.

There are usually no third parties to delegate to. If you're mainly concerned 
with intranet applications, you might be able to delegate to corporate 
administrators, but you probably want to avoid that too.

Rob
--
He was pierced for our transgressions, he was crushed for our iniquities; the 
punishment that brought us peace was upon him, and by his wounds we are healed. 
We all, like sheep, have gone astray, each of us has turned to his own way; and 
the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]




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.

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

[Marcin Hanclik]

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.hanc...@access-company.com

-Original Message-
From: Jonas Sicking [mailto:jo...@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-a...@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.hanc...@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

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

[David Rogers]

Hi,

I'm going to answer these one by one, so apologies in advance for a slew
of emails coming from me. My comments will always be marked [DAVID]:

-Original Message-
From: Maciej Stachowiak [mailto:m...@apple.com] 
Sent: 19 November 2009 01:20
To: Frederick Hirsch
Cc: ext Jonas Sicking; David Rogers; Marcin Hanclik; Dominique
Hazael-Massieux; Robin Berjon; public-device-a...@w3.org; public-webapps
WG
Subject: Re: DAP and security (was: Rename File API to FileReader
API?)


On Nov 18, 2009, at 5:13 PM, Frederick Hirsch wrote:

 This is a good point, and an argument for policy rather than  
 implicit user consent, if I'm not mistaken. It highlights that  
 usability might also be an issue with the non-modal interaction  
 model,  as well as not always be very meaningful (since I the user  
 might have no idea what most directories are for or where to  
 navigate). Arbitrary directory navigation for writing files is not a  
 good idea.

policy is not a solution to the scenario Jonas posted either. Who is  
going to define a home PC or Mac user's browser policy? The user  
doesn't have the expertise to do it. There's no sysadmin to do it for  
them. And browser/OS vendors should not be in the game of whitelisting  
a specific set of sites for extra access.

[DAVID] This is the whole point - the user could choose who their policy
provider could be. The list is endless but it could be: a child
protection organisation, EFF, Which?, an anti-virus vendor/firewall
company, OS vendor, browser vendor, mobile operator - the point being
that the provider is someone the user trusts. On the subject of
whitelisting etc. have a look at http://stopbadware.org/ - potentially
these are things that could be used by policy providers (I'm sure there
are lots of other reputable sources too).

Dieter Gollman said: security-unaware users have specific security
requirements but usually no security expertise - this is why is wholly
irresponsible to defer the decision to the user in the majority of
cases. Generally, the user would much rather have someone more informed
take that decision for them. I don't think we can eliminate prompts but
we could reduce them to a level that they might actually be read and
treated as important. Right now the opposite is true.

Thanks,


David.

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

[David Rogers]

My comments:

-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc] 
Sent: 18 November 2009 20:15
To: David Rogers
Cc: Maciej Stachowiak; Marcin Hanclik; Dominique Hazael-Massieux; Robin
Berjon; public-device-a...@w3.org; public-webapps WG
Subject: Re: DAP and security (was: Rename File API to FileReader
API?)

On Wed, Nov 18, 2009 at 5:27 AM, David Rogers david.rog...@omtp.org
wrote:
 Hi Maciej,

 From my side I'd like to understand what your thoughts and proposals
for file writing security / policy would entail - would you defer the
decision responsibility to the user via a prompt?

From my point of view the answer is unfortunately there are no simple
answers, it's always a judgement call.

[DAVID] So potentially that 'judgement' can be made by a third party who
has more expertise than the user, extended to allow for context etc. -
there would be lots of metadata to help with that from the policy
provider point-of-view.

For example for the geolocation the security model is basically:

1. Page asks for user position
2. User is faced with a non-modal dialog where he/she can answer yes
or no, or simply ignore the dialog
3. Only if the user answers yes then the position is returned to the
page.

In this case I think this was an acceptable solution.

[DAVID] Obvious answer to this - user clicks yes. Not acceptable. Given
that child protection is a use case for geolocation privacy, do you
think it is responsible to give a child that question?


If we added a directory API which gave access to a requested path on
the users hard drive we could use a similar security model:

1. Page asks user for permission to read/write to a specific
directory, say C:\
2. User is faced with a non-modal dialog where he/she can answer yes
or no, or simply ignore the dialog
3. Only if the user answeres yes a reference to the directory is
returned which the page can read from/write to.

This would *not* be an acceptable solution to me, despite being
basically identical to the geolocation case.

The reason is two-fold. I think it's easier to explain to the user
what the user is authorizing (your location), and if a user doesn't
understand and still clicks yes, it has less catastrophic results.

[DAVID] There are lot of not-so tech-savvie people using the web, so
everything is on the table - you are assuming intelligence/knowledge
from the off.

For the directory API though, it's much harder to explain the decision
to the user. What's the C:\ directory? What's the difference between
that and C:\Documents and Settings\Jonas Sicking\My Images? What's a
directory? Also, if a user clicks yes without understanding the
risks, that has catastrophic results if the directory in question is
C:\ and read/write access is granted.

When it comes to security dialogs, the basic rule to keep in mind is
Lots of people are not going to understand it and just click whatever
button they think will get stuff to work, or a random button.

[DAVID] Agreed.

/ Jonas

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

[David Rogers]

My comments:

-Original Message-
From: public-device-apis-requ...@w3.org 
[mailto:public-device-apis-requ...@w3.org] On Behalf Of Adam Barth
Sent: 19 November 2009 07:42
To: Marcin Hanclik
Cc: Maciej Stachowiak; Dominique Hazael-Massieux; Robin Berjon; 
public-device-a...@w3.org; public-webapps WG
Subject: Re: DAP and security (was: Rename File API to FileReader API?)

On Wed, Nov 18, 2009 at 6:16 AM, Marcin Hanclik
marcin.hanc...@access-company.com wrote:
 The first step is to have the security concerns.
 The widget environment, BONDI etc. then encode them somehow (e.g. as device 
 capability, feature etc.) creating an abstraction.
 In case of the browser, those concerns seem to be simply coded in the browser.
 Still the concerns remain and are handled.
 The widgets spec try to abstract them in order to give the freedom either to 
 the end user, administrator, operator or any other party. Alternatively they 
 could be simply hard-coded in the webruntime.  So the issue is only who is 
 able to specify whether the policy is applied, the concerns are still there.

I'm skeptical that this approach will lead to a secure API for file
access.  Abstracting the problem doesn't make the security challenges
any easier.  The reason the HTML file upload control has been such a
successful secure API for reading files is because the security issues
are specifically *not* abstracted.  The entire API is designed around
the security considerations and eliciting user consent in a
easy-to-understand way.

I suspect we'll need a similarly clever API design to address the
security challenges of letting web content write to the user's file
system.

[DAVID] I would hope that we can come up with some clever API design in terms 
of safe logic. However, this does not solve the whole problem, at some point 
you need to make a decision / judgement call. What the policy advocates are 
proposing is to advance the whole discipline here - let's improve this by 
adding strength in depth and allow the user to defer their decision to someone 
who they trust, who is willing to take the decision for them.

Adam

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

[David Rogers]

My comments:

-Original Message-
From: Dominique Hazael-Massieux [mailto:d...@w3.org] 
Sent: 19 November 2009 09:52
To: rob...@ocallahan.org
Cc: Marcin Hanclik; Jonas Sicking; David Rogers; Maciej Stachowiak; Robin 
Berjon; public-device-a...@w3.org; public-webapps WG
Subject: Re: DAP and security (was: Rename File API to FileReader API?)

Le jeudi 19 novembre 2009 à 22:39 +1300, Robert O'Callahan a écrit :
 The abstraction of the security concerns within a policy may
 allow delegation of the security to some third parties.
 
 There are usually no third parties to delegate to.

That’s true to a certain extent, but a reason for that might well be
that the Web platform hasn’t left enough room for third parties in that
realm.

One could very well imagine that by allowing a certain level of
abstraction in security concerns, we would allow businesses to offer
guarantees against data-loss or data-thief if the user install a
third-party extension that would check Web sites based on a number of
their security aspects.

I’m pretty sure I don’t like all the implications of such a system, and
I’m generally rather in the skeptic side when it comes to the use of a
full-blown policy framework for the Web; but I don’t think it’s fair to
conclude that it is not useful simply based on the fact that it hasn’t
been put to use yet, esp. if it’s currently difficult or impossible to
put it to use.

[DAVID] I agree whole-heartedly with Dom's comments here, we need to open our 
minds to a better future here - the history of the web in security-terms is 
very nasty. Why not make it better? As I said in a previous email, we would 
like to give the user the choice about who they trust to make decisions for 
them. The vast majority of users on the web have no clue about security or any 
of the technical terms (I will hopefully add another usability study as a 
submission in the coming months which OMTP carried out). Why sandbox yourself 
to the browser? The very rationale of opening up physical 'things' to the web 
means you have to do something.


Dom

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

[David Rogers]

My comments:

 

From: rocalla...@gmail.com [mailto:rocalla...@gmail.com] On Behalf Of Robert 
O'Callahan
Sent: 19 November 2009 10:10
To: Dominique Hazael-Massieux
Cc: Marcin Hanclik; Jonas Sicking; David Rogers; Maciej Stachowiak; Robin 
Berjon; public-device-a...@w3.org; public-webapps WG
Subject: Re: DAP and security (was: Rename File API to FileReader API?)

 

On Thu, Nov 19, 2009 at 10:52 PM, Dominique Hazael-Massieux d...@w3.org wrote:

Le jeudi 19 novembre 2009 à 22:39 +1300, Robert O'Callahan a écrit :

 There are usually no third parties to delegate to.

That’s true to a certain extent, but a reason for that might well be
that the Web platform hasn’t left enough room for third parties in that
realm.

One could very well imagine that by allowing a certain level of
abstraction in security concerns, we would allow businesses to offer
guarantees against data-loss or data-thief if the user install a
third-party extension that would check Web sites based on a number of
their security aspects.


Businesses could offer that today, as a Firefox extension for example. There 
are actually a lot of security toolbar extensions, but they tend to offer 
advice rather than enforcement and they don't offer any guarantees. 
(http://groups.csail.mit.edu/uid/projects/phishing/chi-security-toolbar.pdf has 
an interesting analysis (albeit slightly dated).)


 

[DAVID] This is in effect an insurance policy, I’m sure there will be 
organisations willing to step-up.

 


Rob
-- 
He was pierced for our transgressions, he was crushed for our iniquities; the 
punishment that brought us peace was upon him, and by his wounds we are healed. 
We all, like sheep, have gone astray, each of us has turned to his own way; and 
the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]

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

[Robert O'Callahan]

On Thu, Nov 19, 2009 at 11:54 PM, David Rogers david.rog...@omtp.orgwrote:

 *From:* rocalla...@gmail.com [mailto:rocalla...@gmail.com] *On Behalf Of 
 *Robert
 O'Callahan



 On Thu, Nov 19, 2009 at 10:52 PM, Dominique Hazael-Massieux d...@w3.org
 wrote:

 Le jeudi 19 novembre 2009 à 22:39 +1300, Robert O'Callahan a écrit :

  There are usually no third parties to delegate to.

 That’s true to a certain extent, but a reason for that might well be
 that the Web platform hasn’t left enough room for third parties in that
 realm.

  One could very well imagine that by allowing a certain level of
 abstraction in security concerns, we would allow businesses to offer
 guarantees against data-loss or data-thief if the user install a
 third-party extension that would check Web sites based on a number of
 their security aspects.


 Businesses could offer that today, as a Firefox extension for example.
 There are actually a lot of security toolbar extensions, but they tend to
 offer advice rather than enforcement and they don't offer any guarantees. (
 http://groups.csail.mit.edu/uid/projects/phishing/chi-security-toolbar.pdfhas 
 an interesting analysis (albeit slightly dated).)



 [DAVID] This is in effect an insurance policy, I’m sure there will be
 organisations willing to step-up.


But they haven't.

Rob
-- 
He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all. [Isaiah
53:5-6]

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

[David Rogers]

My comments:

-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc] 
Sent: 19 November 2009 10:11
To: Marcin Hanclik
Cc: David Rogers; Maciej Stachowiak; Dominique Hazael-Massieux; Robin
Berjon; public-device-a...@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.hanc...@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

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

[David Rogers]

 

 

From: rocalla...@gmail.com [mailto:rocalla...@gmail.com] On Behalf Of Robert 
O'Callahan
Sent: 19 November 2009 10:58
To: David Rogers
Cc: Dominique Hazael-Massieux; Marcin Hanclik; Jonas Sicking; Maciej 
Stachowiak; Robin Berjon; public-device-a...@w3.org; public-webapps WG
Subject: Re: DAP and security (was: Rename File API to FileReader API?)

 

On Thu, Nov 19, 2009 at 11:54 PM, David Rogers david.rog...@omtp.org wrote:

From: rocalla...@gmail.com [mailto:rocalla...@gmail.com] On Behalf Of 
Robert O'Callahan

 

On Thu, Nov 19, 2009 at 10:52 PM, Dominique Hazael-Massieux 
d...@w3.org wrote:

Le jeudi 19 novembre 2009 à 22:39 +1300, Robert O'Callahan a 
écrit :

 There are usually no third parties to delegate to.

That’s true to a certain extent, but a reason for that might 
well be
that the Web platform hasn’t left enough room for third parties 
in that
realm.

One could very well imagine that by allowing a certain level of
abstraction in security concerns, we would allow businesses to 
offer
guarantees against data-loss or data-thief if the user install a
third-party extension that would check Web sites based on a 
number of
their security aspects.


Businesses could offer that today, as a Firefox extension for example. 
There are actually a lot of security toolbar extensions, but they tend to 
offer advice rather than enforcement and they don't offer any guarantees. 
(http://groups.csail.mit.edu/uid/projects/phishing/chi-security-toolbar.pdf has 
an interesting analysis (albeit slightly dated).)


 

[DAVID] This is in effect an insurance policy, I’m sure there will be 
organisations willing to step-up.

 

But they haven't.



[DAVID] But they will ;-) – we have to actually create a framework for that to 
happen first! As someone mentioned before, in the mobile world this already 
happens.

 


Rob
-- 
He was pierced for our transgressions, he was crushed for our iniquities; the 
punishment that brought us peace was upon him, and by his wounds we are healed. 
We all, like sheep, have gone astray, each of us has turned to his own way; and 
the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]

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

[Adam Barth]

On Thu, Nov 19, 2009 at 2:49 AM, David Rogers david.rog...@omtp.org wrote:
 -Original Message-
 From: public-device-apis-requ...@w3.org 
 [mailto:public-device-apis-requ...@w3.org] On Behalf Of Adam Barth
 Sent: 19 November 2009 07:42
 To: Marcin Hanclik
 Cc: Maciej Stachowiak; Dominique Hazael-Massieux; Robin Berjon; 
 public-device-a...@w3.org; public-webapps WG
 Subject: Re: DAP and security (was: Rename File API to FileReader API?)

 I'm skeptical that this approach will lead to a secure API for file
 access.  Abstracting the problem doesn't make the security challenges
 any easier.  The reason the HTML file upload control has been such a
 successful secure API for reading files is because the security issues
 are specifically *not* abstracted.  The entire API is designed around
 the security considerations and eliciting user consent in a
 easy-to-understand way.

 I suspect we'll need a similarly clever API design to address the
 security challenges of letting web content write to the user's file
 system.

 [DAVID] I would hope that we can come up with some clever API design in terms 
 of safe logic. However, this does not solve the whole problem, at some point 
 you need to make a decision / judgement call.

Really?  What decision / judgement call do we need to make for the
file upload control?  What decision / judgement call do we need to
make for the video tag?

 What the policy advocates are proposing is to advance the whole discipline 
 here - let's improve this by adding strength in depth and allow the user to 
 defer their decision to someone who they trust, who is willing to take the 
 decision for them.

You're not listening to the folks on this thread who are telling you
that this model has been tried and failed.  At best this is a science
experiment.  Writing web standards is a terrible way to run a science
project.

Adam

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

[Adam Barth]

David, you're not listening.

On Thu, Nov 19, 2009 at 3:02 AM, David Rogers david.rog...@omtp.org wrote:
 -Original Message-
 From: Jonas Sicking [mailto:jo...@sicking.cc]
 Sent: 19 November 2009 10:11
 To: Marcin Hanclik
 Cc: David Rogers; Maciej Stachowiak; Dominique Hazael-Massieux; Robin
 Berjon; public-device-a...@w3.org; public-webapps WG
 Subject: Re: DAP and security (was: Rename File API to FileReader
 API?)

 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?

Jonas just said that they had a policy mechanism and that's what
*caused* the problem in the first place.  He solved the problem by
removing the policy lever in Thunderbird that let users shoot
themselves in the foot.

Adam

Re: DAP and security (was: Rename “File API” to “FileReader API”?)

[Marcos Caceres]

2009/11/12 Dominique Hazael-Massieux d...@w3.org:
 Le mardi 10 novembre 2009 à 17:47 -0800, Maciej Stachowiak a écrit :
 I would be concerned with leaving file writing to DAP, because a
 widely held view in DAP seems to be that security can be ignored while
 designing APIs and added back later with an external policy file
 mechanism.

I don't know where you got the idea that it's a widely held view -
That is plainly ridiculous and verging on the insulting. I'm pretty
certain no one holds that view in DAP.

-- 
Marcos Caceres
http://datadriven.com.au

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

[Marcin Hanclik]

+1
APIs - specifically their design - shall be specified tightly with the security 
model in mind to make them both easy to use and effective.
This is what makes the whole task that difficult.

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.hanc...@access-company.com

-Original Message-
From: public-device-apis-requ...@w3.org 
[mailto:public-device-apis-requ...@w3.org] On Behalf Of Dominique 
Hazael-Massieux
Sent: Thursday, November 12, 2009 10:30 AM
To: Maciej Stachowiak
Cc: Robin Berjon; public-device-a...@w3.org; public-webapps WG
Subject: DAP and security (was: Rename “File API” to “FileReader API”?)

Le mardi 10 novembre 2009 à 17:47 -0800, Maciej Stachowiak a écrit :
 I would be concerned with leaving file writing to DAP, because a
 widely held view in DAP seems to be that security can be ignored while
 designing APIs and added back later with an external policy file
 mechanism.

Frederick already mentioned this isn’t the case at all, and I want to
strongly reject the notion that DAP is considering security as an
after-the-fact or out-of-band aspect in the design of its APIs.

Our charter clearly stipulates that our policy model “must be consistent
with the existing same origin policies (as documented in the HTML5
specification), in the sense that a deployment of the policy model in
Web browsers must be possible”.

In fact, most of models that have been discussed in this thread to
reduce the risks exposed by new APIs (sandbox for writing, user
interaction or markup-based element for sharing data) were already
mentioned as options by DAP WG participants during our F2F last week.

More generally, I don’t think assuming that DAP would create worse/less
secure APIs than WebApps or any other group would is either right nor
useful to ensure a good collaboration between our groups. And clearly,
we will actively be seeking feedback and input from the WebApps Working
Group when we produce new APIs, which should also contribute to reduce
the fears that we would get it all wrong :)

Regards,

Dom






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.

Re: DAP and security (was: Rename “File API” to “FileReader API”?)

[Maciej Stachowiak]

OK, I will take your word for it that security is an important  
consideration for DAP. But while at the TPAC, I heard more than one  
DAP participant say, when faced with a potential security concern,  
something like can't we just leave that up to the policy? In one  
case when I enquired further, at least one DAP member mentioned to me  
the idea of using some sort of policy file that would take care of  
all security issues. He suggested this might come from a corporate  
administrator, and that the format would be XML, but otherwise details  
were light.


To me that seems like a plausible model for something like widgets or  
browser extensions or walled garden content, but not for sites on the  
public Web.


My apologies if I misinterpreted these remarks or got the wrong  
impression.


One more comment below:

On Nov 18, 2009, at 4:18 AM, Marcin Hanclik wrote:


+1
APIs - specifically their design - shall be specified tightly with  
the security model in mind to make them both easy to use and  
effective.

This is what makes the whole task that difficult.

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.hanc...@access-company.com

-Original Message-
From: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org 
] On Behalf Of Dominique Hazael-Massieux

Sent: Thursday, November 12, 2009 10:30 AM
To: Maciej Stachowiak
Cc: Robin Berjon; public-device-a...@w3.org; public-webapps WG
Subject: DAP and security (was: Rename “File API” to “FileReader  
API”?)


Le mardi 10 novembre 2009 à 17:47 -0800, Maciej Stachowiak a écrit :

I would be concerned with leaving file writing to DAP, because a
widely held view in DAP seems to be that security can be ignored  
while

designing APIs and added back later with an external policy file
mechanism.


Frederick already mentioned this isn’t the case at all, and I want to
strongly reject the notion that DAP is considering security as an
after-the-fact or out-of-band aspect in the design of its APIs.

Our charter clearly stipulates that our policy model “must be  
consistent

with the existing same origin policies (as documented in the HTML5
specification), in the sense that a deployment of the policy model in
Web browsers must be possible”.


It seems to me that for most of DAP's likely deliverables, there are  
serious security considerations, but the same-origin policy is  
irrelevant to addressing them. The same-origin policy is designed to  
protect Web sites from attacks by other Web sites. It does not really  
apply to access to system resources. Doing that in a Web-safe way will  
require new inventions or might not even be possible in some cases.




In fact, most of models that have been discussed in this thread to
reduce the risks exposed by new APIs (sandbox for writing, user
interaction or markup-based element for sharing data) were already
mentioned as options by DAP WG participants during our F2F last week.

More generally, I don’t think assuming that DAP would create worse/ 
less

secure APIs than WebApps or any other group would is either right nor
useful to ensure a good collaboration between our groups. And clearly,
we will actively be seeking feedback and input from the WebApps  
Working

Group when we produce new APIs, which should also contribute to reduce
the fears that we would get it all wrong :)

Regards,

Dom






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.

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

[David Rogers]

Hi Maciej,

From my side I'd like to understand what your thoughts and proposals for file 
writing security / policy would entail - would you defer the decision 
responsibility to the user via a prompt?

Thanks,


David.


-Original Message-
From: public-device-apis-requ...@w3.org 
[mailto:public-device-apis-requ...@w3.org] On Behalf Of Maciej Stachowiak
Sent: 18 November 2009 12:35
To: Marcin Hanclik
Cc: Dominique Hazael-Massieux; Robin Berjon; public-device-a...@w3.org; 
public-webapps WG
Subject: Re: DAP and security (was: Rename File API to FileReader API?)


OK, I will take your word for it that security is an important  
consideration for DAP. But while at the TPAC, I heard more than one  
DAP participant say, when faced with a potential security concern,  
something like can't we just leave that up to the policy? In one  
case when I enquired further, at least one DAP member mentioned to me  
the idea of using some sort of policy file that would take care of  
all security issues. He suggested this might come from a corporate  
administrator, and that the format would be XML, but otherwise details  
were light.

To me that seems like a plausible model for something like widgets or  
browser extensions or walled garden content, but not for sites on the  
public Web.

My apologies if I misinterpreted these remarks or got the wrong  
impression.

One more comment below:

On Nov 18, 2009, at 4:18 AM, Marcin Hanclik wrote:

 +1
 APIs - specifically their design - shall be specified tightly with  
 the security model in mind to make them both easy to use and  
 effective.
 This is what makes the whole task that difficult.

 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.hanc...@access-company.com

 -Original Message-
 From: public-device-apis-requ...@w3.org 
 [mailto:public-device-apis-requ...@w3.org 
 ] On Behalf Of Dominique Hazael-Massieux
 Sent: Thursday, November 12, 2009 10:30 AM
 To: Maciej Stachowiak
 Cc: Robin Berjon; public-device-a...@w3.org; public-webapps WG
 Subject: DAP and security (was: Rename File API to FileReader  
 API?)

 Le mardi 10 novembre 2009 à 17:47 -0800, Maciej Stachowiak a écrit :
 I would be concerned with leaving file writing to DAP, because a
 widely held view in DAP seems to be that security can be ignored  
 while
 designing APIs and added back later with an external policy file
 mechanism.

 Frederick already mentioned this isn't the case at all, and I want to
 strongly reject the notion that DAP is considering security as an
 after-the-fact or out-of-band aspect in the design of its APIs.

 Our charter clearly stipulates that our policy model must be  
 consistent
 with the existing same origin policies (as documented in the HTML5
 specification), in the sense that a deployment of the policy model in
 Web browsers must be possible.

It seems to me that for most of DAP's likely deliverables, there are  
serious security considerations, but the same-origin policy is  
irrelevant to addressing them. The same-origin policy is designed to  
protect Web sites from attacks by other Web sites. It does not really  
apply to access to system resources. Doing that in a Web-safe way will  
require new inventions or might not even be possible in some cases.


 In fact, most of models that have been discussed in this thread to
 reduce the risks exposed by new APIs (sandbox for writing, user
 interaction or markup-based element for sharing data) were already
 mentioned as options by DAP WG participants during our F2F last week.

 More generally, I don't think assuming that DAP would create worse/ 
 less
 secure APIs than WebApps or any other group would is either right nor
 useful to ensure a good collaboration between our groups. And clearly,
 we will actively be seeking feedback and input from the WebApps  
 Working
 Group when we produce new APIs, which should also contribute to reduce
 the fears that we would get it all wrong :)

 Regards,

 Dom




 

 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.

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

[Marcin Hanclik]

Hi Maciej,

I think that there are many potential oversimplifications when stating that 
security concerns are to be left to the policy and that a policy file could be 
a cure to everything. These seem to be just superficial comments from the 
people who already did related exercise in some implementation. E.g. BONDI spec 
- input to DAP already in version 1.1 - touches upon the whole problem.

OK, I will take your word for it that security is an important
consideration for DAP.
It is for me after BONDI experience. I cannot speak for the others.

The first step is to have the security concerns.
The widget environment, BONDI etc. then encode them somehow (e.g. as device 
capability, feature etc.) creating an abstraction.
In case of the browser, those concerns seem to be simply coded in the browser.
Still the concerns remain and are handled.
The widgets spec try to abstract them in order to give the freedom either to 
the end user, administrator, operator or any other party. Alternatively they 
could be simply hard-coded in the webruntime.  So the issue is only who is able 
to specify whether the policy is applied, the concerns are still there.

During the TPAC I commented on irc that the policy file is just a 
representation of the policy, specifically for interchange purposes. It is up 
to the spec designers whether the concerns are properly reflected in the policy 
and later in the format/syntax of the policy file.
In BONDI we agreed on the format, there is no need for all to comply with that 
format.
No problem with that, but the security concerns are still there and are handled.

It seems to me that for most of DAP's likely deliverables, there are
serious security considerations, but the same-origin policy is
irrelevant to addressing them. The same-origin policy is designed to
protect Web sites from attacks by other Web sites. It does not really
apply to access to system resources. Doing that in a Web-safe way will
require new inventions or might not even be possible in some cases.
The origin is a topic in WebApps in the Widgets 1.0 spec,  e.g. TWI [1].
We have the issue of the widget instance (e.g. do we allow the same widget be 
instantiated multiple times, how to synchronize between instances etc.).
BONDI specs distinguish additionally between websites and widgets.
The same-origin policy is still there. We would potentially like a widget not 
to be able to act in place of another widget (identity spoofing, for this we 
need widget URI [2] with authority component).
So similarly to same-website/script, we have same-widget policy. Origins are 
websites and widgets.

It may be up to the policy (set by whoever) whether e.g. two widgets or two 
websites are able to write to the same folder in the FS.
In this case, the security concern is: who can write to FS, where actually can 
it write etc.
The realization of these concerns is abstracted in BONDI as:
- io.file.read / io.file.write: device capability (abstraction to accommodate 
various APIs doing file writing / reading)
- http://bondi.omtp.org/api/filesystem.read / 
http://bondi.omtp.org/api/filesystem.write: API feature (api availability, 
specific for BONDI-defined APIs)
- path: parameter to device capability that states the actual path being 
accessed.
Each API has different security concerns, thus there are e.g. different 
parameters in BONDI.

In case of the browser environment, I was personally thinking about something 
like personal firewall (a tab in the browser settings? ) where the end-user 
defines the actual policy defaulted by the browser vendor. In walled-garden 
environments such firewall would be disabled and e.g. the operator would define 
the policy. The prompts would then depend on the policy and not only on the API 
being used.
There could also be browsers that do not expose the policy settings to the end 
users. In BONDI there is freedom about that, but still the security concerns 
are there and are handled.

Thanks,
Marcin

[1] http://dev.w3.org/2006/waf/widgets-api/
[2] http://dev.w3.org/2006/waf/widgets-uri/

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

-Original Message-
From: Maciej Stachowiak [mailto:m...@apple.com]
Sent: Wednesday, November 18, 2009 1:35 PM
To: Marcin Hanclik
Cc: Dominique Hazael-Massieux; Robin Berjon; public-device-a...@w3.org; 
public-webapps WG
Subject: Re: DAP and security (was: Rename File API to FileReader API?)


OK, I will take your word for it that security is an important
consideration for DAP. But while at the TPAC, I heard more than one
DAP participant say, when faced with a potential security concern,
something like can't we just leave that up to the policy? In one
case when I enquired further, at least one DAP member mentioned to me
the idea of using some sort of policy file that would take care of
all security issues. He suggested this might come from a corporate

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

[SULLIVAN, BRYAN L (ATTCINW)]

Maciej, 

Security is important in DAP, and should be considered carefully in the context 
of each API and its use cases. There is no one size fits all solution to 
security, and that includes approaches based solely upon explicit user action 
(including explicitly expressed permission via dialogs). 

The ability to define trust and related policy in a manageable policy document 
is a necessary *supplement* to the native (API-specific) security methods 
inherent in API's and their support/influence on the UI. The supplement ensures 
that the security approach can be tailored to the device in which the webapp is 
running, supporting a better user experience where reliance upon implicit user 
action is insufficient.

It is however just a supplement that may applied in specific cases, and its use 
is a deployment decision. BONDI defined such a policy file based upon XACML 
concepts (this has been provided as input to DAP), and ATT (among others 
supporting BONDI) considers this to be a valuable option, which complements the 
API-specific methods.

Best regards,
Bryan Sullivan | ATT
-Original Message-
From: public-device-apis-requ...@w3.org 
[mailto:public-device-apis-requ...@w3.org] On Behalf Of Maciej Stachowiak
Sent: Wednesday, November 18, 2009 4:35 AM
To: Marcin Hanclik
Cc: Dominique Hazael-Massieux; Robin Berjon; public-device-a...@w3.org; 
public-webapps WG
Subject: Re: DAP and security (was: Rename File API to FileReader API?)


OK, I will take your word for it that security is an important  
consideration for DAP. But while at the TPAC, I heard more than one  
DAP participant say, when faced with a potential security concern,  
something like can't we just leave that up to the policy? In one  
case when I enquired further, at least one DAP member mentioned to me  
the idea of using some sort of policy file that would take care of  
all security issues. He suggested this might come from a corporate  
administrator, and that the format would be XML, but otherwise details  
were light.

To me that seems like a plausible model for something like widgets or  
browser extensions or walled garden content, but not for sites on the  
public Web.

My apologies if I misinterpreted these remarks or got the wrong  
impression.

One more comment below:

On Nov 18, 2009, at 4:18 AM, Marcin Hanclik wrote:

 +1
 APIs - specifically their design - shall be specified tightly with  
 the security model in mind to make them both easy to use and  
 effective.
 This is what makes the whole task that difficult.

 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.hanc...@access-company.com

 -Original Message-
 From: public-device-apis-requ...@w3.org 
 [mailto:public-device-apis-requ...@w3.org 
 ] On Behalf Of Dominique Hazael-Massieux
 Sent: Thursday, November 12, 2009 10:30 AM
 To: Maciej Stachowiak
 Cc: Robin Berjon; public-device-a...@w3.org; public-webapps WG
 Subject: DAP and security (was: Rename File API to FileReader  
 API?)

 Le mardi 10 novembre 2009 à 17:47 -0800, Maciej Stachowiak a écrit :
 I would be concerned with leaving file writing to DAP, because a
 widely held view in DAP seems to be that security can be ignored  
 while
 designing APIs and added back later with an external policy file
 mechanism.

 Frederick already mentioned this isn't the case at all, and I want to
 strongly reject the notion that DAP is considering security as an
 after-the-fact or out-of-band aspect in the design of its APIs.

 Our charter clearly stipulates that our policy model must be  
 consistent
 with the existing same origin policies (as documented in the HTML5
 specification), in the sense that a deployment of the policy model in
 Web browsers must be possible.

It seems to me that for most of DAP's likely deliverables, there are  
serious security considerations, but the same-origin policy is  
irrelevant to addressing them. The same-origin policy is designed to  
protect Web sites from attacks by other Web sites. It does not really  
apply to access to system resources. Doing that in a Web-safe way will  
require new inventions or might not even be possible in some cases.


 In fact, most of models that have been discussed in this thread to
 reduce the risks exposed by new APIs (sandbox for writing, user
 interaction or markup-based element for sharing data) were already
 mentioned as options by DAP WG participants during our F2F last week.

 More generally, I don't think assuming that DAP would create worse/ 
 less
 secure APIs than WebApps or any other group would is either right nor
 useful to ensure a good collaboration between our groups. And clearly,
 we will actively be seeking feedback and input from the WebApps  
 Working
 Group when we produce new APIs, which should also contribute to reduce
 the fears that we would get it all wrong :)

 Regards,

 Dom

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

[Jonas Sicking]

On Wed, Nov 18, 2009 at 5:27 AM, David Rogers david.rog...@omtp.org wrote:
 Hi Maciej,

 From my side I'd like to understand what your thoughts and proposals for 
 file writing security / policy would entail - would you defer the decision 
 responsibility to the user via a prompt?

From my point of view the answer is unfortunately there are no simple
answers, it's always a judgement call.

For example for the geolocation the security model is basically:

1. Page asks for user position
2. User is faced with a non-modal dialog where he/she can answer yes
or no, or simply ignore the dialog
3. Only if the user answers yes then the position is returned to the page.

In this case I think this was an acceptable solution.

If we added a directory API which gave access to a requested path on
the users hard drive we could use a similar security model:

1. Page asks user for permission to read/write to a specific
directory, say C:\
2. User is faced with a non-modal dialog where he/she can answer yes
or no, or simply ignore the dialog
3. Only if the user answeres yes a reference to the directory is
returned which the page can read from/write to.

This would *not* be an acceptable solution to me, despite being
basically identical to the geolocation case.

The reason is two-fold. I think it's easier to explain to the user
what the user is authorizing (your location), and if a user doesn't
understand and still clicks yes, it has less catastrophic results.

For the directory API though, it's much harder to explain the decision
to the user. What's the C:\ directory? What's the difference between
that and C:\Documents and Settings\Jonas Sicking\My Images? What's a
directory? Also, if a user clicks yes without understanding the
risks, that has catastrophic results if the directory in question is
C:\ and read/write access is granted.

When it comes to security dialogs, the basic rule to keep in mind is
Lots of people are not going to understand it and just click whatever
button they think will get stuff to work, or a random button.

/ Jonas

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

[Frederick Hirsch]

This is a good point, and an argument for policy rather than  
implicit user consent, if I'm not mistaken. It highlights that  
usability might also be an issue with the non-modal interaction  
model,  as well as not always be very meaningful (since I the user  
might have no idea what most directories are for or where to  
navigate). Arbitrary directory navigation for writing files is not a  
good idea.


More importantly we have to be careful with analogies.


regards, Frederick

Frederick Hirsch
Nokia



On Nov 18, 2009, at 3:14 PM, ext Jonas Sicking wrote:

On Wed, Nov 18, 2009 at 5:27 AM, David Rogers  
david.rog...@omtp.org wrote:

Hi Maciej,

From my side I'd like to understand what your thoughts and  
proposals for file writing security / policy would entail - would  
you defer the decision responsibility to the user via a prompt?


From my point of view the answer is unfortunately there are no  
simple

answers, it's always a judgement call.

For example for the geolocation the security model is basically:

1. Page asks for user position
2. User is faced with a non-modal dialog where he/she can answer yes
or no, or simply ignore the dialog
3. Only if the user answers yes then the position is returned to  
the page.


In this case I think this was an acceptable solution.

If we added a directory API which gave access to a requested path on
the users hard drive we could use a similar security model:

1. Page asks user for permission to read/write to a specific
directory, say C:\
2. User is faced with a non-modal dialog where he/she can answer yes
or no, or simply ignore the dialog
3. Only if the user answeres yes a reference to the directory is
returned which the page can read from/write to.

This would *not* be an acceptable solution to me, despite being
basically identical to the geolocation case.

The reason is two-fold. I think it's easier to explain to the user
what the user is authorizing (your location), and if a user doesn't
understand and still clicks yes, it has less catastrophic results.

For the directory API though, it's much harder to explain the decision
to the user. What's the C:\ directory? What's the difference between
that and C:\Documents and Settings\Jonas Sicking\My Images? What's a
directory? Also, if a user clicks yes without understanding the
risks, that has catastrophic results if the directory in question is
C:\ and read/write access is granted.

When it comes to security dialogs, the basic rule to keep in mind is
Lots of people are not going to understand it and just click whatever
button they think will get stuff to work, or a random button.

/ Jonas

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

[Maciej Stachowiak]

On Nov 18, 2009, at 5:13 PM, Frederick Hirsch wrote:

This is a good point, and an argument for policy rather than  
implicit user consent, if I'm not mistaken. It highlights that  
usability might also be an issue with the non-modal interaction  
model,  as well as not always be very meaningful (since I the user  
might have no idea what most directories are for or where to  
navigate). Arbitrary directory navigation for writing files is not a  
good idea.


policy is not a solution to the scenario Jonas posted either. Who is  
going to define a home PC or Mac user's browser policy? The user  
doesn't have the expertise to do it. There's no sysadmin to do it for  
them. And browser/OS vendors should not be in the game of whitelisting  
a specific set of sites for extra access.


Regards,
Maciej



More importantly we have to be careful with analogies.


regards, Frederick

Frederick Hirsch
Nokia



On Nov 18, 2009, at 3:14 PM, ext Jonas Sicking wrote:

On Wed, Nov 18, 2009 at 5:27 AM, David Rogers  
david.rog...@omtp.org wrote:

Hi Maciej,

From my side I'd like to understand what your thoughts and  
proposals for file writing security / policy would entail - would  
you defer the decision responsibility to the user via a prompt?


From my point of view the answer is unfortunately there are no  
simple

answers, it's always a judgement call.

For example for the geolocation the security model is basically:

1. Page asks for user position
2. User is faced with a non-modal dialog where he/she can answer yes
or no, or simply ignore the dialog
3. Only if the user answers yes then the position is returned to  
the page.


In this case I think this was an acceptable solution.

If we added a directory API which gave access to a requested path on
the users hard drive we could use a similar security model:

1. Page asks user for permission to read/write to a specific
directory, say C:\
2. User is faced with a non-modal dialog where he/she can answer yes
or no, or simply ignore the dialog
3. Only if the user answeres yes a reference to the directory is
returned which the page can read from/write to.

This would *not* be an acceptable solution to me, despite being
basically identical to the geolocation case.

The reason is two-fold. I think it's easier to explain to the user
what the user is authorizing (your location), and if a user doesn't
understand and still clicks yes, it has less catastrophic results.

For the directory API though, it's much harder to explain the  
decision
to the user. What's the C:\ directory? What's the difference  
between
that and C:\Documents and Settings\Jonas Sicking\My Images?  
What's a

directory? Also, if a user clicks yes without understanding the
risks, that has catastrophic results if the directory in question is
C:\ and read/write access is granted.

When it comes to security dialogs, the basic rule to keep in mind is
Lots of people are not going to understand it and just click  
whatever

button they think will get stuff to work, or a random button.

/ Jonas