Sketch for how postMessage / MessageEvent could work

[jeisinger]

/cc @annevk @mikewest

[annevk]

Why not something like

dictionary NonStringOrigin {
  required USVString origin;
  required USVString suborigin;
};
typedef (NonStringOrigin or USVString) Origin;

and then make the various thingies take Origin rather than USVString.

[annevk]

I guess that'll confuse existing postMessage() endpoints.

[mikewest]

Yeah, the goal of this approach is to roll out something additive to the existing interface.

At core, we want to ensure that existing applications fail closed when presented with a message from a suborigin, and can opt-into accepting such messages by changing their code. It would be unfortunate if "fail closed" meant "throw an exception and explode because the types changed", though. :)

[annevk]

I wish we could do away with the awful name while we're at it. It's just too confusing with subdomains. (Identifier origins?)

So if you want to fail closed I suppose MessageEvent's origin should be "null" (or maybe the empty string, though user-agent-generated events cannot have that so that might be a risk too). And then you'd just have a new attribute originObject or some such that returns the better thing. (Or you'd take this chance and fix cross-origin postMessage().)

[mikewest]

I wish we could do away with the awful name while we're at it. It's just too confusing with subdomains. (Identifier origins?)

My original goal was to make this pretty similar to subdomains, at least in impact if not implementation. I'm not sure if the current state of the spec matches that thought, but it was at least intentional at some point. :)

So if you want to fail closed I suppose MessageEvent's origin should be "null" (or maybe the empty string, though user-agent-generated events cannot have that so that might be a risk too).

What's the risk with the empty string?

The string "null" might be reasonable, now that you mention it. I guess anyone comparing e.origin === "null" is already open to anyone and anything out there in the world.

And then you'd just have a new attribute originObject or some such that returns the better thing.

That's more or less what this suggestion boils down to: the message event contains an initiator (or whatever) property which holds the more detailed view of the origin. I think that's actually might be useful independent of suborigins for domain...

Or you'd take this chance and fix cross-origin postMessage().

What does "fix" mean?

[annevk]

What's the risk with the empty string?

Thinking about it some more it would have to be very brittle code to break down.

What does "fix" mean?

The listener defines ahead of time who to listen for.

[jeisinger]

updated the PR, PTAL

[adob]

Is there any way for an application to obtain its own suborigin namespace value? In the past, the application could inspect document.origin and obtain the serialized suborigin, I believe.

[jeisinger]

Is there any way for an application to obtain its own suborigin namespace value? In the past, the application could inspect document.origin and obtain the serialized suborigin, I believe.

I plan to add document.suborigin that will expose the suborigin namespace

[annevk]

document.suborigin

Just after we plan on removing document.origin?

Aside: I'd really appreciate if my design questions above could be addressed in some way. You all are planning on changing quite a bit of the security model in HTML, but nobody involved there is involved here. You can't just do a complex change to a model without getting more folks involved in the design.

[annevk]

(And to be clear, I've said this many times. But each time I'm told to go away and have a look later once suborigins is more ready. I've the feeling it's not ready because the design is still lacking and you need more folks to get it right.)

[jeisinger]

Just after we plan on removing document.origin?

Ah, sorry, I meant window.suborigin

[jeisinger]

I chatted with @annevk on #whatwg and agreed to file issues to integrate with suborigins at least against HTML, Fetch, storage, and permissions

[jeisinger]

addressed all comments (except for the ones from @annevk - filing an HTML issue now)

[devd]

merged. thanks!