Meta: add ancestorOrigins warning due to continued disagreement

[annevk]

See #1918 for context.

[annevk]

@bzbarsky suggested we add this since folks keep being confused as to why it's not in Firefox yet. (And presumably they're equally confused about Edge, although we don't really know the reason for that.)

[annevk]

Also paging @jungkees and @jakearchibald since this affects service workers as well to some extent.

[domenic]

I would feel more comfortable about this if we had any implementer interest from implementations besides Firefox in the change proposal. As-is, I don't think it's accurate to say that it's expected to change. It's just another API of many that Firefox and Edge don't implement, and that's taken care of by the caniuse box already.

[bzbarsky]

It's not an API that Firefox doesn't implement but expects to sometime. It's an API that Firefox considers an unacceptable privacy leak in its current form and will not implement in that form, period.

But yes, I would like to hear some feedback on my change proposal from Blink, of course.

[domenic]

Adding a note saying "Firefox considers this API to be a privacy leak and that's why it's not implemented in Firefox" seems more honest than saying that the API is expected to change (and implying that maybe that's why Edge isn't implementing it).

I'm still not sure that's a job for the spec though. Maybe a Mozilla Hacks blog post and a caniuse footnote linking to it.

[annevk]

We have two implementations, one objection, and one unknown. It's not entirely clear to me that doing nothing is helpful either. I was hoping that by more clearly calling it out in the standard more folks would feel like trying to solve this somehow.

[domenic]

I'd like to close this; I don't think it's the spec's job to explain browser policy positions, and that aside, the wording in this PR is not good (saying that the API is expected to change).

[bzbarsky]

I don't think it's the spec's job to spec something that has explicit disagreements for security reasons either, unless it's really trying to force the insecure behavior.

[domenic]

Well, I guess we'll have to disagree there. I think it's important to spec things with multiple interoperable implementations.

[bzbarsky]

I think that's important, but it's also important to not make it sound like anyone who doesn't implement it that way is "just wrong" when that's not the case. Because if you do that, people just completely lose faith in the standards process.

That's why we end up with things like specs for how to implement something if one chooses to implement it, with clear indications that one may choose not to and why one may choose not to. This is not great, but its better than nothing if there are irreconcilable differences as to whether the thing should be implemented at all, in that form.

I'm not saying this is all a happy situation, by the way; I would much prefer it if we could converge implementations here in general on something that won't be a violation of my users' privacy so I could ship it, I've been saying that for years, and I've made a concrete proposal for what the spec should actually say that would give it the desired privacy properties. But since we're apparently not willing to spec it that way and Chrome and Safari are apparently not willing to implement it, here we are. I'm not willing to ship something with the same name and different semantics, obviously.

[foolip]

FWIW, I think that if changing "expected to change" to "may change", this PR would be fine.

[annevk]

Probably better as "can change" given "may" has a normative meaning? @domenic?

[domenic]

"might" sounds fine.

[annevk]

Should be good to go now.