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

Hi again,

Relevant to the BONDI security model and to the relationships between APIs and policy are also the API design patterns [6], specifically those currently listed in section [7], i.e. versioning, API coverage by features and feature-sets.
The document [6] is to be refreshed soon, specifically with already applied design pattern related to instantiation (see \def-instantiated in 4.3.2 of [6]).

I hope this helps.

Thanks,
Marcin

P.S. The below comment about clickability of [1] should actually point to [2].

[6] http://bondi.omtp.org/1.1/CR/apis/BONDI_Interface_Patterns_v1.1.html
[7] http://bondi.omtp.org/1.1/CR/apis/BONDI_Interface_Patterns_v1.1.html#arch-patterns
________________________________________
From: Marcin Hanclik
Sent: Thursday, November 19, 2009 10:59 PM
To: Marcin Hanclik; Maciej Stachowiak; Adam Barth
Cc: Robin Berjon; public-device-apis@w3.org; public-webapps WG
Subject: RE: Trying to summarise (was Re: DAP and security)

Hi Maciej, All,

The file under [1] is not clickable, therefore browsing the relationships between various identifiers may be difficult at the first time.
At [3,4] there is/are clickable versions of the BONDI API specs.
At [5] there are live updates of the APIs.

I hope this helps.

Thanks,
Marcin

[3] http://bondi01.obe.access-company.com/1_1_4263_120/devcaps_clickable.html
[4] http://bondi01.obe.access-company.com/1_1_4263_120/
[5] http://bondi01.obe.access-company.com/
________________________________________
From: public-device-apis-request@w3.org [public-device-apis-request@w3.org] On Behalf Of Marcin Hanclik [Marcin.Hanclik@access-company.com]
Sent: Thursday, November 19, 2009 10:41 PM
To: Maciej Stachowiak; Adam Barth
Cc: Robin Berjon; public-device-apis@w3.org; public-webapps WG
Subject: 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.


________________________________________

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 23:03:52 UTC