OK, I will take your word for it that security is an important
consideration for DAP. But while at the TPAC, I heard more than one
DAP participant say, when faced with a potential security concern,
something like "can't we just leave that up to the policy?" In one
case when I enquired further, at least one DAP member mentioned to me
the idea of using some sort of "policy file" that would take care of
all security issues. He suggested this might come from a corporate
administrator, and that the format would be XML, but otherwise details
were light.
To me that seems like a plausible model for something like widgets or
browser extensions or walled garden content, but not for sites on the
public Web.
My apologies if I misinterpreted these remarks or got the wrong
impression.
One more comment below:
On Nov 18, 2009, at 4:18 AM, Marcin Hanclik wrote:
+1
APIs - specifically their design - shall be specified tightly with
the security model in mind to make them both easy to use and
effective.
This is what makes the whole task that difficult.
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: [email protected]
-----Original Message-----
From: [email protected] [mailto:[email protected]
] On Behalf Of Dominique Hazael-Massieux
Sent: Thursday, November 12, 2009 10:30 AM
To: Maciej Stachowiak
Cc: Robin Berjon; [email protected]; public-webapps WG
Subject: DAP and security (was: Rename “File API” to “FileReader
API”?)
Le mardi 10 novembre 2009 à 17:47 -0800, Maciej Stachowiak a écrit :
I would be concerned with leaving file writing to DAP, because a
widely held view in DAP seems to be that security can be ignored
while
designing APIs and added back later with an external "policy file"
mechanism.
Frederick already mentioned this isn’t the case at all, and I want to
strongly reject the notion that DAP is considering security as an
after-the-fact or out-of-band aspect in the design of its APIs.
Our charter clearly stipulates that our policy model “must be
consistent
with the existing same origin policies (as documented in the HTML5
specification), in the sense that a deployment of the policy model in
Web browsers must be possible”.
It seems to me that for most of DAP's likely deliverables, there are
serious security considerations, but the same-origin policy is
irrelevant to addressing them. The same-origin policy is designed to
protect Web sites from attacks by other Web sites. It does not really
apply to access to system resources. Doing that in a Web-safe way will
require new inventions or might not even be possible in some cases.
In fact, most of models that have been discussed in this thread to
reduce the risks exposed by new APIs (sandbox for writing, user
interaction or markup-based element for sharing data) were already
mentioned as options by DAP WG participants during our F2F last week.
More generally, I don’t think assuming that DAP would create worse/
less
secure APIs than WebApps or any other group would is either right nor
useful to ensure a good collaboration between our groups. And clearly,
we will actively be seeking feedback and input from the WebApps
Working
Group when we produce new APIs, which should also contribute to reduce
the fears that we would get it all wrong :)
Regards,
Dom
________________________________________
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.
