Re: Registries and Interoperability

On Mon, Feb 18, 2013 at 4:43 AM, Harry Halpin <hhalpin@w3.org> wrote:
>> This only applies if incorporating security considerations - which we
>> should not.
>
>
> So, you don't think there should be a place where WebApp developers using
> this algorithm can go to determine the security properties of various
> algorithms?
>
> I am *not* (I feel I am repeating myself ad infinitum here) saying this
> should be done in the API. If done, this should be done somewhere else and
> maintained outside of the WG.

Harry, I'm trying to point out the inconsistency in what you're asking.

I say nothing against having developers have a place to discover
algorithm security considerations. But what that means, and what that
entails, is a task far beyond the ability or scope of this WG.

You propose a registry as a solution, but it's not a solution. You're
not going to magically get all the crypto research distilled into a
form understandable by a lay person (which I only mention because
they're the audience you seem to be arguing for) just by saying
"registry". Nor, and again I too find myself repeating similar points,
are you going to find that the research that does exist is somehow
specific or applicable to the web crypto API - this is general purpose
research.

You argue for a registry so that we don't have to maintain security
considerations in the API. I'm saying it's arguing from a false
premise - if we accept that we shouldn't be including such
considerations to begin with, then a registry to somehow distill all
these considerations (which it won't) is no net win - because there's
no problem to begin with.

>
> I'm not saying its a magic bullet. But HTML WG does run a wiki-registry of
> rel-links. Microformats.org had a wiki. Your colleagues at Google
> (schema.org) work with W3C to keep the vocabularies unfragmented.
>
> Obviously, registries can be tricky to get right. However, I find your
> recognize the problem but have no suggested solution other than re-open the
> WG every time someone wants to use a non-standard algorithm identifier *or*
> the crypto landscape changes.

We're not talking about data sets that can be arbitrarily extended by
authors without support from tooling. These are fundamental API
decisions that require interoperable implementations. This is NOT the
"plug and play" web - nor would that be a good thing.

I absolutely am suggesting that the ONLY solution to improve or alter
web APIs should be through standards, consensus based approach, and
with relevant parties acting on good faith both in the community and
in IPR. And that's something we ONLY get through a WG. Having a "plug
and play" registry makes this API, without requiring standardization
or interoperability, puts the entire value of this WGs effort at risk.
For that matter, why even have a WebApps WG? Why not just have a
registry of vendor APIs? That's the *same thing* as what you're
proposing, from the perspective of both implementations and web
authors. Surely you see your solution is much, much worse than the
problem?

>
> Of course the Web will keep evolving and a registry does not substitute for
> consensus, and experimentation will continue.  Yet as explained earlier, it
> is 1) difficult to form WGs and 2) the crypto landscape does change.
> Ignoring these two brute facts may not be a good idea and I think may even
> strike many as foolish. I agree a registry may be suboptimal, but then
> again, you have
>
> So again, how do you deal with the situation that there is a new algorithm
> or minor changes in an algorithm that are needed in short-order?
>
> Right now I see no way of dealing with that situation. Do you believe that
> is *not* a problem?
>
> If the API has no way to dealing with this situation, I would be worried it
> would be concerned its value may be loss too quickly.

The API does have a way for dealing with this situation - the same way
that WebApps and HTML deal with this - through multi-stakeholder
consensus. I'm not arguing that we immortalize these APIs from all
future changes - but I think it's absolutely foolish to suggest or so
ardently support a solution that gives both developers and
implementers perverse incentives to ignore any interoperability or
standardization. Beyond the legitimizing effect of a registry -
whether you call it experimental or not (eg: look at how many
'experimental' IETF drafts are effective standards or effectively
immutable) - it creates even more incentives to vendor one-off, rather
than developing APIs that can be maintained.

It sounds like your real concern is with how HTML, CSS, WebApps
operate, and how I'm proposing that we operate similarly, given that
they're one of the few truly recognizable success stories in
standardization. I suspect this is a broader issue than just this WG,
but I remain convinced that the registry proposal creates more
problems than it solves, as I've repeatedly enumerated.

Received on Tuesday, 19 February 2013 18:04:45 UTC