New issue
Advanced search Search tips
Starred by 192 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: ----

Sign in to add a comment

Issue 405925: Support navigating to .local (mDNS) URLs in Android

Reported by, Aug 21 2014 Project Member

Issue description

This feature is very useful for trying out under-development sites on real hardware.

This has been asked for. Unfortunately, the discussion happened on StackOverflow, instead of here.

This is supported on iOS, on both Chrome and Safari. It would be nice if Android worked like the other platforms, for consistency. Android has an mDNS client API. It's not a straightforward "resolve" -- we'd have to start scanning, then wait for an (unspecified) amount of time to collect responses and filter for the address we're looking for.

Before jumping into implementation, please consider that mDNS service discovery (.local) seems fundamentally incompatible with https, which is required for powerful Web features. Official CAs should not issue .local certificates, so you'd need a custom CA whose root cert is trusted by the Android device. This piece of infrastructure seems much more difficult to set up than a DNS server.

While mDNS is really convenient, we shouldn't invest significant efforts here until the security story is figured out.

Comment 1 by, Aug 21 2014

Labels: Cr-Internals-Network-DNS

Comment 2 by, Jun 11 2015

In our product, the user must find the correct IP in order to establish communication between the Android phone and our local embedded system - not very user friendly.

Comment 3 by, Jul 31 2015

Is this a partial dup of issue 13573?

Comment 4 by, Aug 5 2015

This seems like a much less ambitious subset of  issue 13575 , which seems to ask for a UI that lists all servers that have mDNS announcements.

As a developer, all I want is to be able to get something like "pwnage.local" resolved. Asides from slightly slowing down development, not having .local can lead to embarrassing demo failures.

For example, in some hackathons, the demo area has a different WiFi configuration from the general hacking area. If I use an Android, I have to either find time to connect my laptop and phone/tablet to the demo network and change any hardcoded IPs, or I have to use a hack, such as setting up WiFi tethering on my phone and connecting my laptop to its AP. The saddest part is, I figure most developers learn this the hard way.

I'd be glad to help with the implementation, if this is a desirable feature, and can be done entirely on the Chromium side.

Comment 5 by, Oct 12 2015

I hit this the other day and was fairly disappointed it wasn't supported - use case was accessing a local Raspberry Pi running a web server.

Regarding jpsugar's comments, I think this bug blocks #13573. This bug is regarding  supporting navigation to .local URLs, where the user knows the URL. Bug #13573 is regarding a UI to list the URL's, meaning the user doesn't need to know the URL at all.

NOTE: This is supported on Chrome for Desktop.

Comment 6 by, Nov 24 2015

I would like to surf to raspberry.local and don't want to look up its ip in the dhcp server.

iPhone and Desktop is working. Just Android doesn't :(

Comment 7 by, Dec 10 2015

