Re: Security evaluation of an example DAP policy

My understanding from reading the thread is that the concern is with  
complexity, increased attack surface due to mechanisms that can be  
used in unanticipated ways or misconfigured, and management issues.

Thus though policy can state a simple approach, I'm not sure the above  
concerns are addressed by that expression.

I think we need to work through the use cases, both for those that do  
need a policy language and those that do not, then consider if APIs  
have various methods as Robin suggested, or otherwise how it will all  
fit together.

regards, Frederick (not as chair)

Frederick Hirsch
Nokia



On Nov 19, 2009, at 7:49 PM, ext Marcin Hanclik wrote:

> Hi Jonas, Maciej,
>
> It seems that the policy that you would accept would be:
>
> <policy-set combine="deny-overrides">
> <policy description="Default Policy for websites. Simply denying all  
> API that are covered by some device capability:) ">
>   <target>
>     <subject>
>       <subject-match attr="class" match="website" func="equal"/>
>     </subject>
>   </target>
>   <rule effect="deny">
>     <condition>
>       <resource-match attr="device-cap" func="regexp">/.+/</resource- 
> match>
>     </condition>
>   </rule>
> </policy>
> </policy-set>
>
> Let's see how DAP will evolve then.
>
> Thanks,
> Marcin
> ________________________________________
> From: Maciej Stachowiak [mjs@apple.com]
> Sent: Friday, November 20, 2009 1:26 AM
> To: Jonas Sicking
> Cc: Marcin Hanclik; Adam Barth; Robin Berjon; public-device-apis@w3.org 
> ; public-webapps WG
> Subject: Re: Security evaluation of an example DAP policy
>
> On Nov 19, 2009, at 4:23 PM, Jonas Sicking wrote:
>
>> On Thu, Nov 19, 2009 at 4:07 PM, Marcin Hanclik
>> <Marcin.Hanclik@access-company.com> wrote:
>>> Hi Adam,
>>>
>>> I think that
>>> <resource-match attr="param:name" func="regexp">/(C|c):\\(.+)\\(.+)/
>>> <resource-match />
>>> should be
>>> <resource-match attr="param:name" func="regexp">/(C|c):\\([^\\]+)\\.
>>> +/<resource-match />
>>> up to any further bug in the RE.
>>> Sorry, my problem.
>>>
>>> Anyway, the general comment is that the use case is under control
>>> based on the current spec.
>>
>> For what it's worth, I think any API that opened a dialog asking the
>> user "Do you want to give website X access to directory Y in your  
>> file
>> system" would not be an API we'd be willing to implement in firefox.
>> I.e. our security policy would be to always deny such a request (thus
>> making implementing the API useless for our users).
>
> Ditto for Safari.
>
>  - Maciej
>
>
> ________________________________________
>
> 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 Friday, 20 November 2009 13:54:26 UTC