RE: Trying to summarise (was Re: DAP and security)

Hi Maciej,

Thanks for your review!

The page <http://www.w3.org/2009/dap/> does not yet include the BONDI 1.1 Candidate Release at [1].
The device capabilities [2] could be regarded as a compact form of security considerations within BONDI APIs.
It should be noted that the device capabilities - although related to BONDI APIs - could be regarded as generic enough to incorporate any APIs.

Based on the BONDI policy format specification, I would propose to start with the following default policy for "the Web":

<policy-set combine="deny-overrides">
  <policy description="Default Policy for BONDI API & device capabilities within Win2K environment">
    <target>
      <subject>
        <subject-match attr="class" match="website" func="equal"/>
        <subject-match attr="uri.scheme" match="http" func="equal"/>
      </subject>
      <subject>
        <subject-match attr="class" match="website" func="equal"/>
        <subject-match attr="uri.scheme" match="https" func="equal"/>
      </subject>
    </target>
    <rule effect="deny">
      <condition combine="or">
        <condition combine="and">
          <condition combine="or">
            <resource-match attr="device-cap" match="io.file.read"/>
            <resource-match attr="device-cap" match="io.file.write"/>
          </condition>
          <condition combine="or">
            <resource-match attr="param:name">C:\WINNT<resource-match />
            <resource-match attr="param:name">C:\Documents and Settings<resource-match />
          </condition>
        </condition>
        <condition combine="or">
            <resource-match attr="device-cap" match="devicestatus.set"/>
            <resource-match attr="device-cap" match="commlog.clear"/>
        </condition>
      </condition>
    </rule>
    <rule effect="prompt-session">
      <condition combine="or">
         <resource-match attr="device-cap" match="location.position"/>
         <resource-match attr="device-cap" match="devicestatus.get"/>
         <resource-match attr="device-cap" match="devicestatus.list"/>
        <condition combine="and">
          <condition combine="or">
            <resource-match attr="param:inContacts">undefined<resource-match />
          </condition>
          <condition combine="or">
                <resource-match attr='device-cap' match='messaging.email.send'>
                <resource-match attr='device-cap' match='messaging.mms.send'>
                <resource-match attr='device-cap' match='messaging.sms.send'>
                <resource-match attr='device-cap' match='messaging.binary.send'>
          </condition>
        </condition>
      </condition>
    </rule>
    <rule effect="prompt-oneshot">
      <condition combine="or">
         <resource-match attr="device-cap" match="applauncher.launch"/>
         <resource-match attr="device-cap" match="io.file.write"/>
      </condition>
    </rule>
    <rule effect="permit">
      <condition combine="or">
        <resource-match attr='device-cap' match='appconfig.get'>
      </condition>
    </rule>
    <rule effect="prompt-blanket">
      <condition combine="or">
        <resource-match attr="device-cap" match="appconfig.set">
        <resource-match attr="device-cap" match="applauncher.get">
        <resource-match attr="device-cap" match="camera.access">
        <resource-match attr="device-cap" match="camera.capture">
        <resource-match attr="device-cap" match="camera.record">
        <resource-match attr="device-cap" match="commlog.sms.get">
        <resource-match attr="device-cap" match="commlog.mms.get">
        <resource-match attr="device-cap" match="commlog.email.get">
        <resource-match attr="device-cap" match="commlog.call.get">
        <resource-match attr="device-cap" match="io.file.read"/>
        <resource-match attr="device-cap" match="location.position">
        <resource-match attr="device-cap" match="messaging.email.attach">
        <resource-match attr="device-cap" match="messaging.mms.attach">
        <resource-match attr="device-cap" match="messaging.email.getAccounts">
        <resource-match attr="device-cap" match="messaging.email.send">
        <resource-match attr="device-cap" match="messaging.mms.send">
        <resource-match attr="device-cap" match="messaging.sms.send">
        <resource-match attr="device-cap" match="messaging.binary.send">
        <resource-match attr="device-cap" match="messaging.mms.subscribe">
        <resource-match attr="device-cap" match="messaging.sms.subscribe">
        <resource-match attr="device-cap" match="messaging.binary.subscribe">
        <resource-match attr="device-cap" match="pim.contact.read">
        <resource-match attr="device-cap" match="pim.contact.write">
        <resource-match attr="device-cap" match="pim.task.read">
        <resource-match attr="device-cap" match="pim.task.read">
        <resource-match attr="device-cap" match="pim.event.write">
        <resource-match attr="device-cap" match="pim.event.read">
        <resource-match attr="device-cap" match="ui">
      </condition>
    </rule>
  </policy>
</policy-set>


Thanks,
Marcin

[1] http://bondi.omtp.org/1.1/CR/
[2] http://bondi.omtp.org/1.1/CR/apis/devcaps.html
________________________________________
From: public-device-apis-request@w3.org [public-device-apis-request@w3.org] On Behalf Of Maciej Stachowiak [mjs@apple.com]
Sent: Thursday, November 19, 2009 6:35 PM
To: Adam Barth
Cc: Robin Berjon; public-device-apis@w3.org; public-webapps WG
Subject: Re: Trying to summarise (was Re: DAP and security)

On Nov 19, 2009, at 7:58 AM, Adam Barth wrote:

> On Thu, Nov 19, 2009 at 3:24 AM, Robin Berjon <robin@berjon.com>
> wrote:
>> Finally, we can all talk about policy and trust in browsers until
>> we're bluer in the face than a hypothermic smurf the fact of the
>> matter is that I don't believe that this is a case where discussion
>> can produce consensus. There are use cases for policy, and
>> solutions for those will be developed at the very least for the
>> widgets landscape. If it so happens that they yield interesting
>> innovative stuff that could be useful in browsers, then it'll be
>> easy to point to it as proof and demo. Far easier than to argue
>> about it, and it'll happen faster if we create the technology
>> rather than talk about it :)
>
> I don't believe you can design secure APIs by first implementing the
> APIs and then worrying about security later.  That's the road that
> leads to systems like User Account Control (UAC).  Instead, you need
> to understand the security requirements up-front and design your APIs
> to match.
>
> If you ignore input from browser vendors who've been working with
> these issues for years, it's unlikely you'd design something they'll
> find palatable.

This is pretty much how I feel about the security design aspects of
many of the proposed DAP specifications. If you look at the specs
listed in the Input section here: <http://www.w3.org/2009/dap/>, they
mostly have missing or unhelpful Security Considerations sections. The
BONDI security document listed there doesn't seem to provide anything
for security other than a policy mechanism, with no hint of what might
be a safe default policy for the Web.

Apple will consider joining the DAP Working Group, but the security
direction so far is on reason we are hesitant.

Regards,
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 Thursday, 19 November 2009 21:42:11 UTC