New editor for the Web Crypto spec

[sideshowbarker]

We need an active editor for the Web Crypto spec. We need an editor to lead the spec/architecting decisions about the 13 open enhancement requests/proposals we have at https://github.com/w3c/webcrypto/labels/enhancement, as well as the 44 open issues in total that we have https://github.com/w3c/webcrypto/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc that are in need of an editor to triage/evaluate.

So if you’re reading this and would like to explore the idea of taking responsibility for editing/decision-making/discussion-leading for the spec (or can think of somebody else who might be), then please let me know — by e-mail at mike@w3.org, or by any other means — and I can give you more details about the tasks and level of effort that would be expected and needed.

One essential piece of the work is to communicate about each open feature proposal with implementors from the Safari/WebKit, Chrome/Blink, and Firefox/Gecko browser-engine teams, and then make an assessment/call about what level of implementor interest exists or doesn’t exist for actually implementing the feature proposal.

And if there’s not sufficient implementor interest in a particular proposal, then the next task would be to basically park the issue — with some kind of “lacks implementor interest” label — or else just close it outright.

The basic level-of-effort details: The rule of thumb we typically use is, an editor for a particular spec should be willing and able (that is, have support from their company management) to put one full day a week of their time, over at least 3 months, into tasks related to being editor/decision-maker/discussion-leader for the spec: 20% of their work week, ~8 hours a week.

And anybody willing to commit to that would get some number of hours of support time from a W3C staff person (e.g., me).

[sideshowbarker]

I’m happy to announce that we’ve found a new editor, Daniel Huigens https://github.com/twiss, who’s agreed to take on the responsibilities outlined in the issue description here. From discussions with Daniel, it’s clear he understands well what’s needed, and he’s got a solid plan on how we can move some things for.

So with that, I’ll leave it to Daniel to comment here to introduce himself, and to explain in his own words what he’ll putting his time into first.

Daniel, thanks — and welcome aboard

[twiss]

Thanks a lot Mike, and hi everyone!

I'm Daniel Huigens, the crypto team lead at Proton, and lead maintainer of OpenPGP.js. I have quite a lot of experience working with the Web Crypto API, both from working at Proton and on OpenPGP.js but also previously. I don't have as much experience editing specifications, so please bear with me while I figure that part out :)

I volunteered as editor for the Web Crypto spec with the goal of making it possible for web developers to build more secure web apps. The most pressing need in the Web Crypto spec I see in that regard is to modernize the set of algorithms available. In particular, adding more secure curves, adding a more modern key derivation function, and adding a more modern AEAD construction come to mind.

On the flip side, I should also explicitly say that it's not my goal to add algorithms or features purely for compatibility reasons (and that extends to things that might be useful for Proton or OpenPGP.js equally as any other company or library). I'd much rather see everyone moving towards a more secure set of algorithms.

I'll make a special mention of #73 (by far the most liked issue here) - while not strictly speaking related to improving the security, it prevents web apps from using the Web Crypto API if they have to deal with very large files, so it would be nice if we can make some progress there.

I plan to reach out to the browser vendors to see if we can align on this goal, and hopefully we can get some experimental implementations in the browsers and some new text in the spec together :)

Thanks for reading this far, and looking forward to working with everyone!