Aside from the entire world of web developers who would appreciate this feature, this would be very helpful in the developing world where we bring servers from the cloud to the ground (ground servers) because Internet usage is prohibitively expensive. Android is the go to device these days to lower the barrier to access ground servers. Literally millions of people in the developing world would benefit from this feature. It's a damn shame it isn't built into Android in the first place ( If anyone needs financial assistance to help work on this, I know of some sources we might be able to tap.

Comment 9 by, Sep 29 2016

Ran in to a brick wall here. Please support. I move my raspberrypi.local around on different networks and do not have the ability to set static ips or reserve DHCP addresses.

Comment 10 by, Jan 19 2017

As of IPv4 slowly fading away and IPv6 becoming a standard even for local networks, this is kind of feature which must be implemented ASAP.

Comment 11 by, May 9 2017


Comment 12 by, Jun 24 2017

To present a more common use: in networked homes (and with IoT gaining more publicity) the web interface of services and devices that support mDNS could be easy to access without knowing their IP address, just using their name.

Comment 13 by, Jul 6 2017

Please add this compatibly it is a shame, deploy things on IoT that works on every browser but not on android :(

Comment 14 by, Jul 12 2017

I wish I could Star the last Comment 13.

I fully agree! 
It's a shame.

:( :(

Comment 15 by, Jul 12 2017

Shame chrome for Android!
1.1 MB View Download

Comment 16 by, Oct 30 2017

As IoT developer this functionality will be very useful, please consider develop it on a next update, thanks.
95.2 KB View Download

Comment 17 by, Nov 25 2017

I got to this 'the long way round' in that I have a flimsy grasp of networking and assumed that there must be a configuration error in my LAN. I now find myself with Chrome on Windows and OSX being super convenient and Android and ChromeOS being the place where I need to memorise/keep and eye out for changes on my LAN. Shaaaaame.

Comment 18 by, Dec 3 2017

It is a shame !!

Comment 19 Deleted

Comment 20 by, Dec 10 2017

Just setting up my .local network and figured out that it is not my setup which causes the trouble. Please provide the resolving of the .local addresses asap.

Comment 21 by, Dec 14 2017

This would help people using IoT devices. The only alternative, for an IoT device acting as a Wifi station, is for people to address the device by its IP address. 

Even for IPv4 you lose a lot of people when asking them to do that, even those who know how to find the IP address - it's an unproductive frustration and barrier. For IPv6 it becomes an even bigger burden. There is also the problem of IP addresses changing, whereas a .local name can remain the same.

This seems to channel devices into having to upload their data to the 'cloud', and people then having to access that data via another website. However this makes the design brittle and dependent on a continuous internet connection. Or to channel developers into having to make apps to access the device.

Even when the IoT device acts as an access point, and can use DNS to capture the browser request, it is a smoother experience if it can redirect to a .local name rather than an IP address so that that same name and bookmark continues to work when the device is in station mode.

There are usable mDNS responder implementations now for many low end and low cost IoT devices. These are widely used by 'makers' and may well be used for education. Please support mDNS in Chrome on Android, it will make the experience of the IoT community easier and help make Chrome a compelling recommendation from this community.

Comment 22 by, Dec 18 2017

As much as this issue is filed under the Chromium project, the solution really ought to be implemented in Android so that all networking applications get the solution, not just Chrome.

Comment 23 by, Dec 19 2017

ChromeOS ;)

Comment 24 by, Dec 19 2017

This irritates me so much that I loaded armbian onto my android box and removed android.  Try to stop me now, Google.

Comment 25 by, Mar 23 2018

Owner: ----
Status: Available (was: Unconfirmed)

Comment 26 by, Apr 12 2018

Shame on you Android!
And shame on the Android developers which never fix a bug when we tell them...
I'm getting tired of reporting bugs to Google, they are anyway not gonna fix it.

Comment 27 by, Apr 24 2018

+ 1 
We have it working on windows, apple and linux, why not on android?

Comment 28 by, May 14 2018

using this feature helps consumers for accessing much simpler their IoT devices: just typing ALWAYS THE SAME URL.local at the browser instead of finding out the IP address & typing it into the Android browser. Just causing troubles to find out the IP adress in case you are a simple user (no Admin rights) of a WiFi system.

Simplification for the user is a huge PLUS for the users!

So please implement it as soon as possible!

Comment 29 by, Jun 17 2018

It's embarrassing that this is still an issue. Do I actually have to get an overpriced phone to have this simple quality of life improvement that Actual Chrome (and everything else) already has?

Comment 30 by, Sep 11

As others have said I must add my frustration to the stack: it is a shame that this is still an issue. 
The only reason I can think to justify this is that Google has a business-oriented reason for this not working. 
I hope our complaints make something happen...

Comment 31 Deleted

Comment 32 by, Sep 15

For onboarding a new IOT device this is crucial (if you want the end-user experience to be pleasant).

Two ways at the moment.
1. Bring up your IOT device as an AP and put a sticker on it with SSID/password
   Then let the user set up SSID's and password to reach AP's switch back 
   from AP to Station mode.

2. Make the IOT device join a predefined SSID with predefined password. 
   Force the user to tether their Android using that SSID. 
   The IOT device will get a DHCP IP.

   Now here is where the torture begins for the end-user. Looking up that  IP
   and writing it in a browser...

   Being able to simply do a "mything.local" would be sooo much easier.

A big benefit of using option #2 is that you dont have to host the frontend webclient on the IOT device itself. I usually redirect to cloud resources and can have an updated version ready.

If someone could offer an even simpler way I would remove my request here to implement this feature.

Otherwise a BIG +1 from me!

Comment 33 by, Sep 19

I'd love to see this feature implemented.

I'm guessing the addition of this feature would be much appreciated by more people everyday, both end-users and developers alike.

With the rise in popularity of the IoT and the availability of cheap boards like the ESP8266, this feature makes absolute sense to be implemented in order to stop the Android platform lagging behind when it comes to ease and connectivity in this marketplace.

I believe the addition of this will be inevitable. I'd just like to see it sooner rather than later because I like the easy life!

Comment 34 by, Sep 30

i need this feature available on Chrome for Android as well

i made a Arduino project that uses mDNS and it works fine on Chrome for Windows, but does not work in Chrome for Android

i know it is possible, because my Arduino devices that have the mDNS service running show up in the app "Pea Finder", so it just needs to be implemented into Chrome for Android

Comment 35 by, Sep 30

Can someone give me a logical reason why Google refuses to implement
Zeroconf in Android?

It's 2018 people. Network discovery has been solved for years.

Google - why do you continue to piss off manufacturers and developers and
make network discovery on Android suck ?

Comment 36 by, Sep 30

why did they remove "do no evil" from their company charter?

Comment 37 Deleted

Comment 38 by, Oct 2

i try to buld an iot device that automatically connects to a know ssid if in range, otherwise make an AP so the user can connect to it. 
Nice thing: it works every where except android.

nicest thing: when i connect the iot device to my android AP, i can use a desktop-pc/mac/box connect it to android AP as well and get the "device-name.local" working. so the Android AP shares the local.-domain name except for itself... no browser can connect to the iot device on the android device...

Comment 39 by, Oct 7

any progress yet? this issue has been open for 4 years!

Comment 40 by, Oct 7

Labels: -Pri-2 Pri-3
Status: ExternalDependency (was: Available)
(I'm the bug reporter; I work on Chrome now)

Switching to P3, as the issue been available for a few years.

mDNS service discovery (.local) seems fundamentally incompatible with https, which is required for powerful Web features. Official CAs should not issue .local certificates, so you'd need a custom CA whose root cert is trusted by the Android device. This piece of infrastructure seems much more difficult to set up than a DNS server. I don't think we should invest significant efforts into making this use case work without figuring out the security story.

Assuming security gets figured out... Android now has an mDNS client API. It's not a straightforward "resolve" -- we'd have to start scanning, then wait for an (unspecified) amount of time to collect responses and filter for the address we're looking for.

I suspect that a high-quality implementation in Chrome would have to deal with caching the discovered addresses so we don't have to wait for a full discovery round every time we need to resolve a .local. Asides from the extra complexity, we'd have to consider how the implementation impacts battery life and memory usage.

Comment 41 by, Oct 7

Description: Show this description

Comment 42 by, Oct 7

Status: Available (was: ExternalDependency)

Comment 43 by, Oct 8

The security story is, the device is on the local subnet. Verify that that is what the user expects, and then proceed.

You're making an unsecured connection to a local device. >Continue<
You're making an encrypted connection to a local device [with an untrusted certificate]. >Continue<

Comment 44 by, Oct 8

Comment 43 is pretty much what I think should happen if a user types in a URL containing an mDNS hostname.

As far as service discovery goes I think the playing field is open. For local https services, I'd like to see Chrome implement a trust-on-first-use scheme that uses signed service discovery records (signed by way of a field in the TXT record, not RRSIGs) such that once a user has trusted a service, Chrome can identify it again regardless of the target host/port or the service name changing (due to conflict or otherwise). This would make advertising a service more involved as conflicts would have to be handled manually but it would be a nicer and safer experience for the end user.

Comment 45 by, Oct 8

The security issues are interesting -- but there aren't any good solutions. These devices, by their nature, do not have globally unique names. In the absence of ipv6, they don't have globally unique IP addresses either. This does raise some interesting issues -- what should happen when the browser moves from one local environment to another, and there may be duplicate names between the two environments?

I think that the 'ssh-like' model proposed above is about the best that can be acheived -- i.e. trust on first use (with a prompt).

Comment 46 by, Oct 10

Sadly, SSH has a cop-out, not a model. The research I've seen shows that the public key digest is completely incomprehensible, and users just click "yes".

I think that prompting may have been acceptable for SSH, because it was an improvement on the status quo (IIRc, "telnet" sent everything in plaintext). For the Web, it'd be an unacceptable downgrade from the status quo.

To be clear, I'm not stating that implementing mDNS in Android is *blocked* on figuring out the HTTPS situation. I'm just saying that it's unlikely to be *prioritized*, because it would push users away from secure contexts.

Comment 47 by, Oct 10

All this talk about connecting to devices on the Internet (such as using SSH) is completely irrelevant. We're talking about connecting to a device the user has physical control over. Distinguishing that case would be a tremendous upgrade in both security and usability over the status quo.

Comment 48 by, Oct 10

#47: Unfortunately, that's not the case. The selling point of mDNS is that it works without a central DNS system. We have no way of knowing that Chrome's user has complete control over their current network. This assumption is particularly difficult to make in the context of Android, which mostly powers mobile devices.

Not going to disagree on the usability point. Sadly, usability is at odds with security here.

Comment 49 by, Oct 10

If "we have no way of knowing that Chrome's user has complete control over their current network" is a stumbling block, then it should be impossible to navigate anywhere, since we don't know that the user's DNS is any more trustworthy than their mDNS. The user knows what network they're connecting to. As long as they understand whether a given connection is to a local device, they have sufficient information to make their own decisions.

Comment 50 by, Oct 10

What about warning the user that https connections to .local domain is dangerous, and proceed at your own risk? The main use case is connecting to IoT devices or servers on a home network. If the user wants to connect to a .local url on a public network, the warning should make one think twice.

Comment 51 by, Oct 10

Speaking to the possibility of HTTPS here, the big non-development use case
for this is IOT style devices. For IOT devices to be interacted with over
HTTPS, the domain must be publicly route-able and the certificate must be
from a real CA. For that page to show data from the IOT device, that data
either has to come from a secure domain (possibly the same as the page, but
not necessarily), or the device itself. But the device doesn't have a
public domain or a trusted certificate, so it's ruled out as a direct
source for the page, due to mixed-content issues. That means there is no
zeroconf workflow to interact with an IOT device where the page is secure
and the device's data doesn't leave the local network. As a user, wanting
my data to stay within my local network, despite being plaintext, seems
like a valid trade-off compared to encrypted data that transits the public

(And yes, I'm aware "the 'S' in IOT stands for Security") I'm glad HTTPS
isn't going to block this issue, because Android sticks out like a sore
thumb not supporting this.

I do think there are a couple interesting examples that could be considered
models for improving security of .local addresses:

Printers commonly advertise using this protocol, and interestingly, Chrome
on Android (possibly because of a share intent in the system?) is likely
using mDNS or something similar. What's interesting is none of these
security concerns are commonly discussed for connecting to printers, but we
happily send all kinds of data there. As a model to follow, the system UI
does show the IP address when choosing a printer, so somebody else involved
in Chrome on Android has thought highly enough of users' skill to think
that's a good idea. Maybe that's just the best that can be done.

Bluetooth pairing is possibly a good model to consider for this as well. I
think doing anything similar to the code exchange in the Bluetooth pairing
flow would require a new protocol beyond just mDNS, but the lack of
meaningful authentication (and thus the difficulty of encryption) does call
out that we probably need a better technology for local service discovery.

Comment 52 by, Dec 7

As far as mDNS goes for me, I control my local network and want this to "just work" on authorized WiFi networks. I'm I'm favor of adding some kind of warning to Android, but there needs to be a very simple override. I know what I'm doing, and understand that local network traffic is not encrypted via TLS. With that understanding, I'm willing to accept the minor risks, given the other security controls I have in place. 

Right now, I'm trying to access my 3D printer status via OctoPrint, running on Raspberry Pi, from my Android device. Unfortunately I'm not able to, because I don't know the IP address of the device. Rather, I only know its mDNS name. I'll have to use my Windows 10 laptop to access this instead.

Comment 53 by, Dec 7

I guess we could host an external web page with JavaScript that sends requests on the 192.168.1.x range until we find an expected response.. but that requires a small range and has other security concerns.

Comment 54 by, Dec 21


Comment 55 Deleted

Comment 56 by, Feb 2

Its really weird that Android does not support this, and neither does Chrome browser for Android.

mDNS name resolution works for Mac OS and iOS. Windows doesn't support it, but offers an alternative: llmnr. Android / Chrome has nothing; and no alternative (or did I miss it in my searching?).

The original poster wrote:

> Before jumping into implementation, please consider
> that mDNS service discovery (.local) seems fundamentally
> incompatible with https, which is required for powerful
> Web features. Official CAs should not issue .local
> certificates, so you'd need a custom CA whose root
> cert is trusted by the Android device. This piece of
> infrastructure seems much more difficult to set up
> than a DNS server.
> While mDNS is really convenient, we shouldn't invest
> significant efforts here until the security story is
> figured out.

The security story can (only) be figured out by showing the typical `Are you sure, we can't validate the authenticity of this website` warning in a browser.

Anything else is besides the point and out of scope for the simple 'please make mDNS resolving work' task. As there is no simple solution; it shouldn't block the original request.

I agree that it would be great have a better solution for the generic security problem with admin pages of local devices in a (home-) network; but thats then a discussion in a much wider scope: not only for Android/Chrome. And should not block the original request (Oh; did I say that already? ;o)   ).

Comment 57 by, Feb 2

It seems that the easy thing to do is to implement it, but chrome is the most used browser and has the responsibility to push for safer standards.

What standard do we need to use though? A whole local DNS server?

Comment 58 by, Feb 2

Yes. I better understand  ‘as such needs to push for safer standards’ as a reason to hold off on implementing this.

However, I’m still failing to understand what security issue exists that is so enourmous that the ‘are you sure?’ warning, in combination with only resolving .local addresses, is not adequate enough? Such warning is (apparently) deemed sufficient for lots of other security issues.

To me, the security situation needs be rather serious to be a reason to break / not implement a technology that everybody else does implement. A difference between the various browsers and OS-es like this is a huge pain for both device manufacturers as users; complicating manuals, user instructions, and so forth.

By the way; to limit the risk, perhaps it is an option to make it only accept addresses that are within the local subnets? That way its not possible that the user thinks to be visiting a local device local but in reality is not. That idea might/will probably break the standard a bit (see mdns reflector in the docs); but still cover 99.99% of the use cases that I’m aware of. Better than having nothing :-)

Comment 59 by, Feb 5

For maximum compatibility, Chrome delegates all *.local resolutions to the OS (via getaddrinfo()).  Wouldn't want Chrome to do mDNS while everything else in the OS resolves *.local through local DNS servers (a scenario that exists in some enterprise environments).

So Chrome doesn't resolve *.local hostnames via mDNS on Android, because Android doesn't resolve them via mDNS.  As for why Android doesn't resolve via mDNS, I don't know.  Does anybody know if there's a relevant bug filed on the Android bug tracker?

Comment 60 by, Feb 5

There was, but the Android team closed it without action or comment.

Comment 61 by, Feb 6

 Issue 928642  has been merged into this issue.

Sign in to add a comment