RE: Security evaluation of an example DAP policy

Hi Jonas,

Thanks for your comments.

The below policy actually blocks access to all device APIs for all websites (up to bugs in the RE, now I think it should be /.*/ instead of /.+/), thus actually expresses the currently applied policy available in the browsers. I.e. it already works to some extent :)

I assume the clear arguments raised in this mail thread will be very helpful for DAP and BONDI.

Handling data exchange between scripts and OS via <input> element with explicit user consent is another paradigm that I believe will be explored.
We could think of some mapping of the APIs from/to <input> to be able to realize functionally same scenarios with minimal change of the code.
E.g. <input type="contact"> would be a kind of equivalent to addressbook.getContact() or so.
The differentiation could be as above, but the properties of the objects retrieved by both above scenarios could match for easy integration. Personally I perceive it as a design pattern.

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: Jonas Sicking [mailto:jonas@sicking.cc]
Sent: Friday, November 20, 2009 2:04 AM
To: Marcin Hanclik
Cc: Maciej Stachowiak; Adam Barth; Robin Berjon; public-device-apis@w3.org; public-webapps WG
Subject: Re: Security evaluation of an example DAP policy

On Thu, Nov 19, 2009 at 4:49 PM, Marcin Hanclik
<Marcin.Hanclik@access-company.com> 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.

Given that I don't know the specifics about this policy format I can't
comment on the above policy specifically. However I will note that the
security experts at Mozilla did agree that opening a non-modal dialog
asking for access to geo-location was considered acceptable, as I
noted in a previous email. I don't know what effect that has on the
above policy.

I don't know what policy other browsers have used in this area.

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

Received on Friday, 20 November 2009 08:51:21 UTC