- From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
- Date: Thu, 19 Nov 2009 11:17:57 +0100
- To: "robert@ocallahan.org" <robert@ocallahan.org>
- CC: Jonas Sicking <jonas@sicking.cc>, David Rogers <david.rogers@omtp.org>, Maciej Stachowiak <mjs@apple.com>, Dominique Hazael-Massieux <dom@w3.org>, Robin Berjon <robin@berjon.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>, public-webapps WG <public-webapps@w3.org>
- Message-ID: <FAA1D89C5BAF1142A74AF116630A9F2C28942D758A@OBEEX01.obe.access-company.com>
Hi Robert, Thanks for the report! >>This model generally does not work on the Web. What about: “This model generally have not yet worked on the Web”? Maybe we do not know. Let’s assume I am an advanced user and I want to create a system that allows me to write to arbitrary files and dirs on my PC from the web page, e.g. a walled garden solution. Then I can either take Fx sources, add the APIs, compile and use it, or take binary Fx as is, configure the policy and use it. Taking the analogy to the OneWeb principle [1] (I found that there is also OneWeb™) we specify the general security concerns, but their handling would be different in various environments (e.g. based on applied policies). >>Forcing users to make decisions they do not want to make or cannot make is a failure. I am not sure whether anyone is forcing the user. The policy may be such that it prompts the user (forces her/him) or it may enable/disable the functionality. If the user does not want to make the decision, then she/he will not re-configure the browser. I think that the API (file walking) selected as the initial example is quite unfortunate. We may really want to disable access to some parts of the file system, for all (the policy could say that “C:\Windows\*” is not writable at all). To overcome this, we may focus on gallery API that could be a selected area within a file system. Then the policy is less about enabling something critical (access to “C:\Windows\System”) and more about limiting access to something what we could think is generally available. Let’s take another example then: Bluetooth API. Some people may want it to be accessible always and the others would like to limit that (for any reason). >>There are usually no third parties to delegate to. I have an impression that mobile operators and vendors (i.e. those who want to write the actual policies) are eager to take the responsibility. But I cannot speak for them. Thanks, Marcin [1] http://www.w3.org/TR/mobile-bp/#OneWeb Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanclik@access-company.com From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan Sent: Thursday, November 19, 2009 10:40 AM To: Marcin Hanclik Cc: Jonas Sicking; David Rogers; Maciej Stachowiak; Dominique Hazael-Massieux; Robin Berjon; public-device-apis@w3.org; public-webapps WG Subject: Re: DAP and security (was: Rename "File API" to "FileReader API"?) On Thu, Nov 19, 2009 at 10:08 PM, Marcin Hanclik <Marcin.Hanclik@access-company.com<mailto:Marcin.Hanclik@access-company.com>> wrote: The default settings within a browser could e.g. disable directory walking and file writing. But if the user changes the settings (and is warned about the potential security risks when switching some protection off), then it is up to the user and she/he takes over the responsibility. This model generally does not work on the Web. Few users understand settings or potential security risks and even fewer care. Lots of studies have shown this (e.g. see http://groups.csail.mit.edu/uid/projects/phishing/chi-security-toolbar.pdf). Forcing users to make decisions they do not want to make or cannot make is a failure. The abstraction of the security concerns within a policy may allow delegation of the security to some third parties. There are usually no third parties to delegate to. If you're mainly concerned with intranet applications, you might be able to delegate to corporate administrators, but you probably want to avoid that too. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6] ________________________________ ________________________________________ 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 10:18:58 UTC