Dom: Consider removing `document.origin`

[mikewest]

We have self.origin in HTML, present inside workers and documents. It seems redundant and confusing to suggest that there's a different origin for documents than for the global object they host. Perhaps we can simply remove this in favor of the property on the global?

@bzbarsky seems to be on board with this notion. @cdumez, WDYT?

Edge hasn't implemented this yet, but perhaps @travisleithead has an opinion from a TAG/platformey perspective?

[cdumez]

WebKit does not currently support self.origin but we will likely implement it in the future. Once we support self.origin, we can start deprecating document.origin in WebKit but I suspect it is going to be a while until we actually remove it (if ever, depending on how much it beaks existing content). That said, I do not have an objection if people want to drop document.origin from the spec, I just think it is a bit early given that self.origin is not well deployed yet.

Here are a few things that are not mentioned on this issue that would help decide:

1. Who currently supports document.origin? I seem to remember it is only Blink and WebKit but someone should confirm.
2. Who already ships self.origin? I suspect no one yet even though it is implemented in Firefox nightly iirc.

[bzbarsky]

Correct on both counts, as far as I know: document.origin is only in Blink and WebKit, but not interoperable between the two in shipped versions. self.origin is only in Firefox nightlies so far.

[mikewest]

I just think it is a bit early given that self.origin is not well deployed yet.

I think we're just looking for feedback from other vendors at this point. If you're on board with the idea of migrating to self.origin, and can commit to the (hopefully minimal) work necessary to implement it at some point in the future, and send a console warning or something when you do, then I'm pretty sure we'll do the same in Blink. We're arguing about the impact of this a bit in https://groups.google.com/a/chromium.org/d/msg/blink-dev/CO52Bt15cuc/ya6u_devCQAJ if you'd like to skim through and add your thoughts.

To your questions:

1. Only Blink and WebKit (and, really, only WebKit nightly after your recent fix: you could, for instance, drop that entirely rather than keeping the broken implementation, right?)

2. Firefox nightly is it. We'll have a patch for Blink tomorrowish, but it won't hit stable for a few weeks.

[cdumez]

Sure, I can commit to implementing self.origin in WebKit in the relatively short-term, given that other browsers are already implementing it and I like the idea.

I also do not object to dropping document.origin from the spec given that this is a Blink/WebKit thing only and there is a better alternative available.

[domenic]

As predicted the use counter in Blink is around ~0.09%: https://www.chromestatus.com/metrics/feature/timeline/popularity/1828 But we have no idea how much of that is just enumeration of the document's properties.

@mikewest, what's our next move?

[cdumez]

If we remove document.origin, am I right that developers will have no way of setting the document's origin via JS? I believe self.origin is readonly while document.origin is not.

[bzbarsky]

document.origin is readonly. See https://dom.spec.whatwg.org/#document

Maybe you were thinking about document.domain, which is a totally different thing?

[mikewest]

Yeah. The numbers are higher than I'd hoped. I think there's a reasonable argument to be made that until Safari's change actually hits users (with Safari 11, I imagine?), that these pages are actually broken. @cdumez, it looks like self.origin is in ToT (https://github.com/WebKit/webkit/blob/39765fd9f55c0268bef9d887fc8b8cb0edf5f64b/Source/WebCore/page/WindowOrWorkerGlobalScope.idl#L31); do you happen to know if it landed in time to make the cut for Safari 11?

If so, then it seems reasonable to try for deprecation.

[cdumez]

Oh I was thinking of document.domain, sorry.

[cdumez]

Self.origin is in Safari 11, yes.

[dstorey]

Is there any update here? We (Edge) have to decide if we're going to implement this or not. We're currently working on the other missing features.

[annevk]

I think we would have liked that, but judging from the spike to 0.75% in https://www.chromestatus.com/metrics/feature/timeline/popularity/1828 it seems like it might be way too late.

Given https://github.com/whatwg/dom/issues/410#issuecomment-280069977 we probably need to add some more tests for document.origin to ensure that it at least becomes interoperable.

[bzbarsky]

What do the uses look like? If it's document.origin || self.origin that could explain a spike while also allowing removal... The fact that Edge and Gecko don't implement and it hasn't been an obvious compat problem makes me a bit wary of assuming things about the data here.

[travisleithead]

Chatted with @dstorey and we think we can help the situation out by _not_ implementing document.origin and instead getting self.origin implemented in an upcoming release. We're not seeing the compat pain (yet?) for document.origin, so we can try to hold-out as long as possible on that front.

[dstorey]

To summarise:

• Gecko, Blink, and WebKit support self.origin, while Edge plans to do so in a future release
• WebKit and Blink support document.origin but they're not interoperable
• Edge and Gecko have so far not seen any interop pain from not supporting document.origin
• Edge has no plans to support it unless we see interop pain in the future
• Having both self.origin and document.origin could be seen as redundant/confusing

Considering the above I'd propose we:

• remove document.origin from the spec or move it into a deprecated partial
• add deprecated messages to the console in Blink and Webkit pointing to self.origin

[annevk]

@foolip @RByers @cdumez your feedback on the above proposal would be appreciated!

[cdumez]

Proposal sounds fine to me.

[RByers]

