[00:00.000 --> 00:02.160]  Some more widely known today.
[00:02.500 --> 00:21.180]  And actually, what you discover is that the core fundamentals of the Internet, such as TLS, are effectively ran by groups of volunteers, you know, somewhat self-selecting, some people working there for companies, and they're running an open consensus-based process,
[00:21.180 --> 00:23.200]  which is sort of crazy if you think about it.
[00:23.200 --> 00:25.880]  So it's a global consensus-based process.
[00:25.880 --> 00:31.260]  And that, effectively, anyone, particularly the IETF, can join.
[00:31.440 --> 00:40.720]  And this comes from the unique history of the Internet, as essentially it was a research project, and basically graduate students, you know, got involved.
[00:41.660 --> 00:49.000]  And when they were defying the protocols of the software, because the military and the research units only paid for the hardware, they found what were called RFCs.
[00:49.500 --> 00:50.800]  Do people know what RFCs are?
[00:50.940 --> 00:53.160]  Do we have...okay, so request for...okay, excellent!
[00:53.320 --> 00:54.000]  Good, I was getting worried.
[00:55.160 --> 00:58.400]  So I'm glad people still actually read RFCs.
[00:58.520 --> 01:10.040]  So the fact that matters, anyone, including you, could sit down and look at something, you know, I know, for example, Tor's looking at this and say, I could create an informational RFC and suggest this.
[01:10.140 --> 01:12.160]  And then you can also say, I would create an informational RFC.
[01:12.740 --> 01:23.780]  And I actually think this should be a standard, and then it goes through this process of widespread open review, eventually gets up to the Internet Architecture Board, this takes a few years, it gives a quite thorough view, and they either approve it or deny it.
[01:25.200 --> 01:30.880]  And the web...often people ask, what is the relationship between the World Wide Web Consortium and the Internet?
[01:31.180 --> 01:35.020]  Well, the web is an application that runs on top of the Internet, right?
[01:35.120 --> 01:45.500]  So the Internet, of course, as everyone here probably knows, existed way before the web, and that the web may not last.
[01:45.660 --> 01:46.100]  We don't know.
[01:46.280 --> 01:57.380]  But the fact of the matter is, when the web started getting really big, a lot of large companies, large players started getting involved with the IETF, and the IETF is a much more loose and formal process.
[01:57.900 --> 02:09.280]  And so basically, Tim Berners-Lee, in order to sort of defend the open web from being taken over by a single company, I believe the problems at the time, were Netscape and Microsoft, basically sort of said, hey, we're going to create a standards body,
[02:09.280 --> 02:15.200]  which is a consortium, which is more structured than the IETF, and which will handle just the web-facing layers.
[02:15.500 --> 02:17.580]  And that's the World Wide Web Consortium.
[02:18.060 --> 02:20.560]  Now, why a consortium?
[02:20.620 --> 02:21.760]  That sounds very exclusionary.
[02:21.940 --> 02:27.600]  Well, what may...so the word open, everyone throws around all the time, open-source, open standards.
[02:27.820 --> 02:29.040]  What does open mean?
[02:29.320 --> 02:35.540]  The W3C actually has a pretty good definition of open, which comes from the fact that it's consortium.
[02:35.540 --> 02:42.480]  So even if you're making open-source, you are possibly liable for licensing fees from software patents.
[02:42.580 --> 02:42.920]  The U.S.
[02:43.000 --> 02:53.620]  software patent system is completely broken and is exceptionally rife with crazy software patents.
[02:53.820 --> 03:11.740]  So effectively, by making consortium of most of the large companies, we're currently running 300-some companies, including most of Silicon Valley, IBM, Google, et cetera, et cetera, and in the newer ones like Facebook and Twitter, all of those patents are gathered together and they make what is effectively a large patent war chest.
[03:12.020 --> 03:32.180]  And so if you say, hey, I'm a patent troll, I have a patent on HTML, I have a patent on crypto and JavaScript, or what can happen is that W3C can sort of say, actually, we have a giant patent war chest of patent commits from major companies to HTML, and if you want to go up against us and IBM's lawyers and Google's lawyers,
[03:32.320 --> 03:33.020]  go for it, buddy.
[03:33.240 --> 03:37.700]  And that actually basically provides a large amount of safety for ordinary developers.
[03:37.820 --> 03:41.440]  So that's the important connection between open standards and open-source.
[03:41.760 --> 03:54.500]  That while open-source effectively deals, you know, in the level of the source code, we, with specifications, deal in the level of the software process, the more abstract level can be implemented in open-source, can be implemented in proprietary code,
[03:54.560 --> 03:58.200]  and the consortium has its structure to defend against patents.
[03:58.200 --> 04:01.920]  However, the consortium is open for all sorts of participation.
[04:01.940 --> 04:11.280]  You usually have to email the working group chair, the invited expert, and they will basically give you status of what's called an invited expert.
[04:11.480 --> 04:16.660]  So I think a question is, with the World Web Consortium, is we basically start working groups.
[04:17.020 --> 04:21.080]  And how many people here participate in a W3C working group?
[04:21.460 --> 04:22.700]  Okay, one, excellent.
[04:23.060 --> 04:25.320]  Okay, so, well, it's better than IETF, I don't know.
[04:25.320 --> 04:40.060]  So the W3C basically, how we work and how we make standards, is effectively mailing list, IRC, and depending on how your working group goes, teleconfs and bug tracking.
[04:40.440 --> 04:41.700]  Huge Bugzilla list.
[04:42.180 --> 04:51.980]  And so effectively, if you can participate in any of those mediums, and you can actually track the often quite heavy amount of conversation going on, it's very easy to get involved.
[04:52.140 --> 04:58.260]  And the W3C starts working groups in particular places, which we view as crucial to the future of the web.
[04:58.480 --> 05:03.140]  So, you know, for many years, there was this excitement on XML, you know, a lot of work, of course, going on in graphics.
[05:03.500 --> 05:11.760]  And where the web has perhaps been weakest is, as everyone here, I would assume, is intimately familiar with, web security.
[05:12.780 --> 05:14.560]  And that's what we're trying to fix.
[05:17.120 --> 05:26.060]  So, another difference is that the RFCs are on ASCII, while the W3C uses HTML, because obviously the web may not be around.
[05:27.320 --> 05:43.020]  But one of the concerns we have in standards bodies is that as long as there's only a very small number of people sort of really involved in these sort of voluntary processes, and often people are paid by their employers to be involved, it's actually quite easy,
[05:43.680 --> 05:47.540]  or at least, let's say, plausible, to manipulate the process.
[05:47.720 --> 05:58.680]  So, we know that Project Bull Run had a segment of it was to actually influence standards bodies to produce standards which were more amenable to whatever the NSA's goals were.
[05:58.800 --> 06:01.280]  And this had a very large budget, you know, $250 million.
[06:01.860 --> 06:06.020]  The W3C's whole operating budget is, I think, around $10 million.
[06:06.700 --> 06:09.640]  So, it's actually very small, so they could have just bought us, I guess.
[06:09.840 --> 06:10.340]  But they didn't.
[06:11.040 --> 06:28.700]  And while we don't have any evidence that the W3C itself has been manipulated, you know, there's been a lot of controversy going on in the IETF with one of the co-chairs of the International Cryptographic Research Forum, while he worked for the NSA, and this has,
[06:28.780 --> 06:36.260]  of course, been called out and discussed, and he's still the co-chair, but, you know, it's by Trevor Perrin, among others.
[06:36.780 --> 06:55.880]  We do have a number of places where we have good evidence, not 100% solid, but solid enough that you should be suspicious, that back doors have possibly been put in at least the pseudorandom number generators recommended by NIST, and that NIST, the National Institute for Standards in the U.S.,
[06:55.880 --> 07:06.340]  because it does have heavy cryptographic expertise, does often recommend the parameters, and we'll go into this with WebCrypto in a second, used by various algorithms.
[07:06.860 --> 07:17.600]  And this is becoming much more earlier, because America was viewed as essentially having a sort of benign and neglectful role towards Internet governance.
[07:18.320 --> 07:28.980]  And NIST, you know, the problem with NIST has had sort of both an offensive and defensive sort of roles, so sometimes, you know, you want good security standards internally, and you want enemies to have weak ones.
[07:29.340 --> 07:37.900]  And so, therefore, people sort of had a, I would say, more trust in NIST than they had before, after the Stone and Revelations.
[07:38.100 --> 07:47.340]  I think Stone and Revelations did reveal that NSA was manipulating NIST in some circumstances, and now there's been recommendations from the White House, amongst others, to get that back in order.
[07:47.480 --> 07:51.340]  It's still a concern, and the question is, how do you detect that?
[07:51.340 --> 07:55.060]  Will you detect that via open processes where you have lots of people involved?
[07:55.240 --> 07:59.460]  Because the more people look at something, the more likely you are to discover the back door.
[07:59.700 --> 08:09.280]  If you're basically cooking up your standard, being in a closed industry consortium, no one will know if NIST or anyone else has manipulated your crypto.
[08:11.020 --> 08:20.540]  So what's been happening, which has been sort of interesting, is post Stone and Revelations, there was a lot of outcry by the engineers.
[08:20.900 --> 08:26.220]  So most of these standards bodies are not ran by particularly, I would say, high-level types.
[08:26.400 --> 08:36.560]  The most participation comes from people who are implementers or, I would say, at least engineers with a high-interest implementation in various organizations.
[08:36.900 --> 08:41.320]  And they were, most people were quite shocked when the Stone and Revelations came out.
[08:41.320 --> 08:51.700]  You know, Tim Berners-Lee, the director of the web consortium and inventor of the web, basically said that he felt that Snowden, you know, is a hero, should be protected.
[08:52.160 --> 09:00.020]  And that there was generally a lot of internal reviews started happening, looking at what standards that we produced, where they could have been influenced.
[09:00.580 --> 09:16.420]  And that the most important thing is that for all future standards, the Internet Engineering Task Force has basically decided that they should be pervasive surveillance, which is some sort of global passive adversary, which can basically monitor all ends of the communication network,
[09:16.620 --> 09:18.760]  should be taken as a serious consideration.
[09:19.000 --> 09:27.280]  So just as we have, in most IETF standards, security and privacy considerations, we should have considerations around pervasive surveillance.
[09:28.140 --> 09:38.840]  And if you're interested in this discussion, the IETF has a discussion at Pear Pass, which is a pervasive surveillance mailing list, and there's a lot of other discussion going on.
[09:38.840 --> 09:43.520]  But I'm going to give you more about what the W3C is doing, because that's who I work for.
[09:43.660 --> 09:50.680]  And the Internet Engineering Task Force has been very upfront, and W3C is still sort of working on our game plan for this area.
[09:50.840 --> 09:57.400]  So we did host a workshop in March, which you can look at if you want to know what we're thinking about.
[09:57.580 --> 09:59.760]  We write and make public all of our logs.
[09:59.900 --> 10:06.700]  And we were sort of saying, well, what can we as W3C do to basically help combat pervasive surveillance?
[10:06.700 --> 10:09.040]  And there's a lot of problems.
[10:09.220 --> 10:11.360]  So some of them are outside of our control.
[10:11.640 --> 10:14.940]  One of the larger problems, of course, is the problem of certificates, right?
[10:15.500 --> 10:28.800]  So, you know, certificate management, certificates, basically, you know, if there is not a hard fail for certificates, the certificate system has this ridiculous attack surface, which can be easily compromised.
[10:29.200 --> 10:30.400]  And a lot of that's out of our control.
[10:30.400 --> 10:38.080]  That's in the hands of private, closed industrial consortiums, like the certificate browser CA forum.
[10:39.680 --> 10:45.040]  But at the same point, there are some things we thought for new standards, which should be taken into account.
[10:45.180 --> 10:49.840]  So previously, in general, we have not taken into account data minimization principles.
[10:50.500 --> 10:53.940]  We have not taken into account ever traffic analysis.
[10:54.800 --> 11:06.090]  And of course, you know, although the situation is pretty despairing right now around browser fingerprinting, we are trying to at least take these into account in future standards.
[11:06.700 --> 11:16.820]  And there are large amounts of problems, which I won't go through in detail, but effectively, the web security model is well known to be broken.
[11:16.820 --> 11:27.120]  Very simple things like parsing URIs across various web browsers are not completely standardized and often prevent very interesting attack surfaces.
[11:27.320 --> 11:28.800]  So there's tons of stuff going on.
[11:28.860 --> 11:32.580]  I list quite a few of them there in all sorts of different working groups.
[11:32.600 --> 11:36.000]  But I'm going to concentrate on the ones that I'm working in.
[11:36.200 --> 11:42.540]  So the working group that I'm most involved with and helped start was the web cryptography working group.
[11:42.540 --> 11:50.340]  So we noticed the sort of disturbing phenomenon where effectively a lot of people wanted to do crypto and JavaScript.
[11:50.780 --> 11:53.500]  And, you know, they were really often very well-meaning people.
[11:54.440 --> 12:00.260]  And the fact of the matter is that sort of it's in general, particularly a few years ago, a very bad idea.
[12:00.380 --> 12:03.700]  It's still often a bad idea, but we're getting a little bit better at it.
[12:03.800 --> 12:08.740]  At least we understand the problem and have some good things we can offer you, although not enough.
[12:08.740 --> 12:15.700]  So effectively, the issue is, even if I want to do any crypto and JavaScript, I basically have to call some server-side library.
[12:15.820 --> 12:17.660]  I have to often retrieve that library from another server.
[12:17.840 --> 12:21.760]  You have to... you basically have to get... you have to trust whatever that code is.
[12:21.940 --> 12:26.280]  That code often has not been very... very well-reviewed.
[12:26.280 --> 12:28.140]  So you look at OpenPGP.js.
[12:29.180 --> 12:35.860]  And well-meaning web developers, this came up with, I believe, CryptoCad and has come up much more recently with ProtonMail.
[12:36.000 --> 12:40.380]  And it was even, strangely enough, mentioned by LADAR in Darkmail.
[12:40.460 --> 12:47.400]  There's this real desire to do things like provide Indian encryption in JavaScript.
[12:47.820 --> 12:53.240]  Which is, at least without a browser plug-in, a terrible idea.
[12:53.360 --> 12:58.980]  It just does not work because you cannot basically buffer the private key from the server.
[12:58.980 --> 13:03.680]  And furthermore, your cryptographic routines, you know, they're not necessarily well-verified.
[13:03.820 --> 13:04.720]  They're not constant time.
[13:04.840 --> 13:06.180]  There's all sorts of problems there.
[13:06.360 --> 13:09.360]  And so we basically don't want people to create...
[13:09.360 --> 13:13.140]  And I can't tell if it's advertising or just idiocy.
[13:13.860 --> 13:24.660]  Something like ProtonMail, which basically claims to be an end-to-end encrypted email service, which actually isn't because it just runs in the browser runtime, where you can't do that for very principled reasons.
[13:24.820 --> 13:29.480]  We would eventually like to get to the point where that is possible, but that's a long road.
[13:29.620 --> 13:33.320]  I'm going to walk through what progress we've made and what progress we have in.
[13:33.700 --> 13:41.080]  So, what we did is we did create a JavaScript Web Cryptography API.
[13:41.540 --> 13:43.080]  Just Google if you want to look at the API.
[13:43.220 --> 13:50.460]  And the API offers all the features that one would want out of, effectively, JavaScript Web Crypto.
[13:50.460 --> 13:52.660]  So, however, it is...
[13:52.660 --> 13:56.140]  So, basically, it's asynchronous, which is great.
[13:56.300 --> 13:58.640]  So, it uses promises, which allows...
[13:58.640 --> 14:07.280]  So, what you don't want when you're running JavaScript Web Crypto is you don't want to start generating a key, and that jam up all the rest of your JavaScript code.
[14:07.280 --> 14:12.980]  It does offer probably too many cryptographic parameters.
[14:13.140 --> 14:14.080]  There's a bit of debate over this.
[14:14.220 --> 14:26.420]  But we do encryption, decryption, ECC, RSA, all of the classic stuff, all of the hashes that you could...hash functions that you could possibly want, including ones that people, you know, don't like, and some of which are clearly broken, like SHA-1.
[14:26.580 --> 14:30.360]  But we do give all those to you, and we do want them to be sort of constant time.
[14:30.360 --> 14:50.680]  The problem is we do not...we realize that this API effectively is going to be used, we think, at least in this version, by people who are basically trying to code up some sort of protocol, and they can follow the instructions, and they understand their security models.
[14:50.740 --> 14:59.720]  What we are not trying to create in this version of the API is the API for end developers who don't know what they're doing, who just want some quick level of security.
[14:59.720 --> 15:01.100]  We would like to do that.
[15:01.260 --> 15:18.360]  The problem is that's very protocol-specific, so we said we're going to create the most general-purpose one we can in the beginning, and more higher-level, abstract ones could be created afterwards by essentially, at first, polyfilling and later, building on top in a more cohesive way and maybe a second version of the spec.
[15:18.600 --> 15:20.720]  So that's called the high-level API.
[15:22.760 --> 15:25.160]  But we have a number of open issues.
[15:25.360 --> 15:29.500]  So one of the open issues is...so how...
[15:29.500 --> 15:40.960]  the W3C works is we create a draft spec with the implementers involved, with a larger crowd involved, and the WebCrypt API had about, you know, originally about 50 people in the room, and it's kind of died down a bit.
[15:41.300 --> 15:50.920]  But right now, we do have all the major browser vendors involved, and one thing that the developers want is the developers want Bernstein's ECC curve.
[15:50.920 --> 16:00.520]  So curve 25519 is considered, you know, more trustworthy than the NIST-provided parameters for ECDSA.
[16:00.760 --> 16:03.000]  And this has been very controversial.
[16:03.020 --> 16:06.000]  It's actually still an open issue within the working group.
[16:07.780 --> 16:17.700]  Most of the browser vendors feel like providing this curve is a bad idea, mainly because it's unclear if that curve can be...so right now, DGB says, well, of course, it's a great curve.
[16:17.880 --> 16:20.100]  But there's, of course, the Serticom patent concerns.
[16:20.260 --> 16:26.060]  And also, there's the fact that can...well, DJB will provide in Libsodium some very good code.
[16:26.220 --> 16:30.200]  The fact of the matter is, can you replicate that code across multiple environments?
[16:30.480 --> 16:32.860]  Is it...is it well specified enough?
[16:32.960 --> 16:37.100]  And there isn't an IETF RFC for DJB's code yet.
[16:37.100 --> 16:38.960]  I mean, hopefully there will be shortly.
[16:39.380 --> 16:48.000]  And then, if you're going to open up the door to different ECC curve parameters, why don't you open up the door to all sorts of possible curves?
[16:48.600 --> 16:53.220]  And if you...if you do that, what else can you do?
[16:53.360 --> 17:01.980]  And this is where, effectively, Brian Lamacchia and other folks at Microsoft have been suggesting a new set of curves called the nothing-up-my-sleeve curves.
[17:02.140 --> 17:05.400]  And these curves have been...and they want to put...they already have them in Windows.
[17:06.220 --> 17:11.540]  They're available in the web...next-generation cryptography API from Microsoft.
[17:12.300 --> 17:13.920]  And should you expose those to the browsers?
[17:14.080 --> 17:16.940]  So these are sort of issues that we have in a working group.
[17:17.860 --> 17:23.320]  What kind of algorithms with what parameters should we let into the API?
[17:23.440 --> 17:27.040]  And we have to balance that with the very real implementation concerns, right?
[17:27.120 --> 17:40.460]  So we don't have DJB's curve in NSS, which is the sort of baseline code which everyone uses for all of their crypto in their browsers, at least if you're cross-platform, such as Chrome and Mozilla.
[17:41.020 --> 17:45.300]  Other browsers, of course, call it like Apple, and Windows call it an underlying OS code.
[17:45.440 --> 17:46.480]  So that's one open issue.
[17:47.200 --> 17:51.780]  Another open issue is the sort of broken crypto issue.
[17:52.060 --> 17:57.660]  So we do give developers possibly enough crypto to shoot themselves in the foot with.
[17:57.660 --> 18:12.680]  Now, the reason why we do this is that we do believe that people will want some level of backwards compatibility when, you know, trying to do very well-known protocols, you know, SSH, for example, using the crypto API.
[18:12.940 --> 18:20.060]  And we do believe the crypto API is not just going to be used in browsers, but will be a sort of standard API across all sorts of native JavaScript environments.
[18:20.060 --> 18:23.840]  So we, of course, we have SHA-1 in there, which is broken.
[18:23.980 --> 18:30.740]  We did remove PKCS 1.15, because we do not authenticate, force authentication.
[18:30.840 --> 18:35.140]  We do not force initialization of vector randomization.
[18:35.440 --> 18:47.180]  We do not... and we have a lot of algorithms there, which, of course, don't have security proofs, and some of them, some of the password-based key derivation functions, have known weaknesses.
[18:47.180 --> 18:55.280]  At the same point, if we feel that they are well-specified and enough people want them, we are currently adding them in, and we're trying to figure out how to make it extensible.
[18:55.540 --> 19:07.420]  We do feel that crypto agility could be a good thing, and this is a discussion I'd like to have with people here, but we also... we don't want to try to force people to use what we think is good crypto, and later we discover it's not.
[19:07.960 --> 19:10.860]  So we're trying to be non-judgmental would be one way to put it.
[19:10.860 --> 19:17.980]  Now, maybe the hardest problem, which we do not tackle, is key storage, right?
[19:18.220 --> 19:26.220]  So... so what a lot of people want to do is they want to basically do end-end encryption with some kind of long-term private key material.
[19:26.380 --> 19:29.300]  That private key material is hidden from the server.
[19:29.440 --> 19:31.120]  So we try to do the best we can.
[19:31.840 --> 19:38.160]  Currently, the best the Web Crypto API does is it basically does not pass around the raw key material.
[19:38.160 --> 19:42.240]  It passes around only handlers or identifiers the key material.
[19:42.420 --> 19:48.300]  And keys can be marked as either extractable, as in I can extract them from...
[19:48.300 --> 19:52.640]  and ship... get the raw key material and ship it around, or not.
[19:52.820 --> 20:00.320]  So we say, well, look, we can make keys which we say shouldn't be extracted, and we can also define an array of usages, such encrypt, decrypt.
[20:00.360 --> 20:05.200]  So you don't want to reuse keys for things, often destroys whatever security properties they have.
[20:05.200 --> 20:09.920]  And we often... and this is what we try... we try to do.
[20:10.060 --> 20:15.820]  But there is some just fundamental problems with the web security model.
[20:16.420 --> 20:25.140]  So right now, you know, we cannot guarantee that those key usages you gave for encryption and decryption, and in assigning, actually are attached to that key material forever.
[20:25.340 --> 20:31.220]  So it can be removed and changed by JS code, either from the server or from the user side.
[20:31.220 --> 20:37.780]  And, you know, we don't preserve those via... inside of key wrapping and unwrapping operations.
[20:38.280 --> 20:42.360]  And furthermore, we only offer ephemeral keys.
[20:42.540 --> 20:44.020]  The keys are bound to the session.
[20:44.600 --> 20:46.260]  And some of that was on purpose.
[20:46.440 --> 20:51.080]  So there was a... there was a concern that effectively...
[20:51.080 --> 20:59.700]  if we created another magical key storage mechanism, without thinking it through very hard for long-term key materials, we would just be creating super cookies.
[21:00.140 --> 21:03.500]  And we don't really want more super cookies than we already have.
[21:04.400 --> 21:06.300]  Also, we're also trying... we're trying...
[21:06.300 --> 21:19.540]  and this is very different from the encrypted media extensions, DRM, effectively, which is being pushed through HTML5, not my working group, in W3C, where we're basically saying the key materials should remain under user control.
[21:19.540 --> 21:23.240]  So the user should be able to delete keys whenever they want.
[21:23.240 --> 21:27.840]  And they shouldn't be forced to... there shouldn't be any key material which is hidden from them in particular.
[21:28.620 --> 21:35.160]  And so trying to figure out how you get key storage working in that paradigm ended up being a very hard problem.
[21:35.480 --> 21:39.420]  At the same point, there's a lot of good usages for that... for having that.
[21:40.180 --> 21:42.040]  And we will return to those.
[21:42.220 --> 21:44.340]  And this... the... the last thing...
[21:46.460 --> 21:48.240]  which we... we notice is also that...
[21:48.240 --> 21:53.960]  that, you know, we... we do let polyfilling happen over the primitives right now.
[21:55.300 --> 21:55.820]  So...
[21:55.820 --> 22:10.440]  if you did have a cross-site scripting attack, or your server just decided to give you some new JavaScript code, and the server had gone malicious on you for some reason or another, you currently would not know if your JS functions had been polyfilled.
[22:10.660 --> 22:13.400]  At the same point, polyfilling could be very good.
[22:13.520 --> 22:29.280]  We can imagine very easy, more developer-friendly versions of JS crypto being made, with polyfilling, and making certain functions not polyfillable, and various functions things immutable, is... is a pretty large change to JavaScript, which we... we couldn't get through in a single API.
[22:29.740 --> 22:36.540]  That being said, we do think this API has some real usages.
[22:36.800 --> 22:55.660]  So... this is really sort of funny saying from the IETF, is that, you know, sending a... often sending packets across using TLS, is like sending money in an armored truck between a guy who's living on a park bench, some homeless guy on a park bench, and another homeless guy in a tent.
[22:56.300 --> 23:03.280]  And this is because, effectively, usually the servers are not particularly secure, and the client's not particularly secure.
[23:03.360 --> 23:20.280]  So we were hoping that by providing another level of crypto, another level of digital signature, particularly the digital signature verification, which could work very well with protocols such as OAuth, we were allowing another level of crypto, which would not be as easily compromised.
[23:20.440 --> 23:27.320]  So, basically, if you have one... if one sort of channel gets attacked, you can... you can... you still have another channel which can keep secure.
[23:27.420 --> 23:28.560]  You could do channel binding.
[23:28.800 --> 23:34.140]  And we... we believe that this sort of thing is both... capable of reinforcing the channel.
[23:34.320 --> 23:40.120]  And, of course, what a lot of people want, which is storing the data encrypted on the server, could be very useful.
[23:41.880 --> 23:48.860]  However, that being said, the problem with the web security model is that you always... the server is just completely trusted.
[23:49.120 --> 23:56.020]  And as Douglas Crockford said, you can never trust a server to act completely in the interest of the user.
[23:56.220 --> 24:13.920]  And what the W3C would like, which I would love to discuss with what time we have, is that we would like to see how we can, over the next few years, move the web security model away from one which is purely server trusted into one which actually is user-centric,
[24:14.160 --> 24:15.520]  which actually is client-centric.
[24:15.780 --> 24:20.300]  But then, there's a contradiction there because today, of course, clients...
[24:20.300 --> 24:22.720]  there's so many different clients.
[24:23.000 --> 24:25.180]  So, you can't... you don't want to tie it to a particular client.
[24:25.240 --> 24:32.100]  You really want to tie it to a user because the user will be using many, many different user agents over many, many different client devices.
[24:32.600 --> 24:36.540]  So there's a lot of thinking which has to be done there to sort that out.
[24:37.940 --> 24:40.140]  And this is tricky.
[24:41.240 --> 24:43.600]  There is some work going on this way.
[24:43.720 --> 24:49.420]  So the obvious thing that people need to be able to do is they need to be able to sort of verify JavaScript code.
[24:49.560 --> 24:52.360]  Right now, JavaScript code, you just get it, it runs.
[24:52.600 --> 24:53.960]  It's not all bad, right?
[24:54.040 --> 25:00.240]  So if you look at a lot of the zero days out there, a lot of the zero days that we have in the wild are often browser plug-ins.
[25:00.240 --> 25:02.100]  Browser plug-ins are often not very well maintained.
[25:03.020 --> 25:06.800]  You know, at least with zero days in JS, you don't have the installation problem.
[25:06.920 --> 25:15.380]  How do you make a user install a particular piece of client software and a particular piece of... or a particular plug-in?
[25:15.820 --> 25:18.220]  And, you know, with the web, you just get that JavaScript.
[25:18.420 --> 25:27.700]  At the same point, you don't have a good way of verifying where that JavaScript came from and has it changed since you've last downloaded it.
[25:27.700 --> 25:34.400]  And that, since that's basically impossible, you're always going to be completely trusting the server.
[25:34.540 --> 25:35.940]  And that's pretty dangerous.
[25:37.000 --> 25:44.960]  Now, there is some work in the space already commencing in a working group in the W3C called the Web Application Security Working Group.
[25:44.960 --> 26:01.400]  And this is W3C sub-resource integrity, which basically takes a hash of the JavaScript and you can sort of put that hash in your link and you can check to make sure that JS is really working with what... in combination with things such as content security policy,
[26:01.420 --> 26:08.760]  which the fellow from Twitter just talked about, we think does help, but it's not really the complete solution, right?
[26:08.760 --> 26:10.040]  So it's just a hash.
[26:10.220 --> 26:23.460]  So what we like, you know, very primitive language... very primitive ways of doing this would be let's add digital signatures to the whole JS code, let's add an index of digital signatures, some append-only logs, looking at work such as the certificate transparency work,
[26:23.800 --> 26:24.820]  coming to IETF.
[26:24.940 --> 26:39.700]  And so you could imagine that, hey, I got some JavaScript, it's signed, I'm going to check that signature, see if it's been updated, see if it's trusted, see if it fits in with my web of trust, and then you could start building a more user-centric JavaScript paradigm into the web.
[26:41.060 --> 26:48.280]  Second thing is we really do need to fix the problem around key storage and polyfilling.
[26:48.580 --> 26:54.080]  And while we're at it, we do believe that we should probably fix the long-standing problem around passwords.
[26:54.980 --> 27:02.600]  And so the W3C is having a workshop, you're all invited, even though the deadline for interest was, I think, today.
[27:04.120 --> 27:05.880]  We're probably going to extend it a week.
[27:06.140 --> 27:08.300]  And that's in Mountain View in September.
[27:08.640 --> 27:12.320]  And what this workshop is called Web Cryptography Next Steps.
[27:12.380 --> 27:15.640]  So we're looking at what are the next steps for crypto on the web.
[27:15.900 --> 27:18.820]  And we have a lot of interesting options on the table.
[27:19.220 --> 27:26.340]  So I don't know how many people here have something like the German Privacy Foundation's USB stick, or something like this, a smart card.
[27:26.480 --> 27:27.900]  Okay, Sasha, of course, does, yes.
[27:27.900 --> 27:35.220]  So we would like for, you know, the key material to not always be in local storage, right?
[27:35.260 --> 27:44.300]  It would be great if you could have long-term key material outside the browser, and somehow the browser could check if that key material is there, and ideally under your control.
[27:45.820 --> 27:51.820]  And we, right now, that's basically impossible, and that's something a lot of vendors are interested in fixing.
[27:51.820 --> 28:00.800]  And not only, of course, the key material, but the cryptographic operations themselves, which now put you kind of more in this sort of trusted execution environment, quote-unquote, land.
[28:01.120 --> 28:09.840]  But you can imagine, you know, that the actual key operations which run over that key material are also kept in a hardware token or whatnot.
[28:09.960 --> 28:10.900]  So that's sort of one angle.
[28:11.400 --> 28:14.040]  Another angle, how many people here have heard of the FIDO Alliance?
[28:15.320 --> 28:17.680]  Okay, so the FIDO Alliance is exceedingly interesting.
[28:17.680 --> 28:25.220]  There's all sorts of very nice, high-tech, biometric, zero-knowledge proof stuff going on in one hand, and a bunch of more lower-level two-factor authentication.
[28:25.900 --> 28:33.020]  Hey, I got a phone message, and that's going to check my identity, and therefore, unlikely, I've stolen the password.
[28:34.340 --> 28:37.420]  And all of that sort of stuff has web-based components.
[28:37.560 --> 28:48.880]  The problem with the FIDO Alliance is they're currently a closed industrial consortium, and they're interested in opening up some of their standards to open standards bodies, which is in their long-term game plan, like the W3C.
[28:49.740 --> 28:53.520]  And so this sort of stuff will be discussed at the workshop.
[28:53.520 --> 28:58.540]  And the workshop is, like most W3C events, free to attend.
[28:58.540 --> 29:04.580]  You just have to send in a little submission of interest, and we'll get you inside of the room.
[29:05.280 --> 29:06.740]  So we hope to see you all there.
[29:08.780 --> 29:09.480]  Say that again?
[29:11.200 --> 29:13.920]  Oh, we don't pay for travel.
[29:13.920 --> 29:16.220]  Like I said, we can barely pay for ourselves.
[29:18.080 --> 29:29.100]  However, often, if you really think you should be able to go, and you don't have enough money, there are, of course, ways you could... lots of different other people you could ask for money.
[29:29.240 --> 29:30.900]  I just want to ask for us.
[29:31.040 --> 29:39.380]  I mean, we can... unfortunately, it's exceptionally not a... standards are effectively non-profit, and there's not a giant bank account, unfortunately.
[29:40.240 --> 29:47.540]  And the last thing I'd like to mention is that the W3C is also not just interested in, of course, making crypto and security more user-centric.
[29:47.800 --> 29:52.740]  There's also a lot of interest in social networking.
[29:52.880 --> 30:11.900]  Looking... we have noticed that this sort of move towards effectively what Tim calls sort of walled gardens is having some sort of negative long-term effects on the web, and that we do think that social should be a first-class citizen of the web, just like HTML.
[30:12.540 --> 30:15.060]  And so we're launching a new working group on Monday.
[30:15.200 --> 30:16.300]  This is just a sneak preview.
[30:16.580 --> 30:29.840]  And this working group is going to be a... sort of chaired by Tantec from the IndieWeb group, along with Arnaud Lahors and Evan Podromo, who most people here might remember from Identica or Status.net.
[30:29.840 --> 30:37.460]  And this working group will investigate how can we create federated or decentralized social networking protocols.
[30:37.720 --> 30:39.140]  And we're going to go over those really quickly.
[30:40.580 --> 30:44.480]  So this working group will basically look into three particular things.
[30:44.680 --> 30:46.940]  We're going to look into what's called activity streams.
[30:47.140 --> 30:49.160]  So activity streams is just another way of saying status updates.
[30:49.420 --> 30:56.960]  And we would like for people to make not just, you know, like status updates, but all sorts of status updates for whatever application they want.
[30:56.960 --> 31:08.500]  So we're going to... we have a older activity stream spec, which is currently in the ITF, which we're going to move in W3C, which will allow people to create their own schemas for describing activities in whatever possible domain they want.
[31:08.760 --> 31:13.580]  And of course, you know, data formats are great, but what you really want to do is you want to put them in a web app.
[31:14.140 --> 31:24.800]  And that's why we're going to work... looking at some of the older open social stuff and upgrading it to use more modern HTML5 work, such as web components, and better JavaScript sandboxing.
[31:24.960 --> 31:35.400]  How can we get a... you to be able to easily embed sort of social web applications in a decentralized way across many different websites and put that in JS apps?
[31:36.800 --> 31:38.800]  That's the... that's the API component.
[31:39.000 --> 31:41.740]  And then on the... so that's the client side component, basically.
[31:42.000 --> 31:46.880]  But on the server side, if you have a decentralized social networking system, you have to keep everything synchronized.
[31:47.480 --> 31:54.780]  And right now, activity streams, you can imagine in more or less like RSS feeds, open social API, just, you know, that's another JS API.
[31:55.400 --> 31:58.680]  But the hard unsolved problem is how do we federate?
[31:58.780 --> 32:01.180]  How can we have different nodes talking to each other?
[32:01.520 --> 32:07.280]  And how can they all keep their status updates and other social information, this is your personal data, in sync?
[32:07.940 --> 32:10.780]  And how can you do discovery, request?
[32:11.100 --> 32:14.200]  And these are all very hard problems.
[32:14.780 --> 32:17.060]  And these are what we're going to be tackling over the next few years.
[32:17.220 --> 32:19.960]  And I'm just going to mention a few of the obvious security problems.
[32:19.960 --> 32:29.580]  So, one of the more obvious security problems is that decentralization does not always bring security benefits.
[32:29.920 --> 32:41.000]  I mean, you can make it often a very good case, which Google made and many other companies made up to fairly recently, due to the revolutions of surveillance, they sort of said, well, why do you trust some sort of flaky decentralized system?
[32:41.180 --> 32:45.280]  It's better to put all your eggs in one basket and with a good security team.
[32:46.080 --> 32:48.220]  And there is some truth to that, right?
[32:48.220 --> 32:53.080]  So, in a decentralized system, if you don't have a good trust model, you can always have Sybil attacks.
[32:53.220 --> 33:06.480]  NSA can always send, you know, 5,000 nodes into your smaller network, overwhelm you, and then you think you're talking to your friend, and you're actually being talking to the NSA and having that message then shipped to your friend.
[33:06.600 --> 33:08.680]  So, these sort of Sybil attacks are very dangerous.
[33:09.000 --> 33:12.820]  And they're often solved by using social networking techniques.
[33:12.820 --> 33:17.520]  So, you sort of say, well, if I know you and I have a trust relationship with you, I can route traffic through you.
[33:17.700 --> 33:20.600]  So, that's sort of friend, social friend trafficking.
[33:20.800 --> 33:30.100]  And that's often what a lot of the decentralized social networking software that we've seen up till now do, but then that has another problem, which is then you're vulnerable to traffic analysis.
[33:30.340 --> 33:39.460]  So, when you start sending traffic to all of your friends, often the most important part of any sort of collection of data is who knows who.
[33:39.460 --> 33:45.160]  And therefore, by decentralizing your system, you've actually made yourself more vulnerable to traffic analysis.
[33:45.700 --> 33:54.380]  And as we all know, the metadata around social graphs is perhaps the thing that the NSA and all these sort of folks are more interested in than almost anything else.
[33:54.880 --> 33:57.240]  So, there's a lot of really hard problems there.
[33:57.400 --> 34:00.980]  And some of these are technical, and I'm just going to end on a social note.
[34:01.440 --> 34:04.060]  A lot of these problems are also political and social.
[34:05.380 --> 34:20.800]  And while the W3C is a technical standards body, Tim Berners-Lee has, in reaction to this notion of mass surveillance, called for what he's described as the Web We Want campaign.
[34:21.120 --> 34:39.380]  Where he's basically sort of saying what the Web actually needs, is it needs people to really get politically involved, and effectively a social movement around the future of the Web, so that we can pass a user-centric, secure, privacy-preserving Web to our children.
[34:39.640 --> 34:49.220]  And the only way we're going to do that is effectively, you know, getting involved in politics, getting into the streets, but also by having a shared vision of the kind of Web that we want.
[34:49.460 --> 34:51.460]  What's its both technical characteristics?
[34:51.680 --> 34:54.740]  Do we want, you know, for example, more decentralized alternatives to DNS?
[34:54.880 --> 34:57.600]  Do we want a more decentralized social Web?
[34:57.800 --> 35:02.220]  Do we want crypto which is more user-facing?
[35:02.940 --> 35:12.100]  You know, this sort of stuff are effectively what Tim would conceive as, and which I agree, they're kinds of rights.
[35:12.320 --> 35:17.000]  And they're not rights which are given to us by any government.
[35:17.000 --> 35:30.060]  They're rights which we can use to have a common vision of the kind of Web that we want, the kind of society that we want, and then we can use these to politically organize around.
[35:30.220 --> 35:45.220]  So I think what's happening with this initiative is Tim, because of course he's British, imagines it as a Magna Carta in the United States, probably more of a Bill of Rights, but regardless, he wants some sort of core statement of principles, ideally crowdsourced from the Internet itself,
[35:45.220 --> 36:04.740]  which, and there's been lots of previous efforts in this, but I think after Snowden it's time to give it a real good shot, to really do it for real, and produce a sort of document, which then in various countries we can rally around, and either try to pass into whatever is the appropriate local law,
[36:04.940 --> 36:10.980]  and also protest for in countries where passing into local law is impossible.
[36:10.980 --> 36:18.780]  And that's how we can move from not just the Web we want, but to the world we want.
[36:18.920 --> 36:23.040]  So I think that's it for my presentation.
[36:23.040 --> 36:26.880]  That was very high level, and I would like to take detailed questions.
[36:27.900 --> 36:29.540]  So do we have any questions?
[36:29.700 --> 36:31.120]  And thank you for staying up so late.
[36:31.260 --> 36:32.520]  I know it's almost midnight.
[36:32.700 --> 36:33.480]  You're missing a movie.
[36:33.480 --> 36:37.600]  It's probably beer and alcohol of all sorts downstairs.
[36:38.180 --> 36:47.160]  But the main message here is that we really need you guys and girls to get involved in the future of the Web.
[36:47.340 --> 36:56.940]  That, you know, we're basically, I'm here, on my knees, there, going all the way down, asking you to please get involved.
[36:56.940 --> 37:06.560]  We do not have enough neutral, earnest, technically adept people in this space.
[37:06.920 --> 37:18.400]  And that the future of these protocols really does depend on just having the time and the patience and the technical knowledge to get involved.
[37:18.580 --> 37:20.880]  And anyone can get involved and start.
[37:21.100 --> 37:23.580]  That's how Aaron Swartz started out.
[37:23.580 --> 37:26.280]  He was involved in the W3C RDF working group.
[37:26.400 --> 37:27.760]  And, of course, went on to do great things.
[37:28.320 --> 37:46.200]  And I think that the more people that we have involved in this, by the sheer virtue of open, transparent processes, is the best guarantee we have to technically defeat pervasive surveillance, or any kind of surveillance, really.
[37:46.700 --> 37:50.360]  And that is critically important.
[37:50.360 --> 37:59.340]  And in combination with a large-scale, ideally global, social movement, I think, yeah, five or ten years from now, we will actually have the web we want.
[37:59.520 --> 38:00.600]  So, that's it.
[38:00.820 --> 38:01.440]  Thanks a lot.
[38:06.510 --> 38:10.770]  I am shocked people are still awake.
[38:11.050 --> 38:12.530]  I'm actually jet-lagged as well.
[38:12.730 --> 38:14.950]  So, any questions of any sort?
[38:15.870 --> 38:16.610]  Go for it.
[38:18.570 --> 38:26.670]  So, that's when you, like, basically, I have a JavaScript function, and I can dynamically replace it with another JavaScript function with the same name.
[38:27.230 --> 38:27.590]  Right?
[38:27.630 --> 38:28.970]  And you can get that from another website.
[38:29.010 --> 38:31.530]  So, let's say I don't like the WebCrypto API's encrypt.
[38:31.690 --> 38:32.790]  I want another encrypt.
[38:32.850 --> 38:37.590]  I want this encrypt to automatically, let's say, randomize the initialization vector, which is a good idea.
[38:37.990 --> 38:40.310]  And I can make that my function do that.
[38:41.110 --> 38:45.530]  But it's also dangerous, because I can also imagine a case where I'm some very malicious person.
[38:45.530 --> 38:47.490]  I say, ha, ha, ha, you think you're encrypting.
[38:47.630 --> 38:53.190]  But actually, you've retrieved my library, and my library is doing something completely different with your data, just like shipping it to me.
[38:54.650 --> 39:00.930]  So, that's, it's a very hard problem to solve, but it's something which we think is possible in the future.
[39:03.450 --> 39:04.910]  Okay, and something on the back.
[39:12.490 --> 39:22.430]  Yeah, I mean, I think I've already made my views clear on this, which is, I'm personally very against digital rights management.
[39:22.710 --> 39:37.590]  And it's been brought up that the issue, one of the issues with digital rights management, is that the key is completely hidden from the user in the magical content CDM, content decryption module, which is actually...
[39:37.590 --> 39:48.950]  And the key with DRM, particularly with encrypted media extensions, is that, you know, it's the code and the CDMs already exist in a lot of hardware.
[39:49.150 --> 39:51.670]  So, right, so Microsoft and Google have pushed that out.
[39:51.930 --> 39:56.890]  The W3C has not made dear EME a recommendation yet.
[39:57.310 --> 40:03.990]  And actually, the use case, which is how do we protect high-value content, got in.
[40:04.130 --> 40:10.070]  So, what I would like to see personally, I'm not speaking for W3C here, so don't fire me.
[40:10.750 --> 40:27.210]  But what I would like to see personally, is I would like to see systems which allow access control in a way which does not put private key material in any device that a user doesn't control.
[40:28.250 --> 40:40.190]  And right now, you know, it's an open question, could the WebCrypt API does not have key material that can at least be deleted by the user in the same way users can clear cookies.
[40:41.410 --> 40:48.490]  At the same point, there are legitimate cases where the user, like I said earlier, wants to have some long-term private key material.
[40:48.630 --> 40:52.690]  Hardware tokens, privacy, German privacy foundation, USB sticks.
[40:53.150 --> 40:57.990]  And for these, I'm okay with that as long as the user is authorizing the use of that key.
[40:58.150 --> 41:00.150]  As they say, hey, you know, I have this key.
[41:00.150 --> 41:02.290]  I can put it in my device, or it's in my device.
[41:03.290 --> 41:11.190]  And, but I should also be if I'm, let's say, a subscriber to a DRM using, let's say, streaming service.
[41:11.810 --> 41:21.850]  You know, if I want to go delete that private key, then yeah, maybe I lose access to the streaming service, but it's my right to delete or remove that private key material.
[41:21.970 --> 41:25.810]  I think that's really important to preserve that right.
[41:27.290 --> 41:32.210]  That being said, the future of EME is still unwritten.
[41:32.770 --> 41:34.530]  You, you can still make comments.
[41:34.730 --> 41:35.510]  It's an open process.
[41:35.510 --> 41:37.650]  It would be nice if more people made comments.
[41:38.450 --> 41:52.430]  It would be useful to imagine a case where you can solve the use cases of high value content, including streaming media, without forcing something like cryptic media extensions through.
[41:52.430 --> 42:08.970]  So you can imagine, and there's been discussions around watermarking and other technologies, but what, weirdly enough, while it's very easy to write a blog post complaining about DRM, it's actually hard to say, well, look, we want to take that use case seriously.
[42:08.970 --> 42:12.270]  I think there should be something like access control on the web.
[42:13.070 --> 42:15.790]  And W3C is having a workshop on this in September in Paris.
[42:15.790 --> 42:22.970]  But I don't think that EME is the right answer, so I need to make that watermarking specification.
[42:23.130 --> 42:28.860]  I need to make a draft access control specification.
[42:30.050 --> 42:35.470]  I need to make a version of something that does encrypt media where the user controls the key.
[42:35.650 --> 42:40.750]  And if you could write that specification down, you could ship that to W3C.
[42:40.750 --> 42:44.750]  And Tim would take a look at it when he makes a decision if we should approve EME or not.
[42:46.550 --> 42:48.310]  Sorry, that's a long story.
[42:48.510 --> 42:49.750]  That was probably too much of an answer.
[42:49.970 --> 42:51.710]  I think we have one minute left and one more person.
[42:52.070 --> 42:52.830]  It's all over.
[42:55.810 --> 42:58.550]  I think he... it's over there.
[43:07.030 --> 43:09.750]  David from the Internet Society of New York.
[43:09.890 --> 43:12.830]  We've already sort of had a little bit of a conversation a while ago.
[43:13.490 --> 43:14.610]  I missed your panel.
[43:14.790 --> 43:15.070]  I'm sorry.
[43:15.070 --> 43:16.030]  Right, don't worry about that.
[43:16.610 --> 43:24.630]  We had been discussing the multi-stakeholder model, which is generally conceived of as, you know, NGOs and governments and things like that.
[43:24.730 --> 43:34.950]  But the real... the way I feel is that the multi-stakeholder model in the current world is everybody who uses the Internet who is affected by it.
[43:35.230 --> 43:39.770]  And that's, you know, every sentient being on the planet very soon.
[43:39.770 --> 43:49.910]  So the question is, how do we get all those people, all those even sentient beings, there are moves to get, you know, animals on the Internet and things like that.
[43:50.370 --> 43:50.930]  How do we get everybody...
[43:51.710 --> 43:52.210]  Yeah, right.
[43:52.350 --> 43:52.550]  Yes.
[43:52.810 --> 43:53.130]  Right.
[43:53.170 --> 44:00.530]  How do we get everybody into the process of actually, you know, being able to advocate for the Internet that they want?
[44:01.270 --> 44:15.190]  So, I mean, we are hoping that the Web Foundation's Web We Want campaign and the Internet, Magna Carta, Bill of Rights campaign can help that because we would like something that's simple enough that everyone can understand and we can translate it into many languages.
[44:15.470 --> 44:19.850]  I do think it's an open organizational problem as well.
[44:20.170 --> 44:21.730]  Like, some of it actually comes down to organization.
[44:22.930 --> 44:33.390]  How is it that you, right now, one of the reasons why relatively small groups run a lot of working groups is because, A, it takes a lot of time, and, B, like, small groups can be pretty productive.
[44:33.510 --> 44:37.210]  You have about a dozen people, that's a good-sized group, maybe distributed throughout the world.
[44:37.470 --> 44:52.310]  When you have distributed groups of hundreds of thousands or hundreds of thousands or millions of people, how to sift through all of that feedback, how to get things done is, I think, a really hard problem, but I think it's imminently solvable.
[44:54.070 --> 45:09.830]  And the World War Web Consortium were actually involved in a research project called Decent, or Decentralized Citizen Engagement Technologies, where we'll be running some experiments around very large-scale, multi-thousand-person group involvement.
[45:10.010 --> 45:17.870]  And I feel like until we solve that problem, we are in a situation where you do not want multi-stakeholder governance.
[45:18.350 --> 45:33.350]  So a lot of people, you know, they compare multi-stakeholder governance to, let's say, you know, national-level political negotiations, with political negotiations in the UN between various nation-states, and you say, well, you know, the W3C is just negotiations among companies.
[45:33.510 --> 45:40.950]  But it's not the same, because we do want this open nature of anyone, hackers, civil society, whatever, can get involved.
[45:41.130 --> 45:49.710]  And we do have trouble, I think, getting people, you know, because the obvious reason why corporations get involved, because they have business interests, they can pay people to be in working groups, et cetera, et cetera.
[45:49.870 --> 45:56.730]  And that's harder for people from a non-profit, activists, just normal person on the street background.
[45:56.970 --> 46:07.050]  But we really, I think, until we get more and more of those people involved, we're not genuinely multi-stakeholder in the way that I think a multi-stakeholderism should work.
[46:07.050 --> 46:12.650]  And we have to be this if we really want the Internet to be for everyone.
[46:13.070 --> 46:17.750]  And that, and it's, I'm sure it can be done, but we need really smart people working on it.
[46:18.290 --> 46:19.470]  So, I think that's it.
[46:20.830 --> 46:21.550]  Thanks a lot.
[46:21.550 --> 46:22.350]  Thank you.
[46:22.350 --> 46:22.550]  Thank you very much.