Align cross-origin [[Delete]] with implementations

[annevk]

Returning false would only cause its callers to throw in “strict mode”.
Implementations however always throw. Always throwing also allows for
more implementation flexibility which is somewhat preferable here due
to the different cross-origin security architectures in browsers.

Fixes #1726.

[domenic]

We need to decide whether to throw a TypeError or a DOMException SecurityError... I wasn't clear from #1726 which it should be.

[annevk]

Seems nicer to match what ECMAScript would throw. Especially if we want to allow for varied implementation strategies.

[domenic]

I could see either way. We chose SecurityError for [[Get]]/[[GetOwnProperty]] and for "perform a security check". It seems kind of nice to separate the security errors from the normal TypeErrors.

[annevk]

Oh, hmm. I guess we should discuss all of them then.

[cdumez]

So [Get] / [GetOwnProperty] and [Set] throw a SecurityError as per the HTML specification, right? Shouldn't [Delete] throw a SecurityError as well?

Chrome throws a SecurityError. Firefox seems to throw a generic Error but then again, it seems it throws in generic Error for [Get] / [GetOwnProperty] / [Set] as well, which is not spec-compliant.

[domenic]

Yeah, I am leaning toward a SecurityError here for all cross-origin stuff.

[cdumez]

This does not update [[Delete]] for Location?

[domenic]

I think that's what this line is doing, it's just the diff makes it hard to see.

[cdumez]

This line seems to update Window's [[OwnPropertyKeys]]. Window's [[Delete]] is updated earlier in this patch. However, I do not see any changes to Location.

[domenic]

No, if you look at the actual source file, line 81702 is for location. (Check out line 81705 below). GitHub has an un-expandable gap between line 79325 (for window) and line 81699 (by which time we're in location).

[cdumez]

Ok, I guess I cannot read github diffs, sorry :)

[cdumez]

Cross browser, it seems we have the following

• Firefox: Throws a generic Error for [Get] / [Set] / [GetOwnProperty] / [Delete]
• Chrome: Throws a SecurityError for [Get] / [Set] / [GetOwnProperty] / [Delete]
• WebKit nightly: I have recently updated our behavior to match Chrome (and the spec) and throw a SecurityError for [Get] / [Set] / [GetOwnProperty]. I am working on the [Delete] now [1], which is why I filed Should deleting a cross-origin Window property throw? #1726. Given I have matched Chrome so far, my preference would be to spec a SecurityError for [Delete] as well.

[1] https://bugs.webkit.org/show_bug.cgi?id=161397

[annevk]

If we do that though, we should also update the places where we currently return false (that then make it throw) and throw a SecurityError instead. But all that seems uglier to me than consistently throwing a TypeError. And I believe not calling special attention to the security-sensitive failures is @othermaciej's preference, but maybe that changed.

[domenic]

I agree we should consistently throw a SecurityError, not just in get/set. So:

• [[GetPrototypeOf]] should throw instead of returning null. (http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4430)keep returning null; see discussion below
• [[SetPrototypeOf]] should branch on cross-origin vs. same-origin and throw SecurityError vs. return false (http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4434)
• [[IsExtensible]] should continuing returning true (http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4431)
• [[PreventExtensions]] should branch on cross-origin and throw SecurityError vs. return false (http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4432)
• [[GetOwnProperty]] should continue doing what it does now (SecurityError for cross-origin)
• [[DefineOwnProperty]] should switch to SecurityError instead of returning false for cross-origin (http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4433)
• [[Get]] should continue throwing a SecurityError
• [[Set]] should switch to SecurityError instead of returning false.
• [[Delete]] should switch to SecurityError instead of returning false.
• [[OwnPropertyKeys]] should keep returning useful values.

This scheme matches Chrome/Firefox more so than currently, with the exception that Firefox is using Error instead of SecurityError. Neither of them are returning false (leading to silent sloppy mode failures) and neither of them are throwing a TypeError.

I'm happy to make these updates as long as you sign off.

[annevk]

It's still not quite clear to me what the advantage of using SecurityError is. Also, we primarily need implementers such as @bholley, @ajklein, and @cdumez to sign off.

[cdumez]

[[GetPrototypeOf]] should throw instead of returning null.

Firefox and Chrome seem to agree with the specification and return null here though.

[bholley]

Yeah, I think null for the prototype is probably better.

[domenic]

Hmm, http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4430 gives an error in Chrome and Firefox though.

[bholley]

Yes, because proto is an accessor (access to which is denied), rather than a pure MOP operation.

[ajklein]

Adding @yuki3, who's a more representative Blink implementer for this stuff.

[yuki3]

+FYI for @jeisinger.

I'd support to update the spec to throw a SecurityError when deleting a property on a cross origin object.

I also agree with the goal of @domenic's proposal, but I'm not sure if each statement is right or not. For example, IIRC, crossOriginObj.proto must throws while Object.getPrototypeOf(crossOriginObj) must return null. However,
http://www.ecma-international.org/ecma-262/7.0/#sec-object.getprototypeof
says Object.getPrototypeOf(O) returns ToObject(O).[GetPrototypeOf]. So, IIUC, crossOriginObj.[[GetPrototypeOf]] needs to return null? Given that crossOriginObj.proto is an accessor property, is it a crossOriginObj.proto's duty to throw a SecurityError?

I agree with the resulting behaviors of @domenic's proposal, but not sure what layer is responsible to throw a SecurityError.

