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

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

-----Original Message-----
From: Maciej Stachowiak [mailto:mjs@apple.com]
Sent: Wednesday, November 18, 2009 1:35 PM
To: Marcin Hanclik
Cc: 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"?)


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.hanclik@access-company.com
>
> -----Original Message-----
> From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org
> ] On Behalf Of Dominique Hazael-Massieux
> Sent: Thursday, November 12, 2009 10:30 AM
> To: Maciej Stachowiak
> Cc: Robin Berjon; public-device-apis@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.


________________________________________

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 Wednesday, 18 November 2009 14:17:50 UTC