Sounds reasonable to me, but someone will need to do the analysis to come up with a concrete deprecation plan according to our compat principles. We don't add deprecation messages without an approved removal timeframe anymore. But given the existing lack of interop, I suspect this may be as simple as showing some evidence that removal is unlikely to cause observable breakage (eg. spot check a handful of sites we find via HTTP archive) and giving removal a try. @mikewest perhaps you or someone on your team could do this?

[annevk]

@foolip can you help with this? I'm happy to help with tests and the specification.

[dstorey]

Update: origin on WorkerGlobalScope and Window is now in code review. Will be in some future version of Edge (probably 18)

[foolip]

Looks like we already had an Intent to Deprecate: document.origin on blink-dev.

[foolip]

@mikewest did usage analysis in https://groups.google.com/a/chromium.org/d/msg/blink-dev/CO52Bt15cuc/x_V5frbBCQAJ

[foolip]

The results of a fresh search for "document.origin" is in document_origin.json. I used unjson to split it into 2419 files. I split those into different buckets to try to filter out the harmless stuff. The result I've uploaded as https://storage.googleapis.com/blink-httparchive-export/document_origin.tgz.

Almost all (2205) fall into the false-positives, fingerprinting, and not-broken buckets.

In the maybe-broken bucket there's these sites that could throw an exception if document.origin isn't there and I can reach the code path in Chrome:
http://www.amebaownd.com/
http://www.aromaspace-japan.tokyo/
http://www.brandnewidolsociety.tokyo/
http://www.hiroyuki.com/
http://www.hi-vision.net/
http://www.mienoko.jp/
http://www.yuqinakamura.jp/

But they still seem to work fine in Firefox, can't see what's broken, if anything.

Also in the maybe-broken bucket is a bunch of sites that include https://assets.pscp.tv/univ/main-da74a29ac84387feaee6.js, including http://www.pscp.tv/ itself. It has this event handler:

window.addEventListener("message", function(t) {
    var n = t.origin || t.originalEvent.origin === document.origin
        , r = t.source === e.popup;
    n && r && e.props.onMessage && e.props.onMessage({
        message: t.data
    })
})

But I can't reach that code path in Chrome, not sure what it takes.

There are 80 hits that didn't fall into a bucket and would need individual checking. I checked a few and couldn't find any breakage and nothing that screamed "this will break" on the same lines in grep. Still, some might be affected: (not checked/filtered for porn, which often shows up in these anlyses)
http://aktuelnaturvidenskab.dk/
http://cs.au.dk/
http://www.ab.gr/
http://www.adbug.cn/
http://www.adexchanger.cn/
http://www.adme.ru/
http://www.ascc2017.com/
http://www.attendstar.com/
http://www.au.dk/
http://www.avito.ru/
http://www.avito.ru/
http://www.avito.st/
http://www.avito.st/
http://www.bikeworld.pl/
http://www.brightside.me/
http://www.cargotec.com/
http://www.cassidytravel.ie/
http://www.codio.com/
http://www.delhaize.be/
http://www.devdocs.io/
http://www.ellechina.com/
http://www.fiverr.com/
http://www.fiverr.co.uk/
http://www.fivver.com/
http://www.genial.guru/
http://www.glamsquad.com/
http://www.griffith.edu.au/
http://www.hackster.io/
http://www.haiwai.com/
http://www.hermo.my/
http://www.heroic.academy/
http://www.hijup.com/
http://www.incrivel.club/
http://www.irishlife.ie/
http://www.jackrogersusa.com/
http://www.kadenze.com/
http://www.lariojaturismo.com/
http://www.learnnext.com/
http://www.letsrecap.com/
http://www.likemtr.ru/
http://www.loandepot.com/
http://www.magisto.com/
http://www.mgen.fr/
http://www.multisim.com/
http://www.newslaundry.com/
http://www.nextgurukul.in/
http://www.olx.ru/
http://www.olx.ru/
http://www.pigeonhole.at/
http://www.plumbnation.co.uk/
http://www.promovacances.com/
http://www.pymex.pe/
http://www.reacttraining.com/
http://www.slando.ru/
http://www.slando.ru/
http://www.sparks-lab.org/
http://www.sympa-sympa.com/
http://www.trendwatching.com/
http://www.trustscam.es/
http://www.turfomania.fr/
http://www.universalorlando.com/
http://www.whistler.com/
http://www.yves-rocher.cz/
http://www.yves-rocher.ro/

Noteworthy is that on http://www.ing.com.au/ there's traces of a web developer wasting time because of this interop issue, with a comment saying "document.origin is not by ie":

function InterestRateManager() {
        //document.origin is not by ie
        this.serviceUrl = location.protocol + '//' + location.host + "/ReverseProxy/ProductService/V1/productservice.svc/json/interestrates/
currenteffective";

That's it. To me it seems like we should try to deprecate an remove this, because neither I nor @mikewest could find something that would break badly, and I found evidence of web developers being bitten by the interop problem.

[foolip]

New Intent to Deprecate and Remove:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/0D_37iuh1zc/ndyyNaxgCQAJ

[annevk]

Based on discussion in https://github.com/whatwg/html/issues/2697 I think we should also remove document's origin concept, alongside the attribute. All the security checks we have are about origins of globals, not of documents.

[annevk]

(Removing the concept might be harder than I thought, there's a fair number of dependencies on it at the moment that would have to be revamped. See also https://github.com/whatwg/html/issues/2697#issuecomment-395068417.)

[domenic]

document.origin is now only in Safari, and self.origin is in all engines. It's probably time to remove document.origin from the spec \o/