Intent to Implement and Ship: 'document.origin'.

[Mike West]

Contact emails

mk...@chromium.org

Spec

https://dom.spec.whatwg.org/#dom-document-origin

Patch

https://codereview.chromium.org/758913002/

Summary

This tiny feature adds an 'origin' accessor to the Document object, which can be used to read the document's actual origin, rather than the origin of it's location (which is available via 'document.location.origin').

Motivation

Right now, developers have no good mechanism to determine what a document's _effective_ origin is. Consider '<iframe sandbox>', for instance, which changes the document's origin, while leaving it's location untouched.

This gap makes it a bit more difficult to write tests for some features. See http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0299.html for an example where this has been annoying.

Compatibility Risk

Low. Firefox intends to implement as well https://bugzilla.mozilla.org/show_bug.cgi?id=931884.

Ongoing technical constraints

None.

Will this feature be supported on all sixfive Blink platforms (Windows, Mac, Linux, Chrome OS,  and Android, and Android WebView)?

Yes.

OWP launch tracking bug?

https://crbug.com/436377

Link to entry on the feature dashboard

Small change, fits under general DOM features.

Requesting approval to ship?

Yes

-mike

[Philip Jägenstedt]

Non-owner LGTM!

The HTML spec has both "origin" and "effective script origin" concepts:
https://html.spec.whatwg.org/multipage/browsers.html#origin

Are those clearly separated concepts in Blink and do you know of any
corner cases where the return value would differ from the spec?

(git grep -i effectivescriptorigin finds nothing)

Philip

> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.

[Jochen Eisinger]

afaik we only store the effective script origin

> email to blink-dev+unsubscribe@chromium.org.

[Mike West]

The effective script origin is tied to 'document.domain'. I don't believe we update the actual origin if a page chooses to use that setter (there's a test in the patch to verify that: https://codereview.chromium.org/758913002/patch/40001/50001).

I'm pretty sure this matches the spec: https://html.spec.whatwg.org/multipage/browsers.html#relaxing-the-same-origin-restriction:effective-script-origin changes the effective script origin, but not the origin.

That said, it's not clear that we're always doing what the spec says with regard to the effective script origin. I suspect that's intentional in at least some cases, but I haven't gone through and enumerated the various cases.

If nothing else, this change will help us write tests to figure out where browser behavior diverges, and make intelligent decisions about how to resolve those differences.

-mike

--
Mike West <mk...@google.com>

Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Graham Law, Christine Elizabeth Flores

(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

[Philip Jägenstedt]

The CL uses securityOrigin()->toString(), which is stored, do you mean
that this is more like the spec's "effective script origin" than
"origin"?

On Fri, Nov 28, 2014 at 9:39 AM, Jochen Eisinger <joc...@chromium.org> wrote:

>> > email to blink-dev+...@chromium.org.

[Jochen Eisinger]

ah, indeed. SecurityOrigin::toString() uses the m_host field of SecurityOrigin to build the string, while document.domain overrides the m_domain field of its SecurityOrigin.

Guess that's the difference then (m_host = origin, m_domain = effective script origin)

-jochen

>> > email to blink-dev+unsubscribe@chromium.org.

[Anne van Kesteren]

On Fri, Nov 28, 2014 at 9:50 AM, Jochen Eisinger <joc...@chromium.org> wrote:
> ah, indeed. SecurityOrigin::toString() uses the m_host field of
> SecurityOrigin to build the string, while document.domain overrides the
> m_domain field of its SecurityOrigin.
>
> Guess that's the difference then (m_host = origin, m_domain = effective
> script origin)

Not per the specification...

Note that document.origin does not return the effective script origin
(e.g. setting document.domain would not alter its value).


--
https://annevankesteren.nl/

[Mike West]

Jochen's referring to Blink's SecurityOrigin object internals, not the specced behavior. If you look at the tests in the patch, I think you'll see that the implementation of 'document.origin' matches what's specced in HTML and DOM.

-mike

--
Mike West <mk...@google.com>

Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Graham Law, Christine Elizabeth Flores

