Remove SecureContext requirement

[broofa]

Despite broad consensus in #23 for not having a SecureContext requirement, vendors have been rolling out implementations that restrict this API to secure contexts.

This is proving problematic as it encourages developers to use less secure options and just generally complicates things. The longer we allow this to continue, the more difficult this decision will be to reverse.

While it has been argued this spec should follow vendor implementations, the current implementations appear to be a result of Mozilla ignoring this group's consensus.

Given the lack of response to our questions about how we can remedy this situation, I think it's appropriate we make this change and file tickets with the WebKit and Chromium projects requesting they bring their implementations inline with what's been decided here.

cc: @annevk @domenic @ljharb @ctavan @marcoscaceres @bakkot

[domenic]

This doesn't seem appropriate. No browser has agreed to the change. Remember, writing fiction in specs is not OK; you need to change browser implementations first, and then specs follow.

Also recall that browsers are the ultimate arbiter here; not whatever group you are referring to. If you spec something they won't implement, then your spec is worse than useless, and browsers will be forced to fork it into something that matches reality (as has happened throughout history) so they can document their preferred behavior.

I find your definition of "this group's consensus", which apparently excludes a major browser vendor, pretty strange. As such, as part of the Chromium project, I will lend my weight to Mozilla's position also, if that helps; you'll need to redefine "this group" to exclude both Chromium and Mozilla if that's the path you want to take. And I can help maintain the forked Mozilla/Chromium/WebKit spec if necessary.

I suggest you close this issue and continue discussion in #23.

[broofa]

@domenic Let me preface my response by saying that I'm not speaking for @bcoe or others here. I opened this issue to push conversation on a process issue that I am increasingly frustrated by and to try to get some movement on a technical matter that's actually beginning to cause a bit of real-world pain for a project I'm involved with. If you feel compelled to side with Mozilla on this simply because I'm misbehaving in some way, don't take it out on others.

you need to change browser implementations first, and then specs follow

How do you suggest we go about doing that? What rationale am I to give you or Mozilla for making this change that doesn't point back at the discussion we've already had?

The only substantive rationale for this restriction that we've been given here is @annevk's reference to Mozilla's policy. But that policy is based on... wait for it... the W3C TAG's decision.

So maybe I've answered my own question. Surely if we can get the TAG to agree to an exemption, Mozilla will go along with that, right? Oh.... wait.

This is exactly the sort of thing @hober and @othermaciej were arguing against when they referred to "limiting features to secure contexts solely as a carrot to encourage HTTPS adoption".

I find your definition of "this group's consensus"... pretty strange

I was referring to pretty much everyone other than @annevk who weighed in on #23, as well as the W3C TAG that @cynthia talked to. I believe even you said you were leaning toward exempting this API from the SecureContext requirement.

[domenic]

In general there's no magic bullet for getting large projects to change their stance on an issue. It's a subject books have been written about and careers made in. I don't have any specific advice on how to learn lobbying skills. Sometimes, indeed, providing rationales is not enough, or decision makers on the projects disagree with your rationales presented.

[broofa]

I'll go ahead and close this out as I don't want to cause problems for this project. But I hope you can see why this has been frustrating. All of this discussion feels so... pointless.

[marcoscaceres]

I'm reopening this issue because members of the community shouldn't be made to feel they are "causing problems". @broofa, I'm deeply sorry and concerned you've been made to feel that way.

