Add API for access checks on observed objects

Add API for access checks on observed objects

When calling Object.observe on an object, if that object has access
checks enabled, call out to the embedder asking if observing the object
is allowed and throw if it is not.

In order to accomplish this, a new version of SetAccessCheckCallbacks()
has been added to the API, with the old version to be V8_DEPRECATED()
once Chromium/WebKit is updated to use the new API.

An alternate approach would have been to filter out objectionable
change records either when enqueueing or delivering them, but this
would have likely been much slower and would have required some gymnastics
to get the proper context info for the access check on the WebKit side.

[adamk, 2013-01-07 23:19:16]

Note that this is my first attempt to add anything to the V8 API, and I realize
it's something of an unfortunate change. Willing to consider other options as
they're suggested, but the existing security callbacks just aren't sufficient to
ask the right question.

[rossberg, 2013-01-17 17:49:13]

Hm, I'm not sure you can circumvent the filtering you describe as an
"alternative approach". Even with your API, a client can still choose to make an
object observable, but disallow access to some properties, can't they?
Observation has to respect that in any case.

Also, I'm afraid deprecating parts of the existing API to adapt to an
experimental feature won't fly. If we introduce something new into the API at
all then it must be separate from existing functionality and clearly marked as
experimental.

[adamk, 2013-01-24 00:02:34]

On 2013/01/17 17:49:13, rossberg wrote:
> Hm, I'm not sure you can circumvent the filtering you describe as an
> "alternative approach". Even with your API, a client can still choose to make
an
> object observable, but disallow access to some properties, can't they?
> Observation has to respect that in any case.

The proposal here is basically that the embedder ought to disallow observation
to avoid leaking reads via oldValue. You're correct that that doesn't seem quite
right, but it's sufficient for the WebKit use case, and it's not clear to me
that there's any other use of access checks beyond web security. I would have
liked to just disallow observation of objects that have access checks enabled,
but that'd disallow observing Window.

I'd be interested if there are use cases besides web security for access checks.

> Also, I'm afraid deprecating parts of the existing API to adapt to an
> experimental feature won't fly. If we introduce something new into the API at
> all then it must be separate from existing functionality and clearly marked as
> experimental.

Agree that that just seems wrong. If we did decide that an API change was the
way to go I'd likely delay it until it was agreed that the feature was no longer
experimental.

[rossberg, 2013-01-28 13:38:29]

On 2013/01/24 00:02:34, adamk wrote:
> On 2013/01/17 17:49:13, rossberg wrote:
> > Hm, I'm not sure you can circumvent the filtering you describe as an
> > "alternative approach". Even with your API, a client can still choose to
make
> an
> > object observable, but disallow access to some properties, can't they?
> > Observation has to respect that in any case.
> 
> The proposal here is basically that the embedder ought to disallow observation
> to avoid leaking reads via oldValue. You're correct that that doesn't seem
quite
> right, but it's sufficient for the WebKit use case, and it's not clear to me
> that there's any other use of access checks beyond web security. I would have
> liked to just disallow observation of objects that have access checks enabled,
> but that'd disallow observing Window.
> 
> I'd be interested if there are use cases besides web security for access
checks.

I don't actually know. But regardless, I think the API should stand for itself
and be self-consistent. Ignoring read access restrictions in the case of
observation feels too shady for my taste, even if that case wouldn't be
exploited by any (current) embedder.

[adamk, 2013-08-15 17:39:54]

This has been superseded by https://codereview.chromium.org/22962009/ (which
includes no API changes).