WEBVTT 00:00.000 --> 00:10.840 Okay, we have a band again with us and this time I think we will hear a little bit about 00:10.840 --> 00:15.420 the authentication that auto config is especially ongoing work on we have been hearing 00:15.420 --> 00:21.060 a couple of times today that this is still an issue from any client service and says 00:21.060 --> 00:30.780 is ongoing work actually to make more interoperability here and we are happy to hear. 00:30.780 --> 00:39.780 So this is an update on the efforts to for the authentication and auto config in email. 00:39.780 --> 00:49.100 I gave the talk in the same place here last year, who is here in the talk last year? 00:49.100 --> 00:52.780 So not even half, okay. 00:52.780 --> 00:59.180 So the idea is we have this problem, everybody has to use passwords for email, it's understood 00:59.180 --> 01:03.660 that this is the problem because they reuse the password everywhere the people because 01:03.660 --> 01:06.540 they don't can't remember and that's a problem. 01:06.540 --> 01:11.060 So how do we fix that for email? 01:11.060 --> 01:13.660 Okay, wait. 01:14.660 --> 01:20.140 Quickly about me, you've seen that maybe this morning, I have been for 25 years core 01:20.140 --> 01:26.380 contributor to Thunderbird, I wrote the authentication logic in Thunderbird for IMF 01:26.380 --> 01:32.820 POP 3 and SMTP, I have also been involved with four different implementations of OAuth 01:32.820 --> 01:39.580 for mail specifically, including one product for a German ISP which had a few million users, 01:39.580 --> 01:44.940 one for the add-on for Thunderbird in two products of mine in Perula and it was a review 01:44.940 --> 01:46.900 for the Thunderbird implementation. 01:46.900 --> 01:53.420 So I have firsthand experience with OAuth in this product and we need to support that in our 01:53.420 --> 01:54.420 product. 01:54.420 --> 01:58.980 I've also created software for other companies. 01:58.980 --> 02:00.340 So what do we need? 02:00.340 --> 02:02.060 Why do we need that? 02:02.060 --> 02:07.220 First, from the point of view of the end users, what do we need? 02:07.220 --> 02:12.580 They want to set up the email account once, they want to lock in, they want to set it up 02:12.580 --> 02:15.020 and then they want it to just work. 02:15.020 --> 02:19.700 They do the lock in once, between set up and then after that, they just wanted to work. 02:19.700 --> 02:22.940 Like they want to have the email check coming in when the new mail notification that 02:22.940 --> 02:30.380 I don't want to be randomly locked out, randomly redoing things, and obviously they want 02:30.380 --> 02:37.180 don't want somebody to hack the email account. 02:37.180 --> 02:43.180 Before I go into authentication, just a little segue into auto-config. 02:43.180 --> 02:53.780 These standard out there, currently it's an actual, how do we call this, pseudo-not-sutus 02:53.780 --> 02:59.100 standard, but something that's actually deployed, but not often, defector, thank you. 02:59.100 --> 03:00.100 That's the work I was looking at. 03:00.100 --> 03:04.380 The fact is standard, that was 15 years ago I realized that there's a big problem setting 03:04.380 --> 03:08.860 up email accounts, and I couldn't even figure out and set up my own email accounts. 03:08.860 --> 03:15.860 So I had to do something that was the, I've invented this protocol here. 03:15.860 --> 03:20.540 You just go to a well-known URL based on the domain of your email address. 03:20.540 --> 03:28.620 It gives you back this XML, which describes what the host name, the SSL, config, the authentication 03:28.620 --> 03:34.220 method, your username, and all this information to set up your email account. 03:34.220 --> 03:38.580 And ideally, with this information, you can set up the email account, the context, 03:38.580 --> 03:42.860 the calendar, saying the file, thing, and a bunch of other stuff. 03:42.860 --> 03:50.060 And importantly, for later on, the OAuth information can be included there as well. 03:50.060 --> 03:55.380 This works in Thunderboards in 15 years, very successfully, because people keep using that 03:55.380 --> 04:01.380 as, I think, like 60,000 people per day use this. 04:01.380 --> 04:10.340 And we have configurations for, if you have an ISP that has more than 0.01 percent, no, 0.1 04:10.340 --> 04:14.980 percent market share, then probably your configuration is in there. 04:14.980 --> 04:19.300 And it can configure, I don't know, that sets 80-90 percent of mail accounts that can configure 04:19.300 --> 04:23.100 to a phone figure already automatically. 04:23.100 --> 04:29.740 There is a draft, an internet draft out there, which is adopted by the relevant ITF working 04:29.740 --> 04:35.940 group, and it's on route to become an RFC real soon, now hopefully. 04:35.940 --> 04:40.500 So then it becomes official RC. 04:40.500 --> 04:47.580 This also unbuilding website here, ISPDB.net, where we're going to publish the configurations 04:47.580 --> 04:53.500 of the major ISPs, and documentation, if you are implementing a mail client, how you can 04:53.500 --> 04:58.420 implement this and query that and get the configuration for the main ISPs, and it's going 04:58.420 --> 05:04.860 to be free to be, you can use that if you need that contact me, if you're mail client, 05:04.860 --> 05:09.820 and you want this to talk to me. 05:09.820 --> 05:15.820 There is an alternative proposal, which was just invented a few months ago by some people 05:15.820 --> 05:20.220 at the IFTF, which has the exact same purpose, it's just a little bit not invented 05:20.220 --> 05:21.220 to you thing. 05:21.220 --> 05:23.540 They do things a little bit differently. 05:23.540 --> 05:29.060 It uses DNS servers to find the server where the configuration is, and then it gets 05:29.060 --> 05:36.420 the configuration via HTTPS from a JSON, and the difference is that it assumes the current 05:36.420 --> 05:42.380 bad-back best practices, like it assumes that your username is identical to your email address, 05:42.380 --> 05:47.500 which is a very good assumption, it's a fair, good configuration to do it this way, 05:47.500 --> 05:53.980 but it does imply that the administrator specifically sets up the infrastructure for to work 05:53.980 --> 06:01.180 with this, so that also implies that it can thus many mail conflicts of existing ISPs out 06:01.180 --> 06:04.180 there, which this system cannot represent. 06:04.180 --> 06:11.500 They doubted the current code name is Park or a PACC, however you want to pronounce that. 06:11.500 --> 06:15.620 This is coming as an internet draft to be discussed as well on the relevant work of 06:15.620 --> 06:16.620 group. 06:16.620 --> 06:26.100 There's likely to be both in parallel because this fit different needs and different use cases. 06:26.100 --> 06:34.620 Let's go over to authentication, so we all agree, passwords need to get rid of that. 06:34.620 --> 06:39.780 They are based solution as use OAuth, and because it's a very widely deployed, however, 06:39.780 --> 06:46.780 it OAuth works well if you have your mail servers provider, you have your OAuth server, 06:46.780 --> 06:52.220 and you have your metmail, and you make that particular web mail work with your OAuth server, 06:52.220 --> 06:58.340 and you optimize them together then OAuth first perfectly, if you have a mail client with 06:58.340 --> 07:04.060 all the thousands of ISPs there, then OAuth has problems, I'm going to get into details. 07:04.060 --> 07:09.020 The other alternative that we are considering is Paschis, if anybody has some other alternative 07:09.100 --> 07:11.940 idea comes to me. 07:11.940 --> 07:18.420 The main problem with OAuth first number, there's a number of configuration options that 07:18.420 --> 07:23.140 the mail client needs to know in order for it to work, for example, it needs to know all 07:23.140 --> 07:26.380 the URLs. 07:26.380 --> 07:34.660 The clients need to be registered, the tokens expire, the login expires, OAuth is a framework, 07:34.700 --> 07:40.820 not a protocol, even the RC says it's a framework, so it's not tightly defined, everything 07:40.820 --> 07:46.060 is up to for a configuration, which is a problem for if you make it a standard, and we need 07:46.060 --> 07:48.780 to fix that. 07:48.780 --> 07:54.220 For the configuration, there's a number of solutions, so you need, this is the reason why this 07:54.220 --> 08:00.940 doesn't work with your server, only Google, you're who in Microsoft can do use that, 08:00.940 --> 08:04.980 because it's all hard-coded, there's solutions for that, there's a well-known URL from 08:04.980 --> 08:11.740 OpenIVConnect, there's an IFC with another well-known ID, which is also pretty much just 08:11.740 --> 08:15.740 the same thing, it's a different URL, but pretty much the same content, and you can also 08:15.740 --> 08:21.860 use all the config, like I just showed earlier, so there's solutions for that. 08:21.860 --> 08:26.660 The other problem with OAuth is the client registration, and that's a very fundamental 08:26.660 --> 08:31.700 problem, and if you want to talk to an OAuth server, you must have a client ID, otherwise 08:31.700 --> 08:37.180 you're not allowed to connect, and the client ID is no more specified in the OAuth spec, 08:37.180 --> 08:43.580 how you get that, in the reality is you have to register with Google, you have to register 08:43.580 --> 08:49.220 with Microsoft, you have to register with Yahoo, in reality, with Yahoo, I have to sign 08:49.220 --> 08:53.900 a contract, and there's very nasty terms in the contract, and I'm not allowed to tell you 08:53.900 --> 08:58.340 why they're nasty because they forbid me to tell you what's in the contract. 08:58.340 --> 09:01.620 With Microsoft, they gave me the run-around for two months, I had to become a partner 09:01.620 --> 09:07.860 for them, fill our tons of forms, which didn't even work, had to contact the support, 09:07.860 --> 09:12.700 and they admitted, yeah, this is not working, sorry, and with Google, I have to make a 09:12.700 --> 09:16.500 paid audit with a third-party company, which costs a lot of money, and I have to do that 09:16.500 --> 09:17.820 every year. 09:17.820 --> 09:22.420 So that is inherently bad. 09:22.420 --> 09:26.780 Microsoft is a direct competitor with me, like they have Outlook as an application, I have 09:26.780 --> 09:31.220 a different email application, I need my users to be able to connect to Office 365, and 09:31.220 --> 09:36.000 to Outlook.com, otherwise, I'm not an email client, if they can do that, and so we are 09:36.000 --> 09:40.740 a direct competitive situation, and they make my life hard, so for me, that's clearly 09:40.740 --> 09:47.460 anti-competitive behavior, at least it feels like that to me, and is also directly against 09:47.460 --> 09:52.060 the idea of open-source, because I cannot just fork a client, and distribute that under 09:52.060 --> 09:55.900 my own name, because I'm not supposed to use a client idea of Thunderbird, right? 09:55.900 --> 09:59.940 So I need to register all these myself, which makes it really hard, I can tell you it 09:59.940 --> 10:04.540 takes me three months of work, you don't want to do that, so it basically makes it impossible 10:04.540 --> 10:06.260 to fork in practice, right? 10:06.260 --> 10:13.860 You can do it as to much work, so it's not a good idea, and the main problem is you 10:13.860 --> 10:19.100 have 100 email clients, you have 1,000 providers, and you multiply the registration, 10:19.100 --> 10:24.220 so you have 10,000 registrations, it doesn't work in practice. 10:24.220 --> 10:29.180 The other problem with OAuth is, is it inherently depends on the web browser, so as a mail 10:29.180 --> 10:35.300 client, I either have to have a web server embedded, or have a web server embedded, I have 10:35.300 --> 10:36.300 the two choices. 10:36.300 --> 10:43.460 If I want to launch the browser, I have to somehow get back to me, so I don't like that, 10:43.460 --> 10:47.460 I mean, it's doable, I don't like it, but the real problem is that everything that 10:47.460 --> 10:52.900 happens in that little box there in the web browser is complete black box for me. 10:52.900 --> 10:59.460 If user comes to me, a user comes to me and says, hey, my login doesn't work, and I have 10:59.460 --> 11:03.300 no way to debug that, because I don't know what's happening in that little browser frame 11:03.300 --> 11:08.540 there, so, and I don't have an account at the company that he has in all the problems 11:08.540 --> 11:12.260 are specific to that company or that doc, and I cannot debug that, and I cannot help 11:12.260 --> 11:17.540 this people, and they just come to me does work, and I say, yeah, not my fault, and this 11:17.540 --> 11:23.620 is the end, and I lost this customer, so I cannot support my customers, and that is not 11:23.620 --> 11:24.900 an acceptable situation. 11:24.900 --> 11:30.920 I can put in a lot of work to make Google, and maybe the standard Office 365 and you 11:30.920 --> 11:35.280 who more work, but like I said, it's cost a lot of work, but I cannot make full of them 11:35.280 --> 11:38.020 work, it's practically impossible. 11:38.020 --> 11:44.820 So there needs to be more transparent, I need to be able to have some way to debug this. 11:44.820 --> 11:48.260 Expire is a problem, like I said earlier, if my mother sets this up, she expects this 11:48.260 --> 11:52.260 to work, not just break after two months. 11:52.260 --> 11:56.500 Error handling too, I just said that, like, if something fails, I don't even know why it failed, 11:56.500 --> 12:01.300 it could be that the user just decided to app board, it could be that he couldn't log in, 12:01.300 --> 12:05.300 and I don't even know, or maybe forgot his password, and I cannot distinguish whether 12:05.300 --> 12:10.220 the user forgot the password, or he hit a problem, or his administrator just disabled 12:10.220 --> 12:14.740 that, and I cannot find out what the problem is, and if I don't know what the problem 12:14.740 --> 12:18.380 is, I cannot fix it. 12:18.380 --> 12:24.100 So that's the reason why mail clients today still use password, because of all these problems 12:24.100 --> 12:25.100 that I just mentioned. 12:25.100 --> 12:28.380 Password is a simple protocol that's very defined. 12:28.380 --> 12:33.300 I send the username, I send the password, if they both are incorrect, I can log in. 12:33.300 --> 12:38.180 That's not the case for OAuth, and this is the reason why we're in this problem, and 12:38.180 --> 12:43.620 we get to fix those underlying problems, a recognized that they're there, not everybody 12:43.620 --> 12:48.820 even recognizes that we have a problem with OAuth, and then we get in agreement how to fix 12:48.820 --> 12:52.820 them, and we are not there yet. 12:52.820 --> 12:59.180 So there is a proposal out there for that's currently, I think it's adopted by the mail 12:59.180 --> 13:05.940 management, IFTF working group, that's a proposal from fast mail, how to do this. 13:05.940 --> 13:12.580 So what they're saying is, okay, we take OAuth, and then we take the dynamic line registration 13:12.580 --> 13:17.940 to take care of the client ID thing, and then we specify the scope, how they're supposed 13:17.940 --> 13:22.140 to look like, because they're different for every mail provider, so let's name a low-down, 13:22.140 --> 13:26.180 and then they're nailing another, that I need to get a refresh token, I need to get a whole 13:26.180 --> 13:32.020 expire time, all this list of loosely defined and OAuth, this defining it more precisely. 13:32.020 --> 13:38.900 So that's an attempt to do that, if everybody adheres to all of that's in there, then the 13:38.900 --> 13:45.180 problem could be working with the caveat that if something goes wrong, I still can't fix 13:45.180 --> 13:48.940 it, because in the rep route, but otherwise it should theoretically work. 13:48.940 --> 13:55.020 The problem is the should, because a lot in this document is should, so it doesn't have 13:55.020 --> 13:59.500 to do it, and if, as a client, I still have to handle that case and then things don't 13:59.500 --> 14:00.900 work and so on. 14:00.900 --> 14:07.900 The other problem is, if we accept that this is okay, the OAuth stuff, then there is a ton 14:07.900 --> 14:11.620 of ISPs who are going to say, yes, I'm going to do all of that, but I'm not going to do 14:11.620 --> 14:15.700 like dynamic line registration, you still have to come to me in register. 14:15.700 --> 14:22.140 So that is very likely to happen, I think, a lot of the big ISPs are going to take that 14:22.140 --> 14:26.300 stands, and then we still have the problem that we have today. 14:26.300 --> 14:32.500 So I have a really bad feeling about this, but in theory, that should be working. 14:32.500 --> 14:36.460 This is an internet draft right now, this is under discussion. 14:36.460 --> 14:40.500 If you have an opinion about that, if you're free to post to the mailman mailing list on 14:40.500 --> 14:44.140 the IFT, and the IFTF. 14:44.140 --> 14:48.380 Another alternative from me, that's probably not going to fly, but it was my idea to just 14:48.380 --> 14:53.900 disable the client ID by just cartconning it to open, and if an ISP wants this to work 14:53.900 --> 14:59.060 with my outlines, they have to accept open as client ID, and if all the my outlines just 14:59.060 --> 15:05.340 send open, then the ISP has a choice, either he allows my outlines with open or he doesn't. 15:05.340 --> 15:09.900 But everybody has to agree on that, that we do it this way, but doesn't seem to be the 15:09.900 --> 15:12.700 case, I don't know, we'll see. 15:12.740 --> 15:16.700 The other alternative that we have is pass keys. 15:16.700 --> 15:22.300 So what we're doing right now is we are proposing an Sassel standard, Sassel is the 15:22.300 --> 15:26.700 lock-in mechanism for IMF S&TP and pop-free. 15:26.700 --> 15:36.820 We're proposing a Sassel wire format, how you can use pass keys with IMF and S&TP and so on. 15:36.820 --> 15:41.460 One problem with that is when the lock-in, we need some free implementations for that, 15:41.460 --> 15:43.900 and then you do help for this. 15:43.900 --> 15:47.740 How does Sassel pass key work? 15:47.740 --> 15:54.660 So he is the URL for that proposed standard, the way it works is you would be working is 15:54.660 --> 16:01.300 you go with your web browser, you go to your ISP website, in your account, in the security 16:01.300 --> 16:05.820 settings, and you say here I would like to create a pass key, in the same way that you do 16:05.820 --> 16:09.540 it on GitHub right now, where you add a pass key there, you would do the same thing on your 16:09.540 --> 16:16.500 ISP's website, you create the pass key, your browser contacts your authenticator that you 16:16.500 --> 16:22.260 have on your operating system, whatever that may be, and the authenticator creates a pass 16:22.260 --> 16:27.300 key, the returns the public key to the browser, he sends it to the website, the website 16:27.300 --> 16:30.060 register that. 16:30.060 --> 16:36.340 Then the mail application would have to access that same authenticator with the same 16:36.340 --> 16:43.060 store of pass keys, so when it does the lock-in, it says Sassel pass key, and then the server 16:43.060 --> 16:49.420 sends a challenge to the client, and the client would then mail the main client would just 16:49.420 --> 16:55.420 take that challenge, rub it in and pass it on directly as it is to the authenticator 16:55.420 --> 17:03.700 or the pass key manager if you want, and that one then would show your lock-in, you can 17:03.700 --> 17:09.260 either do a fingerprint or the face ID or your device lock, or the device unlock thing 17:09.260 --> 17:17.260 that you do, the pin, whatever you're using, and then the authenticator allows the signing 17:17.260 --> 17:21.900 with the pass key of this challenge, it signs that challenge with your pass key, once this 17:21.900 --> 17:26.500 completed, sends it back, your mail app takes it verbatim and just pass it forward to the 17:26.500 --> 17:32.500 mail server, and the mail server then verifies that against your pass key, the public key, 17:32.500 --> 17:36.780 sees whether the site's nature is correct, and if everything is good, you're locked in 17:36.780 --> 17:40.180 all is good. 17:40.180 --> 17:46.140 There's one problem, and that is there's a fairly good agreement that this is a good 17:46.140 --> 17:52.460 way to go forward, there's one problem with that, you don't want to put your fingerprint 17:52.460 --> 17:57.220 every time your mail client opens an IMF connection, because that happens all the time. 17:57.220 --> 18:00.500 So how do we do that then? 18:00.500 --> 18:06.220 There's another proposal for a sassel, remember me, which is something that you do after 18:06.220 --> 18:11.780 you lock in with your pass key, you say, remember me, the server returns you a token, and 18:11.780 --> 18:16.260 the mail client saves that token the same way what save a password, and the next time 18:16.260 --> 18:20.500 it wants to connect with IMF, it just takes that token and it says sassel, remember me 18:20.500 --> 18:24.980 with that token, the server gets that token, sees, okay, that token is valid for that 18:24.980 --> 18:26.780 user, okay, you're locked in. 18:26.780 --> 18:32.580 So that's the non-interactive lock-in path, and that can then work afterwards, either with 18:32.580 --> 18:38.380 the next connection or tomorrow or in a week or whatever, and this token can be anything, 18:38.380 --> 18:43.100 this is completely up to the server, what it uses as a token, it could be a JWT, it could 18:43.100 --> 18:48.860 be an O-auth refresh token, it could be just a random string that the server saves for that 18:48.860 --> 18:53.340 user, for that user account, it's completely up to the server how it wants to implement 18:53.340 --> 18:54.340 that. 18:54.340 --> 18:59.980 That password, that you create on the author, whatever. 18:59.980 --> 19:05.180 This one big gap for a pass key is right now, and he has a plea for you or for any of your 19:05.180 --> 19:09.300 friends who are looking for a great project, because this is a big need right now. 19:09.300 --> 19:16.340 I'm using a Linux desktop, and there is no operating system level authenticator, a pass 19:16.340 --> 19:18.780 key manager for the operating system. 19:18.780 --> 19:24.500 We have the bitboard and key pass exceed, but they're browser add-ons, they work only 19:24.500 --> 19:31.540 in a web page, because they're hooking up into the web page and hijacking the web APIs, 19:31.540 --> 19:36.380 but it's not going through the browser, so I can either use this manager or my hardware 19:36.380 --> 19:41.540 token, but not both at the same time, and it's not going through the browser, and so 19:41.540 --> 19:44.540 it would not work with this proposal. 19:44.540 --> 19:50.340 And it would work on Windows, on Macon, as on iOS, on Android, there is operating system 19:50.340 --> 19:53.900 level authenticator, some pass key managers. 19:53.900 --> 20:00.260 Unfortunately, those are tied to the vendor system, so I need, on Android, I have to have 20:00.260 --> 20:02.860 a Google account in order for pass keys to work. 20:02.860 --> 20:07.100 And for me, that's completely unacceptable, I don't do that in a cannot use pass keys. 20:07.100 --> 20:14.940 So I would like there to be some open standard, some standard API, it's just like four 20:14.940 --> 20:20.660 C functions, it's completely trivial and simple, and just to get a pass key and create a 20:20.660 --> 20:25.940 pass key, it's very simple, but somebody needs to define that API and build some implementations 20:25.940 --> 20:29.820 for it to save these pass keys, generate them, sign them. 20:29.820 --> 20:36.220 So could somebody please build this standard API for Linux, it makes some implementations 20:36.220 --> 20:40.940 so that can select which authenticator I want to use, and then build an actual authenticator 20:40.940 --> 20:46.220 so that Firefox has an API to call, because on all the platforms, for example, it's 20:46.220 --> 20:50.900 a part from Linux because it's not there, and on Android, I also need some choice. 20:50.900 --> 20:55.700 So somebody, please, we need to help with this to implement some pass key managers, only 20:55.700 --> 20:59.940 Linux, and the other platforms. 20:59.940 --> 21:03.260 That's it, so any question. 21:03.340 --> 21:10.260 So I realize this is very controversial topic, so maybe if you'll build a lot of temperature 21:10.260 --> 21:24.260 raised, if you've made two questions, sorry for that, please raise them to us some questions. 21:24.340 --> 21:31.260 Yeah, I mean, you went up, first of all, now a very technical thing about the 21:31.260 --> 21:34.260 successful pass keys, they're supposed to be down to the main, right? 21:34.260 --> 21:35.260 Correct. 21:35.260 --> 21:41.660 So sorry, he's saying the successful pass keys are supposed to be bound to a specific domain, 21:41.660 --> 21:46.460 the combination of user account or domain, so I can not reuse them on some other domain 21:46.460 --> 21:48.260 which is a security feature, it's intentional like that. 21:48.260 --> 21:54.260 So I'm wondering how this is going to work for me, for my web, my mail server, I have a web 21:54.260 --> 21:59.260 mail interface, so does it mean that the exact same host name, or if that's for you during 21:59.260 --> 22:02.260 I-net, for I-net? 22:02.260 --> 22:05.260 You've eat the question? 22:05.260 --> 22:12.260 He's asking whether the web mail host name has to identical to be with the I-map host name 22:12.260 --> 22:15.260 in order for the pass key to match. 22:15.260 --> 22:19.260 I believe that's up for the definition of the client, so it doesn't have to be like that. 22:19.260 --> 22:23.260 We can specify that, we could, for example, say it needs to be the same domain, top level 22:23.260 --> 22:25.260 domain, but not the same host name. 22:25.260 --> 22:27.260 This is still up to- 22:27.260 --> 22:37.260 So if the browser, if you're in your browser, you're on your web mail, you're registering, 22:37.260 --> 22:41.260 for example, you're on mail.mox.de. 22:41.260 --> 22:55.260 I'm not 100% certain whether it does the domain, top level domain, only all the host. 22:55.260 --> 23:05.260 I have to look that up, but then the mail client would be the one that's selecting the name, so it can define that. 23:05.260 --> 23:07.260 Does it good question? 23:07.260 --> 23:10.260 Yes, Michael. 23:10.260 --> 23:11.260 Yes, Michael. 23:11.260 --> 23:15.260 You shouldn't have to repeat the question. 23:15.260 --> 23:18.260 No, it's in front of the microphone for the video. 23:18.260 --> 23:23.260 Not as surprised to see here that you don't like, for the whole observation, we don't like the fact that somebody 23:23.260 --> 23:26.260 has stopped happening to the HTTP web browser world. 23:26.260 --> 23:28.260 But you seem to be okay with that. 23:28.260 --> 23:30.260 Someone has stopped happening in the pass key world. 23:30.260 --> 23:34.260 How do you reconcile those two positions? 23:34.260 --> 23:38.260 You're saying that I have a problem with the HTTP. 23:38.260 --> 23:40.260 I'm just repeating the question. 23:40.260 --> 23:43.260 I'm just repeating the question, okay, for the video. 23:43.260 --> 23:49.260 So you're saying that for all of, I have a problem with HTTP web browser, but I don't have that problem with pass keys. 23:49.260 --> 23:56.260 The difference being that in this sets of pass key thing, there is neither any HTTP, nor any web browser involved. 23:56.260 --> 23:58.260 For the record, I have no problem with HTPS. 23:58.260 --> 24:02.260 I have a problem with the HTML, whatever is happening in the browser stuff. 24:03.260 --> 24:08.260 But in the system, there is no HTTP involved at all from the main client. 24:08.260 --> 24:12.260 You have to register that pass key sometime in your browser. 24:12.260 --> 24:20.260 But that's one time thing, and then the main client is not involved in that. 24:20.260 --> 24:23.260 The main client never opens any browser window. 24:23.260 --> 24:27.260 But there's still the dependency at some point you've made on this registration. 24:27.260 --> 24:29.260 Yeah, we're not going to make it. 24:29.260 --> 24:33.260 We're not going to make the web go away, and we don't want to. 24:33.260 --> 24:36.260 But it's just in the log-in sequence. 24:36.260 --> 24:40.260 We don't want to depend on that and the log-in sequence. 24:40.260 --> 24:42.260 Does it make sense? 24:42.260 --> 24:45.260 I don't understand, but you're saying it's still a dependency at some point. 24:45.260 --> 24:51.260 It's not necessarily on my device. 24:51.260 --> 24:53.260 I can do that on my desktop. 24:53.260 --> 24:54.260 I can register on the desktop. 24:54.260 --> 24:58.260 The key can be synced to my mobile, and I can use the same key. 24:59.260 --> 25:00.260 Pass keys can be synced. 25:00.260 --> 25:02.260 If you don't chew, that can be synced here. 25:04.260 --> 25:06.260 Any other questions? 25:09.260 --> 25:10.260 Aren't? 25:10.260 --> 25:12.260 Yes, you had a question. 25:12.260 --> 25:14.260 Not really, I have a comment. 25:14.260 --> 25:15.260 Okay. 25:23.260 --> 25:25.260 There's still a dependency. 25:25.260 --> 25:27.260 The point is to make that dependency. 25:27.260 --> 25:35.260 The dependency on variety of the web that's less hard to debug. 25:35.260 --> 25:41.260 To get rid of the kind of dependency that's hard to debug. 25:41.260 --> 25:44.260 Not because it's hard to debug. 25:44.260 --> 25:52.260 It's more about the fact that the user is probably already a registered. 25:52.260 --> 25:54.260 Like, the user is that one to use that. 25:54.260 --> 25:56.260 That probably already have a pass key. 25:56.260 --> 25:58.260 Or that might already have a pass key in this in the set. 25:58.260 --> 26:00.260 So the main client can just use that. 26:00.260 --> 26:04.260 And it doesn't have to be specifically registered for the mail application. 26:06.260 --> 26:08.260 Or, yeah. 26:10.260 --> 26:12.260 Are there questions? 26:12.260 --> 26:14.260 All right. 26:14.260 --> 26:16.260 All right. 26:16.260 --> 26:17.260 Sweet. 26:17.260 --> 26:18.260 Thank you again. 26:22.260 --> 26:24.260 Thank you.