[Bug 25985] WebCrypto should be inter-operable

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985

--- Comment #35 from Henri Sivonen <hsivonen@hsivonen.fi> ---
(In reply to Ryan Sleevi from comment #34)
> Further, if we go the route of "all or nothing", which I understand you to
> be suggesting, than it means we would run the risk of cutting off the nose
> to spite the face on one extreme, or landing with something 'less than
> desirable' on the other.

I'm not advocating for all or nothing. E.g. WHATWG HTML or a sufficiently large
CSS spec doesn't get implemented in an all-or-nothing fashion. Still, the specs
set the expectation that they'll be eventually fully implemented instead of
setting the expectation that implementors are welcome to implement even
disjoint subsets and that's fine ("conforming"). 

I expect Web Crypto be implemented piecewise.

> What's the expected behaviour, for a UA, if a user chooses to disable an
> algorithm (by policy)?
> Does it
>   a) Allow all of WebCrypto, mod the disabled algorithm
>   b) Disable all of WebCrypto, because it fails to meet the profile?
>   c) Other?

Preferably c): Making it hard to to mess with the feature set so that only
those who *really* have to do so. But when they do, a).

> Whatever the choice (a-c), if we go MTI, the spec needs to provide guidance
> on that.
> 
> If you answer (a/c), then further questions emerge, such as:
> - What if the UA can't determine whether or not the user intentionally
> disabled an algorithm (i.e.: it's disabled at an OS layer that the UA is
> unaware/agnostic towards)

Why in the case of a) does the UA need to know the intent, if the algorithm has
been withheld from it?

> - What should the behaviour of the site operator's script be when it
> attempts to use SHA-1?

The same as requesting an unknown algorithm.

> - What should "well-behaved" application developers do to handle this?
>   a) Not handle it at all. Watch it burn!
>   b) Handle it, with fallback to JS crypto
>   c) Other?

b) is likely in the short term with a) likely becoming more prevalent over time
(based on what we know about how Web developers behave as features become more
consistently available across browsers).

I imagine once in a while someone will do c): Show a UI message to tell the
user go download a browser that supports Web Crypto.

> - If you answered (b) [which, evidence suggests, is invariably what people
> will do], how is that different than the present state of things?

There's a difference between

 1) establishing a feature set that implementors agree is a worthwhile target
to converge their default configurations to over time

and

 2) not even setting the expectation for browsers converging on a common
interoperable feature set available by default (either resulting in a mess or
resulting in expectation setting happening outside the WG/spec).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Tuesday, 8 July 2014 10:04:49 UTC