Consider explicitly allowing `digest` for non-secure origins

Follow-up to #28. Currently webcrypto requires a secure origin. This excludes, for example, web SPAs served on a local network without SSL. (I don't want to dwell too much on why people serve local web apps without SSL, except to say installing a new CA on all machines in your network just to use a local web app is a common anti-pattern that causes unnecessary exposure due to certificates being mismanaged.)

Please consider other use cases for webcrypto, e.g. SHA-256 for blob stores implemented on top of IndexedDB. Is the use of a secure origin relevant here? This was mentioned in the Bugzilla discussion in 2014:

I believe that UAs that wish to restrict the availability of Web Crypto to secure origins - or to restrict the set of operations (for example, perhaps only allowing digest() operations, but no keyed operations)

This was never properly addressed in the Bugzilla thread. The only response was this one, which mostly talked about signature verification rather than pure digest:

You are not protected from an attacker, at all, who can modify the code and insist that any arbitrary file has a "valid" signature. Or replacing the signature in transit.

This doesn't make much sense. In the described scenario the check could also be patched out, and preventing access to webcrypto would have achieved nothing. The point about replacing signatures in transit goes against the basic mechanics of how signatures work. Also, allowing digest alone, without signature operations, was never addressed after the first message that mentioned it.

I was invited to open this issue by https://github.com/w3c/webcrypto/issues/28#issuecomment-4333828356. I don't think there are any issues with the definition of secure origins or secure contexts. However the resolution in #28 focused too much on the technical aspects and ignored the obvious human behavioural consequences. The hardest problem in security is still getting people to use the secure primitives you built. If someone hand-rolls a crypto implementation for non-SSL local deployments (or development) then there is a chance it could get re-used in secure contexts, and now you have hand-rolled crypto in secure contexts.

I don't think it ever makes sense to push people away from vetted implementations of standard algorithms. That's a policy decision though. The specific case of digest is different because these algorithms have other applications. There were open questions about digest in the original spec discussions that were never resolved.

Start with issue #28 and the linked Bugzilla discussion, then review how the secure-origin requirement applies to Web Crypto and the digest use cases described here. Done requires a resolved policy and specification decision on whether digest may be exposed to non-secure origins; the issue does not name implementation files or tests.