(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

[Philip Jägenstedt]

Yep, document-origin-domain.html tests the case that Anne mentioned,
so everything seems in order.

Philip

[Dirk Schulze]

On Nov 28, 2014, at 9:21 AM, Mike West <mk...@chromium.org> wrote:

> Compatibility Risk
> Low. Firefox intends to implement as well https://bugzilla.mozilla.org/show_bug.cgi?id=931884.

An open bug report is hardly an intent to implement. Was there a discussion on dev-platform maybe?

Greetings,
Dirk

[Mike West]

https://bugzilla.mozilla.org/show_bug.cgi?id=931884#c1 is a patch, so it's a bit more than a bug report. That said, I potentially overstated Mozilla's position, thanks for calling me on it. Perhaps Anne or Boris (CCd) can expound on their colleagues' opinions in a more authoritative manner?

I don't think the revision markedly changes the state of the world. The feature remains tiny and useful, and I haven't seen any objections to its implementation from other vendors. I'd still like to implement and ship it. :)

-mike

[Boris Zbarsky]

On 12/1/14, 8:43 AM, 'Mike West' via blink-dev wrote:
> https://bugzilla.mozilla.org/show_bug.cgi?id=931884#c1 is a patch, so
> it's a bit more than a bug report. That said, I potentially overstated
> Mozilla's position, thanks for calling me on it. Perhaps Anne or Boris
> (CCd) can expound on their colleagues' opinions in a more authoritative
> manner?

Not yet, but on a personal note this seems like a totally reasonable and
useful thing to implement, with a very low implementation burden and
I've gone ahead and updated the patch to actually do what the spec says
and little details like that.

The only real confusion might stem from the difference between
document.origin and location.origin; I'm a bit torn about what to do
about that, short of removing location.origin....

-Boris

[Philip Rogers]

LGTM

[TAMURA, Kent]

LGTM2.

--

TAMURA Kent
Software Engineer, Google

[Chris Harrelson]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Boris Zbarsky]

On 12/1/14, 7:05 AM, Boris Zbarsky wrote:
> Not yet, but on a personal note this seems like a totally reasonable and
> useful thing to implement, with a very low implementation burden and
> I've gone ahead and updated the patch to actually do what the spec says
> and little details like that.

An update: an issue was brought up that it would be nice to have a
uniform API across Window and worker contexts here. document.origin
clearly isn't that API. Whether such an API is desirable and if so
whether document.origin should exist in addition to that API is a good
question.

Note that location.origin _does_ exist in workers, but is of slightly
questionable utility, insofar as it just returns the origin of the
worker's URI, not the origin of the worker and the two may or may not be
identical.

-Boris

[Mike West]

Adding `self.origin` as an analog to `document.origin` seems like a reasonable way of addressing this need (and I agree that it sounds reasonable). Is that more or less what you're thinking, or do you see a better way of unifying the API?

-mike

--
Mike West <mk...@google.com>

Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Graham Law, Christine Elizabeth Flores

