Re: Security evaluation of an example DAP policy

I'm not saying that there is no need for policies (you listed two great
examples of where they can be useful).  They seem useful for overriding
default secure behavior that we require for the web.  All that I (and I
believe others) am saying is that security cannot completely be decoupled
from the implementation and differed to policies.  Especially in APIs that
we want to expose to the web.  I'd even go as far as to say that differing
to policies or asking the user for permission should be a last resort.

On Fri, Nov 20, 2009 at 2:29 PM, Frederick Hirsch <
Frederick.Hirsch@nokia.com> wrote:

> Jeremy
>
> Thanks. I want to make sure I understand the concerns.
>
> I guess the question is whether one can bake all the security in that is
> needed for various (possibly conflicting) use cases, including those that do
> not presume user interaction. An argument for  policy is to decouple the
> mechanism from the decision criteria to get that flexibility, while making
> sure the mechanism is secure.  On the other side I hear the concern that the
> mechanism cannot be as secure.
>
> I note that the policy requirements document includes some use cases Paddy
> contributed in an earlier email:
>
> http://dev.w3.org/2009/dap/policy-reqs/#use-cases
>
> So for example, how does one "bake in" these:
>
> The weather.example.com Widget can connect to weather.example.com without
> notifying the user, except when roaming.
>
> Reliably identified Websites can send and receive SMS except to premium
> rate numbers.
>
> Do we need to go into more detail on these two (as examples)?
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
>
> On Nov 20, 2009, at 9:15 AM, ext Jeremy Orlow wrote:
>
>  These are reasons, but I think the greatest cause of our concern is that
>> we have not seen any examples of how policies can provide the same level of
>> security that baking security into the API from the beginning can provide.
>>
>> All too often the policy based approaches fall back on either asking the
>> user or simply denying access--both of which are not viable solutions in
>> most cases within the browser.  If we take security into account when
>> designing the APIs we can often find creative approaches that satisfy all of
>> the requirements/use-cases while providing an API that can be on by default.
>>
>> On Fri, Nov 20, 2009 at 1:53 PM, Frederick Hirsch <
>> frederick.hirsch@nokia.com> wrote:
>> 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.
>>
>>
>>
>>
>>
>