Trying to summarise (was Re: DAP and security)
Whoa. I believe that the original renaming of the thread intended to clarify the DAP's mission and stance on security, but we've devolved again into more muddied up discussion, so I'd like to take a second stab at clarifying the landscape. One, DAP *will* handle security. I think everyone's on the same page on that one now. Second, DAP APIs are fully intended to be able to run in a browser context. I believe that there may have been unfortunate misunderstandings, but the fact of the matter is that APIs not supported by default in browsers will be considered a failure. I think that some of the confusion about the fact that these would necessarily have to follow a security model that works inside a browser stems from the fact that people (including myself) have repeatedly stated that they wanted authors to have the same APIs irrespective of whether they were running in a browser or in a web runtime used in a different context. This does *not* mean that the security model will be the same in both context, and indeed since the entry points to said APIs are likely to be different in each context some part of the APIs may turn out to be different. The point was that those differences should be minor, and clear to authors. 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 :) Speaking of innovation and trust in browsers, it seems that the JetPack elves are working on some form of social web of trust for browser extensions — is there a chance that they could chat about it with DAP? -- Robin Berjon - http://berjon.com/
Re: Trying to summarise (was Re: DAP and security)
On Thu, Nov 19, 2009 at 11:24 AM, Robin Berjon ro...@berjon.com wrote: Whoa. I believe that the original renaming of the thread intended to clarify the DAP's mission and stance on security, but we've devolved again into more muddied up discussion, so I'd like to take a second stab at clarifying the landscape. One, DAP *will* handle security. I think everyone's on the same page on that one now. Second, DAP APIs are fully intended to be able to run in a browser context. I believe that there may have been unfortunate misunderstandings, but the fact of the matter is that APIs not supported by default in browsers will be considered a failure. Is this practical without the major browsers being part of the DAP WG? (Last time I checked, there were some absences.) I think that some of the confusion about the fact that these would necessarily have to follow a security model that works inside a browser stems from the fact that people (including myself) have repeatedly stated that they wanted authors to have the same APIs irrespective of whether they were running in a browser or in a web runtime used in a different context. This does *not* mean that the security model will be the same in both context, I don't understand. If security is baked into APIs from the start (as is a requirement for browsers) and the same API should be used in the different context, then what need is there for a policy model? The policy model seems to only be applicable when APIs are inherently insecure and trust is required...which is the type of API a browser will not implement. and indeed since the entry points to said APIs are likely to be different in each context some part of the APIs may turn out to be different. The point was that those differences should be minor, and clear to authors. 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 :) Speaking of innovation and trust in browsers, it seems that the JetPack elves are working on some form of social web of trust for browser extensions — is there a chance that they could chat about it with DAP? -- Robin Berjon - http://berjon.com/
Re: Trying to summarise (was Re: DAP and security)
On Nov 19, 2009, at 13:09 , Jeremy Orlow wrote: Is this practical without the major browsers being part of the DAP WG? (Last time I checked, there were some absences.) Well, the absences have been vocal in commenting so far; and others have indicated intention to join. We can't wait for every browser vendor to find the resources to join a WG to get it rolling. It took a *long* while to get everyone on WebApps. I don't understand. If security is baked into APIs from the start (as is a requirement for browsers) and the same API should be used in the different context, then what need is there for a policy model? The policy model seems to only be applicable when APIs are inherently insecure and trust is required...which is the type of API a browser will not implement. In a widget context for instance, policy could override the user consent mechanism that an API has baked in. If you have an asynchronous security entry point à la Geo for instance, it could return immediately (or block indefinitely) without ever interacting with the user. And as I said in the message to which you replied, additional entry points can be made available. To take a totally random example, if the policy grants it you might become able to do navigator.device.gimmeOneFile(/etc/passwd) which would return just what you'd get from the File API. -- Robin Berjon - http://berjon.com/
Re: Trying to summarise (was Re: DAP and security)
On Thu, Nov 19, 2009 at 3:24 AM, Robin Berjon ro...@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. Adam
RE: Trying to summarise (was Re: DAP and security)
I don't believe you can design secure APIs by first implementing the APIs and then worrying about security later. +1 Speaking for myself, in BONDI [1] the most interesting, controversial and complex topics arise when the Interfaces [2] meet Architecture Security [3,4]. Security requires clarity, i.e. Architecture. Interfaces - to deliver Architecture - require something like API design patterns [5]. The task may be not completed on all fronts, but BONDI tries to deliver all of those components in a consistent manner as required. Though, it is hard to make a large group work together on all aspects at once. Thanks, Marcin [1] http://bondi.omtp.org/1.1/CR/ [2] http://bondi.omtp.org/1.1/CR/apis/index.html [3] http://bondi.omtp.org/1.1/CR/security/BONDI_Architecture_and_Security_v1.1_CR.pdf [4] http://bondi.omtp.org/1.1/CR/security/BONDI_Architecture_and_Security_Appendices_v1.1_CR.pdf [5] http://bondi.omtp.org/1.1/CR/apis/BONDI_Interface_Patterns_v1.1.html Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org] On Behalf Of Adam Barth Sent: Thursday, November 19, 2009 4:59 PM To: Robin Berjon Cc: public-device-a...@w3.org; public-webapps WG Subject: Re: Trying to summarise (was Re: DAP and security) On Thu, Nov 19, 2009 at 3:24 AM, Robin Berjon ro...@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. Adam 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.
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 ro...@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
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:nameC:\WINNTresource-match / resource-match attr=param:nameC:\Documents and Settingsresource-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:inContactsundefinedresource-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-requ...@w3.org [public-device-apis-requ...@w3.org] On Behalf Of Maciej Stachowiak [...@apple.com] Sent: Thursday, November 19, 2009 6:35 PM To:
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-requ...@w3.org [public-device-apis-requ...@w3.org] On Behalf Of Marcin Hanclik [marcin.hanc...@access-company.com] Sent: Thursday, November 19, 2009 10:41 PM To: Maciej Stachowiak; Adam Barth Cc: Robin Berjon; public-device-a...@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:nameC:\WINNTresource-match / resource-match attr=param:nameC:\Documents and Settingsresource-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:inContactsundefinedresource-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
