[Bug 25618] Extensibility: Offer spec-blessed ways to extend the algorithms and curves, rather than monkey-patching the spec

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

--- Comment #47 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Harry Halpin from comment #45)
> Extension spec S2 would normatively reference S1. Why would it make sense to
> have S1 reference S2? 
> 

This was answered two lines below in the message you were replying to.

> > 
> > If you were talking about versions of implementations, I have no idea what
> > you were trying to say.
> > 
> > > No one is "pretending" S2 doesn't exist.
> > 
> > Please put yourselves in the shoes of an implementor who is told to
> > "implement S1".  They find the S1 spec and implement.  How do they find out
> > about S2?
> 
> Like I said, the W3C has offered to host either a web-page or wiki, which
> can be pointed at from S1, for these. That's pretty simple and solves your
> problem. 

It doesn't solve the problem for a second.

One, the issue at hand is "Implement S1", except the Web now depends on "S1+S2"
because some Vendor C implemented S2 and decided to ship it, and sites and
authors came to believe that S1 (the Web Crypto API, in this case) also
guarantees support for S2, because for some vendors, it does.

So now you have two problems:
1) How do authors realize that S1 and S2 are disjoint (answer: And this is true
for nearly every implementor - is that they don't, no matter how much we try to
spin it)
2) How do implementors realize that sites are expecting S2 when they ask for S1
(answer: Again, plenty of experience here is that they don't, until well after
the fact)

The question of "Put it in S1" vs "Put it in a wiki that is put in S1" is
silly. It highlights the exact process issues being discussed in
http://www.w3.org/community/w3process/track/issues/141

> Agreed. We wanted extension specs to be discoverable. Ryan pushed against it
> for reasons which he has not clarified. 

No, that's not really true. I've provided quite clear reasons why
non-discoverable extension specs are a problem. I've also provided quite clear
reasons why "random extension specs" are a problem, especially for the Web
Platform (i.e.. the 'IETF and JOSE developed extension specs')

> Why would sites assume S2 is implemented if it's clearly an extension?

Because that's exactly how the web and authors work? We're being pragmatic,
rather than dogmatic, in that the process here continually leads to failure.

> > As in, if S2 is in fact a required consequence of having S1, then by not
> > making that clear you set up people implementing S1 to fail.
> 
> However, using Curve25519 and NUMs curves as examples, we are *not* saying
> they are required.

And yet, when a critical mass of UAs implement Curve25519 or NUMS, then
_regardless_ of what the spec says, it is in fact required for a UA that wishes
to expose the web.

This is what we've seen time and time again w/r/t HTML, which is why we have
the WHATWG documenting the way the world _is_, not the way the W3C imagined the
world should look like. Because ultimately, the world we live in is the messy
one where sites depend on these algorithms, and so any new UA, or any UA
freshly implementing S1, needs to know that S2, despite being "extension", is
in effect "required" (the same as the majority of S1 is already)

> Given there is a vastly decreasing amount of browsers, I don't think this is
> a huge problem. Indeed, the problem is that some jurisdictions and
> applicaitons *require* crypto that for, some reason or another, some browser
> vendor won't implement but another will. To discpline this, an extension
> spec mechanism makes sense. 
> 
> Also, note the point made by Mark that at least his company is interested in
> using this API in JS programs that aren't browsers. 

Which just amplifies the problem that either the W3C and Web Crypto WG are
either set up to serve UAs for the web, or they aren't. If you're trying to be
ecumenical for NodeJS, WinJS, <insert some language here that doesn't even use
ES but uses WebIDL for reasons yet unknown>, then all you're doing is forcing
UAs to go off on their own to focus on the things that matter.

This is how and why we got the WHATWG, and why it increasingly may be a better
place for future development. UAs cannot effectively discuss what matters or is
idiomatic for NodeJS or WinJS, nor, as has been repeatedly shown in this WG,
can vendors of non-UAs be expected to effectively discuss what matters or is
idiomatic for the Web.

> Yes, because the patent commits go to the spec and adding algorithms to the
> base spec would cause us to go back to Last Call.

That's not a BUG. It's a FEATURE.

> No, we are not prioritizing the comfort of the working group. Certain
> groups, like *entire countries*, need crypto that is not included in the
> base spec for some reason or another. 

Put differently: You believe that the legislative fiat of independent countries
should trump implementor or developer concerns.

Either the boutique crypto needs of these *entire countries* are of concerns
for implementors - in which case, it's an implementation issue - or they
aren't, in which case, discussions of them are in effect placing a higher
priority on legislation than implementation.

That's not a good path.

> 
> As a global standards body we can't ignore whole countries. I rank ordinary
> people above both the comfort of standards bodies and implementers to be
> honest. 
> 
> We will clearly define a browser profile that every developer can depend on. 
> 
> However, we do understand some browsers don't have the resources or desire
> to implement certain crypto (like Curve25519 or NUMS or SEED or GOST) that
> certain people (and again, whole countries) need. As long as specs for these
> are written and code works in at least one browser, I think extension specs
> are a good idea for tackling this issue without putting any additional
> weight on browser vendors. If the browser vendors decide later to implement
> extension specs, then we can update accordingly but no reason to hold up
> other browser vendors and the rest of W3C now.

This ignores how the Web has worked, currently works, and, from implementors,
how they desire it to work.

For the W3C to ignore these concerns or reality seems... less than ideal.

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

Received on Friday, 10 October 2014 15:15:53 UTC