I'm cc'ing @LJWatson, @cwilso, and @yoavweiss as Chairs to review communication in this and related thread (#23), and to review if a CoC violation has occurred. I don't believe one has - but no-one at the WICG should be left to feel that their input is "pointless"

@broofa, in essence (but perhaps not in framing), @domenic is correct. I think what was perhaps missing was input from WebKit if they are willing to change their implementation - @cdumez, @hober, or @othermaciej could give a definitive yes/no. Similarly, I'm not sure who the ultimate arbiter is on the Chromium side - @domenic or @bcoe, is that you... or would it be something to maybe raise over on Blink-Dev as Intent to Implement?

[ljharb]

Perhaps what would be useful, rather than talking about process and staking ownership claims, is helping the non-implementers to understand why, when nobody who’s not an implementer wants this restriction, it’s so valuable to have it?

[cdumez]

From the WebKit side, we merely added the SecureContext requirement because of the specification. I don’t think we feel strongly either way, we haven’t even shipped this in stable yet as far as I know (removing [SecureContext] post shipping wouldn’t really be risky either). I seem to remember reviewers wondering why the spec had this restriction in the first place when I implemented the change.

Maciej or Tess can feel free to contradict me but I think we would be fine with removing this restriction if that’s what people prefer.

[broofa]

@marcoscaceres: Thanks, but let's not concern ourselves with questions of misconduct. I don't believe there's been any. As you've said, this almost certainly boils down to communication issues. Hopefully we can get this cleared up with a minimum of distraction.

cc: @LJWatson @cwilso @yoavweiss

[marcoscaceres]

I might be biased, but I think a strong case for the removal of SecureContext in #23 - in particular @bcoe's #23 (comment). We have at least one implementer willing to entertain the idea of dropping the SecureContext requirement (#48 (comment)). So again, who is the ultimate arbiter on the Chromium side and can we appeal the decision?

I trust that @annevk speaks for Mozilla in #23 (comment) - but having a 2 to 1 decision would break the deadlock, presumedly with Mozilla following implementation consensus.

[cynthia]

Thank you @marcoscaceres for arbitrating. Our position on this still stands - that this case looks like shipping on insecure context has benefits. Hope the implementors can reconsider.

[marcoscaceres]

Our position on this still stands

Sorry, who is "our"? Google or TAG?

that this case looks like shipping only on secure context has benefits.

@cynthia, do you mean in "insecure contexts"? Those benefits haven't been clearly or convincingly articulated, which is why this issue was opened and #23 remains open... why this also came up as a question when implemented in WebKit... so not following? Maybe you misread?

[domenic]

The ultimate arbiters on the Chromium side are the Blink API owners, who previously stated their position on the Intent to Ship thread.

is helping the non-implementers to understand why, when nobody who’s not an implementer wants this restriction, it’s so valuable to have it?

I think we've made it pretty clear; you just don't agree with the reasoning.

[cynthia]

Sorry, who is "our"? Google or TAG?

TAG. I don't work on Chrome so I'm inferring the Google position based on what is written above.

[cynthia]

Sorry! I wrote that comment on a train and just realized it made no sense - edited. Sorry for the confusion.

[yoavweiss]

The ultimate arbiters on the Chromium side are the Blink API owners, who previously stated their position on the Intent to Ship thread.

From my end, and with my API owner hat on, I have no strong opinions about the restriction to secure contexts in itself, and generally prefer to make sure that restrictions align well with risk - which doesn't seem to be the case for the secure context restriction here.

At the same time, due to Mozilla's objections, it seems that exposing the API to non-secure contexts increases its interoperability risk.

What will developers do if some implementations applied such restrictions and others didn't? Seems like the choice would be to either make the same tradeoffs developers do today (e.g. ship a polyfill) or choose to break some users' experiences in some browsers. The latter is a risk we're trying to avoid.

The above interoperability risk increase must be weighed against the benefits of exposing the API in insecure context. In order for Blink's API owners to reach a different conclusion, one may attempt to show that the benefits (user security from more secure UUIDs, etc) outweight the risks.

[marcoscaceres]

ok, so we have the TAG saying "it’s ok to ship in non-secure context" for this. And we have WebKit willing to entertain the idea of allowing in non-secure context, which should weight equally to citing Mozilla's (partial and not-shipping) implementation when it comes to interoperability risk.

Also, I'm still a bit confused: crypto.getRandomValues() does work in non-secure contexts from my own testing (clearly, I'm missing something?). If we have precedence for allowing crypto.getRandomValues() in non-secure contexts, them what's the harm in allowing the same thing for UUIDs? (specially in this case of clear demand from developers and no demonstrable risk to privacy).

[annevk]

I'm not sure why we're revisiting #23 in a new issue? At this point we're also rehashing points already addressed in that issue.

[ljharb]

@domenic its not clear to me, which is why i asked. In other words, I don’t understand the reasoning (so i can't yet agree or disagree with it)

[bcoe]

At this point we're also rehashing points already addressed in that issue.

We need to respect that @annevk represents Mozilla's position. I think folks who disagree have done a good job of making a case in #23 (and in this thread). I trust that @annevk will bring this position back to their peers, and if they choose to shift their position, great 😄

I don't think we should deep end on this one point of contention. We've done a great job of shipping a feature that's valuable for the community -- and we've already observed usage in the community.

Why don't we wait and see how user's are using crypto.randomUUID in a year's time, by which point it will be available widely in browsers so we'll have a better picture of adoption.

I'd like to advocate closing this issue in favor of #23 , just from a house cleaning perspective.