[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 #54 from Harry Halpin <hhalpin@w3.org> ---
(In reply to Ryan Sleevi from comment #51)
> (In reply to Harry Halpin from comment #48)
> > You are assuming "entire Web" depends on S2. It is more realistic certain
> > classes of applications and countries depend on S2.
> > 
> > First of all, can you please clarify if this position is *your personal
> > position* or an agreed-upon internal Google position?
> > 
> > Microsoft has made their agreed-upon position clear, and W3C would
> > appreciate the same from Google. 
> 
> As a W3C staff contact, both the tone and knowledge of the space
> representing are disappointing. It is well known within the W3C and it's
> member organizations that this "entire web" distinction you make does not
> exist for implementors, and that assumption has caused great harm and damage
> to the web platform that the WHATWG has spent correcting.

To summarize, previously you wanted *everything* to be viewed as an extension
and no normative algorithms. This is backed by other real-world vendors like
Netflix who plan to implement, albeit not in a browser. However, given concerns
from browser implementers, the process would be that a normative "browser
profile" would be developed during CR to satisfy Boris' earlier concerns. 

We have to double-check to make sure you guys haven't changed your minds to
make everything normative and not allow extensions. 

If you want is forward references, then extension specs can be listed in errata
that the editors, the WG, and W3C will commit to keeping up to date. 

In which case, I believe all problems are solved. We have forward-references so
extension specs can be discovered, we have a clear "browser profile" so
developers and users know what to expect, and we don't prematurely optimize our
algorithms given the state of play in crypto. 

Unless you can see another way forward, I suggest we keep Richard's proposal as
consensus and go forward out of Last Call with that as the resolution.

> 
> Our position and preference for living specs has been made clear,
> repeatedly, within the W3C and the TAG. Beyond this, I don't think much more
> productive discussion can be made here with you. 
> 
> > 
> > > 
> > > 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)
> > 
> > There are separate specs.
> > 
> > Again, cryptographic applications are not adding new shiny graphics to CSS
> > that we expect everyone to implement.
> > 
> > Particular implementers are not idiots, particularly if they are using a
> > library that is called "SubtleCrypto". 
> 
> This isn't at all what I was saying. I encourage you to re-read Boris'
> thoughtful replies to your message, which have already spelled out the
> issues here.
> 
> This is not hypothetical. This is something we see time and time again - and
> which the W3C has made efforts to try to address, seeing that they had been
> supplanted by the WHATWG. This tone and response suggests that perhaps it's
> harder for the process to adjust to the reality - the concerns Jeff Jaffe
> was talking about, that you've heard from Boris, Anne, and Domenic on.
> 
> 
> > Furthermore, you have changed your mind on this *several* times on this.
> > Now, you are basically arguing *all algorithms* should be normative.
> > 
> > Can you explain why?
> > 
> 
> I am not arguing this anymore with you, for the reasons I explain below.
> 
> > 
> > Again, see above question. You can't have it both ways. Either you declare
> > all algorithms are normative and MUST be implemented or you allow extension
> > specs. Otherwise none of the examples you discuss hold.
> 
> You've continually misinterpreted this point that it's no doubt no longer
> productive to discuss. You've heard from both Boris and myself about the
> distinction between "spec required" and "implementation required". I've
> spent quite a bit of time explaining to you, both publicly and privately,
> regarding how the normative requirements of the spec play out for
> implementors.
> 
> You've heard from other UAs and representatives to this same effect.
> 
> > 
> > Hey, I'm not the one blocking Curve 25519, which developers do want, I
> > believe you are. We are trying to have some agility so as crypto changes and
> > developers need, we can let them have it.  I think that's dealing with the
> > messy world actually. 
> 
> I'm telling you, with an implementation hat on, where Curve25519 sits for
> priorities.
> 
> Either we add it to a spec, which is then ignored, or we have the spec
> reflect reality.
> 
> > No, I believe the needs of developers and users overrun the comfort of
> > browser vendors and the W3C. It's interesting that you call the concern for
> > non-NIST curves "boutique crypto". I think a lot of people would disagree.
> 
> You don't convince UAs to implement it by putting it in a spec. If anything,
> that's how you get UAs ignoring the W3C - when it fails to reflect the
> realities of the web, it is no longer relevant nor productive.
> 
> > 
> > Ditto for any individual person. For implementors to ignore the needs of
> > users isn't great either. 
> > 
> > That's why W3C have a consensus-based process and clear governance.
> 
> Indeed. But that doesn't, for a second, mean that it produces specs relevant
> to UAs. The specs most driven by consensus, rather than implementation,
> reflect this - no one uses them.

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

Received on Saturday, 11 October 2014 09:20:49 UTC