RE: [WARP] Comments to WARP spec
Hi Robin, Great thanks for the descriptive example! At first I thought that it all depends on the trust model. The security issue in your example results from the eval that is contained in the html within a widget. So we could assume that if the widget is signed we could somehow rely on its content. Then the evil eval would maybe not be used (at least not in the context you quote). So we could have the simple distinction between executable content (js, html) and non-executable content (img, css [until scripts come there] ). However, since some images can also be executed, the distinction is de-facto void. Therefore it seems the use case is not doable, because we probably do not want to overload the implementations with [SNIFF] algorithms. 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: marcin.hanc...@access-company.com -Original Message- From: Robin Berjon [mailto:ro...@berjon.com] Sent: Wednesday, November 18, 2009 6:37 PM To: Marcin Hanclik Cc: WebApps WG Subject: Re: [WARP] Comments to WARP spec Hi Marcin, On Nov 18, 2009, at 14:37 , Marcin Hanclik wrote: One could request an image that is redirected to http://address/of/image?put+a+complete+script+here and then evaluate the query. Ok, but then it will still be processed as image and will result in an invalid image, I think. Not so. Consider the following piece of Perl: #!/usr/bin/perl print Location: img.png?alert('I am evil!')\n\n; And the following HTML: !DOCTYPE html iframe src='img.pl' id='pl'/iframe script window.onload = function () { eval(unescape(document.getElementById(pl).contentDocument.location.search.substring(1))); } /script This produces the expected alert. No script was ever exchanged, and I get the image to display perfectly fine. -- Robin Berjon - http://berjon.com/ 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: DAP and security (was: Rename File API to FileReader API?)
Hi Jonas, I think that it all depends on the user or the abstraction that we seem to have about the user. We can take the analogy to the operating system. OS may e.g. not be writable for the user, may have pre-defined active firewalls etc. The user then may not access some sites, may not install any native app etc. The OS or PC is a kind of a toy or a kiosk. Later, the user switches off firewalls, gets admin rights, installs apps that have access to the file system etc. I think that the same principle is being applied to the browser world. Policy is to make it all easier and more comprehensible. 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. The abstraction of the security concerns within a policy may allow delegation of the security to some third parties. 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: marcin.hanc...@access-company.com -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Wednesday, November 18, 2009 9:15 PM To: David Rogers Cc: Maciej Stachowiak; Marcin Hanclik; Dominique Hazael-Massieux; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: DAP and security (was: Rename File API to FileReader API?) On Wed, Nov 18, 2009 at 5:27 AM, David Rogers david.rog...@omtp.org wrote: Hi Maciej, From my side I'd like to understand what your thoughts and proposals for file writing security / policy would entail - would you defer the decision responsibility to the user via a prompt? From my point of view the answer is unfortunately there are no simple answers, it's always a judgement call. For example for the geolocation the security model is basically: 1. Page asks for user position 2. User is faced with a non-modal dialog where he/she can answer yes or no, or simply ignore the dialog 3. Only if the user answers yes then the position is returned to the page. In this case I think this was an acceptable solution. If we added a directory API which gave access to a requested path on the users hard drive we could use a similar security model: 1. Page asks user for permission to read/write to a specific directory, say C:\ 2. User is faced with a non-modal dialog where he/she can answer yes or no, or simply ignore the dialog 3. Only if the user answeres yes a reference to the directory is returned which the page can read from/write to. This would *not* be an acceptable solution to me, despite being basically identical to the geolocation case. The reason is two-fold. I think it's easier to explain to the user what the user is authorizing (your location), and if a user doesn't understand and still clicks yes, it has less catastrophic results. For the directory API though, it's much harder to explain the decision to the user. What's the C:\ directory? What's the difference between that and C:\Documents and Settings\Jonas Sicking\My Images? What's a directory? Also, if a user clicks yes without understanding the risks, that has catastrophic results if the directory in question is C:\ and read/write access is granted. When it comes to security dialogs, the basic rule to keep in mind is Lots of people are not going to understand it and just click whatever button they think will get stuff to work, or a random button. / Jonas 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: DAP and security (was: Rename File API to FileReader API?)
Hi Maciej, I think we should separate the policy definition from its application. We could have a single policy abstraction for browsers/OS vendors and all others. At the risk of oversimplification we could summarize that such abstraction is just a list of applicable security concerns. In some environments some third parties could be responsible for policy application (corporate, walled garden etc) within a configurable runtime/OS/etc and in the others the policy could be hard-coded and not modifiable (e.g. in a freely downloaded browser the browser vendor applies the policy once and forever). Still we could have the same security concerns. 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: marcin.hanc...@access-company.com -Original Message- From: Maciej Stachowiak [mailto:m...@apple.com] Sent: Thursday, November 19, 2009 2:20 AM To: Frederick Hirsch Cc: ext Jonas Sicking; David Rogers; Marcin Hanclik; Dominique Hazael-Massieux; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: DAP and security (was: Rename File API to FileReader API?) On Nov 18, 2009, at 5:13 PM, Frederick Hirsch wrote: This is a good point, and an argument for policy rather than implicit user consent, if I'm not mistaken. It highlights that usability might also be an issue with the non-modal interaction model, as well as not always be very meaningful (since I the user might have no idea what most directories are for or where to navigate). Arbitrary directory navigation for writing files is not a good idea. policy is not a solution to the scenario Jonas posted either. Who is going to define a home PC or Mac user's browser policy? The user doesn't have the expertise to do it. There's no sysadmin to do it for them. And browser/OS vendors should not be in the game of whitelisting a specific set of sites for extra access. Regards, Maciej More importantly we have to be careful with analogies. regards, Frederick Frederick Hirsch Nokia On Nov 18, 2009, at 3:14 PM, ext Jonas Sicking wrote: On Wed, Nov 18, 2009 at 5:27 AM, David Rogers david.rog...@omtp.org wrote: Hi Maciej, From my side I'd like to understand what your thoughts and proposals for file writing security / policy would entail - would you defer the decision responsibility to the user via a prompt? From my point of view the answer is unfortunately there are no simple answers, it's always a judgement call. For example for the geolocation the security model is basically: 1. Page asks for user position 2. User is faced with a non-modal dialog where he/she can answer yes or no, or simply ignore the dialog 3. Only if the user answers yes then the position is returned to the page. In this case I think this was an acceptable solution. If we added a directory API which gave access to a requested path on the users hard drive we could use a similar security model: 1. Page asks user for permission to read/write to a specific directory, say C:\ 2. User is faced with a non-modal dialog where he/she can answer yes or no, or simply ignore the dialog 3. Only if the user answeres yes a reference to the directory is returned which the page can read from/write to. This would *not* be an acceptable solution to me, despite being basically identical to the geolocation case. The reason is two-fold. I think it's easier to explain to the user what the user is authorizing (your location), and if a user doesn't understand and still clicks yes, it has less catastrophic results. For the directory API though, it's much harder to explain the decision to the user. What's the C:\ directory? What's the difference between that and C:\Documents and Settings\Jonas Sicking\My Images? What's a directory? Also, if a user clicks yes without understanding the risks, that has catastrophic results if the directory in question is C:\ and read/write access is granted. When it comes to security dialogs, the basic rule to keep in mind is Lots of people are not going to understand it and just click whatever button they think will get stuff to work, or a random button. / Jonas 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: DAP and security (was: Rename File API to FileReader API?)
Hi Adam, Abstracting the problem doesn't make the security challenges any easier. I agree. The implementations still need to properly code the abstractions, and additionally have to properly capture the application of the policy. So the work virtually doubles. The only difference / advantage of having the abstraction is that the way of operation is configurable. That's what the policy is in the nutshell. 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: marcin.hanc...@access-company.com -Original Message- From: Adam Barth [mailto:w...@adambarth.com] Sent: Thursday, November 19, 2009 8:42 AM To: Marcin Hanclik Cc: Maciej Stachowiak; Dominique Hazael-Massieux; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: DAP and security (was: Rename File API to FileReader API?) On Wed, Nov 18, 2009 at 6:16 AM, Marcin Hanclik marcin.hanc...@access-company.com wrote: The first step is to have the security concerns. The widget environment, BONDI etc. then encode them somehow (e.g. as device capability, feature etc.) creating an abstraction. In case of the browser, those concerns seem to be simply coded in the browser. Still the concerns remain and are handled. The widgets spec try to abstract them in order to give the freedom either to the end user, administrator, operator or any other party. Alternatively they could be simply hard-coded in the webruntime. So the issue is only who is able to specify whether the policy is applied, the concerns are still there. I'm skeptical that this approach will lead to a secure API for file access. Abstracting the problem doesn't make the security challenges any easier. The reason the HTML file upload control has been such a successful secure API for reading files is because the security issues are specifically *not* abstracted. The entire API is designed around the security considerations and eliciting user consent in a easy-to-understand way. I suspect we'll need a similarly clever API design to address the security challenges of letting web content write to the user's file system. 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: DAP and security (was: Rename File API to FileReader API?)
Le jeudi 19 novembre 2009 à 22:39 +1300, Robert O'Callahan a écrit : 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. That’s true to a certain extent, but a reason for that might well be that the Web platform hasn’t left enough room for third parties in that realm. One could very well imagine that by allowing a certain level of abstraction in security concerns, we would allow businesses to offer guarantees against data-loss or data-thief if the user install a third-party extension that would check Web sites based on a number of their security aspects. I’m pretty sure I don’t like all the implications of such a system, and I’m generally rather in the skeptic side when it comes to the use of a full-blown policy framework for the Web; but I don’t think it’s fair to conclude that it is not useful simply based on the fact that it hasn’t been put to use yet, esp. if it’s currently difficult or impossible to put it to use. Dom
Re: CfC - publish Selectors API as CR
On Nov 19, 2009, at 00:49 , Charles McCathieNevile wrote: this is a Call for consensus to request publishing the Selectors API draft at http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.101content-type=text/html;%20charset=iso-8859-1 as a Candidate Recommendation (assuming Lachy fixes the apparent encoding errors, the incorrect URIs and so on as editorial corrections). That's a plus-one from us. As for the encoding errors, I recommend going to the document directly rather than through the baroque URLs that cvsweb makes up: http://dev.w3.org/2006/webapi/selectors-api/ -- Robin Berjon - http://berjon.com/
Re: DAP and security (was: Rename File API to FileReader API?)
On Thu, Nov 19, 2009 at 10:52 PM, Dominique Hazael-Massieux d...@w3.orgwrote: Le jeudi 19 novembre 2009 à 22:39 +1300, Robert O'Callahan a écrit : There are usually no third parties to delegate to. That’s true to a certain extent, but a reason for that might well be that the Web platform hasn’t left enough room for third parties in that realm. One could very well imagine that by allowing a certain level of abstraction in security concerns, we would allow businesses to offer guarantees against data-loss or data-thief if the user install a third-party extension that would check Web sites based on a number of their security aspects. Businesses could offer that today, as a Firefox extension for example. There are actually a lot of security toolbar extensions, but they tend to offer advice rather than enforcement and they don't offer any guarantees. ( http://groups.csail.mit.edu/uid/projects/phishing/chi-security-toolbar.pdfhas an interesting analysis (albeit slightly dated).) 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]
Re: DAP and security (was: Rename File API to FileReader API?)
On Thu, Nov 19, 2009 at 1:08 AM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Jonas, I think that it all depends on the user or the abstraction that we seem to have about the user. We can take the analogy to the operating system. OS may e.g. not be writable for the user, may have pre-defined active firewalls etc. The user then may not access some sites, may not install any native app etc. The OS or PC is a kind of a toy or a kiosk. Later, the user switches off firewalls, gets admin rights, installs apps that have access to the file system etc. I think that the same principle is being applied to the browser world. Policy is to make it all easier and more comprehensible. 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. The abstraction of the security concerns within a policy may allow delegation of the security to some third parties. I doubt that we'd spend time on implementing a feature that is disabled by default out of security considerations. First of all it'd basically not be worth our time since very few users change default settings. This is magnified by the fact that very few websites would use such a feature (since, again, few users change default settings), so we wouldn't really be improving the web a whole lot. Second, users would inevitably turn the feature on without realizing what security implications it has, meaning that we put a group of users at risk. Third, we'll have to spend efforts maintaining the code, even though it benefits only a small number of people. For example if a buffer overflow bug is found we'll have to treat that as as serious of a bug as a overflow in normal on-by-default code. Up to and including engineering efforts to fix the bug, QA efforts to test the fix, release resources to spin a new emergency release, and marketing efforts asking people to upgrade. I can draw a couple of real-world analogies. In Thunderbird (the email reader from mozilla), there is support for enabling javascript in emails. This support is turned off by default. However many people turn it on, without realizing that this means that someone that sends you an email can see if you forward this email to anyone, and see what comments you are adding to that email. All they wanted was javascript for some other, much more secure, use case. Additionally, we've having to release *many* security updates specifically to account for the minority of people that turn on javascript. We're currently on security update number 23. If we didn't bother making updates when only people that had turned on javascript were affected, we would have had a fraction as many updates. As a result, the next major version of thunderbird is removing the ability to turn on javascript completely. Not even a hidden preference exists. Similarly, there was a preference in Firefox 3 that allowed XMLHttpRequest to load resources from any site without any security restrictions. Originally the preference had been added for no particular reason; why not, it's disabled by default. And intended to be enabled only on a per-site basis. However due to how some security architecture works it was possible to set a default behavior that applied to all sites. Eventually developers found this preference (how, i do not know, we never had documentation for it) and word spread through blogs that switching this pref was useful during development and testing [1]. What these people didn't realize is that switching this pref means that any website you go to can read your creditcard numbers and bank statements if you happen to be logged in to your bank. Or your emails if you happen to be logged in to gmail. So switching that pref essentially handed all the personal information you store on the web to any evil site you visit. Once I noticed that that pref existed I removed it. Ultimately I don't really have anything against security policies in principal. However when looking at implementing an API in firefox we'll definitely be reviewing the API in the light of the default policy used by Firefox. If the API doesn't make sense from that point of view I don't see us implementing it. [1] http://blog.dirolf.com/2007/06/enabling-cross-domain-ajax-in-firefox.html / Jonas
Re: [WARP] Comments to WARP spec
Hi Marcin, On Nov 19, 2009, at 09:44 , Marcin Hanclik wrote: Great thanks for the descriptive example! A pleasure :) The security issue in your example results from the eval that is contained in the html within a widget. So we could assume that if the widget is signed we could somehow rely on its content. Then the evil eval would maybe not be used (at least not in the context you quote). Perhaps, but the example I used was very straightforward and easy to review — it would be possible for the original HTML to be a trojan with a less obvious attack path. For instance consider a createElement(name, parent, content) method; you could obtain script and alert('I am evil!') using the same trick, and call createElement(script, document.body, alert('I am evil!')) — it would work just the same as eval(). However, since some images can also be executed, the distinction is de-facto void. Right, it's one of those things that people would've done differently if we'd had a chance to think about the consequences while the web was being organically grown, but that's water under the bridge now. -- Robin Berjon - http://berjon.com/
RE: DAP and security (was: Rename File API to FileReader API?)
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.hanc...@access-company.com From: rocalla...@gmail.com [mailto:rocalla...@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-a...@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.hanc...@access-company.commailto:marcin.hanc...@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.
RE: DAP and security (was: Rename File API to FileReader API?)
Hi Jonas, Well, great thanks for the very exhaustive report. It seems we will have to think a lot in DAP. 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: marcin.hanc...@access-company.com -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Thursday, November 19, 2009 11:11 AM To: Marcin Hanclik Cc: David Rogers; Maciej Stachowiak; Dominique Hazael-Massieux; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: DAP and security (was: Rename File API to FileReader API?) On Thu, Nov 19, 2009 at 1:08 AM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Jonas, I think that it all depends on the user or the abstraction that we seem to have about the user. We can take the analogy to the operating system. OS may e.g. not be writable for the user, may have pre-defined active firewalls etc. The user then may not access some sites, may not install any native app etc. The OS or PC is a kind of a toy or a kiosk. Later, the user switches off firewalls, gets admin rights, installs apps that have access to the file system etc. I think that the same principle is being applied to the browser world. Policy is to make it all easier and more comprehensible. 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. The abstraction of the security concerns within a policy may allow delegation of the security to some third parties. I doubt that we'd spend time on implementing a feature that is disabled by default out of security considerations. First of all it'd basically not be worth our time since very few users change default settings. This is magnified by the fact that very few websites would use such a feature (since, again, few users change default settings), so we wouldn't really be improving the web a whole lot. Second, users would inevitably turn the feature on without realizing what security implications it has, meaning that we put a group of users at risk. Third, we'll have to spend efforts maintaining the code, even though it benefits only a small number of people. For example if a buffer overflow bug is found we'll have to treat that as as serious of a bug as a overflow in normal on-by-default code. Up to and including engineering efforts to fix the bug, QA efforts to test the fix, release resources to spin a new emergency release, and marketing efforts asking people to upgrade. I can draw a couple of real-world analogies. In Thunderbird (the email reader from mozilla), there is support for enabling javascript in emails. This support is turned off by default. However many people turn it on, without realizing that this means that someone that sends you an email can see if you forward this email to anyone, and see what comments you are adding to that email. All they wanted was javascript for some other, much more secure, use case. Additionally, we've having to release *many* security updates specifically to account for the minority of people that turn on javascript. We're currently on security update number 23. If we didn't bother making updates when only people that had turned on javascript were affected, we would have had a fraction as many updates. As a result, the next major version of thunderbird is removing the ability to turn on javascript completely. Not even a hidden preference exists. Similarly, there was a preference in Firefox 3 that allowed XMLHttpRequest to load resources from any site without any security restrictions. Originally the preference had been added for no particular reason; why not, it's disabled by default. And intended to be enabled only on a per-site basis. However due to how some security architecture works it was possible to set a default behavior that applied to all sites. Eventually developers found this preference (how, i do not know, we never had documentation for it) and word spread through blogs that switching this pref was useful during development and testing [1]. What these people didn't realize is that switching this pref means that any website you go to can read your creditcard numbers and bank statements if you happen to be logged in to your bank. Or your emails if you happen to be logged in to gmail. So switching that pref essentially handed all the personal information you store on the web to any evil site you visit. Once I noticed that that pref existed I removed it. Ultimately I don't really have anything against security policies in principal. However when looking at implementing an API in firefox we'll definitely be reviewing the API in the light of the default policy used by Firefox. If the API doesn't make sense from that point of view I don't see us
RE: [FileReader API, ProgressEvents] Design patterns, FileWriter API
Hi Arun, To be clear, IMHO it's absolutely too late for FileReader FileReader is still ED, therefore we may have time, I think. Regarding FileWriter, I'm open to considering new event names, but in general, discussing FileWriter's event model may be putting the cart in front of the horse. Even if we had an event-driven FileWriter, what would it do? We'll need to figure out filesystem access (real or virtual) first! :-) Agreed. I have been thinking in terms of API design patterns and IMHO their target is to first document what we have in order to be able to foresee potential incompatibilities. That is why I shout early :) 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: marcin.hanc...@access-company.com -Original Message- From: Arun Ranganathan [mailto:a...@mozilla.com] Sent: Thursday, November 19, 2009 12:55 AM To: Marcin Hanclik Cc: Anne van Kesteren; WebApps WG; public-device-a...@w3.org Subject: Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API Marcin Hanclik wrote: Hi Anne, XHR still is used also for data retrieval, so it is a kind of border case and I can live with load there :) . Using load for writing to a file will mean that we are stuck with the legacy stuff. load and write pull semantically in the opposite directions, IMHO. I think there is still time to change it in case of FileReader and prepare background for FileWriter. To be clear, IMHO it's absolutely too late for FileReader, and also not desirable. I've already mentioned developer familiarity with onload, etc. and I strongly disagree with changing names in this case. The existing progress events are fine for FileReader. We've also got a beta implementation in place in Fx 3.6. Regarding FileWriter, I'm open to considering new event names, but in general, discussing FileWriter's event model may be putting the cart in front of the horse. Even if we had an event-driven FileWriter, what would it do? We'll need to figure out filesystem access (real or virtual) first! :-) More on this topic in separate email. -- A* 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: DAP and security (was: Rename File API to FileReader API?)
Hi, I'm going to answer these one by one, so apologies in advance for a slew of emails coming from me. My comments will always be marked [DAVID]: -Original Message- From: Maciej Stachowiak [mailto:m...@apple.com] Sent: 19 November 2009 01:20 To: Frederick Hirsch Cc: ext Jonas Sicking; David Rogers; Marcin Hanclik; Dominique Hazael-Massieux; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: DAP and security (was: Rename File API to FileReader API?) On Nov 18, 2009, at 5:13 PM, Frederick Hirsch wrote: This is a good point, and an argument for policy rather than implicit user consent, if I'm not mistaken. It highlights that usability might also be an issue with the non-modal interaction model, as well as not always be very meaningful (since I the user might have no idea what most directories are for or where to navigate). Arbitrary directory navigation for writing files is not a good idea. policy is not a solution to the scenario Jonas posted either. Who is going to define a home PC or Mac user's browser policy? The user doesn't have the expertise to do it. There's no sysadmin to do it for them. And browser/OS vendors should not be in the game of whitelisting a specific set of sites for extra access. [DAVID] This is the whole point - the user could choose who their policy provider could be. The list is endless but it could be: a child protection organisation, EFF, Which?, an anti-virus vendor/firewall company, OS vendor, browser vendor, mobile operator - the point being that the provider is someone the user trusts. On the subject of whitelisting etc. have a look at http://stopbadware.org/ - potentially these are things that could be used by policy providers (I'm sure there are lots of other reputable sources too). Dieter Gollman said: security-unaware users have specific security requirements but usually no security expertise - this is why is wholly irresponsible to defer the decision to the user in the majority of cases. Generally, the user would much rather have someone more informed take that decision for them. I don't think we can eliminate prompts but we could reduce them to a level that they might actually be read and treated as important. Right now the opposite is true. Thanks, David.
RE: [WARP] Comments to WARP spec
Hi Robin, For instance consider a createElement(name, parent, content) method; you could obtain script and alert('I am evil!') using the same trick, and call createElement(script, document.body, alert('I am evil!')) - it would work just the same as eval(). Yes, it seems the architecture is simply vulnerable per current design (e.g. in ECMA allowing non-strict eval etc.) and we cannot do too much. Right, it's one of those things that people would've done differently if we'd had a chance to think about the consequences while the web was being organically grown, but that's water under the bridge now. Keeping the context of having a chance: what about event naming in [1]? Thanks, Marcin [1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0795.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: Robin Berjon [mailto:ro...@berjon.com] Sent: Thursday, November 19, 2009 11:15 AM To: Marcin Hanclik Cc: WebApps WG Subject: Re: [WARP] Comments to WARP spec Hi Marcin, On Nov 19, 2009, at 09:44 , Marcin Hanclik wrote: Great thanks for the descriptive example! A pleasure :) The security issue in your example results from the eval that is contained in the html within a widget. So we could assume that if the widget is signed we could somehow rely on its content. Then the evil eval would maybe not be used (at least not in the context you quote). Perhaps, but the example I used was very straightforward and easy to review - it would be possible for the original HTML to be a trojan with a less obvious attack path. For instance consider a createElement(name, parent, content) method; you could obtain script and alert('I am evil!') using the same trick, and call createElement(script, document.body, alert('I am evil!')) - it would work just the same as eval(). However, since some images can also be executed, the distinction is de-facto void. Right, it's one of those things that people would've done differently if we'd had a chance to think about the consequences while the web was being organically grown, but that's water under the bridge now. -- Robin Berjon - http://berjon.com/ 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: DAP and security (was: Rename File API to FileReader API?)
My comments: -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: 18 November 2009 20:15 To: David Rogers Cc: Maciej Stachowiak; Marcin Hanclik; Dominique Hazael-Massieux; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: DAP and security (was: Rename File API to FileReader API?) On Wed, Nov 18, 2009 at 5:27 AM, David Rogers david.rog...@omtp.org wrote: Hi Maciej, From my side I'd like to understand what your thoughts and proposals for file writing security / policy would entail - would you defer the decision responsibility to the user via a prompt? From my point of view the answer is unfortunately there are no simple answers, it's always a judgement call. [DAVID] So potentially that 'judgement' can be made by a third party who has more expertise than the user, extended to allow for context etc. - there would be lots of metadata to help with that from the policy provider point-of-view. For example for the geolocation the security model is basically: 1. Page asks for user position 2. User is faced with a non-modal dialog where he/she can answer yes or no, or simply ignore the dialog 3. Only if the user answers yes then the position is returned to the page. In this case I think this was an acceptable solution. [DAVID] Obvious answer to this - user clicks yes. Not acceptable. Given that child protection is a use case for geolocation privacy, do you think it is responsible to give a child that question? If we added a directory API which gave access to a requested path on the users hard drive we could use a similar security model: 1. Page asks user for permission to read/write to a specific directory, say C:\ 2. User is faced with a non-modal dialog where he/she can answer yes or no, or simply ignore the dialog 3. Only if the user answeres yes a reference to the directory is returned which the page can read from/write to. This would *not* be an acceptable solution to me, despite being basically identical to the geolocation case. The reason is two-fold. I think it's easier to explain to the user what the user is authorizing (your location), and if a user doesn't understand and still clicks yes, it has less catastrophic results. [DAVID] There are lot of not-so tech-savvie people using the web, so everything is on the table - you are assuming intelligence/knowledge from the off. For the directory API though, it's much harder to explain the decision to the user. What's the C:\ directory? What's the difference between that and C:\Documents and Settings\Jonas Sicking\My Images? What's a directory? Also, if a user clicks yes without understanding the risks, that has catastrophic results if the directory in question is C:\ and read/write access is granted. When it comes to security dialogs, the basic rule to keep in mind is Lots of people are not going to understand it and just click whatever button they think will get stuff to work, or a random button. [DAVID] Agreed. / Jonas
RE: DAP and security (was: Rename File API to FileReader API?)
My comments: -Original Message- From: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org] On Behalf Of Adam Barth Sent: 19 November 2009 07:42 To: Marcin Hanclik Cc: Maciej Stachowiak; Dominique Hazael-Massieux; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: DAP and security (was: Rename File API to FileReader API?) On Wed, Nov 18, 2009 at 6:16 AM, Marcin Hanclik marcin.hanc...@access-company.com wrote: The first step is to have the security concerns. The widget environment, BONDI etc. then encode them somehow (e.g. as device capability, feature etc.) creating an abstraction. In case of the browser, those concerns seem to be simply coded in the browser. Still the concerns remain and are handled. The widgets spec try to abstract them in order to give the freedom either to the end user, administrator, operator or any other party. Alternatively they could be simply hard-coded in the webruntime. So the issue is only who is able to specify whether the policy is applied, the concerns are still there. I'm skeptical that this approach will lead to a secure API for file access. Abstracting the problem doesn't make the security challenges any easier. The reason the HTML file upload control has been such a successful secure API for reading files is because the security issues are specifically *not* abstracted. The entire API is designed around the security considerations and eliciting user consent in a easy-to-understand way. I suspect we'll need a similarly clever API design to address the security challenges of letting web content write to the user's file system. [DAVID] I would hope that we can come up with some clever API design in terms of safe logic. However, this does not solve the whole problem, at some point you need to make a decision / judgement call. What the policy advocates are proposing is to advance the whole discipline here - let's improve this by adding strength in depth and allow the user to defer their decision to someone who they trust, who is willing to take the decision for them. Adam
RE: DAP and security (was: Rename File API to FileReader API?)
My comments: -Original Message- From: Dominique Hazael-Massieux [mailto:d...@w3.org] Sent: 19 November 2009 09:52 To: rob...@ocallahan.org Cc: Marcin Hanclik; Jonas Sicking; David Rogers; Maciej Stachowiak; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: DAP and security (was: Rename File API to FileReader API?) Le jeudi 19 novembre 2009 à 22:39 +1300, Robert O'Callahan a écrit : 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. That’s true to a certain extent, but a reason for that might well be that the Web platform hasn’t left enough room for third parties in that realm. One could very well imagine that by allowing a certain level of abstraction in security concerns, we would allow businesses to offer guarantees against data-loss or data-thief if the user install a third-party extension that would check Web sites based on a number of their security aspects. I’m pretty sure I don’t like all the implications of such a system, and I’m generally rather in the skeptic side when it comes to the use of a full-blown policy framework for the Web; but I don’t think it’s fair to conclude that it is not useful simply based on the fact that it hasn’t been put to use yet, esp. if it’s currently difficult or impossible to put it to use. [DAVID] I agree whole-heartedly with Dom's comments here, we need to open our minds to a better future here - the history of the web in security-terms is very nasty. Why not make it better? As I said in a previous email, we would like to give the user the choice about who they trust to make decisions for them. The vast majority of users on the web have no clue about security or any of the technical terms (I will hopefully add another usability study as a submission in the coming months which OMTP carried out). Why sandbox yourself to the browser? The very rationale of opening up physical 'things' to the web means you have to do something. Dom
RE: DAP and security (was: Rename File API to FileReader API?)
My comments: From: rocalla...@gmail.com [mailto:rocalla...@gmail.com] On Behalf Of Robert O'Callahan Sent: 19 November 2009 10:10 To: Dominique Hazael-Massieux Cc: Marcin Hanclik; Jonas Sicking; David Rogers; Maciej Stachowiak; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: DAP and security (was: Rename File API to FileReader API?) On Thu, Nov 19, 2009 at 10:52 PM, Dominique Hazael-Massieux d...@w3.org wrote: Le jeudi 19 novembre 2009 à 22:39 +1300, Robert O'Callahan a écrit : There are usually no third parties to delegate to. That’s true to a certain extent, but a reason for that might well be that the Web platform hasn’t left enough room for third parties in that realm. One could very well imagine that by allowing a certain level of abstraction in security concerns, we would allow businesses to offer guarantees against data-loss or data-thief if the user install a third-party extension that would check Web sites based on a number of their security aspects. Businesses could offer that today, as a Firefox extension for example. There are actually a lot of security toolbar extensions, but they tend to offer advice rather than enforcement and they don't offer any guarantees. (http://groups.csail.mit.edu/uid/projects/phishing/chi-security-toolbar.pdf has an interesting analysis (albeit slightly dated).) [DAVID] This is in effect an insurance policy, I’m sure there will be organisations willing to step-up. 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]
Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API
On Nov 19, 2009, at 11:35 , Marcin Hanclik wrote: To be clear, IMHO it's absolutely too late for FileReader FileReader is still ED, therefore we may have time, I think. Actually, it's published (as a WD) and has a rather long background history of previous development in the File Upload spec. I think I'm not the only one who would like this particular baby to move forward rather fast. -- Robin Berjon - http://berjon.com/
Re: [WARP] Comments to WARP spec
Hi, On Nov 19, 2009, at 11:38 , Marcin Hanclik wrote: Right, it's one of those things that people would've done differently if we'd had a chance to think about the consequences while the web was being organically grown, but that's water under the bridge now. Keeping the context of having a chance: what about event naming in [1]? Honestly I think that naming is far less important than architecture, and generally a bike shed topic :) -- Robin Berjon - http://berjon.com/
Re: DAP and security (was: Rename File API to FileReader API?)
On Thu, Nov 19, 2009 at 11:54 PM, David Rogers david.rog...@omtp.orgwrote: *From:* rocalla...@gmail.com [mailto:rocalla...@gmail.com] *On Behalf Of *Robert O'Callahan On Thu, Nov 19, 2009 at 10:52 PM, Dominique Hazael-Massieux d...@w3.org wrote: Le jeudi 19 novembre 2009 à 22:39 +1300, Robert O'Callahan a écrit : There are usually no third parties to delegate to. That’s true to a certain extent, but a reason for that might well be that the Web platform hasn’t left enough room for third parties in that realm. One could very well imagine that by allowing a certain level of abstraction in security concerns, we would allow businesses to offer guarantees against data-loss or data-thief if the user install a third-party extension that would check Web sites based on a number of their security aspects. Businesses could offer that today, as a Firefox extension for example. There are actually a lot of security toolbar extensions, but they tend to offer advice rather than enforcement and they don't offer any guarantees. ( http://groups.csail.mit.edu/uid/projects/phishing/chi-security-toolbar.pdfhas an interesting analysis (albeit slightly dated).) [DAVID] This is in effect an insurance policy, I’m sure there will be organisations willing to step-up. But they haven't. 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]
RE: DAP and security (was: Rename File API to FileReader API?)
My comments: -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: 19 November 2009 10:11 To: Marcin Hanclik Cc: David Rogers; Maciej Stachowiak; Dominique Hazael-Massieux; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: DAP and security (was: Rename File API to FileReader API?) On Thu, Nov 19, 2009 at 1:08 AM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Jonas, I think that it all depends on the user or the abstraction that we seem to have about the user. We can take the analogy to the operating system. OS may e.g. not be writable for the user, may have pre-defined active firewalls etc. The user then may not access some sites, may not install any native app etc. The OS or PC is a kind of a toy or a kiosk. Later, the user switches off firewalls, gets admin rights, installs apps that have access to the file system etc. I think that the same principle is being applied to the browser world. Policy is to make it all easier and more comprehensible. 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. The abstraction of the security concerns within a policy may allow delegation of the security to some third parties. I doubt that we'd spend time on implementing a feature that is disabled by default out of security considerations. [DAVID] ...apart from your example below? First of all it'd basically not be worth our time since very few users change default settings. This is magnified by the fact that very few websites would use such a feature (since, again, few users change default settings), so we wouldn't really be improving the web a whole lot. [DAVID] Completely agreed - and the reason why? They don't understand (or care). Allow someone else to provide that for the user. Second, users would inevitably turn the feature on without realizing what security implications it has, meaning that we put a group of users at risk. [DAVID] See above Third, we'll have to spend efforts maintaining the code, even though it benefits only a small number of people. For example if a buffer overflow bug is found we'll have to treat that as as serious of a bug as a overflow in normal on-by-default code. Up to and including engineering efforts to fix the bug, QA efforts to test the fix, release resources to spin a new emergency release, and marketing efforts asking people to upgrade. [DAVID] I would expect that you would do this as a matter of course anyway as part of the security lifecycle. However a side-benefit from your argument would be that policy would therefore help reduce your maintenance? I can draw a couple of real-world analogies. In Thunderbird (the email reader from mozilla), there is support for enabling javascript in emails. This support is turned off by default. However many people turn it on, without realizing that this means that someone that sends you an email can see if you forward this email to anyone, and see what comments you are adding to that email. All they wanted was javascript for some other, much more secure, use case. Additionally, we've having to release *many* security updates specifically to account for the minority of people that turn on javascript. We're currently on security update number 23. If we didn't bother making updates when only people that had turned on javascript were affected, we would have had a fraction as many updates. [DAVID] Strange argument this one, so you're complaining about protecting your users. However, I see where you are coming from, perhaps policy could help ;-) As a result, the next major version of thunderbird is removing the ability to turn on javascript completely. Not even a hidden preference exists. [DAVID] So the problem couldn't be solved without significant effort so it was avoided? This a risk-avoidance strategy, rather than risk-management - it works sometimes but you can't do it for everything. That would be like having agoraphobia to avoid being run over by a bus. Similarly, there was a preference in Firefox 3 that allowed XMLHttpRequest to load resources from any site without any security restrictions. Originally the preference had been added for no particular reason; why not, it's disabled by default. And intended to be enabled only on a per-site basis. However due to how some security architecture works it was possible to set a default behavior that applied to all sites. Eventually developers found this preference (how, i do not know, we never had documentation for it) and word spread through blogs that switching this pref was useful during development and testing [1]. What these people didn't realize is that switching this pref means that any website you go to can read your creditcard numbers and bank statements if you happen to be
Re: [WARP] Call for comments on pre-LC#2 of WARP spec; deadline 18 November
Hi Suresh, Thanks for the feedback; some comments and questions below... On Wed, Nov 18, 2009 at 11:11 PM, Suresh Chitturi schitt...@rim.com wrote: Hello Art, all, Please find below a comment that we would like to submit to towards the following WARP Editor's draft. http://dev.w3.org/2006/waf/widgets-access/ If you recall, I did raise the same comment at the joint F2F meeting between Widgets and DAP WG during TP week, and it was recommended that I submit it formally before the deadline. ISSUE: The access element does not specify the ability to have nested feature elements. This is not really an issue. An issue would be something like The access element does not handle scenarios x, y, and z; therefore, access is broken. RATIONALE: The ability of having nested feature elements under the access element, allows the widget authors to control access to a specific set of (platform) features on a per resource/domain basis, improving the overall access-control and Widgets security model. Can you describe the use cases here? I know for playing around with the blackberry emulator that you guys (RIM) already implement this. Can you give us some insight into the actual use case and rationale? What kinds of features are being tightly controlled by access? PROPOSED RESOLUTION: Specify the use of zero or more feature elements as a child of access element. This will require that the current specification of feature element in Widgets 1.0 is reworded to say that it could be present either as a child of widget element or access element. However, in the spirit of having no impact to the Widgets PC 1.0 specification, an alternate approach would be to add a new element called accessFeature (or similar) that uses the same syntax and semantics of the feature element. An access element thereby, may contain a zero or more accessFeature elements under it to indicate the features that the subject resource/origin/domain in the access element is entitled or has access to during the Widget execution. This, we believe will not only offer a fine-grain access control to specific features on a per-domain basis but can also be benefit implementations to load only those feature modules into the JavaScript context that are declared by the widget authors on a per-domain basis. As WARP defines it's own processing model, so any additions can just be defined there. -- Marcos Caceres http://datadriven.com.au
RE: DAP and security (was: Rename File API to FileReader API?)
From: rocalla...@gmail.com [mailto:rocalla...@gmail.com] On Behalf Of Robert O'Callahan Sent: 19 November 2009 10:58 To: David Rogers Cc: Dominique Hazael-Massieux; Marcin Hanclik; Jonas Sicking; Maciej Stachowiak; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: DAP and security (was: Rename File API to FileReader API?) On Thu, Nov 19, 2009 at 11:54 PM, David Rogers david.rog...@omtp.org wrote: From: rocalla...@gmail.com [mailto:rocalla...@gmail.com] On Behalf Of Robert O'Callahan On Thu, Nov 19, 2009 at 10:52 PM, Dominique Hazael-Massieux d...@w3.org wrote: Le jeudi 19 novembre 2009 à 22:39 +1300, Robert O'Callahan a écrit : There are usually no third parties to delegate to. That’s true to a certain extent, but a reason for that might well be that the Web platform hasn’t left enough room for third parties in that realm. One could very well imagine that by allowing a certain level of abstraction in security concerns, we would allow businesses to offer guarantees against data-loss or data-thief if the user install a third-party extension that would check Web sites based on a number of their security aspects. Businesses could offer that today, as a Firefox extension for example. There are actually a lot of security toolbar extensions, but they tend to offer advice rather than enforcement and they don't offer any guarantees. (http://groups.csail.mit.edu/uid/projects/phishing/chi-security-toolbar.pdf has an interesting analysis (albeit slightly dated).) [DAVID] This is in effect an insurance policy, I’m sure there will be organisations willing to step-up. But they haven't. [DAVID] But they will ;-) – we have to actually create a framework for that to happen first! As someone mentioned before, in the mobile world this already happens. 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]
[widgets] multiple co-authors
In PC the author element is defined as: An author element represents people or an organization attributed with the creation of the widget. with zero or one occurrence [1] I was wondering how the element is used to represent more than one person? The example used shows two names, but there can only be one email address, and the href and email attributes are only defined in terms of the singular (the author). I'm not saying this is necessarily incorrect, but perhaps could do with some explanation. S [1] http://dev.w3.org/2006/waf/widgets/#the-author-element smime.p7s Description: S/MIME cryptographic signature
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: [WARP] Call for comments on pre-LC#2 of WARP spec; deadline 18 November
On Nov 19, 2009, at 12:03 , Marcos Caceres wrote: RATIONALE: The ability of having nested feature elements under the access element, allows the widget authors to control access to a specific set of (platform) features on a per resource/domain basis, improving the overall access-control and Widgets security model. Can you describe the use cases here? I know for playing around with the blackberry emulator that you guys (RIM) already implement this. Can you give us some insight into the actual use case and rationale? What kinds of features are being tightly controlled by access? That would be my question as well. To provide more detail, the idea is that remote resources accessed by widgets (in this case we're talking about iframe and object only I think) follow the normal web security model. I have qualms about having the widget model reach onto the web without very good reason for it. It also makes WARP more complex — I would like to once again strongly reinforce the idea that WARP is intended to be extremely simple, and a stop-gap specification until DAP produces something appropriately powerful. The Feature Vault is guarded by an oversized Pistol Shrimp [0] with a bad temper. She will require a very strong use case for this sort of additional feature. [0] http://www.youtube.com/watch?v=eKPrGxB1Kzc -- Robin Berjon - http://berjon.com/
RE: [WARP] Comments to WARP spec
Hi Robin, It seems in I am a naming purist :) 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: marcin.hanc...@access-company.com -Original Message- From: Robin Berjon [mailto:ro...@berjon.com] Sent: Thursday, November 19, 2009 11:58 AM To: Marcin Hanclik Cc: WebApps WG Subject: Re: [WARP] Comments to WARP spec Hi, On Nov 19, 2009, at 11:38 , Marcin Hanclik wrote: Right, it's one of those things that people would've done differently if we'd had a chance to think about the consequences while the web was being organically grown, but that's water under the bridge now. Keeping the context of having a chance: what about event naming in [1]? Honestly I think that naming is far less important than architecture, and generally a bike shed topic :) -- Robin Berjon - http://berjon.com/ 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: [widgets] multiple co-authors
On Thu, Nov 19, 2009 at 11:10 AM, Scott Wilson scott.bradley.wil...@gmail.com wrote: In PC the author element is defined as: An author element represents people or an organization attributed with the creation of the widget. with zero or one occurrence [1] I was wondering how the element is used to represent more than one person? The example used shows two names, but there can only be one email address, and the href and email attributes are only defined in terms of the singular (the author). I see what you mean, but I guess something like: widget ... author email=project_n...@some.org href=http://some.org/project_name/developers;Simon and Garfunkel/author /widget -- Marcos Caceres http://datadriven.com.au
Re: [public-webapps] Comment on Widget URI (7)
Dear Larry, thank you for your comments. On Oct 10, 2009, at 19:44 , Larry Masinter wrote: 7) ** EDITORIAL TITLE ** Widgets 1.0: Widget URIs the 1.0 might imply some kind of versioning, but there is no versioning of URI schemes. Suggestion: retitle Widget URIs I have provisionally made this change. I agree with Marcos that it would be good to do so throughout the widget family of specifications, especially since there is no reason why versions of its various components need to evolve in synchronised fashion — one could use P+C 4.2 with WARP 2.7. Recommendation to the WG: apply the same change throughout. -- 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/
[widgets] The people say NO to 1.0, was Re: [public-webapps] Comment on Widget URI (7)
On Thu, Nov 19, 2009 at 12:07 PM, Robin Berjon ro...@berjon.com wrote: Dear Larry, thank you for your comments. On Oct 10, 2009, at 19:44 , Larry Masinter wrote: 7) ** EDITORIAL TITLE ** Widgets 1.0: Widget URIs the 1.0 might imply some kind of versioning, but there is no versioning of URI schemes. Suggestion: retitle Widget URIs I have provisionally made this change. I agree with Marcos that it would be good to do so throughout the widget family of specifications, especially since there is no reason why versions of its various components need to evolve in synchronised fashion — one could use P+C 4.2 with WARP 2.7. Recommendation to the WG: apply the same change throughout. I strongly agree (and have been pushing this for a long time)... Lets drop the 1.0 everywhere in the widget family of specs. -- Marcos Caceres http://datadriven.com.au
Re: [public-webapps] Comment on Widget URI (6)
Dear Larry, thank you for your comments. On Oct 10, 2009, at 19:44 , Larry Masinter wrote: 6) ** EDITORIAL RE FRAGMENT ** Note that assigning semantics or interpretation to the query or fragment components is outside the scope of this specification. The ways in which they are used depends on the content types that they are applied to, or what executable script decides to do with them. The wording might be taken to mean that a URI scheme registration normally *does* assign semantics or interpretation to the fragment components. Suggestion: drop this note. Agreed, the note has been removed. -- Robin Berjon - http://berjon.com/
Re: [public-webapps] Comment on Widget URI (5)
Dear Larry, thank you for your comments. On Oct 10, 2009, at 19:44 , Larry Masinter wrote: 5) ** EDITORIAL USE OF URI FOR IRI ** Throughout this specification, wherever the term URI [URI] is used, it can be replaced interchangeably with the term IRI [RFC3987]. All widget URIs are IRIs, but the term URI is more common and was therefore preferred for readability. Seriously, do we need a W3C Guideline or Finding to cover DO NOT REDEFINE TERMS? There's glory for you! (see http://www.sabian.org/Alice/lgchap06.htm ). Suggestion: Use IRI since that's what is meant. It seems that we seriously need a finding explaining to specification authors that creating new terms where existing widely used ones can be made to work is a bad idea that will most likely fail. Most technically savvy people I have ever met don't know what an IRI is, and of the happy few who do I've seen many a native English speaker stumble while trying to speak of them orally. All that is needed for interoperability is for implementers to know that widget URIs are IRIs, and the document addresses that. Importing the IRI term into our space would have as sole further benefit to import the confusion and tongue-twisting that surround it. I recommend that while IRIs are being reinvestigated at the IETF, the naming issue be addressed. -- Robin Berjon - http://berjon.com/
Re: [public-webapps] Comment on Widget URI (4)
Dear Larry, thank you for your comments. On Oct 10, 2009, at 19:44 , Larry Masinter wrote: 4) ** EDITORIAL RE OTHER SCHEME ** In fact, it is possible that both this scheme and another defined to access Zip archive content would be used jointly, with little or no overlap in functionality. Without any other context, this is incomprehensible. Suggestion: remove sentence. Fair enough. The entire section has been removed. -- Robin Berjon - http://berjon.com/
Re: [public-webapps] Comment on Widget URI (8)
Dear Larry, thank you for your comments. On Oct 10, 2009, at 19:44 , Larry Masinter wrote: 8) ** EDITORIAL DOCUMENT ORGANIZATION ** Are A, B, C and D appendices? Normative? Suggestion: remove A (Usage as Origin) either remove B (Requirements) or edit it to be comprehensible to someone not familiar with the widgets specification, make C (Acknowledgements) and D (References) into normal document sections. As per the conformance section, sections that are not normative are marked as such — and that has been done here. Usage as Origin is the topic of another comment, and will be discussed separately. Requirements has been removed, it will be integrated in the the Widgets Requirements document. As for Acknowledgements and References, they are indeed appendices and I see no reason for them not to remain as such. -- Robin Berjon - http://berjon.com/
Re: [public-webapps] Comment on Widget URI (9)
Dear Larry, thank you for your comments. On Oct 10, 2009, at 19:44 , Larry Masinter wrote: 9) ** ORIGIN CALCULATION ** A: Usage as Origin This information applies to the notion of origin calculation which is itself incomplete, and introduces an unnecessary normative dependency. Suggestion: Drop this section (if needed for widgets, put it somewhere else) Can you please explain to us in what ways it is incomplete? It is unclear to me. This section does not introduce any normative dependencies, it mentions HTML5 for instance to give an informative example of when such calculation may be used, but does not in any way require support for it. -- Robin Berjon - http://berjon.com/
RE: [widgets] The people say NO to 1.0, was Re: [public-webapps] Comment on Widget URI (7)
Hi, Versioning gets revisited :) I agree to the change, since explicit versioning has been deprecated by many. We switch to spec soup with implicit versioning. 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: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcos Caceres Sent: Thursday, November 19, 2009 1:12 PM To: Robin Berjon Cc: Larry Masinter; public-webapps@w3.org Subject: [widgets] The people say NO to 1.0, was Re: [public-webapps] Comment on Widget URI (7) On Thu, Nov 19, 2009 at 12:07 PM, Robin Berjon ro...@berjon.com wrote: Dear Larry, thank you for your comments. On Oct 10, 2009, at 19:44 , Larry Masinter wrote: 7) ** EDITORIAL TITLE ** Widgets 1.0: Widget URIs the 1.0 might imply some kind of versioning, but there is no versioning of URI schemes. Suggestion: retitle Widget URIs I have provisionally made this change. I agree with Marcos that it would be good to do so throughout the widget family of specifications, especially since there is no reason why versions of its various components need to evolve in synchronised fashion — one could use P+C 4.2 with WARP 2.7. Recommendation to the WG: apply the same change throughout. I strongly agree (and have been pushing this for a long time)... Lets drop the 1.0 everywhere in the widget family of specs. -- Marcos Caceres http://datadriven.com.au 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 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: [public-webapps] Comment on Widget URI (3)
Dear Larry, thank you for your comments. On Oct 10, 2009, at 19:44 , Larry Masinter wrote: 3) ** Reuse URI schemes ** http://www.w3.org/TR/webarch/#URI-scheme includes Good practice: Reuse URI schemes A specification SHOULD reuse an existing URI scheme (rather than create a new one) when it provides the desired properties of identifiers and their relation to resources. The WebApps WG is well familiar with webarch. In this instance, I would like to emphasise when it provides the desired properties of identifiers and their relation to resources. The WebApps WG has discussed this topic with luminaries and experts in both the TAG and the community at large, and to this date, while we have learnt about many obscure and sometimes poorly defined URI schemes, none has provided us with a solution. We've long reached the point where every drive-by you should use this! argument is just a rehash of something we've seen before. Having done due diligence, I feel confident that we haven't found an existing URI scheme that, as per AWWW, provides the desired properties of identifiers and their relation to resources. The draft suggests there are many other schemes (with merit) already proposed, but that these existing efforts, rather than identify packaged resources from the outside, widget URIs identify them only on the inside of a package, irrespective of that package's own location., but this seems to indicate that the requirements for widget URIs are weaker, not stronger. Actually that wasn't the intended meaning, but since it can be construed thusly (and since you made another comment indicating that it was hard to understand) I have removed this section (it was just meant to be informative anyway). Suggestion: Supply use cases where reuse of existing schemes (including thismessage:/) do not provide the desired properties of identifiers and their relation to resources. I do not believe that it would be a useful attribution of resources from the WG to document this in the specification. The process of looking at alternatives has been conducted in public and under strong scrutiny. If someone wishes to document this process, they are welcome to do so, and all the information is available. It would, however, do nothing to lead the web to its full potential. To further the point, I would like to underline the fact that you suggested using thismessage:/ before, and that the WG provided as thorough a debunking of that idea as can be made given such an underspecified scheme, to which you didn't respond: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0972.html Alternate Suggestion: Withdraw registration of widget: and reference existing scheme. That would leave us with no way of addressing widget resources. Having just now implemented a widget runtime, I don't see how we could have interoperability without them. Alternate Suggestion: Provide guidelines so that widget: can be used for other applications that need a way of referencing components within ZIP packages; rename widget: to use a scheme name that is appropriate for this broader application. Anyone who uses the widget packaging can reuse the URI. Extending widget URIs to apply to all Zip archives would be inappropriate the properties of relating identifiers to resources would have to change (see AWWW and Widget P+C for more details). We could also make them reusable for elephantine manicure, but likewise those resources are obtained in entirely different ways. -- Robin Berjon - http://berjon.com/
Re: Constrained specification of Icon element
Hi Ola, Apologies for the delay in replying. I, and others, agree with your presented use cases and have changed the spec to match. Please see comments below. Can you please get back to us ASAP confirming that you agree with the changes. We intend to republish this specification next week, but we must have confirmation from you that you are satisfied with the changes. 2009/11/10 Ola Andersson ola.anders...@ericsson.com: Hi, I understand it might be too late to modify the spec now but I still think the spec isn't clear with regards to icon size and should be clarified, maybe in some future version at least. I'm also not fully convinced your description (bottom of this mail) about clipping an SVG icon is correct. This is because the Widget PC spec states for the icon width/height attributes: The width is only applicable to graphic formats that have no intrinsic width or height (e.g., SVG). However, SVG do have intrinsic size when SVG width/height are specified [1] (except in the case when widht/height are %-values) so the widget spec might want to clarify this and your example below should, according to the icon definition, ignore the icon width/height and render the icon using the intrinsic 1000x1000px size. To me this behavior is not what you want, rather I propose the following changes to the icon size: 1. For the widget icon element's width and height attributes the spec should state that the width and height attribute values are to be seen as a guide to the UA in order for the widget provider to indicate the preferred size of the icon. The UA is allowed to ignore the width/height in order to change the size of the icon, exampels of when this might occur is if a UA is to display icons from different providers in a single GUI (and thus prefer to display them all at the same size). Or if a UA needs to enlarge icons in a GUI due to accessability requirements (vision impaired users...) Agreed. 2. icon width/height attributes should apply to all graphic formats, not just those without intrinsic size. Having this would make it possible to reuse the same icon resource for multiple resolutions. The following example (almost from the widget spec): Agreed. Removed restriction on usage of the width and height attribute (applies to all graphic formats). Ok, the spec now reads: [ Width/Height A numeric attribute greater than 0 that represents, in CSS pixels [CSS21], the author's preferred width/height for the icon. A user agent may ignore this value when changing the height icon to fit a rendering context or for accessibility reasons. ] icon src=icons/big.png/ icon src=icons/medium.png/ icon src=icons/small.png/ could then be rewritten as: icon src=icons/big.png/ icon src=icons/big.png width=128 height=128/ icon src=icons/big.png width=64 height=64/ Which would save the author the work of creating different pngs, and save bandwith. All UAs have features for raster scaling so no issue with that. I think in the above cases the author would just declare (and the UA would just use the icon in all contexts): icon src=icons/big.png/ A more complicated example would be: icon src=icons/big.png/ icon src=icons/medium.png/ icon src=icons/big.png width=16 height=16 / However, I do not see a need to add such complexity to the spec. In other words, though I have changed the definition of the icon width and height, I am reluctant to change the parsing model to allow the same icon to be declared more than once (as above). Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
RE: Constrained specification of Icon element
Excellent! I'm happy with this. cheers /o Hi Ola, Apologies for the delay in replying. I, and others, agree with your presented use cases and have changed the spec to match. Please see comments below. Can you please get back to us ASAP confirming that you agree with the changes. We intend to republish this specification next week, but we must have confirmation from you that you are satisfied with the changes. 2009/11/10 Ola Andersson ola.anders...@ericsson.com: Hi, I understand it might be too late to modify the spec now but I still think the spec isn't clear with regards to icon size and should be clarified, maybe in some future version at least. I'm also not fully convinced your description (bottom of this mail) about clipping an SVG icon is correct. This is because the Widget PC spec states for the icon width/height attributes: The width is only applicable to graphic formats that have no intrinsic width or height (e.g., SVG). However, SVG do have intrinsic size when SVG width/height are specified [1] (except in the case when widht/height are %-values) so the widget spec might want to clarify this and your example below should, according to the icon definition, ignore the icon width/height and render the icon using the intrinsic 1000x1000px size. To me this behavior is not what you want, rather I propose the following changes to the icon size: 1. For the widget icon element's width and height attributes the spec should state that the width and height attribute values are to be seen as a guide to the UA in order for the widget provider to indicate the preferred size of the icon. The UA is allowed to ignore the width/height in order to change the size of the icon, exampels of when this might occur is if a UA is to display icons from different providers in a single GUI (and thus prefer to display them all at the same size). Or if a UA needs to enlarge icons in a GUI due to accessability requirements (vision impaired users...) Agreed. 2. icon width/height attributes should apply to all graphic formats, not just those without intrinsic size. Having this would make it possible to reuse the same icon resource for multiple resolutions. The following example (almost from the widget spec): Agreed. Removed restriction on usage of the width and height attribute (applies to all graphic formats). Ok, the spec now reads: [ Width/Height A numeric attribute greater than 0 that represents, in CSS pixels [CSS21], the author's preferred width/height for the icon. A user agent may ignore this value when changing the height icon to fit a rendering context or for accessibility reasons. ] icon src=icons/big.png/ icon src=icons/medium.png/ icon src=icons/small.png/ could then be rewritten as: icon src=icons/big.png/ icon src=icons/big.png width=128 height=128/ icon src=icons/big.png width=64 height=64/ Which would save the author the work of creating different pngs, and save bandwith. All UAs have features for raster scaling so no issue with that. I think in the above cases the author would just declare (and the UA would just use the icon in all contexts): icon src=icons/big.png/ A more complicated example would be: icon src=icons/big.png/ icon src=icons/medium.png/ icon src=icons/big.png width=16 height=16 / However, I do not see a need to add such complexity to the spec. In other words, though I have changed the definition of the icon width and height, I am reluctant to change the parsing model to allow the same icon to be declared more than once (as above). Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Interface published
Some comments: http://dabase.com/blog/Widget_mapping_quirks/ Do I need to send them inline? I do prefer the Web since I can keep it better upto date. Kind regards,
Re: [widgets] Interface published
On Nov 19, 2009, at 14:37 , Kai Hendry wrote: Some comments: http://dabase.com/blog/Widget_mapping_quirks/ Do I need to send them inline? I do prefer the Web since I can keep it better upto date. Right, but the problem is that you can change them after we've formally addressed them, which is a bit problematic. If you want to keep them on the web, could you make a stable dated version available? -- Robin Berjon - http://berjon.com/
Re: [Widgets] LCWD#3 comments (2)
Hi Marcin, All, Marcin has identified an issue with the spec that requires input from people that know the MIME. Please see the changes I have proposed to the spec below. 2009/11/18 Marcin Hanclik marcin.hanc...@access-company.com: 5.3 (grammar: I hope these are final corrections L ) [*folder-name] Should be *folder-name Since the current form makes it optional twice Right. Fixed. Zip-rel-path file-name/ could be file-name / (note the space before ‘/’) Noted and fixed :) safe-char I suggest putting the ‘/’ sign at the end of each line instead of at the beginning Done. 7.4 Media type attribute It is unclear why the valid-MIME-type production requires “parameter”. “parameter” could specify the charset and that could conflict with the @encoding attribute of the content element. This is true and a really good point. It was actually the reason I included the parameter part (so you didn't need the encoding attribute). And also because parameters could appear, in which case I didn't want those strings to be treated as invalid - and hence make the whole widget invalid! However, given that I forgot to specify the behavior for the situation you describe, we should either: 1. kill the parameter bit - using the ABNF you suggest below. 2. say that it is allowed, but left up to the implementation. 3. say that parameter is allowed, but if it includes an encoding parameter, then @encoding beats it (or the other way around). I don't particularly like 1, because I can imagine use cases where one could automatically convert a web page into a widget and retain the Content-Type: header for a resource without needing to strip out the parameters. Having the parameters would automatically make the content type invalid and, hence, ignored by the UA, which I don't think is right. I share your concerns about 2, because it is ambiguous. I guess 3 seems like the right thing to do. I think @encoding should win - but I don't have a technically valid reason why... maybe just because it could serve as an explicit override. Here is a proposed text, to go into Step 7 as part of the content element parsing rule. I've added it to the latest draft. Please take the time to review it. [ [if it's ] A content element: ... 7. If the encoding attribute is used, then let content-encoding be the result of applying the rule for getting a single attribute value to the value of the encoding attribute. If the character encoding represented by the value of content-encoding is supported by the user agent, then let the start file encoding be the value of content-encoding. If content-encoding is an empty string or unsupported by the user agent, then a user agent must ignore the encoding attribute. 8. If the type attribute is used, then let content-type be the result of applying the rule for getting a single attribute value to the value of the type attribute. If the value of content-type is a media type supported by the user agent, then let the start file content-type be the value of content type. If value of content-type is invalid or unsupported by the user agent, then a user agent must treat the widget package as an invalid widget package. 9. If the start file encoding was set in step 7 of this algorithm as a result of processing a valid and supported value for the content element's encoding attribute, then skip this step in this algorithm. Otherwise, if the value of content-type is a media type supported by the user agent and if content-type contains one or more [MIME] parameter components whose purpose is to declare the character encoding of the start file (e.g., the value text/html;charset=Windows-1252, where charset is a parameter component whose purpose is to declare the character encoding of the start file), then let start file encoding be the value of the last supported parameter components whose purpose is to declare the character encoding of the start file. In the following example, the user agent would set the start file encoding to ISO-8859-1 and would ignore the charset parameter used in the type attribute. widget xmlns=http://www.w3.org/ns/widgets; content src = start.php type = text/html;charset=Windows-1252 encoding = ISO-8859-1 / /widget In the following example the user agent would set the start file encoding to Windows-1252, if the user agent supports that encoding. widget xmlns=http://www.w3.org/ns/widgets; content src = start.php type = text/html;charset=Windows-1252/ /widget ] Also the valid-MIME-type could be replaced with the following from RFC4288 type-name = reg-name subtype-name = reg-name reg-name = 1*127reg-name-chars reg-name-chars = ALPHA / DIGIT / ! / # / $ / / . / + / - / ^ / _ BTW: I understand that W3CMediaReg uses RFC2046 (actually RFC2048), but RFC4288 (also BCP13) obsoletes RFC2048. So it gets blurred to me. I don't know which
Re: [public-webapps] Comment on Widget URI (2)
Dear Larry, thank you for your comments. On Oct 10, 2009, at 19:44 , Larry Masinter wrote: 2) ** WELL-DEFINED MAPPING TO FILES ** Section 4.4 Step 2 makes normative reference: http://www.w3.org/TR/widgets/#rule-for-finding-a-file-within-a-widget- The algorithm there seems to be lacking a clear definition of matches which deals reasonably with the issues surrounding matching and equivalence for Unicode strings, or the handling of character sets in IRIs which are not represented in UTF8. Suggestion (Editorial): Move the definition of the mapping algorithm into the URI scheme registration document so that its definition can be reviewed for completeness. Suggestion (Technical): Define exactly and precisely what match means and make it clear what the appropriate response or error conditions are if there is more than one file that matches. This comment concerns P+C, and I'm unsure about what change you are requesting where. Could you please provide an example of an issue in the current setup and explain how you would like to see it addressed? -- Robin Berjon - http://berjon.com/
Re: [public-webapps] Comment on Widget URI (1)
Dear Larry, thank you for your comments. On Oct 10, 2009, at 19:44 , Larry Masinter wrote: 1) ** WELL DEFINED QUERY AND AUTHORITY ** http://www.w3.org/TR/webarch/#URI-scheme points to RFC 2617, which has been replaced by RFC 4395. I think WebArch should be updated to recommend that W3C recommendations must use permanent schemes and not provisional ones. Does this apply in any way to us? RFC 4395 requires that permanent scheme definitions be Well-defined. Leaving in syntactic components and declaring them out of scope is leaving them undefined. The only parts the semantics of which were flagged as outside the scope were fragment and query — this section has been removed. Suggestion: Remove 'authority' from the syntax, and any sections that refer to them; disallow query components Alternate Suggestion: define the meaning of authority and query components. Neither the authority nor the query components are undefined or out of scope. Authority is syntactically defined, and is clearly specified as being devoid of semantics (opaque). Stating that this makes the scheme not well-defined is untrue — it is like saying that XML Namespaces aren't well-defined because they are equally opaque. The query component is equally defined as to its syntax, and its meaning is left to the processor (typically, a script inside an HTML page, but for other resources it could be different). I can't see how this differs from the http scheme. -- Robin Berjon - http://berjon.com/
Re: [public-webapps] Comments on Widget URI (General)
Hi Larry, the WebApps WG deeply thank you for you comments on the widgets URI last call. We decided to split them over several emails that have been posted to the list with proposed responses to them. We would be grateful if you could indicate whether you are satisfied with each resolution within two weeks. I elected not to copy them to the TAG list since your original copy was Bcc, since it's a WebApps LC to which the TAG can contributed, and since at least several of these would be noise there. Feel free to escalate the discussion there if you feel it may be needed though. Thanks again! -- Robin Berjon - http://berjon.com/
Re: DAP and security (was: Rename File API to FileReader API?)
On Thu, Nov 19, 2009 at 2:49 AM, David Rogers david.rog...@omtp.org wrote: -Original Message- From: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org] On Behalf Of Adam Barth Sent: 19 November 2009 07:42 To: Marcin Hanclik Cc: Maciej Stachowiak; Dominique Hazael-Massieux; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: DAP and security (was: Rename File API to FileReader API?) I'm skeptical that this approach will lead to a secure API for file access. Abstracting the problem doesn't make the security challenges any easier. The reason the HTML file upload control has been such a successful secure API for reading files is because the security issues are specifically *not* abstracted. The entire API is designed around the security considerations and eliciting user consent in a easy-to-understand way. I suspect we'll need a similarly clever API design to address the security challenges of letting web content write to the user's file system. [DAVID] I would hope that we can come up with some clever API design in terms of safe logic. However, this does not solve the whole problem, at some point you need to make a decision / judgement call. Really? What decision / judgement call do we need to make for the file upload control? What decision / judgement call do we need to make for the video tag? What the policy advocates are proposing is to advance the whole discipline here - let's improve this by adding strength in depth and allow the user to defer their decision to someone who they trust, who is willing to take the decision for them. You're not listening to the folks on this thread who are telling you that this model has been tried and failed. At best this is a science experiment. Writing web standards is a terrible way to run a science project. Adam
Re: DAP and security (was: Rename File API to FileReader API?)
David, you're not listening. On Thu, Nov 19, 2009 at 3:02 AM, David Rogers david.rog...@omtp.org wrote: -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: 19 November 2009 10:11 To: Marcin Hanclik Cc: David Rogers; Maciej Stachowiak; Dominique Hazael-Massieux; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: DAP and security (was: Rename File API to FileReader API?) Third, we'll have to spend efforts maintaining the code, even though it benefits only a small number of people. For example if a buffer overflow bug is found we'll have to treat that as as serious of a bug as a overflow in normal on-by-default code. Up to and including engineering efforts to fix the bug, QA efforts to test the fix, release resources to spin a new emergency release, and marketing efforts asking people to upgrade. [DAVID] I would expect that you would do this as a matter of course anyway as part of the security lifecycle. However a side-benefit from your argument would be that policy would therefore help reduce your maintenance? Jonas just said that they had a policy mechanism and that's what *caused* the problem in the first place. He solved the problem by removing the policy lever in Thunderbird that let users shoot themselves in the foot. Adam
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
[widgets] Draft Minutes for 19 November 2009 Voice Conference
The draft minutes from the 19 November Widgets voice conference are available at the following and copied below: http://www.w3.org/2009/11/19-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before 3 December 2009 (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Widgets Voice Conf 19 Nov 2009 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/0763.html See also: [3]IRC log [3] http://www.w3.org/2009/11/19-wam-irc Attendees Present Art, Arve, Robin, David, Marcin, Steven, Marcos, Frederick, Suresh, Benoit, Doug, Chitturi Regrets Chair Art Scribe Art Contents * [4]Topics 1. [5]Agenda review 2. [6]Announcements: 3. [7]PC spec: LCWD#3 comment period ends 19 November 4. [8]PC spec: CfC to publish CR#2 5. [9]WARP spec: Patent exclusions by Apple ; PAG Next steps .. 6. [10]WARP spec: comments 7. [11]URI Scheme spec 8. [12]AOB * [13]Summary of Action Items _ scribe Scribe: Art scribe ScribeNick: ArtB Date: 19 November 2009 drogersuk I can't hear anything either arve neither do I drogersuk that's better arve now, I'm at least hearing ArtB talk Steven Doug and I keep ending up on the same call, but no one else marcin Marcos, :) Marcos Marcin, quickly check out the email I just sent you Steven, Doug - we're all here on 9231 Steven Doug and steven on a separate call again Agenda review AB: draft agenda is [14]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/07 63.html ... any change requests on the agenda? [14] http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/0763.html marcin Marcos, long email :). I think option 3 should win, but I need to check what parameters we may have. I will respond shortly. AB: any change requests on agenda? [ None ] MC: can we add Marcin's regarding PC? AB: yes Announcements: AB: No Voice Conf on 26 November; next one will be 3 December ... Reminder: last day to request publications for 2009 is Friday 18 December ... WebApps has been asked to submit comments re OASIS' Packaging spec for ODF for Office Apps spec; see ( [15]http://www.w3.org/mid/4b016692.2090...@w3.org ) for details ... Doug, anything to add? [15] http://www.w3.org/mid/4b016692.2090...@w3.org DS: they are using ZIP too AB: if there are comments, send them to the OASIS list DS: if need clarification on list, let me know AB: any other annoucements? [ None ] PC spec: LCWD#3 comment period ends 19 November DS: I am on the ODF Tech Committee ... my main reason is SVG ... but I can be a pipe for other ODF comments SP: I will also join the ODF TC but not as a W3C rep AB: November 19 is the last day to submit comments re PC LC#3 ( [16]http://www.w3.org/TR/2009/WD-widgets-20091029/ ). ... the comment tracking document is ( [17]http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets-2 0091029/ ). Marcos, that document must be up to date before the Director's call. ... the Director's call is tentatively set for Nov 23 ... Marcos, which comments still lack a WG response? My count is 5 total: 2 from Marcin ( [18]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/07 11.html and [19]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/07 50.html ), 1 from Ericsson ( [20]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/05 67.html ), 1 from Scott Wilson ( [21]http://lists.w3.org/Archives/Public/public-w [16] http://www.w3.org/TR/2009/WD-widgets-20091029/ [17] http://www.w3.org/2006/02/lc-comments-tracker/42538/WD- widgets-20091029/ [18] http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/0711.html [19] http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/0750.html [20] http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/0567.html [21] http://lists.w3.org/Archives/Public/public-w ebapps/2009OctDec/0808.html ) and 1 from Benoit ( [22]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/04 69.html ) . [22] http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/0469.html AB: let's make sure we are all on the same page re these comments ... what's the plan to populate the CT doc? MC: I'll start tomorrow ... Benoit's is open scribe ACTION: benoit close the loop on your PC comment [recorded in
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
[WebSimpleDB] Flatting APIs to simplify primary cases
We're busy creating experimental implementations of WebSimpleDB to both understand what it takes to implement and also to see what the developer experience looks like. As we started to write application code against the API (particularly the async one) the first thing that popped is the fact that you need two levels of nested callbacks for everything. While the current factoring of the API makes sense on the design board, it's kind of noisy in app code. For example: // assume you already have a database opened in dbReq var html = ul; var storeReq = new ObjectStoreRequest(dbReq.database); storeReq.success = function() { var cursorReq = new CursorRequest(storeReq.store); cursorReq.callback = function(key, cursor, value) { html += li + value.Name + /li; } cursorReq.onsuccess = function(r) { document.getElementById(output).innerHTML = html + /ul; } cursorReq.open(); } storeReq.open(); One option that we would like to explore is to flatten the API, so most common methods are straight in the database class. This trades off some of the factoring in favor of usability for common cases using the async API. The change would span a couple of aspects: 1. Move operations from object store interface and the index interface into the Database interface. Accessing indexes and stores through specialized objects is problematic for the following reasons: - It's always the case that we need to consider when objects are invalidated because something changes from underneath them, for example a schema change. So for example, if there is an explicit store object, then when the store is dropped we need to consider what is valid/invalid and what its failure points and modes are. By not having a standalone store object, we significantly reduce the gotchas to consider. - From a usability perspective, it's simpler to work with a store in a single step, rather than having to open it first and then work with it (see patterns below with a single request and one DBRequest object). - With no two-step access pattern, the API has one less level of asynchronicity, as effectively the table lookup + operation are atomic within the store. This also consolidates all operations with an async variant in a single interface (the Database), which is a great simplification for discoverability. var html = ul; var request = asyncDb.forEachStoreObject(contacts, function(row) { html += li + row.Name + /li; }); request.onsuccess = function(r) { document.getElementById(output).innerHTML = html + /ul; } In moving the operations, it's probably best to rename them to something more descriptive, so we can have for example 'getFromStore(storeName, key)' and 'getFromIndex(storeName, indexName, key)'. This also helps in that 'delete' won't collide with the Javascript keyword. Note that the store and index interfaces are still around to provide metadata, but at this point they behave as simple read-only snapshots. 2. Generalize the use of DBRequest, add a 'result' member to it and have all asynchronous operations be initiated from a DatabaseAsync interface. As a result of the previous changes, all operations that have an async counterpart should now exist on the DatabaseAsync interface. Rather than having multiple types of requests depending on the target object, it is possible to have operations on a DatabaseAsync interface that provide a uniform invocation and handling programming pattern. This gives a nice pattern for understanding how a sync API maps to an async API. So for example: var record = db.getFromStore(store, key); // use record... Becomes: var request = asyncDb.getFromStore(store, key); request.onsuccess = function(req) { var record = req.result; // use record... }; We could include more data in DBRequest or DBRequest.result as needed if in some cases a method produces more than just a simple result. Further specializatons of DBRequest (subtypes) are still possible in the future if we need to introduce special cases for specific operations. Similarly, we would have something like asyncDb.forEachStoreObject() that queues a task to call a callback for each element in a store/index, potentially within a range if specified. The pattern scales well to all the other APIs present in db/store/index today. If this seems like a good idea to folks, we'd be happy to write up a more complete version that articulates the tweaks across all the WebSimpleDB APIs to make this happen. Regards, -pablo
Re: [widgets] multiple co-authors
Hi Scott, Artb would like to include this comment as part of our Disposition of Comments for PC. We intend to republish next week, so I need an approval that you are satisfied with the response I sent you ASAP (hopefully you are:)). Kind regards, Marcos On Thu, Nov 19, 2009 at 11:58 AM, Marcos Caceres marc...@opera.com wrote: On Thu, Nov 19, 2009 at 11:10 AM, Scott Wilson scott.bradley.wil...@gmail.com wrote: In PC the author element is defined as: An author element represents people or an organization attributed with the creation of the widget. with zero or one occurrence [1] I was wondering how the element is used to represent more than one person? The example used shows two names, but there can only be one email address, and the href and email attributes are only defined in terms of the singular (the author). I see what you mean, but I guess something like: widget ... author email=project_n...@some.org href=http://some.org/project_name/developers;Simon and Garfunkel/author /widget -- Marcos Caceres http://datadriven.com.au -- Marcos Caceres http://datadriven.com.au
Microsoft pre-LCWD feedback on WebSocket API
Apologies for only sending this at the deadline. I have been collecting feedback from a number of different groups at Microsoft who have been reviewing the WebSockets API spec and only had chance to collate it today. Feedback on Web Sockets API (draft dated 29 October 2009) 1) In the WebSocket constructor, we think it would make sense to limit the optional protocol string to a set of characters that is easier to secure. The UI never surfaces this string and having something that doesn't require processing the full set of strings into UTF-8 shouldn't be a significant restriction. We also think that specifying length constraints would be useful. For example, stipulating the minimum length that conforming implementations must be able to handle. One suggestion was to re-use the same criteria as a valid scheme name as defined in section 3.1 of RFC 3986. 2) The second comment about the protocol string is editorial. There was quite a lot of confusion about what the protocol string is used for and whether a central registry would be needed for well-known protocol strings. I don't believe this is intended or necessary but this suggests that the language could be clearer. Perhaps an informative section describing the expected use of the protocol string might be included. 3) The spec uses many terms that the HTML5 spec defines. As far as I can tell, there isn't a definitive list of these. The 2.1 dependencies section notes that many concepts come from HTML5 but not saying which ones seems insufficient for spec moving to Last Call. Most of the people who looked at this spec had never looked at HTML5 before and their feedback was simply that many terms were undefined. 4) In step 2 of the UA steps for the WebSocket() constructor, the spec calls for an exception to be thrown if the user agent chooses to block a well-known port. We think that web developers will often miss this case because it will be hard to test the error case and may be an unusual failure. We propose that the UA signal this condition in the same way as failing to connect to a service which will be much more common and more likely to be handled by web developers. 5) It is not clear precisely where the 'fail the Web Socket connection algorithm' is defined. 6) The send() method can both throw an exception in the CONNECTING state or return an 'error' flag if in the CLOSED state. APIs that both have return values and also throw exceptions commonly cause coding errors by developers using them. For example, here web developers may fail to deal with the CONNECTING state because on their test service they get an almost immediate connection but once they deploy hitting this case becomes much more common. We recommend choosing between exceptions or return values but not both. 7) It is not clear exactly how to implement the bufferedAmount property and be interoperable. Where is the queue of bytes not yet sent? Is this at the application layer, in the networking stack, on the network card, or somewhere else? We propose removing the bufferedAmount property. I think we will have some other feedback more related to the wire protocol than the API although changes to the protocol could potentially impact the API. I'm not sure how the working group plans to handle this interaction between the API draft and discussions elsewhere about the protocol (I understand there is a proposal to deal with the protocol in an IETF working group?). Cheers, Adrian. -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: Wednesday, November 04, 2009 5:46 AM To: public-webapps Subject: Seeking pre-LCWD comments for: Server-sent Events, Web {Database, Sockets, Storage Workers}; deadline 19 November As noted on 23 October [1], the following HTML5 APIs are ready or very close to being ready for Last Call Working Draft (LC): 1. Server-Sent Events http://dev.w3.org/html5/eventsource/ 2. Web Database http://dev.w3.org/html5/webdatabase/ 3. Web Sockets API http://dev.w3.org/html5/websockets/ 4. Web Storage http://dev.w3.org/html5/webstorage/ 5. Web Workers http://dev.w3.org/html5/workers/ Please submit comments about these specs by 19 November. Note the Process Document states the following regarding the significance/meaning of LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report
Re: [widgets] multiple co-authors
On Thu, Nov 19, 2009 at 8:53 PM, Marcos Caceres marc...@opera.com wrote: Hi Scott, Artb would like to include this comment as part of our Disposition of Comments for PC. We intend to republish next week, so I need an approval that you are satisfied with the response I sent you ASAP (hopefully you are:)). I modified the example in the spec. It's now: widget xmlns=http://www.w3.org/ns/widgets; nameCafé Finder/name author href = http://dahut.example.org/developers/; email = questi...@example.org Joey and Princesa Bacalhau /author /widget -- Marcos Caceres http://datadriven.com.au
Moving Window and stuff out of HTML5
Dear WGs, (Ccing public-weba...@w3.org.) They could be split out into a separate specification or specifications, and HTML5 would probably not even need to reference them. I agree that it's good design in principle to split the core platform APIs (window, navigator, etc) into separate specs. However, it is also much harder than it may seem. SVG 1.2 Tiny has some of this stuff. Window Object 1.0 WD is a more elaborate take, in hiatus because of no active editor and apparently also of unclearness still covering the dependencies and what should therefore go where to achieve a workable and reasonable suit of orthogonal specs. I suggest scaling the Window Object 1.0 WD down to what SVG 1.2 Tiny specifies, possibly with some small and uncontroversial additions. This spec could progress to Rec quickly, having been long overdue and implemented since 1990s. Then version 2.0 could use a better approximation of our wishlists. To be clear, this list *is* the right venue for discussing the draft, including ideas for changing it. You also wrote to Shelley Powers: In the meantime, please do not attempt to quash discussion of what is in the draft. The way I understood Shelley, and actually support this position, is that placement of these APIs in HTML5 drafts is wrong to begin with because the HTML5 WG isn't chartered to work on APIs which aren't (shouldn't be) particularly associated with HTML. Window (although a misnomer) is the most important badly missing piece in Web scripting, and currently only in SVG (at least as W3C specs go, and of course unless I'm missing something) can it be used legally (e.g. expecting a property called document on the global object if the language is ECMAScript). Best regards, Krzysztof Maczyński Invited Expert, HTML WG
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
[webdatabase] Handling of the query arguments
Hi everyone. Neither the web database specification, nor the IDL, specify the fine grained handling that implementation must do of the several possible values that can be passed in the 2nd argument to executeSql, considering that those ecmascript values need to be handled by the SQL engine, and therefore converted into a database compatible value. The only reference to the arguments is the paragraph that tell that the arguments should be replaced, but I've already asked that paragraph language to be reviewed in http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1329.html Handling of ecmascript to database types could be done the following way: - numerical values would be converted to REAL - strings would be converted to TEXT, including the empty string - booleans would be converted to lowercase TEXT false or true - null and undefined would be handled as NULL - functions would be converted to TEXT Objects, which do not fit the primitive types about, can be handled in two ways. 1) The quick cheap way, which was already hinted, would be to convert them to string. However, that's not very helpful, if the object is a native type wrapper like: new String(aa); new Number(1); new Boolean(true) 2) We can define, in the Web IDL, how an object can be converted to a primitive type. Specifically, in an ecmascript binding we can do the following (note: returns means to stop the steps): - if object is null, return null - if object has a member function called valueOf, invoke valueOf in the context of object - if the returned value is a primitive type, return the value, - if object has a member function called toString, invoke toString in the context of object - if the returned value is a primitive type, return the value, - return Object.prototype.toString.call(object), so we get [object Class] The returned primitive type would then go through the ecmascript to database type steps above. However, the Web IDL need to be language agnostic, so I'll leave for the Web IDL maintainers to decide if this is of its scope and specifiable. There might need to be clarification on how to define what is a numerical value, a string, a boolean, null and undefined, and functions. We could say that a numerical value is just a number, but ideally, it should also include Number() instances, despite these could return non numerical values from their valueOf, but then we would go into the object-to-primitive steps. The complete, we need the specification to tell how to convert database types back into ecmascript object, but this is easier: - TEXT, and other text types are converted to DOMString - REAL and other number types are converted to double - NULL is converted to null - DATE/TIMESTAMP types should be converted to Date objects, if supported Thank you for your time. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: [webdatabase] Handling of the query arguments
On Nov 19, 2009, at 2:12 PM, João Eiras wrote: Hi everyone. Neither the web database specification, nor the IDL, specify the fine grained handling that implementation must do of the several possible values that can be passed in the 2nd argument to executeSql, considering that those ecmascript values need to be handled by the SQL engine, and therefore converted into a database compatible value. The only reference to the arguments is the paragraph that tell that the arguments should be replaced, but I've already asked that paragraph language to be reviewed in http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/ 1329.html Handling of ecmascript to database types could be done the following way: - numerical values would be converted to REAL - strings would be converted to TEXT, including the empty string - booleans would be converted to lowercase TEXT false or true - null and undefined would be handled as NULL - functions would be converted to TEXT Objects, which do not fit the primitive types about, can be handled in two ways. 1) The quick cheap way, which was already hinted, would be to convert them to string. However, that's not very helpful, if the object is a native type wrapper like: new String(aa); new Number(1); new Boolean(true) 2) We can define, in the Web IDL, how an object can be converted to a primitive type. Specifically, in an ecmascript binding we can do the following (note: returns means to stop the steps): - if object is null, return null - if object has a member function called valueOf, invoke valueOf in the context of object - if the returned value is a primitive type, return the value, - if object has a member function called toString, invoke toString in the context of object - if the returned value is a primitive type, return the value, - return Object.prototype.toString.call(object), so we get [object Class] ECMAScript defines a ToPrimitive conversion (Section 9.1 of ECMA-262 5th edition). I think the right thing to do would be for some spec to point to those steps. Probably it has to be Web Database, because in many cases where a Web IDL method takes an any type, it's not appropriate to do ToPrimitive conversion. Regards, Maciej
Re: [webdatabase] Handling of the query arguments
2) We can define, in the Web IDL, how an object can be converted to a primitive type. Specifically, in an ecmascript binding we can do the following (note: returns means to stop the steps): - if object is null, return null - if object has a member function called valueOf, invoke valueOf in the context of object - if the returned value is a primitive type, return the value, - if object has a member function called toString, invoke toString in the context of object - if the returned value is a primitive type, return the value, - return Object.prototype.toString.call(object), so we get [object Class] ECMAScript defines a ToPrimitive conversion (Section 9.1 of ECMA-262 5th edition). I think the right thing to do would be for some spec to point to those steps. Probably it has to be Web Database, because in many cases where a Web IDL method takes an any type, it's not appropriate to do ToPrimitive conversion. Indeed ! -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: [widgets] Test suite: problem with test cases
On Wed, Nov 18, 2009 at 1:59 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: On 18 Nov 2009, at 12:02, Marcos Caceres wrote: 2009/11/14 Scott Wilson scott.bradley.wil...@gmail.com: woops, fixed. Assertion 34: Test d7, d8 === These test cases both contain badly-formed XML: widget content /widget Presumably these ought to be: widget content/ /widget Fixed and checked in. Thanks - btw you still need to check in the updated .wgt files as well as the config.xml Doh, I thought I had. I just checked in new versions for these tests. -- Marcos Caceres http://datadriven.com.au
Security evaluation of an example DAP policy
If I understand this policy correctly, this would let a web site overwrite boot.ini if the user clicks through a prompt-oneshot. This does not seem like a good idea. You can tell your policy is in trouble because you're blacklisting C:\WINNT. What if my system is installed on my D: drive? It's emails like this that make me skeptical of the security work being done in the device APIs working group. Adam On Thu, Nov 19, 2009 at 1:41 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: 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
RE: Security evaluation of an example DAP policy
Hi Adam, Thanks for your review! This is what the BONDI specs need :) I am sorry that you are skeptical and believe that with joint forces BONDI and DAP will end up with a good solution. If I understand this policy correctly, this would let a web site overwrite boot.ini if the user clicks through a prompt-oneshot. This does not seem like a good idea. To handle this use case a more general regular expression could be defined. E.g. the following would have to be inserted into the prompt-oneshot section resource-match attr=param:name func=regexp/(C|c):\\(.+)\\(.+)/resource-match / and the following into deny section resource-match attr=param:name func=regexp/(C|c):\\(.+)/resource-match / Anyway, the BONDI FS is guarded as below. You can tell your policy is in trouble because you're blacklisting C:\WINNT. What if my system is installed on my D: drive? Please note that access to FS is guarded by FileSystemManager.resolve that is described as: Validates and resolves the given location to a File handle and returns a handle. A valid location is prefixed with a valid root or default location and must address an existing and accessible file. The path is resolved and visible to the JS code, but is it not necessarily readable or writable as is. For this there are getDefaultLocations and getRootLocations methods. In other APIs there are already cases around e.g. inContacts that refer to the device-specific information on the policy level. It's emails like this that make me skeptical of the security work being done in the device APIs working group. We try to stay positive and be constructive :) Thanks, Marcin From: Adam Barth [...@adambarth.com] Sent: Friday, November 20, 2009 12:22 AM To: Marcin Hanclik Cc: Maciej Stachowiak; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Security evaluation of an example DAP policy If I understand this policy correctly, this would let a web site overwrite boot.ini if the user clicks through a prompt-oneshot. This does not seem like a good idea. You can tell your policy is in trouble because you're blacklisting C:\WINNT. What if my system is installed on my D: drive? It's emails like this that make me skeptical of the security work being done in the device APIs working group. Adam On Thu, Nov 19, 2009 at 1:41 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: 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
RE: Security evaluation of an example DAP policy
Hi Adam, I think that resource-match attr=param:name func=regexp/(C|c):\\(.+)\\(.+)/resource-match / should be resource-match attr=param:name func=regexp/(C|c):\\([^\\]+)\\.+/resource-match / up to any further bug in the RE. Sorry, my problem. Anyway, the general comment is that the use case is under control based on the current spec. Thanks, Marcin From: public-device-apis-requ...@w3.org [public-device-apis-requ...@w3.org] On Behalf Of Marcin Hanclik [marcin.hanc...@access-company.com] Sent: Friday, November 20, 2009 1:00 AM To: Adam Barth Cc: Maciej Stachowiak; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: RE: Security evaluation of an example DAP policy Hi Adam, Thanks for your review! This is what the BONDI specs need :) I am sorry that you are skeptical and believe that with joint forces BONDI and DAP will end up with a good solution. If I understand this policy correctly, this would let a web site overwrite boot.ini if the user clicks through a prompt-oneshot. This does not seem like a good idea. To handle this use case a more general regular expression could be defined. E.g. the following would have to be inserted into the prompt-oneshot section resource-match attr=param:name func=regexp/(C|c):\\(.+)\\(.+)/resource-match / and the following into deny section resource-match attr=param:name func=regexp/(C|c):\\(.+)/resource-match / Anyway, the BONDI FS is guarded as below. You can tell your policy is in trouble because you're blacklisting C:\WINNT. What if my system is installed on my D: drive? Please note that access to FS is guarded by FileSystemManager.resolve that is described as: Validates and resolves the given location to a File handle and returns a handle. A valid location is prefixed with a valid root or default location and must address an existing and accessible file. The path is resolved and visible to the JS code, but is it not necessarily readable or writable as is. For this there are getDefaultLocations and getRootLocations methods. In other APIs there are already cases around e.g. inContacts that refer to the device-specific information on the policy level. It's emails like this that make me skeptical of the security work being done in the device APIs working group. We try to stay positive and be constructive :) Thanks, Marcin From: Adam Barth [...@adambarth.com] Sent: Friday, November 20, 2009 12:22 AM To: Marcin Hanclik Cc: Maciej Stachowiak; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Security evaluation of an example DAP policy If I understand this policy correctly, this would let a web site overwrite boot.ini if the user clicks through a prompt-oneshot. This does not seem like a good idea. You can tell your policy is in trouble because you're blacklisting C:\WINNT. What if my system is installed on my D: drive? It's emails like this that make me skeptical of the security work being done in the device APIs working group. Adam On Thu, Nov 19, 2009 at 1:41 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: 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
Re: Security evaluation of an example DAP policy
On Thu, Nov 19, 2009 at 4:07 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Adam, I think that resource-match attr=param:name func=regexp/(C|c):\\(.+)\\(.+)/resource-match / should be resource-match attr=param:name func=regexp/(C|c):\\([^\\]+)\\.+/resource-match / up to any further bug in the RE. Sorry, my problem. Anyway, the general comment is that the use case is under control based on the current spec. For what it's worth, I think any API that opened a dialog asking the user Do you want to give website X access to directory Y in your file system would not be an API we'd be willing to implement in firefox. I.e. our security policy would be to always deny such a request (thus making implementing the API useless for our users). / Jonas
Re: Security evaluation of an example DAP policy
On Nov 19, 2009, at 4:00 PM, Marcin Hanclik wrote: Hi Adam, Thanks for your review! This is what the BONDI specs need :) I am sorry that you are skeptical and believe that with joint forces BONDI and DAP will end up with a good solution. If I understand this policy correctly, this would let a web site overwrite boot.ini if the user clicks through a prompt-oneshot. This does not seem like a good idea. To handle this use case a more general regular expression could be defined. E.g. the following would have to be inserted into the prompt-oneshot section resource-match attr=param:name func=regexp/(C|c):\\ (.+)\\(.+)/resource-match / and the following into deny section resource-match attr=param:name func=regexp/(C|c):\\ (.+)/resource-match / Anyway, the BONDI FS is guarded as below. Allowing write access to *any* file with just a one-shot confirmation prompt is unacceptable for the browser context. Or even read access. That's why the File API starts with input type=file which has the user take an affirmative step to choose a file, rather than confirming the Web page's choice of file. This may seem like a subtle issue but it makes a huge difference to the security implications. Access after a blanket prompt to access to read any file, to send email as the user, to read or write the contacts list, and to record via the camera all sound like extremely risky designs. Launching an app after a oneshot prompt is also extremely dangerous. Combined with other functionality, this can put a Web site one user confirmation away from running arbitrary native code. This is the kind of issue that needs to be considered up-front in the design, rather than bolted on by a policy. Many of these issues have to be addressed in the API design, not just by tweaking a policy file, to be truly Web-safe. You can tell your policy is in trouble because you're blacklisting C:\WINNT. What if my system is installed on my D: drive? Please note that access to FS is guarded by FileSystemManager.resolve that is described as: Validates and resolves the given location to a File handle and returns a handle. A valid location is prefixed with a valid root or default location and must address an existing and accessible file. The path is resolved and visible to the JS code, but is it not necessarily readable or writable as is. For this there are getDefaultLocations and getRootLocations methods. In other APIs there are already cases around e.g. inContacts that refer to the device-specific information on the policy level. It's emails like this that make me skeptical of the security work being done in the device APIs working group. We try to stay positive and be constructive :) When a security design seems fundamentally mistaken, I think it's important to be really clear about the problems, even if that comes off as blunt or harsh to some people. Regards, Maciej
Re: Security evaluation of an example DAP policy
On Nov 19, 2009, at 4:23 PM, Jonas Sicking wrote: On Thu, Nov 19, 2009 at 4:07 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Adam, I think that resource-match attr=param:name func=regexp/(C|c):\\(.+)\\(.+)/ resource-match / should be resource-match attr=param:name func=regexp/(C|c):\\([^\\]+)\\. +/resource-match / up to any further bug in the RE. Sorry, my problem. Anyway, the general comment is that the use case is under control based on the current spec. For what it's worth, I think any API that opened a dialog asking the user Do you want to give website X access to directory Y in your file system would not be an API we'd be willing to implement in firefox. I.e. our security policy would be to always deny such a request (thus making implementing the API useless for our users). Ditto for Safari. - Maciej
Re: Moving Window and stuff out of HTML5
On Nov 19, 2009, at 1:11 PM, Krzysztof Maczyński wrote: Dear WGs, (Ccing public-weba...@w3.org.) They could be split out into a separate specification or specifications, and HTML5 would probably not even need to reference them. I agree that it's good design in principle to split the core platform APIs (window, navigator, etc) into separate specs. However, it is also much harder than it may seem. SVG 1.2 Tiny has some of this stuff. Window Object 1.0 WD is a more elaborate take, in hiatus because of no active editor and apparently also of unclearness still covering the dependencies and what should therefore go where to achieve a workable and reasonable suit of orthogonal specs. I suggest scaling the Window Object 1.0 WD down to what SVG 1.2 Tiny specifies, possibly with some small and uncontroversial additions. This spec could progress to Rec quickly, having been long overdue and implemented since 1990s. Then version 2.0 could use a better approximation of our wishlists. Speaking as the former editor, I think Window Object 1.0 actually specifies too little to be a useful for anything in HTML5. Cutting it down further would probably not result in something useful. That's part of why I stopped work. To be clear, this list *is* the right venue for discussing the draft, including ideas for changing it. You also wrote to Shelley Powers: In the meantime, please do not attempt to quash discussion of what is in the draft. The way I understood Shelley, and actually support this position, is that placement of these APIs in HTML5 drafts is wrong to begin with because the HTML5 WG isn't chartered to work on APIs which aren't (shouldn't be) particularly associated with HTML. Window (although a misnomer) is the most important badly missing piece in Web scripting, and currently only in SVG (at least as W3C specs go, and of course unless I'm missing something) can it be used legally (e.g. expecting a property called document on the global object if the language is ECMAScript). That is a reasonable position to take and it's fine for Shelley (or you) to pursue it. But for now the Navigator object is in HTML5, and we should continue to provide a forum for discussing it until such time as we decide to remove it. Regards, Maciej
RE: Security evaluation of an example DAP policy
Hi Jonas, Maciej, It seems that the policy that you would accept would be: policy-set combine=deny-overrides policy description=Default Policy for websites. Simply denying all API that are covered by some device capability:) target subject subject-match attr=class match=website func=equal/ /subject /target rule effect=deny condition resource-match attr=device-cap func=regexp/.+//resource-match /condition /rule /policy /policy-set Let's see how DAP will evolve then. Thanks, Marcin From: Maciej Stachowiak [...@apple.com] Sent: Friday, November 20, 2009 1:26 AM To: Jonas Sicking Cc: Marcin Hanclik; Adam Barth; Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: Re: Security evaluation of an example DAP policy On Nov 19, 2009, at 4:23 PM, Jonas Sicking wrote: On Thu, Nov 19, 2009 at 4:07 PM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Adam, I think that resource-match attr=param:name func=regexp/(C|c):\\(.+)\\(.+)/ resource-match / should be resource-match attr=param:name func=regexp/(C|c):\\([^\\]+)\\. +/resource-match / up to any further bug in the RE. Sorry, my problem. Anyway, the general comment is that the use case is under control based on the current spec. For what it's worth, I think any API that opened a dialog asking the user Do you want to give website X access to directory Y in your file system would not be an API we'd be willing to implement in firefox. I.e. our security policy would be to always deny such a request (thus making implementing the API useless for our users). Ditto for Safari. - 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.
RE: Let's turn WebDatabase into a WG Note
On Wednesday, November 18, 2009 2:51 PM, Charles McCathieNevile wrote: I think it make sense to clarify in working drafts that this spec is unlikely to be interoperable across the web at large, but is usable for various specific systems. I don't think it makes sense to just turn it into a note at this stage - as the Google guys said, let's get some experience with WebSimpleDB before we make a final call. Likewise, I agree with Robin that it might not make sense to take this to Last Call, because of the uncertainty about where we are going to end up. I agree with Chaals. As I noted at TPAC, at Microsoft we don't think we'll collectively be able to achieve reasonable interop because of the SQL dialect issue (it's not like we can even choose one of the existing 'standard' SQL dialects since current implementations don't conform to anything like that). Considering that, it seems unlikely that there will be two independent interoperable implementations at the SQL level which makes moving to Last Call potentially problematic. On the other hand, it seems premature to dismiss the work entirely as a WG Note when more than one member has expressed a desire to move forward. I do wonder whether it might make sense to include an editor's note in the WD indicating that independent implementations of the SQL dialect aren't currently anticipated just so that anyone unfamiliar with this conversation would be aware from the spec. Cheers, Adrian.