WEBVTT 00:00.000 --> 00:12.000 Now, I'm introducing you as Sunil Maya, who is going to talk about local network access in 00:12.000 --> 00:15.000 Firefox. 00:15.000 --> 00:20.000 Hello, everyone. 00:20.000 --> 00:25.000 Let's discuss cleaning up some local mess. 00:25.000 --> 00:30.000 I'm Sunil Maya, I'm a senior software engineer at Firefox network in team and based out of 00:30.000 --> 00:31.000 new budget money. 00:31.000 --> 00:35.000 So, Silver said to me that this talk is going to be recorded and I can only make appropriate 00:35.000 --> 00:36.000 jokes. 00:36.000 --> 00:38.000 So, I hope that jokes are fine. 00:38.000 --> 00:39.000 Okay. 00:39.000 --> 00:42.000 So, what's this mess all about? 00:42.000 --> 00:45.000 Now, before that, can I get some proof of hands please? 00:45.000 --> 00:48.000 How many of you here have Android phones? 00:49.000 --> 00:50.000 Awesome. 00:50.000 --> 00:51.000 Okay. 00:51.000 --> 00:52.000 Awesome. 00:52.000 --> 00:54.000 And how many of you? 00:54.000 --> 00:55.000 Okay. 00:55.000 --> 00:58.000 Now, before I begin this question, again my well-visual service there. 00:58.000 --> 01:01.000 Ask me that I cannot name some of the companies here. 01:01.000 --> 01:03.000 So, I have spoofed them. 01:03.000 --> 01:05.000 So, I spoof some of the names here. 01:05.000 --> 01:08.000 So, that I don't want to get up into some trouble. 01:08.000 --> 01:11.000 I have a lot of insurance in Germany, but I don't want to bankrupt the insurance company. 01:11.000 --> 01:17.000 So, how many of you here have apps from a company called Feta? 01:17.000 --> 01:21.000 On your Android phones. 01:21.000 --> 01:24.000 Don't be shy, raise them. 01:24.000 --> 01:25.000 All right. 01:25.000 --> 01:26.000 And okay. 01:26.000 --> 01:29.000 So, I have got some bad news for you. 01:29.000 --> 01:36.000 In June, 2025 last year, researchers disclosed that the index metric and Feta pixel 01:36.000 --> 01:41.000 were using local hosts to coerclifrate you across the web. 01:41.000 --> 01:43.000 If you were an Android user. 01:43.000 --> 01:46.000 And the scale was quite huge. 01:46.000 --> 01:50.000 There are close to 5.8 million websites that use Feta pixel. 01:50.000 --> 01:54.000 And about 3 million websites use the index metric. 01:54.000 --> 01:56.000 And this is not a joke. 01:56.000 --> 01:59.000 So, clearly, how were they able to do this? 01:59.000 --> 02:06.000 So, it involved these apps like these names, something similar, 02:06.000 --> 02:10.000 opening some local ports on your Android phones. 02:10.000 --> 02:12.000 And listening to requests from the public web. 02:12.000 --> 02:18.000 So, when a user browse the web, use the millions of websites, 02:18.000 --> 02:22.000 already have these analytics scripts embedded in them, 02:22.000 --> 02:25.000 they directly talk to these apps via local hosts ports. 02:25.000 --> 02:27.000 And what did they share? 02:27.000 --> 02:31.000 Allegedly, they shared your cookies, some cookie information, 02:31.000 --> 02:35.000 metadata, and also some commands over these ports. 02:35.000 --> 02:41.000 And these apps combine this data along with unique IDs. 02:41.000 --> 02:45.000 And push them to the servers owned by these companies. 02:45.000 --> 02:49.000 Now, I got some good news for you. 02:49.000 --> 02:54.000 Feta used WebRTC for communicating with the local ports. 02:54.000 --> 02:59.000 So, how many of you use Android, how many of you use Firefox on your Android phone? 02:59.000 --> 03:01.000 Awesome. 03:01.000 --> 03:06.000 So, the good news is you were not affected by Feta apps. 03:06.000 --> 03:08.000 Now, I have got even better news. 03:08.000 --> 03:12.000 If you had ETP strict mode on in your Firefox, 03:12.000 --> 03:16.000 you could have blocked majority of the scripts from your index as well. 03:16.000 --> 03:17.000 Okay. 03:17.000 --> 03:20.000 So, just before the disclosure came out, 03:20.000 --> 03:23.000 these companies stopped listening to this ports. 03:23.000 --> 03:24.000 How convenient. 03:24.000 --> 03:30.000 So, now that the scale was so rampant. 03:30.000 --> 03:33.000 So, we decided we had to add bit immediately. 03:34.000 --> 03:37.000 Although we were not exposed as widely as some of the browsers, 03:37.000 --> 03:41.000 but there could be still a chance that there are some new actors who 03:41.000 --> 03:45.000 start listening to opening these ports and listening from these scripts. 03:45.000 --> 03:49.000 So, to fix that, we immediately stopped sending data, 03:49.000 --> 03:51.000 sending any data to these ports. 03:51.000 --> 03:54.000 So, that was our immediate fix, 03:54.000 --> 03:57.000 but this was just a band-aid to a bullet wood. 03:57.000 --> 03:59.000 So, we needed a deeper surgery, 03:59.000 --> 04:02.000 and the cleaner deep cleaning was necessary in this area. 04:02.000 --> 04:05.000 Now, before I explain what we did, 04:05.000 --> 04:06.000 as a part of that, 04:06.000 --> 04:09.000 I would also like to expose you to some of the problems, 04:09.000 --> 04:13.000 which are faced by our local network devices. 04:13.000 --> 04:15.000 So, over the past few decades, 04:15.000 --> 04:19.000 our local routers or devices in our local networks 04:19.000 --> 04:21.000 are subject to various kinds of attack. 04:21.000 --> 04:24.000 One such attack is SOHO farming. 04:24.000 --> 04:26.000 Where typically, your web, your right web web, 04:26.000 --> 04:30.000 can directly access your router and interact with it. 04:30.000 --> 04:34.000 Let us see typically how such an attack would work. 04:34.000 --> 04:36.000 That would involve a user browsing the web 04:36.000 --> 04:39.000 and clicking on two malicious link. 04:39.000 --> 04:42.000 And that would trigger some configurations to your routers, 04:42.000 --> 04:45.000 which could qualify its DNS entries. 04:45.000 --> 04:50.000 And when the user now logs into a legitimate website, 04:50.000 --> 04:54.000 the IP address would be served from these malicious entries, 04:54.000 --> 04:57.000 which would be controlled by the attacker. 04:58.000 --> 05:01.000 Now, in order to fix such issues, 05:01.000 --> 05:04.000 which respond over decades and the recent local messaging, 05:04.000 --> 05:06.000 we decided to implement, 05:06.000 --> 05:09.000 have a long-term strategy or a long-term solution for this, 05:09.000 --> 05:13.000 which was implementing the local network access standard. 05:13.000 --> 05:15.000 So, what is local network access standard? 05:15.000 --> 05:20.000 Google proposed local network standard in February 2025, 05:20.000 --> 05:25.000 and it superseded the previously trialed private network access standard 05:25.000 --> 05:29.000 with the trialed for four years. 05:29.000 --> 05:32.000 Now that we decided to follow this approach, 05:32.000 --> 05:37.000 let me try to highlight to the key features of the local network access standard. 05:37.000 --> 05:40.000 First, the local access standard proposes 05:40.000 --> 05:45.000 categorization of your IP address into three distinctive IP address pieces. 05:45.000 --> 05:47.000 Mainly, your Rupa address piece, 05:47.000 --> 05:52.000 which belongs to all the IP addresses on your local device, 05:52.000 --> 05:55.000 that's a local host, then a local address piece, 05:55.000 --> 06:00.000 which is where your IP addresses belong to your local network, 06:00.000 --> 06:04.000 and then the public address piece for the rest of the remaining. 06:04.000 --> 06:08.000 So, the first key highlight of this standard or this feature is that 06:08.000 --> 06:15.000 any request that moves to a more private domain or address piece is block, 06:15.000 --> 06:20.000 and that would require user's permission before the request could actually proceed. 06:20.000 --> 06:24.000 The second key highlight is that any secure request coming to 06:24.000 --> 06:27.000 more private domain or automatically block. 06:27.000 --> 06:31.000 Additionally, it's not just that the resources coming from the network are subject 06:31.000 --> 06:33.000 to local network access checks, 06:33.000 --> 06:38.000 but also resources loaded from cash are subject to such checks. 06:41.000 --> 06:46.000 Now that we highlighted what are the key features or the main highlights of this standard, 06:46.000 --> 06:49.000 let's look into how we realized this feature in Firefox. 06:49.000 --> 06:52.000 So next time, whenever a browser, whenever you go website, 06:52.000 --> 06:55.000 actually tries to access a local resource, 06:55.000 --> 06:57.000 we'll be showing them this product. 06:57.000 --> 07:01.000 So here, the key highlight is that we would, 07:01.000 --> 07:03.000 if the user decides to allow our block them, 07:03.000 --> 07:05.000 just like our other permissions, 07:05.000 --> 07:07.000 we remember this for an R, 07:07.000 --> 07:10.000 and then if the user wants to know more about this permissions, 07:10.000 --> 07:12.000 they can click a link to a smooth page, 07:12.000 --> 07:15.000 which has a detailed explanation on what kind of, 07:15.000 --> 07:18.000 what does this access really mean? 07:18.000 --> 07:20.000 Additionally, for more curious users, 07:20.000 --> 07:22.000 they can open our web console, 07:22.000 --> 07:25.000 where we actually dump all the details about this access. 07:25.000 --> 07:27.000 Namely, who is originating that request, 07:27.000 --> 07:29.000 where it is supposed to go, 07:29.000 --> 07:32.000 what's the IP address using and also the script, 07:32.000 --> 07:33.000 which actually makes this access. 07:33.000 --> 07:35.000 So making any such access, 07:35.000 --> 07:39.000 more public and no longer covert. 07:41.000 --> 07:44.000 Now, we also have a separate commission for local networks. 07:44.000 --> 07:47.000 So now, if a request is going to a device in a local network, 07:47.000 --> 07:49.000 we show up a different prompt, 07:49.000 --> 07:54.000 and rest of the features are similar to the local host access. 07:54.000 --> 07:58.000 Now, now that we discussed the permissions, 07:58.000 --> 08:01.000 we also have, if the user wants to modify these permissions at runtime, 08:01.000 --> 08:04.000 they can do so by visiting a permission setting speech, 08:04.000 --> 08:09.000 where they have separate menus for local device and local network options. 08:09.000 --> 08:13.000 For the, here, what the user can actually do is, 08:13.000 --> 08:16.000 they can modify these permissions at runtime, 08:16.000 --> 08:19.000 and if they don't want any more prompts, 08:19.000 --> 08:21.000 they just want to block any local accesses, 08:21.000 --> 08:24.000 then they can directly click the checkbox below there, 08:24.000 --> 08:27.000 so that we don't prompt them, but directly block them. 08:29.000 --> 08:31.000 Firefox is all about customization 08:31.000 --> 08:33.000 and giving more part to a user. 08:33.000 --> 08:36.000 So if the user wants to find a control or most security, 08:36.000 --> 08:39.000 enable, they can do so by changing some of this practice, 08:39.000 --> 08:42.000 or so with their own risk. 08:42.000 --> 08:46.000 Now, money, we've got a lot of feedback that some IP addresses, 08:46.000 --> 08:50.000 the users want to be treated as public, 08:50.000 --> 08:52.000 that means no checks for them. 08:52.000 --> 08:56.000 So for that, we have configurations for overriding such IP addresses. 08:56.000 --> 09:02.000 Now, if the user wants restrictions on a protocol level, 09:02.000 --> 09:06.000 for example, if they want these LNR restrictions or websockets, 09:06.000 --> 09:10.000 or for top level allegations, they can do so by flipping this speech. 09:11.000 --> 09:16.000 Further, if the user wants to allow this certain domains, 09:16.000 --> 09:21.000 they can also do that by using this configuration option. 09:23.000 --> 09:25.000 Finally, for our enterprise users, 09:25.000 --> 09:27.000 we've also launched an enterprise policy, 09:27.000 --> 09:32.000 where they can deploy these configurations at scale. 09:33.000 --> 09:36.000 So Chrome started rolling out this feature in 142, 09:36.000 --> 09:41.000 they started there, which was, I think, late November, 09:41.000 --> 09:46.000 and also they started origin trial and dev trail way back in 138. 09:46.000 --> 09:51.000 So like we highlighted the key difference between Chrome's and R restrictions here, 09:51.000 --> 09:56.000 mainly that in secure requests are actually directly blocked in Chrome, 09:56.000 --> 09:58.000 where we decided to prompt the user. 09:58.000 --> 10:01.000 The idea was to initially understand what kind of breakage this will cause 10:01.000 --> 10:03.000 and slowly also make it more stricter. 10:03.000 --> 10:04.000 That's blocked. 10:05.000 --> 10:07.000 And then the mixed content relaxation. 10:07.000 --> 10:10.000 So Chrome relaxes some of the mixed content checks 10:10.000 --> 10:14.000 if the fetch request is annotated with a target actually address case parameters. 10:14.000 --> 10:15.000 We haven't done that yet. 10:15.000 --> 10:18.000 We will see how this evolves and later on out of that aspect. 10:18.000 --> 10:20.000 And then when Chrome initially rolled out, 10:20.000 --> 10:22.000 it was a single permission policy. 10:22.000 --> 10:26.000 That single permission is required enough for accessing both your device 10:26.000 --> 10:28.000 and your local network, 10:28.000 --> 10:31.000 whereas we followed a split permission policy, 10:31.000 --> 10:33.000 where you need separate permissions between local host 10:33.000 --> 10:35.000 and your local network. 10:35.000 --> 10:37.000 Chrome in the data raises, 10:37.000 --> 10:38.000 they have changed this as well, 10:38.000 --> 10:42.000 and now the standard also has been updated to use a dual permission policy. 10:45.000 --> 10:49.000 Now that we discussed the key standard details 10:49.000 --> 10:53.000 of like to in detail or plans or rolling of this feature. 10:53.000 --> 10:58.000 So we rolled out these restrictions back in August for our 90 users. 10:58.000 --> 11:04.000 So in 143 users have already this enabled in their 90 bills. 11:04.000 --> 11:09.000 Then we experimented this in a beta and other channels 11:09.000 --> 11:14.000 and gradually started rolling out LNA for 147 users. 11:14.000 --> 11:17.000 However, we restricted this only to our e-tipistic users 11:17.000 --> 11:21.000 so that we access the feedback and then move on to wider audience. 11:21.000 --> 11:22.000 So if you are on Firefox, 11:22.000 --> 11:25.000 desktop can update that to the latest build 11:25.000 --> 11:28.000 and also choose e-tipistic options. 11:28.000 --> 11:31.000 So it's not just that you get LNA with e-tipistic, 11:31.000 --> 11:36.000 but you'll also get a lot of other tracking protections from this. 11:36.000 --> 11:40.000 Next, our plan is by 148, 149, 11:40.000 --> 11:44.000 we plan to roll it out to all other users 11:44.000 --> 11:49.000 and slowly we will also start it on Android in the next coming releases. 11:49.000 --> 11:54.000 Then again for other protocols like your web, 11:54.000 --> 11:59.000 sockets and web transport will also enable them base of the 150. 11:59.000 --> 12:02.000 Hopefully we have a smooth experience until then 12:02.000 --> 12:05.000 and we don't see any major problems. 12:05.000 --> 12:08.000 So now that I highlighted the plan, 12:08.000 --> 12:10.000 I'll let you now explain what are the challenge we faced 12:10.000 --> 12:13.000 during a roll out to a beta and likely users. 12:13.000 --> 12:18.000 So the first thing was when we first shipped LNA to a likely users, 12:18.000 --> 12:21.000 we had a very minor bug reported to us. 12:21.000 --> 12:24.000 We just broke Google out. 12:24.000 --> 12:27.000 So this was however, 15 a day, 12:27.000 --> 12:29.000 and that's why I guess you'll have my job. 12:29.000 --> 12:32.000 However, this was not still the case for other clients. 12:32.000 --> 12:35.000 For example, an email client like Bickey. 12:35.000 --> 12:39.000 Here, what happened was the usually there are clients, 12:39.000 --> 12:42.000 which usually open your web browser for authentication. 12:42.000 --> 12:44.000 And once the authentication is complete, 12:44.000 --> 12:46.000 those requested are redirected to the clients. 12:46.000 --> 12:49.000 And we detect this as a local network access, 12:49.000 --> 12:52.000 Sudhu's other browsers, and we prompt the user. 12:52.000 --> 12:56.000 So when we prompt the user, we cancel the connection to the local client, 12:56.000 --> 12:59.000 and that the client detected as an anomaly 12:59.000 --> 13:03.000 and failed the transaction. 13:03.000 --> 13:05.000 And hence, there are few clients out there, 13:05.000 --> 13:09.000 although this was not the case for other top-level navigation cases. 13:09.000 --> 13:13.000 For example, Google CLI Earth worked quite well with LNA problems, 13:13.000 --> 13:16.000 but there are a few more clients which need to still adapt. 13:16.000 --> 13:19.000 So what we did was similar to Chrome, 13:19.000 --> 13:22.000 we have not enabled any top-level navigation restrictions for LNA, 13:22.000 --> 13:27.000 but soon as the other clients adapt, we have one fixed eye. 13:27.000 --> 13:30.000 Next, other role of challenge which you face 13:30.000 --> 13:33.000 was these prompts started appearing in web sites, 13:33.000 --> 13:34.000 we usually expect them. 13:34.000 --> 13:37.000 For example, if you see these prompts on site like Flex, 13:37.000 --> 13:39.000 that's quite intuitive. 13:39.000 --> 13:42.000 You know that you're actually making an access to a local resource, 13:42.000 --> 13:43.000 and that's why you have this prompt, 13:43.000 --> 13:47.000 but imagine a site like Citibank prompts you. 13:47.000 --> 13:51.000 Apparently, Citibank actually scans through your local network 13:51.000 --> 13:53.000 or your devices in your local host 13:53.000 --> 13:55.000 to see if certain posts are open. 13:55.000 --> 13:58.000 Apparently, they have some kind of fraud detection software 13:58.000 --> 14:01.000 to see if certain posts are open in your local posts, 14:01.000 --> 14:03.000 and they've been doing this for years. 14:03.000 --> 14:08.000 So when a prompt is shown, this spooks some of our users. 14:08.000 --> 14:12.000 And then we also see cases where we throw these prompt unnecessary. 14:12.000 --> 14:15.000 For example, consider the case of captive portals. 14:15.000 --> 14:18.000 When the user tries to log into captive portal, 14:18.000 --> 14:21.000 this is again a genuine local access. 14:21.000 --> 14:25.000 We already alert our users that there's been captive portal login, 14:25.000 --> 14:29.000 so it was unnecessary to prompt them again for a local network access. 14:29.000 --> 14:34.000 Similarly, there are also a lot of websites like Reddit and Discord, 14:34.000 --> 14:36.000 which actually periodically ping your network, 14:36.000 --> 14:39.000 just to check if the connectivity is fine. 14:39.000 --> 14:41.000 Although they always try to fetch your public resources, 14:41.000 --> 14:45.000 but there are some network anomalies or your ISP fluctuation, 14:45.000 --> 14:48.000 which can lead to this request diverted to a local resource. 14:48.000 --> 14:51.000 Even in such cases, we saw that these prompts were raised 14:51.000 --> 14:53.000 and cost confusion. 14:53.000 --> 14:56.000 Now, we are mitigating for captive portal case. 14:56.000 --> 14:58.000 We decided not to prompt them. 14:58.000 --> 15:01.000 However, for cases like which way we saw prompts on Reddit 15:01.000 --> 15:05.000 and Discord, we are still investigating it to find out 15:05.000 --> 15:09.000 how we can detect these anomalies and run time. 15:09.000 --> 15:13.000 Finally, we have few edge cases in corporate network. 15:13.000 --> 15:16.000 So a bug was raised by my employer from Tuneo. 15:16.000 --> 15:20.000 Here, in this case, they have a service, 15:20.000 --> 15:22.000 which is hosted locally in their cloud, 15:22.000 --> 15:25.000 and this service is also accessible outside from the web. 15:25.000 --> 15:29.000 So whenever the user moved to the corporate network, 15:29.000 --> 15:33.000 and they have workflows where the request moves a lot from the public to private cloud, 15:33.000 --> 15:36.000 they experienced a lot of prompts. 15:36.000 --> 15:39.000 So much prompt that it prompted them to prompt us a bug. 15:39.000 --> 15:42.000 So that gave us a motivation to give them more control 15:42.000 --> 15:44.000 for the users and enterprise, 15:44.000 --> 15:48.000 where we introduced target domain-based filtering or allow listing. 15:48.000 --> 15:51.000 So these are some of the challenges, 15:51.000 --> 15:53.000 which we face during the rollout. 15:53.000 --> 15:56.000 And they still continue to improve further before we roll this out, 15:56.000 --> 15:58.000 and as we roll out, 15:58.000 --> 16:01.000 one area where we are actually looking out here 16:01.000 --> 16:04.000 is to reduce the prompt frequency. 16:04.000 --> 16:06.000 Here, for example, imagine this, 16:06.000 --> 16:09.000 you are on a black side watching your movies 16:09.000 --> 16:12.000 and getting prompted every one R or disrupted. 16:12.000 --> 16:14.000 I think that's quite disturbing, 16:14.000 --> 16:18.000 and it kills the user experience for our users, 16:18.000 --> 16:21.000 and we want to basically avoid that. 16:21.000 --> 16:22.000 And not to do that, 16:22.000 --> 16:24.000 we actually are planning to increase the permission 16:24.000 --> 16:28.000 prompts from 1R to 24Rs. 16:29.000 --> 16:32.000 Then other things we are working on is to actively reduce 16:32.000 --> 16:34.000 this false positive, which we see. 16:34.000 --> 16:37.000 However, this is not a majority of our concern, 16:37.000 --> 16:38.000 which are coming out, 16:38.000 --> 16:39.000 but there are still a minority, 16:39.000 --> 16:41.000 which would like to address, 16:41.000 --> 16:43.000 so that users are not confused. 16:43.000 --> 16:45.000 Finally, 16:45.000 --> 16:48.000 we also are improving on better messaging. 16:48.000 --> 16:51.000 We are working with the user experience team, 16:51.000 --> 16:56.000 we have deployed these prompts across various users 16:56.000 --> 16:58.000 to check how they feel about this prompt, 16:58.000 --> 17:03.000 and if there is any way we could do to improve this. 17:03.000 --> 17:05.000 Finally, 17:05.000 --> 17:09.000 there is still a strong need to improve the existing security. 17:09.000 --> 17:11.000 This is like a prompt, 17:11.000 --> 17:13.000 which depends on an untrained eye 17:13.000 --> 17:15.000 to make the right decision for you. 17:15.000 --> 17:17.000 Although this is a significant step 17:17.000 --> 17:23.000 in combating the local mess or your local network attacks, 17:23.000 --> 17:25.000 however, I think it's the perfect security. 17:26.000 --> 17:29.000 We still need to strive where we can improve the security 17:29.000 --> 17:31.000 while deploying this. 17:31.000 --> 17:33.000 Finally, 17:33.000 --> 17:35.000 the call for action, 17:35.000 --> 17:37.000 I think I still have some time. 17:37.000 --> 17:38.000 So, 17:38.000 --> 17:41.000 I request you if you are one of the services 17:41.000 --> 17:44.000 which will depends on the communication between your public web 17:44.000 --> 17:46.000 and local host, 17:46.000 --> 17:49.000 do test our implementation and five books. 17:49.000 --> 17:54.000 If you are more concerned about the spec, 17:54.000 --> 17:56.000 feel free to join the discussion there 17:56.000 --> 17:59.000 and help us find some solutions. 17:59.000 --> 18:00.000 Finally, 18:00.000 --> 18:03.000 the most impactful one. 18:03.000 --> 18:07.000 I guess that's it. 18:07.000 --> 18:10.000 I hope 18:10.000 --> 18:14.000 this is implementing local network access stand-up 18:14.000 --> 18:17.000 is one of the important necessary steps 18:17.000 --> 18:20.000 in moving towards a more healthier 18:20.000 --> 18:21.000 internet web, 18:21.000 --> 18:23.000 at least for our private devices. 18:23.000 --> 18:25.000 And if you are more questions, 18:25.000 --> 18:26.000 what to reach out to us, 18:26.000 --> 18:28.000 you can find us here. 18:28.000 --> 18:29.000 And yeah, 18:29.000 --> 18:30.000 thank you. 18:30.000 --> 18:37.000 Thank you so much. 18:37.000 --> 18:40.000 Are there any questions? 18:41.000 --> 18:53.000 You mentioned the example of city bank doing some 18:53.000 --> 18:55.000 fingerprinting on your local network. 18:55.000 --> 18:58.000 Have you found that this change has 18:58.000 --> 19:04.000 caused any sites to stop doing local network accesses 19:04.000 --> 19:07.000 for fingerprinting cases? 19:08.000 --> 19:09.000 The question was, 19:09.000 --> 19:11.000 after deploying this feature, 19:11.000 --> 19:13.000 did any site stop doing this? 19:13.000 --> 19:15.000 At least city bank has not, 19:15.000 --> 19:17.000 because I think first is like we have not disabled 19:17.000 --> 19:20.000 web sockets for city bank as a web sockets connections 19:20.000 --> 19:22.000 to check this. 19:22.000 --> 19:25.000 So we haven't found a city bank stop doing this. 19:25.000 --> 19:26.000 And the thing is, 19:26.000 --> 19:29.000 some of the websites have updated 19:29.000 --> 19:32.000 the documentation explaining why they prompt. 19:32.000 --> 19:34.000 So they are more explicit about this. 19:34.000 --> 19:37.000 And what we have seen extensively is the ad network 19:37.000 --> 19:39.000 trying to fingerprint you. 19:39.000 --> 19:41.000 They haven't stopped doing that. 19:41.000 --> 19:42.000 So, yeah. 19:46.000 --> 19:47.000 Oh, who is? 19:47.000 --> 19:50.000 Are you aware of any, 19:50.000 --> 19:57.000 are you aware of any of the browsers starting to implement this? 19:57.000 --> 19:59.000 Yes, Chrome has done that. 19:59.000 --> 20:01.000 Chrome has shipped this in 1942. 20:01.000 --> 20:04.000 Can we follow the password? 20:04.000 --> 20:05.000 Hi. 20:05.000 --> 20:06.000 Hi. 20:06.000 --> 20:07.000 Thanks for the interesting talk. 20:07.000 --> 20:08.000 I was wondering, 20:08.000 --> 20:10.000 for applications or services breaking 20:10.000 --> 20:13.000 because of this permission model, 20:13.000 --> 20:17.000 if you consider feeding forged data to the 20:17.000 --> 20:20.000 you know, the service in question. 20:20.000 --> 20:23.000 Can you give an example of that? 20:23.000 --> 20:24.000 Well, for example, 20:24.000 --> 20:26.000 for the city group fingerprinting, 20:26.000 --> 20:28.000 maybe you could you know, 20:28.000 --> 20:31.000 it's some plausible looking data? 20:31.000 --> 20:33.000 I think that's an interesting approach, 20:33.000 --> 20:35.000 but the thing here is that some of them 20:35.000 --> 20:37.000 are doing it for legitimate reasons. 20:37.000 --> 20:39.000 So that has to be dealt on a case on cases. 20:39.000 --> 20:41.000 I mean, there are, 20:41.000 --> 20:43.000 I would say there are thousands of websites 20:43.000 --> 20:44.000 which are actually doing this. 20:44.000 --> 20:45.000 For example, 20:45.000 --> 20:46.000 we found a lot of government websites, 20:46.000 --> 20:48.000 actually trying to connect to a particular app 20:48.000 --> 20:49.000 on a particular port. 20:49.000 --> 20:51.000 We don't know that's a legitimate access 20:51.000 --> 20:55.000 or a local misch, kind of a thing. 20:55.000 --> 20:56.000 So it's hard for a street when 20:56.000 --> 20:59.000 maintain a list on what to serve for each particular website, 20:59.000 --> 21:00.000 because if we serve something else, 21:00.000 --> 21:02.000 that might even break their workflows. 21:02.000 --> 21:03.000 So, in a case on, 21:03.000 --> 21:04.000 so hence, 21:04.000 --> 21:06.000 I don't think we have considered the approach of feeding 21:06.000 --> 21:09.000 some forged data to such websites. 21:09.000 --> 21:12.000 However, what could be feasible is 21:12.000 --> 21:16.000 if you have enough evidence of a certain website 21:16.000 --> 21:19.000 deliberately doing this is to basically 21:19.000 --> 21:21.000 denilize them. 21:21.000 --> 21:23.000 So, not allow the request to talk. 21:23.000 --> 21:25.000 Thank you, guys, for the great thought. 21:25.000 --> 21:27.000 I was wondering, 21:27.000 --> 21:30.000 have you been able to find out 21:30.000 --> 21:32.000 if this was only a problem 21:32.000 --> 21:36.000 by Fedor on robot phones? 21:36.000 --> 21:37.000 Or, 21:37.000 --> 21:41.000 it's also a problem with Fedor on banana phones? 21:41.000 --> 21:43.000 No, this was only a problem reported 21:43.000 --> 21:46.000 on Fedor on the Android phones. 21:47.000 --> 21:52.000 I had, 21:52.000 --> 21:54.000 thank for raising awareness, 21:54.000 --> 21:55.000 very cooperating, 21:55.000 --> 21:56.000 I'm wondering, 21:56.000 --> 21:58.000 if, in the interest of, 21:58.000 --> 22:00.000 like, reducing unnecessary prompts, 22:00.000 --> 22:03.000 do you have any kind of way to, 22:03.000 --> 22:04.000 I don't know, 22:04.000 --> 22:06.000 like, roll out a web-combat, 22:06.000 --> 22:07.000 like, 22:07.000 --> 22:08.000 configuration to, 22:08.000 --> 22:10.000 prevent these problems from happening, 22:10.000 --> 22:11.000 and just like, 22:11.000 --> 22:13.000 either block them or allow them to, 22:13.000 --> 22:14.000 and it's limited on, 22:14.000 --> 22:15.000 like, a port number, 22:15.000 --> 22:16.000 and so on. 22:16.000 --> 22:17.000 Just blank it, allow, 22:17.000 --> 22:18.000 or deny. 22:18.000 --> 22:19.000 So, the question is, 22:19.000 --> 22:21.000 do we have any web platform 22:21.000 --> 22:23.000 from compatible way to allow, 22:23.000 --> 22:25.000 or deny certain sites? 22:25.000 --> 22:26.000 Unfortunately, 22:26.000 --> 22:27.000 we, 22:27.000 --> 22:28.000 as far as I know, 22:28.000 --> 22:29.000 at least for the LNF feature, 22:29.000 --> 22:30.000 we don't have, 22:30.000 --> 22:31.000 because the way we could allow, 22:31.000 --> 22:33.000 deny certain features is, 22:33.000 --> 22:34.000 one is remote permissions. 22:34.000 --> 22:36.000 We could configure remote permissions across, 22:36.000 --> 22:37.000 Firefox, 22:37.000 --> 22:38.000 for certain websites, 22:38.000 --> 22:39.000 and I don't think that's, 22:39.000 --> 22:40.000 in a web-combat way, 22:40.000 --> 22:43.000 then is the user-config and enterprise policies. 22:43.000 --> 22:45.000 So, these are very specific to our implementation. 22:45.000 --> 22:46.000 Although, 22:46.000 --> 22:48.000 our enterprise policy uses, 22:48.000 --> 22:50.000 suffix-wide card-based matching, 22:50.000 --> 22:52.000 which is somewhat similar to Chrome, 22:52.000 --> 22:55.000 but it's like separate policy and separate configuration. 22:55.000 --> 22:56.000 So, we don't have a similar, 22:56.000 --> 22:58.000 a single web-combat way to do this. 22:58.000 --> 23:01.000 Do you plan to do the show or not? 23:01.000 --> 23:03.000 I'm not aware of any proposal, 23:03.000 --> 23:06.000 of trying to do this. 23:06.000 --> 23:07.000 But, 23:07.000 --> 23:08.000 if you have, 23:08.000 --> 23:09.000 please place them at the, 23:09.000 --> 23:10.000 we could think of it. 23:10.000 --> 23:11.000 Thanks. 23:11.000 --> 23:13.000 And the other question. 23:21.000 --> 23:22.000 Hello, thank you for the thought. 23:22.000 --> 23:24.000 And I was wondering, 23:24.000 --> 23:26.000 since you mentioned that there were some websites 23:26.000 --> 23:27.000 that surprising, 23:27.000 --> 23:29.000 you didn't expect were doing 23:29.000 --> 23:31.000 this kind of local requests. 23:31.000 --> 23:34.000 I was wondering if there is, 23:34.000 --> 23:35.000 gather by you, 23:35.000 --> 23:36.000 or maybe by someone else, 23:36.000 --> 23:38.000 like any statistics on how many websites 23:38.000 --> 23:40.000 are performing, 23:40.000 --> 23:42.000 either allegedly or not, 23:42.000 --> 23:44.000 or trying to access the local network. 23:44.000 --> 23:45.000 Yes, I think. 23:45.000 --> 23:48.000 The numbers are in thousands of websites. 23:48.000 --> 23:49.000 We're doing it, 23:49.000 --> 23:50.000 and we saw, 23:50.000 --> 23:51.000 there are, 23:51.000 --> 23:54.000 this is a big web is really funny, right? 23:54.000 --> 23:55.000 So, like, 23:55.000 --> 23:57.000 we have some cases where you see 23:57.000 --> 24:00.000 it's one of the big media websites trying to do that. 24:00.000 --> 24:01.000 But, eventually, 24:01.000 --> 24:03.000 it's some ad blocker actually trying to 24:03.000 --> 24:05.000 change your DNS entry and 24:05.000 --> 24:07.000 redirecting that request to localhost. 24:07.000 --> 24:09.000 That we did it as a local network access, 24:09.000 --> 24:12.000 which whereas it was the ad blocker doing the right thing. 24:12.000 --> 24:14.000 So, we have thousands of websites, 24:14.000 --> 24:16.000 but we haven't categorized them 24:16.000 --> 24:18.000 into which is actually malicious, 24:18.000 --> 24:19.000 and which is not. 24:19.000 --> 24:21.000 So, for, at least for now, 24:21.000 --> 24:23.000 we haven't done that book. 24:23.000 --> 24:25.000 One last question. 24:27.000 --> 24:29.000 Yeah, just a very quick question. 24:29.000 --> 24:31.000 Do you also do IPv6, 24:31.000 --> 24:33.000 because you're an issue of IPv4? 24:33.000 --> 24:34.000 No, this is for all. 24:34.000 --> 24:36.000 IPv4 and IPv6. 24:36.000 --> 24:39.000 Okay, thank you. 24:39.000 --> 24:41.000 We are running out of time, so. 24:41.000 --> 24:42.000 Thank you so much. 24:42.000 --> 24:43.000 Yeah. 24:43.000 --> 24:44.000 Thank you. 24:44.000 --> 24:46.000 Thank you.