New issue
Advanced search Search tips

Issue 405925 link

Starred by 185 users

Issue metadata

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

Sign in to add a comment

Support navigating to .local (mDNS) URLs in Android

Project Member Reported by, Aug 21 2014

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
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.
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.
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. 
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.
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 :( 

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
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

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. 
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.
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.
ChromeOS ;)
This irritates me so much that I loaded armbian onto my android box and removed android.  Try to stop me now, Google.
Owner: ----
Status: Available (was: Unconfirmed)
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?
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!

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?
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

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!
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!
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
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 ?
why did they remove "do no evil" from their company charter?

Comment 37 Deleted

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...
any progress yet? this issue has been open for 4 years!
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.
Description: Show this description
Status: Available (was: ExternalDependency)
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 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.
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). 
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.
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.
#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.
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.
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.
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 (6 days ago)

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 (6 days ago)

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.

Sign in to add a comment