Re: [indexeddb] Keypath attribute lookup question

On Fri, Nov 11, 2011 at 5:07 PM, Israel Hilerio <israelh@microsoft.com>wrote:

> On Wednesday, November 09, 2011 4:47 PM, Joshua Bell wrote:
> >On Wed, Nov 9, 2011 at 3:35 PM, Israel Hilerio <israelh@microsoft.com>
> wrote:
> >>In section "4.7 Steps for extracting a key from a value using a key
> path" step #4 it states that:
> >>* If object does not have an attribute named attribute, then skip the
> rest of these steps and no value is returned.
>
> >>We want to verify that the attribute lookup is taking place on the
> immediate object attributes and the prototype chain, correct?
>
> >My reading of the spec: In 3.2.5 the description of add (etc) says that
> >the method creates a structured clone of value then runs the store
> >operation with that cloned value. The steps for storing a record (5.1)
> are the context where the key path is evaluated, which would imply that it
> is done against the cloned value. The structured cloning algorithm doesn't
> walk the prototype chain, so this reading would indicate that the attribute
> lookup only occurs against the immediate object.
>
> >I believe there's a spec issue in that in section 3.2.5 the list of
> >cases where DataError is thrown are described without reference to the
> >value parameter (it's implied, but not stated), followed by "Otherwise
> >this method creates a structured clone of the value parameter". That
> >implies that these error cases apply to the value, whereas the storage
> >operations apply to the structured clone of the value. (TOCTOU?)
>
> >We (Chrome) believe that the structured clone step should occur prior to
> the checks and the cloned value be used for these operations.
>
> What you're saying makes sense!  The scenario we are worried about is the
> one in which we want to be able to index on the size, type, name, and
> lastModifiedDate attributes of a File object.  Given the current SCA
> serialization logic, I'm not sure this is directly supported.  This could
> become an interoperable problem if we allow these properties to be
> serialized and indexed in our implementation but FF or Chrome don't. We
> consider Blobs and Files to be host objects and we treat those a little
> different from regular JavaScript Objects.
>
> We feel that the ability to index these properties enables many useful
> scenarios and would like to see all browsers support it.
>
> What do you and Jonas think?


That's a good scenario. I think this "works" and both of our
concerns/scenarios are satisfied if we mandate that the structured clone
occurs first.

Our concern is that the value can be captured at the time the method is
called, both to avoid TOCTOU issues with the value changing after the call
(either by directly mutating or having the prototype chain mutating) and to
allow the value to be moved across process boundaries efficiently.

For regular JS objects the clone is a snapshot of the object's properties,
without the prototype chain, which satisfies this concern. Per
http://www.w3.org/TR/html5/common-dom-interfaces.html#internal-structured-cloning-algorithm
the
structured clone of a File (or other explicitly-spec-sanctioned host
object) is also a File (...) with the same data - the concern is also
satisfied.

To avoid TOCTOU issues and thinking about ECMAScript edge cases, I think we
still want to mandate that the keypath evaluation does not walk the
prototype chain, e.g. a keypath of "foo" should not inspect the value of
Object.prototype.foo as that could change during the course of an
asynchronous operation - and that async operation could be executing in a
different process!

Given all of that, accessing properties of host objects may need to be
special cased if those would be considered "walking the prototype chain"
(but I'm not sure they are, will have to think/dig further)

So, in summary:
1. Snapshot first for predictable behavior
2. Don't walk the prototype chain, even though 1 precludes prototypes other
than Object.prototype
3. Host objects attribute access may need to be special cased if that runs
afoul of 1 or 2.

Thoughts?