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. http://android.stackexchange.com/questions/49188/how-to-get-mdns-working-for-chrome-on-android This is supported on iOS, on both Chrome and Safari. We should really support it on Android, if the overhead is reasonable. Android seems to have an (unnecessarily cumbersome) API for mDNS. http://developer.android.com/training/connect-devices-wirelessly/nsd-wifi-direct.html http://developer.android.com/reference/android/net/nsd/NsdManager.html
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. http://android.stackexchange.com/questions/49188/how-to-get-mdns-working-for-chrome-on-android 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. https://developer.android.com/training/connect-devices-wirelessly/nsd#discover 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.
Aug 21 2014,
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.
Jul 31 2015,
Is this a partial dup of issue 13573?
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.
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.
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 :(
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 (https://code.google.com/p/android/issues/detail?id=19550). If anyone needs financial assistance to help work on this, I know of some sources we might be able to tap.
Apr 5 2016,
here is a workaround-app: https://play.google.com/store/apps/details?id=com.ersteheimat.peafinder
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.
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.
May 9 2017,
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.
Jul 6 2017,
Please add this compatibly it is a shame, deploy things on IoT that works on every browser but not on android :(
Jul 12 2017,
I wish I could Star the last Comment 13. I fully agree! It's a shame. :( :(
Jul 12 2017,
Shame chrome for Android!
Oct 30 2017,
As IoT developer this functionality will be very useful, please consider develop it on a next update, thanks.
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.
Dec 3 2017,
It is a shame !!
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.
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.
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.
Dec 19 2017,
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.
Mar 23 2018,
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.
Apr 24 2018,
+ 1 We have it working on windows, apple and linux, why not on android?
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!
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?
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...
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?
+1 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!
(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. https://developer.android.com/training/connect-devices-wirelessly/nsd#discover 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.
The security story is, the device is on the local subnet. Verify that that is what the user expects, and then proceed. For HTTP: You're making an unsecured connection to a local device. >Continue< For HTTPS: 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 Internet. (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.
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.
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) ).
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?
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 :-)
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?
There was, but the Android team closed it without action or comment. https://issuetracker.google.com/issues/36932514
Issue 928642 has been merged into this issue.
Sign in to add a comment