- From: Marcos Caceres <marcosc@opera.com>
- Date: Mon, 21 Sep 2009 20:08:35 +0200
- To: Arthur Barstow <Art.Barstow@nokia.com>
- Cc: public-webapps <public-webapps@w3.org>
Hi Art, For the sake of the DoC, can you please acknowledge that the comments below have been addressed and your are satisfied with the way the WG addressed your comments. Kind regards, Marcos 2009/9/14 Marcos Caceres <marcosc@opera.com>: > Art, > Upon further consideration of your feedback, I have removed the > following assertions from the spec (they were redundant because either > WebStorage already says it, or the spec says it in another place > better): > > [[ > A user agent must be able to create unique storage areas for each > origin of a widget. > > A user agent must establish the origin of a widget using the rules set > forth in the [Widgets-URI] specification. > > A user agent should avoid deleting data from a storage area while a > script that could access that data is running. > > and the user agent must behave in accordance with this specification > any time a script accesses a storage object that a user agent has > associated with the origin of a widget. > > A user agent should limit the total amount of space allowed for > storage areas; A minimum of 5MB per origin of a widget is recommended. > > Implementation feedback is welcome on an appropriate storage size for > widgets and will be used to update this suggestion in the future. > > A user agent should impose their own implementation-specific limits on > the length of otherwise unconstrained keys and values of a storage > area, e.g. to prevent denial of service attacks, to guard against > running out of memory, or to work around platform-specific > limitations. > ]]. > > On Mon, Sep 14, 2009 at 5:03 PM, Marcos Caceres <marcosc@opera.com> wrote: >> On Mon, Sep 14, 2009 at 2:01 PM, Arthur Barstow <Art.Barstow@nokia.com> wrote: >>> On Sep 13, 2009, at 3:23 PM, ext Marcos Caceres wrote: >>> >>>> On Wed, Sep 9, 2009 at 10:07 PM, Arthur Barstow <art.barstow@nokia.com> >>>> wrote: >>>>> >>>>> 3. The following statement doesn't seem necessary given preferences is of >>>>> type Storage; as such, I think it should be removed: >>>>> >>>>> [[ >>>>> A user agent must have the ability to directly read and write to the >>>>> storage >>>>> area (i.e., without needing to make use of the [WebStorage] >>>>> specification's >>>>> Storage interface) and must have the ability to delete a storage area. >>>>> ]] >>>> >>>> I don't agree. The above gives a storage area the ability to be >>>> populated with config.xml <preference> data without the UA using the >>>> Storage interface. This is important, as events must not be fired >>>> during pre-population. >>>> >>>> However, it might be that the above assertion needs to be rewritten to >>>> directly address the <preference> use case (hence making the assertion >>>> more testable). WDYT? >>> >>> Section 6. should prescribe everything that needs to be said thus I don't >>> think the text I quoted is necessary. If Section 6 doesn't sufficiently >>> address the mapping to <preference>, then yes, it should be updated. >> >> I agree, it now reads: >> "To facilitate the storage of preferences during the initialization of >> the preferences attribute, a user agent must have the ability to >> directly read and write to a storage area without invoking the methods >> of the [WebStorage] specification's Storage interface." >> >>>>> 6. The following assertion is another implementation detail that should >>>>> be >>>>> removed or made non-normative: >>>>> >>>>> [[ >>>>> A user agent should impose their own implementation-specific limits on >>>>> the >>>>> length of otherwise unconstrained keys and values of a storage area, e.g. >>>>> to >>>>> prevent denial of service attacks, to guard against running out of >>>>> memory, >>>>> or to work around platform-specific limitations. >>>>> ]] >>>> >>>> The above is a boilerplate "hot potato" assertion, that puts the onus >>>> of securing the implementation on implementers. It's basically there >>>> to protect the WG from people asking "what happens if I try to >>>> store/do something strange". I don't know if we should remove it. >>> >>> I don't think the quoted text above provides any protection nor particular >>> value [hint: nuke it or make it a Note]. >> >> Ok, it's a note now. >> >> >> -- >> Marcos Caceres >> http://datadriven.com.au >> > > > > -- > Marcos Caceres > http://datadriven.com.au > -- Marcos Caceres http://datadriven.com.au
Received on Monday, 21 September 2009 18:09:12 UTC