Re: [widgets] Comments on Section 5 of the 18-Aug-2009 LCWD of A&E spec

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

Received on Monday, 14 September 2009 15:07:38 UTC