[domenic]

@bholley pointed out that __proto__ goes through two layers: first, it looks up Object.prototype.__proto__, an accessor property. Then, it executes the logic in that accessor property, to do O.[GetPrototypeOf]. So, it will throw a SecurityError in the first step, while directly doing Object.getPrototypeOf(o) does not. So I will edit my comment to say that we should return null for GetPrototypeOf.

[othermaciej]

Trust @cdumez over me on this one, for WebKit's opinion.

[cdumez]

[[Set]] should switch to SecurityError instead of returning false.

I think [[Set]] already throws a SecurityError in the specification because we call CrossOriginSet() in the cross-origin case. The first thing it does is call [[GetOwnProperty]] which will throw a SecurityError.

[[PreventExtensions]] / [[SetPrototypeOf]]

Those throw either way: cross-origin or not. Therefore, I don't think it is worth doing a cross-origin check just to throw a SecurityError instead of a TypeError. Seems kind of weird:

bool setPrototypeOf() {
  if (crossOrigin)
      throwSecurityError();
  else
      throwTypeError();
  return false;
}

It is not like the reason this is failing is because this is cross-origin. It will fail either way so I don't think this should be a SecurityError. My personal preference would be the leave this part of the spec as is.

[domenic]

OK, so per @cdumez's last comment and #1727 (comment) it sounds like we don't feel a need to be consistent and always do SecurityError here. So here's the new proposal (with only the changes from the current spec listed):

• [[DefineOwnProperty]] should switch to SecurityError instead of returning false.
• [[Set]] should switch to SecurityError instead of returning false.
• [[Delete]] should switch to SecurityError instead of returning false.

This means it will usually be SecurityError, but for things that would always fail (no matter if cross-origin or same-origin), namely [[PreventExtensions]] or [[SetPrototypeOf]], they throw a TypeError unconditionally.

@annevk, I know you have a vacation coming up; do you want me to take this over?

[annevk]

Yeah, failing that I can pick it up mid next week most likely.

[annevk]

CrossOriginSet has "Perform ? Call(setter, Receiver, «V»)" as step. If that throws, should that exception be masked and turned into a SecurityError too? Is that generally something we need to do? Or if the setter can be accessed we can also leak its exceptions?

[annevk]

I think [[Set]] already throws a SecurityError in the specification because we call CrossOriginSet() in the cross-origin case. The first thing it does is call [[GetOwnProperty]] which will throw a SecurityError.

CrossOriginSet can also fail if the descriptor does not have [[Get]] or [[Set]] fields, or if the [[Set]] field is undefined. We can probably simplify the steps of CrossOriginSet by just checking that desc.[[Set]] is not undefined rather than using IsAccessorDescriptor. Thoughts?

[domenic]

Or if the setter can be accessed we can also leak its exceptions?

I think this is correct. If the setter can be accessed then it is already on the safelist.

CrossOriginSet can also fail if the descriptor does not have [[Get]] or [[Set]] fields, or if the [[Set]] field is undefined.

Concretely, this is about trying to set a cross-origin safelisted field that does not have a setter (e.g. crossOriginWindow.top = foo), or is a value field (e.g. crossOriginWindow.close = foo).

I think it would be nicer to follow ES semantics here and ignore that in sloppy mode... let's see what happens in browsers.

• http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4464
• http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4465

Nope, they uniformly deny access even in sloppy mode. So this should be a SecurityError too.

We can probably simplify the steps of CrossOriginSet by just checking that desc.[[Set]] is not undefined rather than using IsAccessorDescriptor. Thoughts?

Yeah, looks right to me. So no [[Set]] => SecurityError.

[annevk]

Do we need to check it is not absent and not undefined then? I guess absent != undefined here unfortunate as that is? Can fix that tomorrow.

[domenic]

That's true, I think if it's an accessor descriptor then there's always both a [[Get]] and a [[Set]], but [[Set]] could be undefined. Whereas for a data descriptor both [[Get]] and [[Set]] are absent.

[annevk]

While writing this commit message I realized we could rid ourselves completely of the IsDataDescriptor and IsAccessorDescriptor dependencies if we wanted to. The latter is only used in an assert that could also assert desc.[[Get]] is present. The former could be replaced by a check that desc.[[Value]] is present. (Although, can you have something where desc.[[Writeable]] is present and desc.[[Value]] is not? That would already be problemtic with the current wording.)

Throw for cross-origin [[Delete]] and use "SecurityError" as needed

Returning false for [[Delete]] (on Window and Location objects) would
only cause its callers to throw in “strict mode”. Implementations
however always throw.

We also decided to throw "SecurityError" for [[DefineOwnProperty]]
and [[Set]] (the latter through CrossOriginSet). We did not do this
for all internal methods. Only those where throwing was unique to
their cross-origin behavior.

[domenic]

I don't see much value in minimizing the dependencies, and I think it's generally clearer using those forms than relying on the implicit knowledge that data -> [[Value]]/[[Writable]] and accessor -> [[Get]]/[[Set]].

Commit message needs a "fixes #1726", and I'm not sure why strict mode is in scare quotes.

Reviewing the actual patch now...

[domenic]

OK, this LGTM!

[annevk]

Can you merge it? Feel free to adjust commit message per your feedback. (I'm assuming you are okay that we removed the dependency on one such ab-op here.)