[Bug 25985] WebCrypto should be inter-operable

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

--- Comment #34 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Henri Sivonen from comment #33)
> So the propagation time of changes to the systems libraries is longer. It
> doesn't follow that Microsoft couldn't make changes to their platform crypto
> to accommodate IE's Web Crypto impl, Apple couldn't make changes to their
> platform crypto to accommodate Safari or Red Hat couldn't make changes to
> NSS to accommodate Firefox--eventually.

I think we're talking past eachother.

Even if the underlying platform changes, it means that you're now looking at
limiting UA support of the feature to only the bleeding edge OS - which we
empirically know few users run.

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.

> So if you are banned from using a particular crypto primitive, don't invoke
> it in your intranet app. It's not reasonable to withdraw it from the
> browsers you have installed thereby breaking random external sites.

That's not how these things work, unfortunately. Many (most?) of these sorts of
requirements explicitly require disabling.

> Wait, you think it's a FEATURE to *allow* something that you think is
> correctly characterized as "won't be able to"???

Yes.

Breaking Web Compat is Bad. It's well-understood you don't remove something
without extreme pain and prejudice. I'm aware that this is particularly
troublesome for some, especially those whose ears prickle at security APIs, but
the reality is, once we ship something to the Web, it's very hard to remove.

This is why the Web has been so successful! You can still go to your old
Angelfire or Geocities page, written in the realm of HTML 1.0, and it "Just
Works". Mod a blink tag or two, which would still render.

The Web is defined by it's backwards compatibility - for better or for worse.

> No. What makes you think that a user who want to remove features from their
> Web browser--be it crypto primitives or anything else--needs anyone to bless
> the resulting personal feature set as conforming? We don't need a spec to
> consider it conforming for a user to delete a block of code from the HTML
> parser and recompile their personal browser instance.
> 
> I don't care about whether users can call their browser compliant if they
> disable some features either by flipping pref or by changing code and
> recompiling. I'm interested in documenting an eventually consistent target
> state across the feature set offered by major browsers in their default
> configurations. For browsers that suffer some non-agility from deferring to
> platform libraries, "eventually" may take a bit more time than the WG has
> planned for their CR schedule.

This doesn't really address at all the point I was making, so I fear we're
talking past eachother here as well.

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?

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)
- What should the behaviour of the site operator's script be when it attempts
to use SHA-1?
- 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?
- If you answered (b) [which, evidence suggests, is invariably what people will
do], how is that different than the present state of things?

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

Received on Monday, 7 July 2014 22:03:39 UTC