Responding back to Michael's original post, I and many others have tried to get Google to implement some trial feature in Chrome. And on occasion, we have succeeded. DANE was in some versions of Chrome at one point.
But persuading someone we know to frob Chrome is not a scalable approach. And from the point of view of the stability of the Internet as a whole it is a really bad idea to be alpha testing ideas on a testbed of a billion users. Google is not the only gatekeeper of course, there is Safari and Microsoft Edge. But those have also got rather large footprints. They are still too big to play games with.
There is a large amount of customization possible within Chrome of course but very little of the work we do in IETF is work that fits easily into a _javascript_ extension. We want to be playing with the low level crypto engine, the transports, etc. All the stuff we do NOT want to be accessible to a plug in. Not ever.
So what is the solution?
What I think we need is a community of knowledge that can help get IETF and other ideas into an alpha/beta test situation without having to become total wonks on the Chrome code base which is very very large and keeping up with it is pretty much a job in itself. Just setting up a machine to compile Chrome is a major undertaking.
What we really need is a version of Chrome or Edge that has some of the old extension points built back in and some new ones added so we can use it as an engineering test bed. APIs like.
* Password vault interface (to drop in choice of password manager).
* Discovery interface (to change DNS lookup).
* Transport interface (to trial new TLS / QUIC like proposals).
* Compression interface (to enable testing of new compression and content encryption schemes).
* Certificate validation
That is my API list wish at any rate. Other people might have different asks but I don't think even a maximal list would be very long.
If there was a community interested in building such a tool, we should be able to find the funds necessary to do it really right from somewhere. Much of the knowledge we need exists within the browser community, it is just a case of getting the right expert to tell us how to do something right.
The way I would find an audience for such a browser is really simple. Just give me the ability to limit Chrome/Edge to never ever allocating more than X GB of memory and I will switch to it immediately. I am sure many others would do the same. No matter how much RAM I put in a machine, it is never going to be enough if Chrome wants half, Visual Studio wants the other half and I try to open Microsoft Word.
The business model for the non-profit callsign registry is to fund exactly that sort of project but that is a couple of years off at this point.
On Fri, Apr 9, 2021 at 7:17 PM Michael Thomas <mike@xxxxxxxx> wrote:
I wrote a blog post about how something like DANE could be used instead
of certificates for the TLS handshake to get it back to the original 3
packet handshake. I know that isn't news to a lot of people, but the
interesting part is that a Google could perform an experiment to see how
well it works in real life just like they did with Quic and Spdy. Since
Quic is all about making setup time faster, it seems like a pretty
reasonable experiment since it would cut out 2 packets generally
speaking since DNS can be cached.
https://rip-van-webble.blogspot.com/2021/04/quic-elephant-in-room.html
Mike
