RE: question about number of occurrences of author and content elements (in Widget packaging spec)
No, it is in webapps (all the widgets work is there) - try: public-webapps@w3.org Cheers! David. -Original Message- From: Ricardo Varela [mailto:pho...@gmail.com] Sent: 02 July 2010 09:02 To: David Rogers Subject: Re: question about number of occurrences of author and content elements (in Widget packaging spec) mmm... is widget packaging and configuration... isn;t that in DAP? did i got the mails wrong? --- ricardo On Fri, Jul 2, 2010 at 3:42 PM, David Rogers david.rog...@omtp.org wrote: Hi Ricardo - did you mean to send that to webapps rather than DAP? Cheers, David. -Original Message- From: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org] On Behalf Of Ricardo Varela Sent: 02 July 2010 04:57 To: public-device-a...@w3.org; Marcos Caceres Subject: question about number of occurrences of author and content elements (in Widget packaging spec) hallo all, hallo Marcos, We have a small question regarding what we interpret may be an inconsistency in the behaviours for parsing a config file as commented in the W3C widget packaging spec [1] According to the spec (latest and also older versions), the occurrences of some elements (eg: author or content) have to be zero or one However, on the algorithm to process a configuration document quoted below, it states: If this is not the first author element encountered, then the user agent must ignore this element and any child nodes It just says ignore and doesn't say to consider it as error Isn't this a contradiction in the parsing of the configuration document? We understand that it should be one of these 2 cases: a) we allow for more than one instance of author and content and let the first one take precedence (and therefore the occurrences should be zero or more) b) we allow only one instance of author and content elements (and therefore the parsing algorithm has got to stop with error on further occurrences) Would appreciate some clarification about this, as we want to clarify what to do for our compliance tests Thanks a lot in advance! Saludos! [1] http://www.w3.org/TR/widgets/ -- Ricardo Varela - http://phobeo.com - http://twitter.com/phobeo Though this be madness, yet there's method in 't -- Ricardo Varela - http://phobeo.com - http://twitter.com/phobeo Though this be madness, yet there's method in 't
OMTP BONDI 1.11 errata release
Dear all, Please note that the OMTP BONDI 1.11 errata release specifications are available at: http://bondi.omtp.org/1.11/ . These contain minor changes and editorial updates to the previously released 1.1 version: http://bondi.omtp.org/1.1/ . Thanks, David. David Rogers OMTP Director of External Relations
RE: Transferring File* to WebApps - redux
The question of where you are represented and your ability to participate cuts both ways - the same is true for us. I think if the browser vendors want their products really to be seen as compatible with the Web application space (as compared to just dynamic Web pages), they will support the work in DAP as its there that non-obtrusive and inherently secure models for Web application access to device resources will be defined as APIs. At present time, I think that the paragraph above accurately summarizes a technical rift between certain members of both working groups (DAP and WebApps). It may not be worthwhile to resolve this rift, and we should allow disparate families of specifications to bloom, taking care not to cause developer confusion with naming (a hard problem). Where specifications worked on in the DAP WG lend themselves to implementation plans, I think Mozilla participants interested in these can comment on them (e.g. Contacts API, at least for now). [DAVID] I don't think it is worth creating a schism. The file API hadn't been touched since 2006 when we started looking at this work so it is good that we have managed to help motivate some further work on it. A number of browser vendors are involved in DAP and are starting to build DAP APIs so I think this might be an incorrect assumption too. We're all in this together, so let's try and get it right for the user. The key question remains around security model. OMTP members believe in separating policy for good security reasons and to advance the general discipline away from the natural answer which would be 'provide a prompt or explicit user interaction'. If we slip back into this old way of thinking, we are destined for failure. Yes, at some point you need user interaction but let's try to minimise that in an intelligent manner which means that the user is not bombarded with prompts, making the system less secure. So, some questions from me: 1) I want to make sure that we can continue the good privacy work that has been started in DAP - please can you clarify if you would propose adopting those requirements if transferred to WebApps? 2) Also, please can you outline the security model that you will propose if it does transfer to WebApps - would it allow for management of access to the file system by policy (in the BONDI manner or by Google Powerbox or Mozilla's separate policy scheme)? 3) Would your proposed API require prompts to the user and explicit user acceptance of some sort? Thanks, David.
RE: Transferring File* to WebApps - Proposed path forward
Hi Robin, It might be worth hanging on for Arun's response to my email this morning before we get to a resolution on this. Also on the proposed naming, the term 'Trusted' has a very specific meaning and it could create ambiguities - i.e. we would not be defining a Trusted File System Access. That is something completely different (and I would love to see a Trusted Services API for access to Trusted Execution Environments and Secure Storage by the way in the future) but this is not it. Cheers, David. -Original Message- From: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org] On Behalf Of Robin Berjon Sent: 16 June 2010 11:57 To: public-device-a...@w3.org; Web Applications Working Group WG Subject: Transferring File* to WebApps - Proposed path forward Hi all, thanks a lot for this useful and frank conversation. Based on this input and stuff I've been ruminating over, I'd like to propose the following arrangement (in detail, so bear with me for stating some parts that may be obvious). * File/FileReader stays in WebApps. It defines all that you need to get data out of a File object and a way of getting hold of one of those through an HTML binding. * File Writer moves to WebApps. It defines all that you need to write data to a File (or Blob). It will also define a way to safely get that data saved, for instance through a download dialog. * File Directories and System moves to WebApps. It defines all that you need to frolic around a file system, exploring directories, creating and deleting entries, etc. It also defines access to a local sandboxed file system. One thing that it loses in the transfer is the DeviceFilesystem interface. * A new Trusted File System Access specification is produced in DAP that inherits the current DeviceFilesystem interface. A word on this new Trusted thingie. There are two goals that we have here: design wicked cool APIs that work in browsers, and design wicked cool APIs that can't work in browsers. The latter are expected to be used for installable apps (widgets, browser extensions, browser-powered apps, mobile apps) or other such situations in which a trust relationship - a situation that is becoming increasingly commonplace and where some interoperability is badly needed (at least on some basic things - e.g. we don't need each browser extension system to have its own separate file API - innovation can and should proceed apace on the more advanced stuff). Instead of trying to cram both aspects into the same specification, we use two, with a layered model that has the Trusted side add access paths. I know that some people have claimed that it would be impossible to produce web-safe APIs that could also be further opened up. I submit that the File family of APIs has shown them to be wrong: all that the trusted level requires is a single interface with all of two methods. This is a pattern that I can see being rather straightforward to apply to Capture (as a more formalised way of expressing previous separation into levels discussions), Contacts, Calendar... And if we do find a case in which it doesn't work, we'll cross that bridge then. WDYT? -- Robin Berjon - http://berjon.com/
RE: Transferring File* to WebApps - redux
Hi Arun, -Original Message- From: Arun Ranganathan [mailto:a...@mozilla.com] Sent: 16 June 2010 19:48 On 6/16/10 2:16 AM, David Rogers wrote: The question of where you are represented and your ability to participate cuts both ways - the same is true for us. I think if the browser vendors want their products really to be seen as compatible with the Web application space (as compared to just dynamic Web pages), they will support the work in DAP as its there that non-obtrusive and inherently secure models for Web application access to device resources will be defined as APIs. At present time, I think that the paragraph above accurately summarizes a technical rift between certain members of both working groups (DAP and WebApps). It may not be worthwhile to resolve this rift, and we should allow disparate families of specifications to bloom, taking care not to cause developer confusion with naming (a hard problem). Where specifications worked on in the DAP WG lend themselves to implementation plans, I think Mozilla participants interested in these can comment on them (e.g. Contacts API, at least for now). [DAVID] I don't think it is worth creating a schism. The file API hadn't been touched since 2006 when we started looking at this work so it is good that we have managed to help motivate some further work on it. A number of browser vendors are involved in DAP and are starting to build DAP APIs so I think this might be an incorrect assumption too. We're all in this together, so let's try and get it right for the user. The key question remains around security model. OMTP members believe in separating policy for good security reasons and to advance the general discipline away from the natural answer which would be 'provide a prompt or explicit user interaction'. If we slip back into this old way of thinking, we are destined for failure. Yes, at some point you need user interaction but let's try to minimise that in an intelligent manner which means that the user is not bombarded with prompts, making the system less secure. So, some questions from me: 1) I want to make sure that we can continue the good privacy work that has been started in DAP - please can you clarify if you would propose adopting those requirements if transferred to WebApps? I think you are referring to: http://dev.w3.org/2009/dap/docs/privacy-license.html . Is that correct? If so, that's a document that seems like a really good start. There's an upcoming workshop on this subject for which Aza Raskin has submitted a paper which also posits a license style model, but couples it with easy user-readable icons. I don't mind where general privacy guidelines live. I think what's wise is to allow for maximum browser vendor review, but additional charter items on WebApps is hard. I think we can review sensible privacy guidelines wherever they live; they don't have to be transferred, but widespread review is desirable. It might be useful to decouple privacy from a secure model for APIs. [DAVID] I was actually referring to: http://dev.w3.org/2009/dap/privacy-reqs/ and yes I don't want to pre-judge the outcome of the workshop but we all pretty much acknowledge that there are privacy issues we need to deal with and that the design of any the work we're doing here should take it into account (in the same way as security). The whole basis of establishing the DAP working group was to protect the consumer and improve on the current status quo. Like you, I'm not precious about where things live, but I just want to make sure that if the file related APIs go into webapps that we can continue in that spirit, not just forget all that - otherwise there is no point and you won't see take-up of the API in the long-term because it would be too risky. As I said before, there is no value in creating a schism here, it would create more problems for W3C as a community and is absolutely needless. 2) Also, please can you outline the security model that you will propose if it does transfer to WebApps - would it allow for management of access to the file system by policy (in the BONDI manner or by Google Powerbox or Mozilla's separate policy scheme)? Are you talking about the email Robin sent about transferring FileWriter and FileSystem over to WebApps? [DAVID] Yes, that is what this whole message thread is about. If so, the security model (which needs more work and shouldn't be considered final by any means) probably shouldn't be based on policy schemes like BONDI's policy language. I'm not sure yet what to make of PowerBox, but I'm personally not considering it in this regard. There isn't a separate Mozilla policy scheme, but the same-origin scheme for scripts and the separation of chrome content and web content is applicable here. [DAVID] So I'll take that as an agreement that we need to address the security model properly before
RE: VMMF - new version
Hi Robin, I'm not sure how far forward we are with this but looking at the security considerations, it would be useful to have the examples for implementers to understand where we're coming from with the concerns. For your info, this was the original proposal I discussed with Marcin: Security Considerations Widgets could be intentionally designed to visually dupe or confuse the user for social engineering purposes. Some methods that could be used to perform this could be by creating: * widgets that the user cannot see (full-screen invisible widgets in front of other things on the screen, such as a PIN-code entry) * widgets that have a size smaller than the user can reasonably see (e.g. a 1px x 1px widget) * widgets that have no chrome that could masquerade as some other existing object on the screen (for example a lock and key) Implementers of this specification are asked to take these points into account and design appropriate measures to safeguard the user. Thanks, David. -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Robin Berjon Sent: 04 March 2010 13:13 To: public-webapps WG Subject: VMMF - new version Hi all, I just produced an update of VMMF to make it ready for publication: http://dev.w3.org/2006/waf/widgets-vmmf/. Essentially I changed it so that it corresponds to CSS Media Queries. That, plus it being a UI oriented specification, means that there's only one normative assertion and it's a SHOULD. Comments welcome, I think that this baby can ship. -- Robin Berjon - http://berjon.com/
RE: VMMF — new version
A small comment. It's probably best to use the OED for English dictionary words rather than a google search: http://www.askoxford.com/results/?view=dictfreesearch=immersivebranch=13842570textsearchtype=exact David. -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of timeless Sent: 10 March 2010 08:55 To: Robin Berjon Cc: public-webapps WG Subject: Re: VMMF — new version On Thu, Mar 4, 2010 at 3:13 PM, Robin Berjon ro...@berjon.com wrote: I just produced an update of VMMF to make it ready for publication: http://dev.w3.org/2006/waf/widgets-vmmf/. Essentially I changed it so that it corresponds to CSS Media Queries. That, plus it being a UI oriented specification, means that there's only one normative assertion and it's a SHOULD. Comments welcome, I think that this baby can ship. Just to be difficult, i object to maximized being misspelled by an old-worlder. I'd suggest max or maxed as a compromise :) widgets that have no chrome and that therefore could masquerade some other existing objects on the screen. s/therefore could/could therefore/ (e.g. tool bars, title bars, menus, etc.). (e.g. the menu bar, the clock and similar icons, the system menu, etc.). the use of 'e.g.' is generally incompatible with 'etc.' The view mode is the manner in which a widget is presented to a user that corresponds to the metaphors and functionalities in use on a given functionality [N-UNCOUNT] Describes a widget providing a more immersive interface, Google says that immersive isn't in their dictionary, Firefox concurs. Oh well, the web and its 3 million hits evolves to provide such terms.
FW: OMTP BONDI 1.1 Approved Release
/ [2] http://bondi.omtp.org/1.1/BONDI%201.1%20Release%20Notes.txt David Rogers OMTP Director of External Relations
RE: [widgets] Draft Agenda for 11 February 2010 voice conf
Apologies in advance for this week and next. Thanks, David. -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: 10 February 2010 13:30 To: public-webapps Subject: [widgets] Draft Agenda for 11 February 2010 voice conf Below is the draft agenda for the 11 February Widgets Voice Conference (VC). Inputs and discussion before the VC on all of the agenda topics via public-webapps is encouraged (as it can result in a shortened meeting). Please address Open and Raised Issues and Open Actions before the meeting: http://www.w3.org/2008/webapps/track/products/8 Minutes from the last VC: http://www.w3.org/2010/02/04-wam-minutes.html Logistics below. -Regards, Art Barstow Agenda: 1. Review and tweak agenda 2. Announcements a. LC of XML Signatures spec published 4 Feb: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0531.html 3. Packaging and Configuration spec http://dev.w3.org/2006/waf/widgets/ CR Implementation Report: http://dev.w3.org/2006/waf/widgets/imp-report/ a. Important Test Suite Updates by Marcos http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0485.html b. Action-486: Create ITS test case(s) for the PC test suite http://www.w3.org/2008/webapps/track/actions/486 4. Widget Interface spec http://dev.w3.org/2006/waf/widgets-api/ a. API - openURL security considerations by Marcos http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0501.html b. TWI: comments by Cyril http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0479.html c. window object by Cyril http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0476.html 5. Access Requests Policy (WARP) spec http://dev.w3.org/2006/waf/widgets-access/ a. Action-490: [AB to] Work with MC, RB and Dom on creating a infrastructure to test the WARP spec http://www.w3.org/2008/webapps/track/actions/490 6. AOB a. Charter renewal - please send comments to public-webapps: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0493.html Comments from Scott Wilson: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/ 0525.html Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration: 90 minutes max Zakim Bridge: +1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152 PIN: 9231 (WAF1); IRC: channel = #wam; irc://irc.w3.org:6665 ; http://cgi.w3.org/ member-bin/irc/irc.cgi Confidentiality of minutes: Public
RE: [widgets] PC: comments submitted after 1-Dec-2009 CR#2 publication
Marcos, Art, Please could you point us in the direction of the documentation from W3C on progressing to PR? Is there some kind of formal gate to progression? Thanks, David. -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcos Caceres Sent: 03 February 2010 14:57 To: Arthur Barstow Cc: public-webapps Subject: Re: [widgets] PC: comments submitted after 1-Dec-2009 CR#2 publication Hi Art, On Wed, Feb 3, 2010 at 1:46 PM, Arthur Barstow art.bars...@nokia.com wrote: Marcos, All - below is a list of headers for comments submitted to public-webapps re the PC spec and test suite after CR#2 was published on 1-Dec-2009. I think the list is complete but I haven't double-checked it. Will addressing any of the post-CR#2 comments prevent this spec from advancing to Proposed Recommendation: http://www.w3.org/2005/10/Process-20051014/tr.html#cfr IMO, there is nothing preventing this spec from progressing to PR from those emails. The emails have only resulted in clarifications to the spec and fixes in the test suite. However, I'd personally like to see two commercial-grade implementations (or whatever you would call them, products with 100,000+ users) pass 100% of the test suite before moving this to PR. I'd hate to see spec bugs showing up in the wild while in PR, when we could have caught them during the CR phase - or that QA processes from well-funded commercial entities discover issues during PR that where not caught by the smaller scale implementations we currently have (no offence to anyone that has implemented thus far, I'm just trying to assure the quality for the benefit of everyone). Anyway that's my position. If other implementers feel confident that the spec is solid enough to become a standard, then onwards we go :) -Art Barstow = From: marc...@opera.com Subject: [widgets] Null in PC Date: February 2, 2010 7:29:42 AM EST Archived-At: http://www.w3.org/mid/4b681ab6.2060...@opera.com = From: ar...@opera.com Subject: One feature, multiple resources Date: January 29, 2010 7:45:18 AM EST Archived-At: http://www.w3.org/mid/op.u7aodsi2byn...@galactica = From: marc...@opera.com Subject: [widgets] PC typo in 9.1.9. Rule for Parsing a Non-negative Integer Date: January 19, 2010 7:06:21 AM EST Archived-At: http://www.w3.org/mid/b21a10671001190406p6d804eachb42b2261ed673...@mail.gmail.com = From: scott.bradley.wil...@gmail.com Subject: [widgets] Anyone working on SNIFF in Java? Date: December 17, 2009 4:57:21 PM EST Archived-At: http://www.w3.org/mid/78001806-b3b5-4751-bbc9-c166b7eeb...@gmail.com = From: scott.bradley.wil...@gmail.com Subject: [widgets] test-suite: start file encoding Date: December 17, 2009 12:21:42 PM EST Archived-At: http://www.w3.org/mid/7c6e8fcf-91ae-4a5d-97c2-7aa35f8ca...@gmail.com = From: cyril.concol...@enst.fr Subject: [widgets] white space handling Date: December 17, 2009 7:26:24 AM EST Archived-At: http://www.w3.org/mid/4b2a2370.60...@enst.fr = From: e...@isoc.org.il ; Eyal Sela Subject: Widget packaging conformance Date: December 16, 2009 7:18:37 AM EST Archived-At: http://www.w3.org/mid/013601ca7e49$e56f27e0$b04d77...@org.il = From: cyril.concol...@enst.fr Subject: [widgets] duplicated feature elements ? Date: December 16, 2009 4:51:20 AM EST Archived-At: http://www.w3.org/mid/4b28ad98.9030...@enst.fr = From: cyril.concol...@enst.fr Subject: [widgets] feature: inconsistent behavior ? Date: December 16, 2009 4:13:55 AM EST Archived-At: http://www.w3.org/mid/4b28a4d3.5060...@enst.fr = From: cyril.concol...@enst.fr Subject: [widgets] features: default value for required Date: December 16, 2009 3:50:02 AM EST Archived-At: http://www.w3.org/mid/4b289f3a.1010...@enst.fr = From: cyril.concol...@enst.fr Subject: [widgets] test suite: br.wgt Date: December 15, 2009 10:41:31 AM EST Archived-At: http://www.w3.org/mid/4b27ae2b.6030...@enst.fr = From: marc...@opera.com Subject: Re: [widgets] test suite, the width/height attribute Date: December 14, 2009 10:49:04 AM EST Archived-At: http://www.w3.org/mid/b21a10670912140749o10252cevaa8a25699a158...@mail.gmail.com = From: amit.kas...@pnyxe.com Subject: Widget specification - liquid height support Date: December 10, 2009 9:54:15 AM EST Archived-At: http://www.w3.org/mid/4b210bab.1438560a.1fc4.c...@mx.google.com = From: cyril.concol...@enst.fr Subject: [widgets] PC simplifying some rules (editorial) Date: December 9, 2009 7:50:44 AM EST Archived-At: http://www.w3.org/mid/4b1f9d24.3010...@enst.fr = From: marc...@opera.com Subject: Re: [widgets] test-cases for icons: some possible errors Date: December 9, 2009 6:34:30 PM EST Archived-At:
RE: [widgets] PC: comments submitted after 1-Dec-2009 CR#2 publication
Thanks Art, Marcos, although I don't disagree on the quality point, I just want to check how this fits in with the formal process. Where did 100,000 users come from? Apologies for being new to this part of the process but it talks about: Proposed Recommendation (PR) A Proposed Recommendation is a mature technical report that, after wide review for technical soundness and implementability, W3C has sent to the W3C Advisory Committee for final endorsement. Are there formal points (e.g. 100,000 users etc.) at which this is gated? I'm assuming that some organisations would wait until it reached PR before implementing so your proposal could be somewhat chicken and egg related. Thanks, David. -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcos Caceres Sent: 03 February 2010 14:57 To: Arthur Barstow Cc: public-webapps Subject: Re: [widgets] PC: comments submitted after 1-Dec-2009 CR#2 publication Hi Art, On Wed, Feb 3, 2010 at 1:46 PM, Arthur Barstow art.bars...@nokia.com wrote: Marcos, All - below is a list of headers for comments submitted to public-webapps re the PC spec and test suite after CR#2 was published on 1-Dec-2009. I think the list is complete but I haven't double-checked it. Will addressing any of the post-CR#2 comments prevent this spec from advancing to Proposed Recommendation: http://www.w3.org/2005/10/Process-20051014/tr.html#cfr IMO, there is nothing preventing this spec from progressing to PR from those emails. The emails have only resulted in clarifications to the spec and fixes in the test suite. However, I'd personally like to see two commercial-grade implementations (or whatever you would call them, products with 100,000+ users) pass 100% of the test suite before moving this to PR. I'd hate to see spec bugs showing up in the wild while in PR, when we could have caught them during the CR phase - or that QA processes from well-funded commercial entities discover issues during PR that where not caught by the smaller scale implementations we currently have (no offence to anyone that has implemented thus far, I'm just trying to assure the quality for the benefit of everyone). Anyway that's my position. If other implementers feel confident that the spec is solid enough to become a standard, then onwards we go :) -Art Barstow = From: marc...@opera.com Subject: [widgets] Null in PC Date: February 2, 2010 7:29:42 AM EST Archived-At: http://www.w3.org/mid/4b681ab6.2060...@opera.com = From: ar...@opera.com Subject: One feature, multiple resources Date: January 29, 2010 7:45:18 AM EST Archived-At: http://www.w3.org/mid/op.u7aodsi2byn...@galactica = From: marc...@opera.com Subject: [widgets] PC typo in 9.1.9. Rule for Parsing a Non-negative Integer Date: January 19, 2010 7:06:21 AM EST Archived-At: http://www.w3.org/mid/b21a10671001190406p6d804eachb42b2261ed673...@mail.gmail.com = From: scott.bradley.wil...@gmail.com Subject: [widgets] Anyone working on SNIFF in Java? Date: December 17, 2009 4:57:21 PM EST Archived-At: http://www.w3.org/mid/78001806-b3b5-4751-bbc9-c166b7eeb...@gmail.com = From: scott.bradley.wil...@gmail.com Subject: [widgets] test-suite: start file encoding Date: December 17, 2009 12:21:42 PM EST Archived-At: http://www.w3.org/mid/7c6e8fcf-91ae-4a5d-97c2-7aa35f8ca...@gmail.com = From: cyril.concol...@enst.fr Subject: [widgets] white space handling Date: December 17, 2009 7:26:24 AM EST Archived-At: http://www.w3.org/mid/4b2a2370.60...@enst.fr = From: e...@isoc.org.il ; Eyal Sela Subject: Widget packaging conformance Date: December 16, 2009 7:18:37 AM EST Archived-At: http://www.w3.org/mid/013601ca7e49$e56f27e0$b04d77...@org.il = From: cyril.concol...@enst.fr Subject: [widgets] duplicated feature elements ? Date: December 16, 2009 4:51:20 AM EST Archived-At: http://www.w3.org/mid/4b28ad98.9030...@enst.fr = From: cyril.concol...@enst.fr Subject: [widgets] feature: inconsistent behavior ? Date: December 16, 2009 4:13:55 AM EST Archived-At: http://www.w3.org/mid/4b28a4d3.5060...@enst.fr = From: cyril.concol...@enst.fr Subject: [widgets] features: default value for required Date: December 16, 2009 3:50:02 AM EST Archived-At: http://www.w3.org/mid/4b289f3a.1010...@enst.fr = From: cyril.concol...@enst.fr Subject: [widgets] test suite: br.wgt Date: December 15, 2009 10:41:31 AM EST Archived-At: http://www.w3.org/mid/4b27ae2b.6030...@enst.fr = From: marc...@opera.com Subject: Re: [widgets] test suite, the width/height attribute Date: December 14, 2009 10:49:04 AM EST Archived-At: http://www.w3.org/mid/b21a10670912140749o10252cevaa8a25699a158...@mail.gmail.com = From: amit.kas...@pnyxe.com Subject:
RE: [widgets] PC: comments submitted after 1-Dec-2009 CR#2 publication
Thanks for that Art, I agree with you, that would also be the OMTP view. Cheers, David. -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: 03 February 2010 15:55 To: Marcos Caceres; David Rogers Cc: public-webapps Subject: Re: [widgets] PC: comments submitted after 1-Dec-2009 CR#2 publication On Feb 3, 2010, at 10:48 AM, ext David Rogers wrote: Are there formal points (e.g. 100,000 users etc.) at which this is gated? I'm assuming that some organisations would wait until it reached PR before implementing so your proposal could be somewhat chicken and egg related. Each CR defines its own exit criteria. For this spec it is: [[ http://www.w3.org/TR/2009/CR-widgets-20091201/#sotd The Web Applications (WebApps) Working Group expects to request that the Director advance this document to Proposed Recommendation once the Working Group has demonstrated at least two interoperable implementations (interoperable meaning at least two implementations that pass each mandatory test in the [PC-Test-Suite]). The WebApps Working Group expects to show these implementations as part of an Implementation Report and advance to Proposed Recommendation after 24 January 2010. ]] Based on this criteria and what has been captured in the Implementation Report, it appears the exit criteria in the CR has been met: http://dev.w3.org/2006/waf/widgets/imp-report/ -Art Barstow
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: 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: 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
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]
RE: DAP and security (was: Rename File API to FileReader API?)
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? Thanks, David. -Original Message- From: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org] On Behalf Of Maciej Stachowiak Sent: 18 November 2009 12:35 To: Marcin Hanclik Cc: 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?) OK, I will take your word for it that security is an important consideration for DAP. But while at the TPAC, I heard more than one DAP participant say, when faced with a potential security concern, something like can't we just leave that up to the policy? In one case when I enquired further, at least one DAP member mentioned to me the idea of using some sort of policy file that would take care of all security issues. He suggested this might come from a corporate administrator, and that the format would be XML, but otherwise details were light. To me that seems like a plausible model for something like widgets or browser extensions or walled garden content, but not for sites on the public Web. My apologies if I misinterpreted these remarks or got the wrong impression. One more comment below: On Nov 18, 2009, at 4:18 AM, Marcin Hanclik wrote: +1 APIs - specifically their design - shall be specified tightly with the security model in mind to make them both easy to use and effective. This is what makes the whole task that difficult. Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org ] On Behalf Of Dominique Hazael-Massieux Sent: Thursday, November 12, 2009 10:30 AM To: Maciej Stachowiak Cc: Robin Berjon; public-device-a...@w3.org; public-webapps WG Subject: DAP and security (was: Rename File API to FileReader API?) Le mardi 10 novembre 2009 à 17:47 -0800, Maciej Stachowiak a écrit : I would be concerned with leaving file writing to DAP, because a widely held view in DAP seems to be that security can be ignored while designing APIs and added back later with an external policy file mechanism. Frederick already mentioned this isn't the case at all, and I want to strongly reject the notion that DAP is considering security as an after-the-fact or out-of-band aspect in the design of its APIs. Our charter clearly stipulates that our policy model must be consistent with the existing same origin policies (as documented in the HTML5 specification), in the sense that a deployment of the policy model in Web browsers must be possible. It seems to me that for most of DAP's likely deliverables, there are serious security considerations, but the same-origin policy is irrelevant to addressing them. The same-origin policy is designed to protect Web sites from attacks by other Web sites. It does not really apply to access to system resources. Doing that in a Web-safe way will require new inventions or might not even be possible in some cases. In fact, most of models that have been discussed in this thread to reduce the risks exposed by new APIs (sandbox for writing, user interaction or markup-based element for sharing data) were already mentioned as options by DAP WG participants during our F2F last week. More generally, I don't think assuming that DAP would create worse/ less secure APIs than WebApps or any other group would is either right nor useful to ensure a good collaboration between our groups. And clearly, we will actively be seeking feedback and input from the WebApps Working Group when we produce new APIs, which should also contribute to reduce the fears that we would get it all wrong :) Regards, Dom Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
FW: OMTP BONDI 1.1 Candidate Release now available
As mentioned in the widgets meeting yesterday, comments welcomed: From: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org] On Behalf Of David Rogers Sent: 02 November 2009 17:30 To: W3C Device APIs and Policy WG Subject: OMTP BONDI 1.1 Candidate Release now available Dear all, As I announced at the start of the DAP meeting, the OMTP BONDI 1.1 Candidate Release now available at http://bondi.omtp.org/1.1/CR/ . Please find the release notes below: BONDI 1.1 (Candidate Release) Release Notes === The BONDI 1.1 release define the composite specifications to allow web applications (widget and web pages) to interoperate over BONDI defined execution environment (widget runtime and web user agent). BONDI technology enables web based content to access native device capability, intermediated through a robust, but flexible security framework. There are three elements to the 1.1 release - APIs: defines the JavaScript functions that expose the underlying accessible device capability - Architecture and Security Specifications: defines the security layer and required architectural components that insulate the web application against risk - Compliance: define the compliance process that allows a widget runtime or web user agent to declare compliance against the BONDI specifications The BONDI 1.1 release differs from the 1.0 release in the following important ways APIs - Messaging Events are supported. - Binary Messaging Support. - Detailed and consistent filtering of PIM info and comm logs. - Maps replaced with specific data types. - More attributes for PIM elements and messaging. - UI Settings management added. - Camera API redesigned. Architecture and Security - - Widgets use of requestFeature(). - Features, sub-features, aggregate Features, and associated clarification of requestFeature() - Minor clarification to processing of multi-valued attributes in the definition of the policy model in AS appendices - IRI vs URI changes - Improving use and consistency of terminology for launch invoke instantiate etc with respect to Widgets. - B.4.1 Widget Subject Identity issues - Network access features - Updates to W3C document references - Change Definitions and perhaps other sections to be normative. -flat structure of Web IDL - module statement has no semantics in BONDI - implements Web IDL keyword is used to define the hierarchy of instantiations - \def-instantiated keyword in widl is used to specify upon which feature the interface may be instantiated - Feature-sets are used to group features - New device capabilities - messaging.binary.send - messaging.mms.subscribe - messaging.sms.subscribe - messaging.binary.subscribe - ui Compliance -- - Process document - Compliance process document amended - Compliance Matrix - Deleted the empty Policy Widget Examples spreadsheets. - Deleted Device Capabilities List in the Security Policy Language spreadsheet - Re-formatting to HTML in progress - Fixes have been applied to requirement numbering and cross referencing - Improvements the test coverage have been made Release Process === A BONDI candidate release is made publically available for 30 days in order to elicit public feedback. For 1.1 the consultation phase will start on November 2nd 2009, therefore feedback must be received by 2nd December 2009. Thanks, David. David Rogers OMTP Director of External Relations
[widgets] View modes security considerations
Hi there, As promised and discussed this afternoon, some basic text for a Security Considerations section in the widgets view modes spec: Security Considerations Implementers of this specification are asked to take into account and design appropriate measures to deal with the following points for the purpose of user security: Widgets could be intentionally designed to visually dupe or confuse the user for social engineering purposes. Some methods that could be used to do this could be: * widgets that the user cannot see (full-screen invisible widgets in front of other things on the screen, such as a PIN-code entry) * widgets that have a size smaller than the user can reasonably see (e.g. a 0.1 x 0.1 widget) * widgets that have no chrome that could masquerade as some other existing object on the screen (for example a lock and key) Thanks, David. David Rogers OMTP Director of External Relations
RE: Proposed additional topic for joint DAP/WebApps Widgets F2F session
Hi, As discussed on the webapps call, in addition to Fredrick's proposal I think we need to understand the relationship between DAP / Widgets / WebApps / HTML5 more clearly. There are overlaps and architectural disparities which we should highlight and come up with a plan for dealing with. Would it be possible for the chairs to come up with some input in terms of an architecture diagram of where they think we are? Thanks, David. -Original Message- From: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org] On Behalf Of Frederick Hirsch Sent: 29 October 2009 14:28 To: public-Webapps@w3.org WG Cc: Frederick Hirsch; Charles McCathieNevile; W3C Device APIs and Policy WG Subject: Proposed additional topic for joint DAP/WebApps Widgets F2F session If we have time and interest, I suggest we might also discuss in the joint DAP/WebApps Widgets session HTML5 security model, even if we also discuss in the joint DAP/WebApps API session, depending on the expertise in the room. I would like to make sure we transfer understanding to the DAP WG from everyone who can help the DAP WG and I'd like to make sure that somehow we have this discussion during TPAC. Thus Agenda topic for joint DAP/Webapps-Widget is Security Considerations, including HTML5. regards, Frederick Frederick Hirsch, Nokia Co-Chair, W3C DAP Working Group
RE: Proposed additional topic for joint DAP/WebApps Widgets F2F session
LOL, I wasn't expecting me to do the legwork for you all :-) One example would be FileSystem in DAP and the File API in webapps. How do these two fit together? I only saw an email on thoughts/assumptions about this recently. To the outside observer, it is not easy to see what the differences are and how this all fits together. We need to have a clear view (on one sheet of paper) about where these overlaps are and what the plan is for dealing with them. I was assuming that the chairs are best placed to do put the starting input in for this. Thanks, David. -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: 29 October 2009 16:04 To: David Rogers Cc: Hirsch Frederick (Nokia-CIC/Boston); public-Webapps@w3.org WG; Charles McCathieNevile; W3C Device APIs and Policy WG; Robin Berjon; Nick Allott Subject: Re: Proposed additional topic for joint DAP/WebApps Widgets F2F session On Oct 29, 2009, at 11:54 AM, ext David Rogers wrote: As discussed on the webapps call, in addition to Fredrick's proposal I think we need to understand the relationship between DAP / Widgets / WebApps / HTML5 more clearly. There are overlaps and architectural disparities which we should highlight and come up with a plan for dealing with. Please elaborate on the overlaps and architectural disparities. -Regards, Art Barstow
RE: Proposed additional topic for joint DAP/WebApps Widgets F2F session
Hi, So of course that was one example and I'm trying not to get into detail here - my main point is that currently we have no big picture view, I don't think that is good enough. This is why I want to put a specific agenda point forward for the following: I think a key output of TPAC for those overlapping groups / work items should be an overall architectural view highlighting overlaps and issues and an accompanying plan to deal with those issues. To reiterate, that is: webapps (APIs), webapps (widgets), DAP, HTML5 and the overall security considerations. I think the Chairs should jointly own this and it should be presentable to the outside world at any stage. Cheers, David. -Original Message- From: Charles McCathieNevile [mailto:cha...@opera.com] Sent: 29 October 2009 16:53 To: David Rogers; Arthur Barstow Cc: Hirsch Frederick (Nokia-CIC/Boston); public-Webapps@w3.org WG; W3C Device APIs and Policy WG; Robin Berjon; Nick Allott Subject: Re: Proposed additional topic for joint DAP/WebApps Widgets F2F session On Thu, 29 Oct 2009 17:18:31 +0100, David Rogers david.rog...@omtp.org wrote: LOL, I wasn't expecting me to do the legwork for you all :-) One example would be FileSystem in DAP and the File API in webapps. How do these two fit together? I only saw an email on thoughts/assumptions about this recently. To the outside observer, it is not easy to see what the differences are and how this all fits together. We need to have a clear view (on one sheet of paper) about where these overlaps are and what the plan is for dealing with them. I was assuming that the chairs are best placed to do put the starting input in for this. That's the major centrepiece of why we have a joint APIs/DAP meeting planned :) cheers Chaals Thanks, David. -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: 29 October 2009 16:04 To: David Rogers Cc: Hirsch Frederick (Nokia-CIC/Boston); public-Webapps@w3.org WG; Charles McCathieNevile; W3C Device APIs and Policy WG; Robin Berjon; Nick Allott Subject: Re: Proposed additional topic for joint DAP/WebApps Widgets F2F session On Oct 29, 2009, at 11:54 AM, ext David Rogers wrote: As discussed on the webapps call, in addition to Fredrick's proposal I think we need to understand the relationship between DAP / Widgets / WebApps / HTML5 more clearly. There are overlaps and architectural disparities which we should highlight and come up with a plan for dealing with. Please elaborate on the overlaps and architectural disparities. -Regards, Art Barstow -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
FW: [widgets] viewmodes spec
Hi Art and Marcos, I didn't see this point discussed in the last widgets meeting minutes. Do you know if anybody has started work on any security guidelines for widgets? I noticed that in the Web Security Context: User Interface Guidelines, for example this requirement[1] there may be some conflict with widgets / potential to put requirements there for the item below and others? Thanks, David. [1] http://www.w3.org/TR/wsc-ui/#keepchromevisible-goodpractice From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of David Rogers Sent: 22 October 2009 11:52 To: public-webapps@w3.org Cc: Barstow Art (Nokia-CIC/Boston) Subject: [widgets] viewmodes spec Hi there, At the last widgets call I agreed to ask OMTP BONDI members if there was any feedback on viewmodes. We didn't receive a lot of views but one thing I raised was that as far as I can tell, there is no text to cover off invisible widgets or widgets of, for example height and width 1x1. There may be a valid reason for someone to have an invisible widget but there are still some abuse scenarios - for example, if someone created a transparent widget that then maximises in front of your payment application just as you go to enter your PIN or password it could be a major issue. I'm not sure that anyone has started work on any widget security guidelines? Thanks, David. David Rogers OMTP Director of External Relations
RE: [widgets] CfC to publish LCWD#3 of the Packaging and Configuration spec; deadline 26 October
Thanks Art, OMTP are happy to proceed. Thanks, David. -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: 22 October 2009 22:40 To: public-webapps Subject: [widgets] CfC to publish LCWD#3 of the Packaging and Configuration spec; deadline 26 October This is a Call for Consensus (CfC) to publish the following document as Last Call Working Draft #3 of the Widgets 1.0: Packaging and Configuration spec: http://dev.w3.org/2006/waf/widgets/Overview_TSE.html This CfC satisfies the group's requirement to record the group's decision to request advancement. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is October 26 which is shorter than usual but we want this spec to be published before the TPAC publication moratorium. -Regards, Art Barstow
[widgets] viewmodes spec
Hi there, At the last widgets call I agreed to ask OMTP BONDI members if there was any feedback on viewmodes. We didn't receive a lot of views but one thing I raised was that as far as I can tell, there is no text to cover off invisible widgets or widgets of, for example height and width 1x1. There may be a valid reason for someone to have an invisible widget but there are still some abuse scenarios - for example, if someone created a transparent widget that then maximises in front of your payment application just as you go to enter your PIN or password it could be a major issue. I'm not sure that anyone has started work on any widget security guidelines? Thanks, David. David Rogers OMTP Director of External Relations
RE: [widgets] Draft Minutes for 22 October 2009 Voice Conf
Art and all, AB: any other comments on this? ... given we don't consensus on this, we will not be able to publish a new LC until after the TPAC meeting ... any last comments? ... given this is still an open issue, we will not discuss LC publication today Given that Marcin and Marcos appear to have resolved this on the mailing lists, I would like to support LC publication as soon as possible. Thoughts anyone? Thanks, David. -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: 22 October 2009 14:51 To: public-webapps Subject: [widgets] Draft Minutes for 22 October 2009 Voice Conf The draft minutes from the October 22 Widgets voice conference are available at the following and copied below: http://www.w3.org/2009/10/22-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before October 29 (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Regards, Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Widgets Voice Conference 22 Oct 2009 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/0283.html See also: [3]IRC log [3] http://www.w3.org/2009/10/22-wam-irc Attendees Present Art, Frederick, Jere, Bryan, Marcin_Hanclik, Magnus, Marcin, AndyB Regrets Marcos, Arve, David Chair Art Scribe Art Contents * [4]Topics 1. [5]Review and tweak agenda 2. [6]Announcements 3. [7]PC spec: Potential bug in Rule for Identifying the Media Type of a File 4. [8]AOB * [9]Summary of Action Items _ scribe ScribeNick: ArtB scribe Scribe: Art Review and tweak agenda AB: I posted the draft agenda on October 21 ( [10]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/02 83.html ). Since Marcos sent regrets for today we will drop the Widget interface spec agenda item. ... any other agenda change requests? [10] http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/0283.html FH: I think we should talk about DAP + WebApps meeting during TPAC AB: ok, during AOB JK: we could talk about Web Notifications ... but may want to wait for more people FH: yes, think we should wait AB: I agree ... if there is no closure by next week, it will be on the Oct 29 agenda Announcements AB: I have 4 short announcements/reminders: ... 1. draft agendas for the November 2-3 TPAC f2f meeting have been updated: Widgets group ( [11]http://www.w3.org/2008/webapps/wiki/TPAC2009Widgets ) and APIs group ( [12]http://www.w3.org/2008/webapps/wiki/TPAC2009APIs ). Fleshing-out the TPAC widgets agenda will be an agenda item for our October 29 call. ... 2. the TPAC registration deadline is Oct 23 ( [13]http://www.w3.org/2009/11/TPAC/Overview.html ) ... 3. TPAC Public Developer Gathering Nov 5 ( [14]http://www.w3.org/2009/11/TPAC/DevMeeting ). Please spread the word. ... 4. Our Oct 29 call will be the same time for everyone except US. The time for US will be one hour later. Thereafter, the times will be the same as today. No call of course during the TPAC week. ... any other annoucements? [11] http://www.w3.org/2008/webapps/wiki/TPAC2009Widgets [12] http://www.w3.org/2008/webapps/wiki/TPAC2009APIs [13] http://www.w3.org/2009/11/TPAC/Overview.html [14] http://www.w3.org/2009/11/TPAC/DevMeeting [ None ] PC spec: Potential bug in Rule for Identifying the Media Type of a File AB: the remaining open bug for P+C spec is documented in the Potential bug in Rule for Identifying the Media Type of a File thread ( [15]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/01 83.html ). ... earlier today Marcos responded to Marcin's latest proposal ( [16]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/02 93.html ). I think this now closes this bug. Any comments? [15] http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/0183.html [16] http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/0293.html MH: I looked at MC's comments ... I disagree with some proposals ... I did some tests ... I also disagree with limitation of file extension to 2 ranges ... proposed ranges are only for ASCII letters ... do not cover digits ... but there are some extension e.g. pk12 with digits ... think we need to consult i18n group ... not sure they will agree with ASCII only extensions ... I will submit a reply to Marcos ... One
RE: HTML5: has input device: use motion detection been included?
Hi there, Have you checked out the DAP working group? http://www.w3.org/2009/dap/ Cheers, David. David Rogers Director of External Relations, OMTP From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of ~:'' ??? Sent: 03 August 2009 15:27 To: wha...@whatwg.org; public-webapps@w3.org Cc: i...@hixie.ch; Doug Schepers; Charles McCathieNevile Subject: HTML5: has input device: use motion detection been included? HTML5: has input device: use motion detection been included? many laptops, mobiles and other devices come with cameras at this time. motion detection offers some potential accessibility benefits, and the opportunity to appear and play in game spaces. I raised this issue before on this list , but received no response: http://lists.w3.org/Archives/Public/public-webapi/2007Dec/0056.html Apple Bug ID 5653030: iSight internal: motion detection 'Thank you for the suggestion. Will explore opportunities. email. also raised recently with Ron Festejo, game developer, eyetoy, Sony. more background detail on the webkit bug: https://bugs.webkit.org/show_bug.cgi?id=16474 regards ~: Eric Carlson, whk prompted me to raise this once again.
FW: BONDI 1.01 Approved Release
Apologies, I should have also forwarded this onto the WebApps group for your information. Thanks, David. From: public-device-apis-requ...@w3.org [mailto:public-device-apis-requ...@w3.org] On Behalf Of David Rogers Sent: 15 September 2009 18:44 To: public-device-apis Subject: BONDI 1.01 Approved Release Dear all, Prior to the DAP call tomorrow, I wanted to direct you to the BONDI 1.01 Approved Release at: http://bondi.omtp.org/1.01/ . This was released on the 27th of July and contains minor updates and editorials to the 1.0 release. The following areas have been updated: * JavaScript APIs * JavaScript API Design Patterns * Architecture Security Requirements and Appendices I think the design patterns would be a good early point for discussion. Thanks, David. David Rogers OMTP Director of External Relations
[widgets] PC progression to CR
Art, Marcos, Please could you give us an update on the status of the progression of Widgets PC to CR? I noticed on the publication status page this is still marked as LCWD. We would like to see prompt progression of this work given the level of effort that has been put in by all parties. Thanks, David. David Rogers OMTP Director of External Relations The information contained in this e-mail and in any files transmitted with it is confidential and intended for the addressee only. If you are not the intended recipient(s) any distribution, copying or use of the information in this communication is prohibited and may be unlawful. If you have received this e-mail in error please notify the sender. This e-mail and any reply may be examined for purposes of reasonable supervision and monitored to ensure the maintenance of standards. This e-mail and any attachments have been scanned for viruses prior to leaving the sender's system but the sender will not be liable for any losses as a result of any viruses being passed on.
RE: [widgets] PC progression to CR
Thanks Marcos, my comments below, marked [DAVID]: -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: 16 July 2009 12:53 To: David Rogers Cc: Arthur Barstow; Web Applications Working Group WG Subject: Re: [widgets] PC progression to CR On Thu, Jul 16, 2009 at 1:36 PM, David Rogersdavid.rog...@omtp.org wrote: Art, Marcos, Please could you give us an update on the status of the progression of Widgets PC to CR? The editor's draft will be the one that is published (it is stable and ready to go, and has been for a few days): http://dev.w3.org/2006/waf/widgets/ I noticed on the publication status page this is still marked as LCWD. We would like to see prompt progression of this work given the level of effort that has been put in by all parties. Agreed. It's up to the W3C to gives us an publication date and set up the directors' call. We've done all we can as a WG I think. Not sure what the hold up is now. From past experience, even though this doc is done, my guesstimate is that the document will be published sometime in July (~3rd) at the earliest. [DAVID] Thanks for clarifying on August 3rd. I think I express the entire group's sentiment by saying that we need to improve on this, at the very least to improve in the future for the remaining specs. I appreciate it is the holiday period but again, given the effort that has been put in and the foreknowledge that we were going to propose this as CR, how does it take nearly a month to get this through? -- Marcos Caceres http://datadriven.com.au
BONDI Approved Release 1.0
Dear all, As I mentioned on the widgets call today, OMTP has released the 'BONDI 1.0 Approved Release', incorporating feedback received from the Candidate Release. The specifications can be downloaded from http://bondi.omtp.org. We will continue to work on our Reference Implementation to bring it in-line with the current draft W3C specifications and the OMTP BONDI specifications, along with putting up some sample widgets. On behalf of OMTP, I would like to thank you all for your feedback and input, all of which has helped greatly. The documents reference today's LCWD of the W3C PC specification and the April 30th LCWD of the Widgets Digital Signatures spec. We have a face-to-face meeting next week in London where we'll be working on the next stages for the BONDI project. Please feel free to contact me if you have any questions. I look forward to seeing you all again at the W3C widgets face-to-face meeting soon. Thanks, David. David Rogers OMTP Director of External Relations
RE: [widget-digsig] Pls review: Additional considerations on elliptic curve algorithms to consider
Marcos, Surely the logic should support algorithm evolution in that way. If it is a SHOULD it doesn't mean that engines need to support all algorithms - that would be a SHALL? If we say nothing at all, you run the risk of dropping off a security cliff if you need to migrate in the future. A SHOULD at least prescribes an intended roadmap and gives the option for implementers to go for that if they so choose. Thanks, David. -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcos Caceres Sent: 23 April 2009 08:53 To: Priestley, Mark, VF-Group Cc: Frederick Hirsch; Web Applications Working Group WG; Babbage, Steve, VF-Group Subject: Re: [widget-digsig] Pls review: Additional considerations on elliptic curve algorithms to consider On Thu, Apr 23, 2009 at 9:31 AM, Priestley, Mark, VF-Group mark.priest...@vodafone.com wrote: Hi Frederick, All, Vodafone supports the move to support ECDSA in XML Signature 1.1 [2] and welcomes the new clarifying text. Vodafone will not object to ECDSAwithSHA256 being specified as mandatory [2] however we would like to propose that it is a recommended algorithm in Widgets 1.0: Digital Signatures [5] (e.g. a SHOULD). Sorry, it doesn't make sense to have them as a should in this context. Either they are in or out because in practice engines will need to support all prescribed algorithms. Lets keep to the smallest possible subset of most commonly used algorithms in 1.0; every algorithm we add makes this specification more difficult/expensive to implement, adds more points of failure, etc. If the market shifts to new algorithms, then we can add those later in a new draft. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
[widgets] access element
Dear all, Please find below some input from the OMTP membership for the access element discussion. Overall, the functionality provided does what we want. It is just about as simple as it can be, which is good. There is functionality in here that we did not have with target - such as the ability to specify a path and query string - but that's OK. The current draft really doesn't say very much about what the consuming User Agent is supposed to do with the information; it says syntactically what is valid but hardly anything about the processing. OMTP propose to have some text to cover this such as: * Each access element that includes a uri attribute defines a set of target IRIs. * The set of target IRIs for the Widget is the union of all of the target IRIs defined by each access element. * The User Agent SHALL prevent any network access by the Widget, by any method*, to an IRI that does not belong to the set of target IRIs. * The User Agent's security policy MAY prevent network access by the Widget to an IRI that does belong to the set of target IRIs. Note: * by any method is a bit weak and it might be necessary to be explicit about what this means. It at least should cover programmatic access (such as by XHR) and network access triggered by the processing of specific DOM element. The drafting could do with tidying in some places, e.g.: * .. the host ... must be granted access to ... Apart from being grammatically broken, OMTP think it is better to have a precise definition of the set of target IRIs, and then have a separate statement about what membership of that set signifies. * Similar comment with lower-level domains. There should be something explicit about it meaning sub domains at arbitrary depth from the specified domain. * It should explicitly say that using the wildcard character in any position other than the first character in a domain specifier is invalid. I.e. it's not intended to be a general glob expression as in a.*.com Thanks, David. David Rogers OMTP Director of External Relations
RE: FW: problems using http://bondi.omtp.org/
Hi Josh, Many thanks for your input, again I'll ensure your comments are considered. Thanks, David. -Original Message- From: timeless.b...@gmail.com [mailto:timeless.b...@gmail.com] On Behalf Of timeless Sent: 23 March 2009 14:17 To: David Rogers Cc: WebApps WG Subject: Re: FW: problems using http://bondi.omtp.org/ 2009/3/18 David Rogers david.rog...@omtp.org: I haven't heard anything back from you - do you have some comments to submit? The deadline is the 23rd of March. sorry, i've been buried. BONDI_Architecture_Security_Task_CR10.pdf 2.1.1WIDGET As described in Widgets 1.0: The Widget Landscape [2], a Widget is an interactive application for displaying and/or updating local data or data on the Web, packaged in a way to allow a single download and installation on a user'smachine or mobiledevice.A Widget may run as a standalone application (meaning it can run outside of a web Browser) hosted in the Widget User Agent (see below). the spec no longer talks about Widget User Agent, and this is a good example of why trying to drive other independent but dependent documents to finalization sooner is a bad idea. ? JavaScriptextension: the mechanisms whereby JavaScript code executing within the Web engine is bound to, and therefore able to invoke, JavaScript APIs; That extension isn't capitalized and means something totally different from what it means in other areas are both unfortunate. ? AccessControl: the system thatenforces a SecurityPolicy, responsible for determining whether, and under what circumstances, a Web Applicationis allowedto use a specific JavaScript API or associated underlying Device Capability. That access control sounds like a w3 spec but means something different is also unfortunate. it is not prescriptive aboutwhoshould bethe management authority of any particular aspect of terminal security policy. terminal security policy is not defined within this document and isn't a term with which I'm familiar. (terminal Security Policy is also used once later) Note that Terminal doesn't appear to be defined either. The established principles and experience of the deployment of the existing OMTP Application Security Framework [4]) I can't find an open parenthesis, I'm using Foxit Reader 3.0 build 1301 If the BONDI format version indicated in a bondi element is greater (later) than that supported a Web So far parsing hasn't defined numbers and greater than. xmlns:bondi='http://bondi.omtp.org/ns/widgets' using fancy quotes in examples is poor form (something has removed the fancy quotes from my paste, but they were fancy) as iirc xml doesn't allow random quotes. where version is a version string of the form major.minor, where each of major and minor are numeric strings of at least one digit. May I use Arabic, Farsi or Indic numerals? if either the presentation orresources elements are [either] are = is :) ? background-operation ? hidden-operation I would strongly caution against using hyphens anywhere, as it's likely someone will use some random dash which isn't the one you want and complain. ? automatic ? indicates that the Widget may initiate access to the network as a result of an internal action not triggered by user interaction unattended sounds like a better name ? frequency ? indicates the typical frequency of attempted network connection for data transfer, measured as the number of network connection attempts made per hour is a very strange name for what it does. I'm not certain how the name will be misinterpreted, but I expect it to be :). ? min-volume ? indicates the typical minimum aggregate upload and download data transfer volume size per hour in kilobytes Volume is likely to be confused with audio. And again hyphens are a bad idea. Something that has the word 'data' or 'bandwidth' or something similar seems like a better choice. ? host ? indicates the internet domain or IP address of this target external site. Does this support ipv6 notation? does it support 32bit numbers? You haven't indicated any port restrictions which worries me. ? min-private ? indicates the typical minimum requirement of the Widget for local persistent storage of private data, expressed in Kbytes. Is a very strange name. I also see no reason to use kilobytes here. I'd recommend using Megabytes throughout. (ie APIs in addition to the standardised client- side DOM APIs supported in the browser environment). i.e
RE: [widgets] Comments on the 9-Feb-2009 BONDI v1.0 Release Candidate
Hi Art, I'll ensure that this input is considered. Many thanks for your feedback. David. -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: 23 March 2009 01:02 To: David Rogers Cc: public-webapps Subject: [widgets] Comments on the 9-Feb-2009 BONDI v1.0 Release Candidate David - I was not able to submit my comments via the link you provided below. Here is what I wanted to submit ... Below are some comments regarding the BONDI 1.0 Release Candidate (RC). These comments are sent as a Chair of the W3C's Web Applications (WebApps) Working Group (WG) and do not necessarily reflect the view of my employer and they do not reflect the consensus of the WebApps WG. My comments are limited to the RC's use of the WebApp's Widgets specs and do not address any of the other functionality in this RC. First, it is good OMTP intends to use various Widgets specifications being developed by the WebApps WG. However, the use of those specs, as codified in this RC raises serious concerns and if this RC is implemented and deployed without addressing these concerns, the result will be increased fragmentation in the market. * Use of incomplete specifications - the RC normatively references at least three of the W3C's Widgets specs and all of these specs are still in the Working Draft (WD) state and all of these WDs clearly state the spec is not yet ready to be implemented. Thus, the RC is by definition also a work in progress and hence not yet stable enough to be implemented. Yet, the expectation appears to be that OMTP considers the RC complete and stable enough to be implemented in products. * Spec forking and fragmentation - since the RC uses incomplete Widgets specs, OMTP has taken the liberty of completing the Widgets specs by both specifying fixes to known holes and issues and by specifying extensions to the Widgets specs. This effectively results in forking the Widgets specs and exacerbates fragmentation by promoting implementations of BONDI widgets that are will not be compatible with implementations of W3C widgets. * Interoperability - it is not possible to objectively define what it means for implementations of this RC to be interoperable. At a minimum, I would expect the RC's exit criteria to include a test suite that tests every assertion in the specs. Additionally, to prove the RC can be implemented in an interoperable way, I would expect the RC's exit criteria to require at least two implementations to pass all of the tests. Lastly, it isn't too late to address the above concerns if OMTP is willing to work with the WebApps WG. In particular, we can work together to: address issues in the relevant Widgets specs, complete the Widgets specs and create a comprehensive test suite. -Regards, Art Barstow (Chair of W3C's Web Applications WG) On Mar 18, 2009, at 11:33 AM, ext David Rogers wrote: Dear all, I'd like to remind webapps members that the formal period for feedback on the BONDI candidate release 1.0 specifications is the 23rd of March 2009. I encourage you to provide feedback before that date, in order that we can consider this before the specification for 1.0 release is finalised. Feedback can be registered as formal Change Requests at [1]. Please let me know if you need any more information. Thanks, David. [1] http://bondi.omtp.org/Lists/BONDI%2010%20CR%20%20Feedback/ AllItems.aspx David Rogers OMTP Director of External Relations No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.11.23/2016 - Release Date: 03/22/09 17:51:00
Re: BONDI Candidate Release 1.0 - open for public comment until 9th of March 2009
Dear Art, Thanks for the email. Please see my comments inline marked [DAVID]. David, Since many of WebApps' members are not familiar with OMTP and BONDI, I have a some first order process-related questions regarding the proposed Release Candidate (RC). I'll withhold other comments e.g spec forking, fragmentation, etc. for now. * Where can we find the process that describes OMTP's comment and response process/protocol as well as the next step after RC? Does OMTP's process include a consensus commitment regarding the public's comments (as does the W3C's process [1])? [DAVID] We can receive any public comments through either our public forum (under feedback at the bottom left of the BONDI homepage) or through a formal change request. In order to register a formal change request you will need to register for an account first. OMTP will discuss all comments during our working group meetings. * Where is the public archive for the comments? [DAVID] All the public comments are stored on the BONDI site, viewable to all. Please see the links from the Release Candidate page. * Where is the exit criteria for this RC? Assuming this criteria requires two or more interoperable implementations (as is typically the case for W3C Candidate specs), where can we find the data that show there are interoperable implementations of the RC? [DAVID] This is dependent on the feedback received from the public review. I should add that we have extended this review period - it will now close on the 23rd of March 2009. I'll be able to give you some more information following those discussions. Clearly we are not going to encourage non-interoperable solutions as the whole intention of BONDI is to have interoperable widgets across devices. * Based on a scan of [2], it appears this RC codifies the following version of WebApps' widgets specs: Packaging and Configuration - 12- Dec-2008; Digital Signatures - unspecified; APIs and Event - not included; Updates - the 07-Oct-2008 FPWD. Please confirm/clarify. [DAVID] As Marcos raised in the meeting, there was an error in one of these references to an earlier draft. You are welcome to register this as feedback. You are correct in stating that we do not reference the APIs and Events spec yet. Our plan is to update references upon the closure date for feedback (23rd of March). * Regarding the following text in [2]: [[ BONDI has chosen to adopt the W3C Widgets 1.0: Packaging and Configuration [7] specification. At the time of writing this specification has been published by the W3C Web Applications group (http://www.w3.org/2008/webapps) as a Working Draft at Last Call, and is judged to be stable enough to use as a basis for this BONDI specification. ]] Given the clear Implementers should be aware that this document is not stable. warning in this LCWD [3], what criteria was used to determine this LCWD is judged to be stable enough to use as a basis for this BONDI specification? [DAVID] Given the wealth of widget platforms being developed and already in the market and OMTP's timelines, I think this is the case for many other organisations who are developing widget solutions. It is our intention to deliver a W3C compliant BONDI once the W3C specifications are complete. We are fully aware that the specs could change. As agreed last week, we will produce an evolution plan to show how we intend to do this. We have committed to doing as much as possible to help W3C in working towards this. Indeed, every person around the table at the Widgets meeting last week was an OMTP member. Thanks, David. OMTP Director of External Relations -Regards, Art Barstow, Chair of WebApps WG [1] http://www.w3.org/2005/10/Process-20051014/policies.html#Consensus [2] http://bondi.omtp.org/Documents/CR10/ BONDI_Architecture_Security_Task_CR10.pdf [3] http://www.w3.org/TR/2008/WD-widgets-20081222/ On Feb 26, 2009, at 3:46 AM, ext David Rogers wrote: Dear all, As discussed in the Widgets F2F in Paris, please find the links to the OMTP BONDI Candidate Release 1.0 documentation as follows. This is open for public comment at the moment until the 9th of March 2009 and can be downloaded from the BONDI site [1]: 1) BONDI Architecture Security [2] 2) BONDI Architecture Security Appendices [3] 3) BONDI Interfaces [4] 4) BONDI Architecture Security Lifecycle Events Use Cases [5] 5) All above files in a zip [6] Please also have a look at the BONDI APIs [7]. We would welcome any feedback or change proposals and if you have any questions, please feel free to email me. Thanks, David. [1] http://bondi.omtp.org/ [2] http://bondi.omtp.org/Documents/CR10/ BONDI_Architecture_Security_Task_CR10.pdf [3] http://bondi.omtp.org/Documents/CR10/ BONDI_Architecture_Security_Task_Appendices_CR10.pdf [4] http://bondi.omtp.org/Documents/CR10
BONDI Candidate Release 1.0 - open for public comment until 9th of March 2009
Dear all, As discussed in the Widgets F2F in Paris, please find the links to the OMTP BONDI Candidate Release 1.0 documentation as follows. This is open for public comment at the moment until the 9th of March 2009 and can be downloaded from the BONDI site [1]: 1) BONDI Architecture Security [2] 2) BONDI Architecture Security Appendices [3] 3) BONDI Interfaces [4] 4) BONDI Architecture Security Lifecycle Events Use Cases [5] 5) All above files in a zip [6] Please also have a look at the BONDI APIs [7]. We would welcome any feedback or change proposals and if you have any questions, please feel free to email me. Thanks, David. [1] http://bondi.omtp.org/ [2] http://bondi.omtp.org/Documents/CR10/BONDI_Architecture_Security_Task_CR 10.pdf [3] http://bondi.omtp.org/Documents/CR10/BONDI_Architecture_Security_Task_Ap pendices_CR10.pdf [4] http://bondi.omtp.org/Documents/CR10/BONDI_Interfaces_Task_CR10.pdf [5] http://bondi.omtp.org/Documents/CR10/BONDI_Architecture_Security_Applica tion_Lifecycle_Events_Use_Cases_CR10.pdf [6] http://bondi.omtp.org/Documents/CR10/BONDI%201_0%20Candidate%20Release.z ip [7] http://bondi.omtp.org/apis/ David Rogers OMTP Director of External Relations
[widgets] OMTP BONDI 2nd public working draft released
Dear all, I'd like to inform you that the 2nd working draft publications of the OMTP BONDI are online and can be downloaded from today[1]. I've listed the released documents below. You will see that we have referenced the W3C Widget Requirements. The 1st public release documents are also archived on the website. 1. OMTP BONDI Architecture Security Public Working Draft v0.43 Gives an overview of the architecture and security issues that need to be addressed when delivering a secure framework that will allow application developers access to sensitive APIs 2. OMTP BONDI Security Framework for API Access Addresses the specific requirements around and proposes a specific model for implementing flexible security model around access to sensitive APIs 3. OMTP BONDI Interfaces Public Working Draft v0.71 Outlines 11 specific interfaces to be made available to web developers via JavaScript interfaces and details the requirements upon those APIs 4. OMTP BONDI Architecture Security Application Lifecycle Events Use Cases Public Working Draft v0.15 Augments the architecture and security requirements with an in-depth analysis of the lifecycle management issues that need to be addressed 5. OMTP BONDI Example Policies v1.0 (Zip file) BONDI example polices to demonstrate the flexible nature of the BONDI security model If you have any questions, please don't hesitate to get in contact. [1] http://www.omtp.org/Bondi/ David Rogers OMTP Director of External Relations
[Widgets] BONDI update from Austin
Dear all, At the last conference call I promised to give you an update on the main points from our BONDI Architecture Security meeting which relate to W3C. As I have already said on previous calls, BONDI would like to be in-line with W3C. Specifically, at a high level: * BONDI will require widgets to be packaged as defined by the W3C Widgets 1.0: Packing and Configuration specification * BONDI will specify the use of the W3C Widgets 1.0: Digital Signature for the signing of widgets These agreements were made on the current working drafts of the W3C work and also with the understanding that the W3C specifications will be completed within the timescales required. We will continue to actively contribute to this work to help this happen. We are planning the next public release of BONDI documents soon which will reflect the points above. I will inform you all when these are online and available to download. If you have any comments or questions, please feel free to contact me. Thanks, David. David Rogers OMTP Director of External Relations
RE: [widgets] OMTP input to W3C Widget Requirements (1 of 2)
Hi Marcos, On behalf of OMTP, I'd like to thank you for your hard work integrating the OMTP input to the requirements spec. We're happy with the changes in [1]. Thanks, David. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marcos Caceres Sent: 05 September 2008 14:30 To: David Rogers; Nick Allott; Priestley, Mark, VF-Group; Paddy Byers Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [widgets] OMTP input to W3C Widget Requirements (1 of 2) Hi All, I've now integrated the OMTP requirements into the Req spec. OMTP crew, I'm made lots of edits (and dropped some of your requirements with Mark's permission) so please check to see that your intent is still conveyed (and that I haven't introduced any new typos, etc.). Apologies to those who are still waiting for me to respond to your comments, I'm going as fast as I can and will do my best to address everyone's comments within the next week. Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-reqs/ On Fri, Aug 1, 2008 at 12:30 PM, David Rogers [EMAIL PROTECTED] wrote: Dear Art, Marcos and all, Please find attached the OMTP BONDI input to the W3C Web Applications WG Widget Requirements last call. I've extracted the text of the input below. Please note this is the first of two sets of input. This first input contains comments to existing requirements and proposals for new requirements. The second document contains more general comments, applicable to the Widget Requirements and also the Packaging and Configuration work. Introduction OMTP is a forum backed by many of the largest mobile operators and has members from many hardware and software vendors across the value chain. It was set up with the aim of gathering and driving mobile terminal requirements to ensure consistent and secure implementations, thereby reducing fragmentation and simplifying the customer experience of mobile data services. OMTP recommendations benefit carriers, content providers, middleware vendors and handset manufacturers to develop open and compatible mobile devices. OMTP have created their BONDI initiative to specifically address the problem of fragmentation in the evolution of the mobile web and to ensure the protection of the user from malicious web based services. The BONDI initiative will be delivering documentation throughout 2008 with the aim of driving activities in other appropriate standardisation and industry bodies such as W3C. Devices supporting some of the features of BONDI will become available in 2009. This document forms the input from BONDI relating to the security aspects of the W3C Widgets: 1.0 Requirements found at http://www.w3.org/TR/2008/WD-widgets-reqs-20080625/. The document is divided into two parts; the first part details proposed changes to existing W3C requirements, the second part proposes new requirements that for inclusion. Part I - Changes to Existing Requirements Proposed By BONDI R11. Digital Signature We suggest the following re-wording of the existing requirement so that it reads: A conforming specification MUST specify a means to verify the authenticity and integrity of all resources in a widget resource, with the exception of any resources explicitly excluded by the specification. A conforming specification MUST provide this capability by specifying a processing model for generating and verifying a digital signature associated to a widget resource. The digital signature scheme MUST be compatible with existing Public Key Infrastructures (PKI), particularly X.509 digital certificates. In addition, the recommended digital signature format SHALL support the ability to include a certificate chain with a digital signature to enable the receiving device to build a certificate chain from the end entity certificate used to generate the signature to a locally stored root certificate. In addition, the recommended digital signature format SHOULD support the ability for a widget resource to be signed using multiple end entity keys (i.e. it SHOULD be possible to include multiple signatures and associated certificate chains). The proposed changes attempt to tighten and clarify the use of digital signatures and certificate chains. In addition we suggest that the following text should be added to the existing requirement: A conforming specification SHALL specify the expected behaviour when multiple signatures and certificate chains are provided. A conforming specification SHALL specify that if none of the signatures and certificate chains can be verified, e.g. because of missing root certificates or where any certificates in the chain have expired or are not yet valid, then the widget resource SHALL be treated as unsigned. A conforming specification SHALL specify that the widget environment SHALL not install or load a widget resource when it can determine that any certificate in the chain has been revoked
RE: [widgets] OMTP input to W3C Widget Requirements (2 of 2)
Hi Thomas, Mark Priestley of Vodafone will respond to you on OMTP's behalf in relation to the comments below. Speak to you all on the call later on today. Thanks, David. -Original Message- From: Thomas Roessler [mailto:[EMAIL PROTECTED] Sent: 07 August 2008 01:30 To: David Rogers Cc: public-webapps@w3.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Nick Allott Subject: Re: [widgets] OMTP input to W3C Widget Requirements (2 of 2) David, thanks a lot for your comments. Some quick reactions to the changes that you propose... A conforming specification SHALL specify the expected behaviour when multiple signatures and certificate chains are provided. A conforming specification SHALL specify that if none of the signatures and certificate chains can be verified, e.g. because of missing root certificates or where any certificates in the chain have expired or are not yet valid, then the widget resource SHALL be treated as unsigned. A conforming specification SHALL specify that the widget environment SHALL not install or load a widget resource when it can determine that any certificate in the chain has been revoked. Note that PKIX CRLs are only required to cover *un*expired certificates. Therefore, a client may not be able to distinguish an expired and a revoked certificate. I'm therefore wary of the proposal to require at least one valid signature chain unless there is at least one revoked chain -- it seems a bit inconsistent. I'd rather that we say very clearly that either all certificate chains must validate and lead up to a trusted root, or that this must be true for at least one. You suggest referencing RFC 3280. I'd suggest we reference RFC 5280 instead. ;-) In the Signing Procedure Agnostic requirement, you write: A conforming specification SHALL specify a mechanism for signing a widget resource that does not explicitly or implicitly impose any restrictions on the procedure for generating the signature. That makes a lot of sense, although there is a question whether a certain set of algorithms should be fixed for interoperability. (SHA-256 and RSA, for example). You get to that point in a proposed later requirement; I actually wonder whether it's still worth calling out SHA-1 as a requirement there. Back to the Signing Procedure Agnostic requirement: More specifically, a conforming specification SHALL allow the use of end entity keys stored in a secure module in a hosted environment. A conforming specification SHALL specify that implementations SHOULD be able to use end entity keys via a PKCS#11 interface. I'm not sure how this fits together with the rest of the requirements, and with the specification overall. Could you clarify? The Key Usage Extension requirement is a good catch. I'd like to understand the motivation for the inclusion of revocation information requirement better. I think that it's a good idea to mandate widget engines to consult CRLs. However, I wonder if packaging these into the widget itself won't cause a significant likelihood of stale information, at least in Web-based deployments. That's all for the moment; I look forward to tomorrow's call. -- Thomas Roessler, W3C [EMAIL PROTECTED] On 2008-08-01 12:41:02 +0100, David Rogers wrote: From: David Rogers [EMAIL PROTECTED] To: public-webapps@w3.org, [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Nick Allott [EMAIL PROTECTED] Date: Fri, 1 Aug 2008 12:41:02 +0100 Subject: [widgets] OMTP input to W3C Widget Requirements (2 of 2) List-Id: public-webapps.w3.org X-Spam-Level: Archived-At: http://www.w3.org/mid/[EMAIL PROTECTED] X-Bogosity: Unsure, tests=bogofilter, spamicity=0.50, version=1.1.6 Dear Art, Marcos and all, Please find attached the second set of OMTP BONDI input to the W3C Web Applications WG Widget Requirements last call as outlined in my last email. The relevant text from the document is extracted below: Expressing Widget Dependency Information in Widget Packaging Introduction OMTP is a forum backed by many of the largest mobile operators and has members from many hardware and software vendors across the value chain. It was set up with the aim of gathering and driving mobile terminal requirements to ensure consistent and secure implementations, thereby reducing fragmentation and simplifying the customer experience of mobile data services. OMTP recommendations benefit carriers, content providers, middleware vendors and handset manufacturers to develop open and compatible mobile devices. OMTP have created their BONDI initiative to specifically address the problem of fragmentation in the evolution of the mobile web and to ensure the protection of the user from malicious web based services. The BONDI initiative will be delivering documentation throughout 2008 with the aim of driving activities in other appropriate standardisation and industry bodies such as W3C. Devices supporting some of the features of BONDI
