While in principal supportive, isn't the rationale a little wonky?

That is, the argument presented - that it provides details like the URL or query string - are applicable to the handler URL, not the invocation of the API method. The API method invocation seems benign regardless of the context, and more applicable is how the handler gets invoked.

I don't think Firefox's arguments make sense, especially not for the data used (which is based on https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/navigatorcontentutils/navigator_content_utils.cc?rcl=2be1d58768138a51a4ee011843ade9251f95ec00&l=153 ), so I think the argument is not about secure/insecure, but rather about Web Compat. I'd be the last one to want to argue to Firefox that they should remove the [SecureContext], but I think the decision wasn't well-considered.

rsleevi: Yeah, I was a bit lazy in explaining the motive in the spec change issue [1].

registerProtocolHandler() requires that the proto-URL be same-origin with the calling context. By implication, if the proto-URL is to be a secure-context, then the calling context should also be a secure context. The implementation in blink is nuanced, but exceptions should be rare.

The collected data, which was only for valid invocation of registerProtocolHandler(), applies approximately equally both to the secure context state of the document and to the state of the URL.

Or am I missing the point entirely?

This came up because we are considering broadening the range of schemes on which registerProtocolHandler() could be used [2].

[1]: https://github.com/whatwg/html/issues/4017
[2]: https://github.com/whatwg/html/issues/3998

Ah! Thanks, I missed this part in the HTML Living Standard:

> User agents must throw a "SecurityError" DOMException if the resulting URL record has an origin that differs from the origin specified by the relevant settings object of this NavigatorContentUtils object.

In that case, yeah, totally makes sense to secure-origin restrict :)

iOS does not use Blink