Mike West

Two differences that seem like they make it easier to hold correctly for this use case: 1. Names are helpful, and representing an origin comparison with a `URLwhatever` object isn't...

> I don't really like the idea of parsing a serialized origin. This is what `MessageEvent.origin` (and `Window.origin` for that matter) require today. It seems strictly easier to parse origins...

> I'm not sure they "require" that today. CORS doesn't require it. "require" is strong, I suppose. But when people do string-based matching today, they're often doing so in ways...

Practically, `MessageEvent` (through `postMessage()` mostly, and `EventSource` much less commonly) and `ancestorOrigins` are the places where I remember folks getting these checks wrong in ways that caused issues. Philosophically, I...

> That package does nothing of the sort we are discussing here It was meant as a justification for my claim that "developers do origin comparisons", and that they're looking...

I agree that developers could benefit from taking even more context into account. They can (unfortunately?) get some of that context today by reaching through `MessageEvent.source.parent`, but you're right that...

I spent some time on https://github.com/mikewest/origin-api/ yesterday to sketch out a proposal in a little more detail. I got some very helpful feedback from @domenic this morning (Thanks!), and I...

Hey folks! I'd like to start upstreaming signature-based integrity checks; this seemed like the simplest self-contained place to start. Assuming folks are on board, I'll file implementation and MDN bugs,...

Friendly ping. It'd be nice to solidify things prior to TPAC. :)

Friendlier ping? Are there concerns with beginning to upstream this work?