Re: [widgets] Preferences API
Arve Bersvendsen wrote: On Tue, 30 Sep 2008 01:35:42 +0200, Marcos Caceres [EMAIL PROTECTED] wrote: Hi All, I think we should dump the Widgets preferences API in favor of HTML5 DOM's storage API. Basically, preferences API basically replicates what DOM Storage already defines. Also, DOM storage is already implemented across three or four browsers and we can assume the specification to be fairly stable (or hopefully it will be by the time we get to CR). Dumping the preferences API will also avoid problems in the future as HTML5 becomes prevalent in the market. While I, in principle, agree that not replicating existing storage APIs is a good thing, are we sure that all widget implementations will implement HTML5? Also, are we sure that a preference storage may not have additional requirements that make them a bad match (such as encryption of stored data)? There is nothing that prevents requiring that that specific part of the HTML5 spec be implemented. This wouldn't require the whole of HTML5 to be implemented. Also, if there are additional requirements, it might be a good idea to raise them with the HTML5 WG to ensure that the storage API can be reused for widgets. / Jonas
W3C Workshop on Security for Access to Device APIs - London, December 10-11
[sorry for the cross-posting, please don't reply-to-all] Hello, W3C just announced a call for participation to a Workshop on security for access to device APIs from the Web, in London on December 10-11 2008. http://www.w3.org/2008/security-ws/ A W3C Workshop is an opportunity for any interested parties to interact and exchange ideas on the topics under discussion. W3C Membership is NOT required to participate in a W3C Workshop. This workshop will focus on the *security challenges* involved in allowing Web applications and widgets to access the APIs that allow to control devices features such as cameras, GPS systems, connectivity and battery levels, external applications launch, access to personal data (e.g. calendar or addressbook), etc, not traditionally available from the Web environment. To participate to this workshop, interested parties need to submit a position paper relevant to this topic before *October 30 2008* to [EMAIL PROTECTED] These position papers will be reviewed by the workshop program committee, and will serve as a basis for the agenda of the two days workshop. Submitters will be notified of acceptance of their papers by November 17. A position paper should: * explain your interest in the Workshop * be aligned with the Workshop's stated goals * be 5 to 10 pages long (2000 - 4000 words) * be formatted in (valid) HTML/XHTML, PDF, or plain text Interested parties are invited to inform the workshop organizers that they are planning to submit a position paper by sending as soon as possible an expression of interest to [EMAIL PROTECTED], including the number of persons from their organizations that are planning to attend the workshop. Topics in scope for the workshop include: * Existing frameworks on desktop and mobile platforms to regulate security policies for specific APIs, * Similarities and differences of the security approaches in desktop and mobile platforms, in a browser and in a widgets environment, * Usability of security relevant user interactions; issues and opportunities in the mobile environment, * Safe language and API subsets, and models for application use of such subsets, * Policy based trust delegation mechanisms, * Reducing the attack surface exposed by Web page scripts * Role of authentication of users and applications in securing API access, * Increasing awareness of good security practices for Web applications, * Usability of security and privacy policies The discussions at this workshop are expected to be relevant in particular to the following W3C Working Groups: * Web Applications Working Group * Geolocation Working Group * Ubiquitous Web Applications Working Group * HTML Working Group * Web Security Context Working Group Should you have any question, please contact Dominique Hazael-Massieux [EMAIL PROTECTED]. Regards, Dom
Re: [widgets] Preferences API
On Tue, Sep 30, 2008 at 12:19 PM, Arve Bersvendsen [EMAIL PROTECTED] wrote: On Tue, 30 Sep 2008 01:35:42 +0200, Marcos Caceres [EMAIL PROTECTED] wrote: Hi All, I think we should dump the Widgets preferences API in favor of HTML5 DOM's storage API. Basically, preferences API basically replicates what DOM Storage already defines. Also, DOM storage is already implemented across three or four browsers and we can assume the specification to be fairly stable (or hopefully it will be by the time we get to CR). Dumping the preferences API will also avoid problems in the future as HTML5 becomes prevalent in the market. While I, in principle, agree that not replicating existing storage APIs is a good thing, are we sure that all widget implementations will implement HTML5? As Jonas said, we would just mandate that implementations implement just that one part of HTML5. Or, we just rip that part of HTML5 and put it in our spec and make sure we keep them synced. Also, are we sure that a preference storage may not have additional requirements that make them a bad match (such as encryption of stored data)? I also agree with Jonas that if it's good for widgets, it's probably good for HTML5 as a whole. For V1 of widgets, I think that HTML5's storage meets r26 [1]. But if new requirements arise (such as data encryption) we should work with the HTML-WG on that. Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-reqs/#r26.- -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Preferences API
On Tue, Sep 30, 2008 at 5:36 PM, Arve Bersvendsen [EMAIL PROTECTED] wrote: On Tue, 30 Sep 2008 18:28:59 +0200, Marcos Caceres [EMAIL PROTECTED] wrote: While I, in principle, agree that not replicating existing storage APIs is a good thing, are we sure that all widget implementations will implement HTML5? As Jonas said, we would just mandate that implementations implement just that one part of HTML5. Or, we just rip that part of HTML5 and put it in our spec and make sure we keep them synced. If we are to do one of these, I'd very much prefer not to have to keep it continously updated until 2022. Agreed. If the Working Group feels comfortable with citing HTML5 for this feature, I think we should. Also, are we sure that a preference storage may not have additional requirements that make them a bad match (such as encryption of stored data)? I also agree with Jonas that if it's good for widgets, it's probably good for HTML5 as a whole. For V1 of widgets, I think that HTML5's storage meets r26 [1]. But if new requirements arise (such as data encryption) we should work with the HTML-WG on that. Note that encryption, which was my example here, may be an implementation detail. I was just trying to say something about the requirement for HTML5 and Widgets might be different. Understood. Appologies, I didn't mean to imply you meant it as an actual feature request. Having said that, the requirements for v1 in regards to this feature are clearly captured in the requirements doc. As we now have consensus within the working group regarding the requirements, I don't foresee them changing for V1. If we need to fork for V2, that should hopefully be ok. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
