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