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