(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

[Boris Zbarsky]

On 12/2/14, 1:44 PM, 'Mike West' via blink-dev wrote:
> Adding `self.origin` as an analog to `document.origin` seems like a
> reasonable way of addressing this need

That's basically what I was thinking. In particular, adding it in both
Window and WorkerGlobalScope, so you can do "self.origin" both places....

If we do that, do we still want document.origin?

-Boris

[Mike West]

`window.origin` seems strange, semantically, as the "window" doesn't really have an origin. It has a document, which has an origin.

And as the global object, it's tougher to decide whether we should be returning the document's origin, or the effective script origin.

But those concerns are probably outweighed by the simplicity of putting the accessor in the same conceptual place on both Worker and Document environments.

Anne? WDYT?

-mike

--
Mike West <mk...@google.com>

Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Graham Law, Christine Elizabeth Flores

(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

[Boris Zbarsky]

On 12/2/14, 1:48 PM, Boris Zbarsky wrote:
> That's basically what I was thinking. In particular, adding it in both
> Window and WorkerGlobalScope, so you can do "self.origin" both places....

Which of course has the problem of introducing a new thing to the global
scope, though we could presumably make it replaceable to mitigate the
compat impact.

-Boris

[Rob Wu]

Throwing new properties in the global namespace does not sound too great to me because of potential for namespace conflicts with applications. If "origin" is going to be read-only, adding a global "origin" property might break (badly coded) applications where the main script is not wrapped in a closure (so it uses global variables).

Perhaps location.securityOrigin ?

Kind regards,

 Rob

 https://robwu.nl

-Boris

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Boris Zbarsky]

On 12/2/14, 2:12 PM, Rob Wu wrote:
> Throwing new properties in the global namespace does not sound too great
> to me because of potential for namespace conflicts with applications. If
> "origin" is going to be read-only

Hence the suggestion to make it replaceable.

> Perhaps location.securityOrigin ?

The problem with putting it on Location is that a "location" object
always describes the current document of the browsing context, not the
document you got it from. I guess this is similar to what happens with
Window...

Furthermore, location.origin already exists; explaining the difference
between that and another origin-returning Location property is going to
be complicated... again, unless we remove location.origin.

-Boris

[Anne van Kesteren]

On Tue, Dec 2, 2014 at 11:01 PM, Mike West <mk...@google.com> wrote:
> But those concerns are probably outweighed by the simplicity of putting the
> accessor in the same conceptual place on both Worker and Document
> environments.
>
> Anne? WDYT?

It seems to me it might be useful to have an object associated with
globals that is not navigator as navigator.origin seems weird. In the
absense of that having document.origin in document environments and
self.origin in worker environments seems okay to me. I would recommend
that as strategy for this particular case.

I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=27497 to define
self.origin in workers.

(Theoretically workers are supposed to be using capability-based
security so it's not entirely clear to me that we should expose such a
concept as origins there, but I guess since we already use origin
there ourselves for some decisions so it's not exactly pure
capabilities.)

(At some point we should also explore the origin setup in
specifications versus those in implementations as apparently at least
for Gecko it's quite a bit different.)


--
https://annevankesteren.nl/

[PhistucK]

I think making it replaceable defeats the security aspect of this property. If you cannot depend on it (because it was replaced by some code), then it is less worthy.

(Perhaps there is no security aspect to it, though?)

However, I think any property can be replaced or forged with getters and setters nowadays -

Object.defineProperty(document.location, "origin", {get: function () {}, set: function () {}});

console.log(document.location.origin);

☆PhistucK

-Boris

[smaug]

On 12/19/2014 01:00 PM, PhistucK wrote:
> I think making it replaceable defeats the security aspect of this property. If you cannot depend on it (because it was replaced by some code), then it
> is less worthy.
> (Perhaps there is no security aspect to it, though?)
>
> However, I think any property can be replaced or forged with getters and setters nowadays -
> Object.defineProperty(document.location, "origin", {get: function () {}, set: function () {}});

Per spec this should throw, since Location interface is [Unforgeable].
Gecko gets this right.


> console.log(document.location.origin);
>
>
> ☆*PhistucK*

>
> On Wed, Dec 3, 2014 at 12:16 AM, Boris Zbarsky <bzba...@mit.edu <mailto:bzba...@mit.edu>> wrote:
>
> On 12/2/14, 2:12 PM, Rob Wu wrote:
>
> Throwing new properties in the global namespace does not sound too great
> to me because of potential for namespace conflicts with applications. If
> "origin" is going to be read-only
>
>
> Hence the suggestion to make it replaceable.
>
> Perhaps location.securityOrigin ?
>
>
> The problem with putting it on Location is that a "location" object always describes the current document of the browsing context, not the
> document you got it from. I guess this is similar to what happens with Window...
>
> Furthermore, location.origin already exists; explaining the difference between that and another origin-returning Location property is going to be
> complicated... again, unless we remove location.origin.
>
>
> -Boris
>

> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@__chromium.org
> <mailto:blink-dev%2Bunsu...@chromium.org>.
>
> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.