3 ms·

I feel like this is going to break many IoT devices (definitely my ones) and I wouldn't be surprised if it's a move to push more developers towards integrating

I feel like this is going to break many IoT devices (definitely my ones) and I wouldn't be surprised if it's a move to push more developers towards integrating with GoogleHomeSpyware™. Since there's still no mdns (resolution of .local domains) in android nor in chromium despite long standing feature requests, workaround I (a hobbyist) and likely other IoT devs chose chose was to host a small website that would brute-force check local ip ranges until the IoT device was found. At least for now I have another reason to transfer hypertext securely but I've honestly no idea for future workaround (other than a large banner saying "install firefox")

southerntofu 5y ago
> I feel like this is going to break many IoT devices (definitely my ones) On one hand i'm sorry for you. On the other hand, the less IoT there is as a whole, the better humanity will fare. IoT is a disaster for security, for the environment, and repairability... I have yet to see a single useful application of IoT which does not bring major downsides.
nybble41 5y ago
> Since there's still no mdns (resolution of .local domains) in android nor in chromium despite long standing feature requests… If you run your own DNS resolver for your local network, you can use a Discovery Proxy (RFC 8766) to allow unicast DNS resolution of multicast DNS records. I'm using mdns-discovery-proxy[0] (slightly modified to support a newer version of the zeroconf Python library) with a forward-only zone rule in bind9 so that xyz.local is mirrored in unicast DNS as xyz.home.arpa. The latter address will work for any program on the network regardless of mDNS support. [0] https://github.com/nybble41/mdns-discovery-proxy https://github.com/nybble41/mdns-discovery-proxy
jabbany 5y ago
IoT onboarding has always been less than ideal. I've personally never been of fan of the "spray (local) and pray" approach as it always felt _super_ sketchy... (IIRC, Magicjack does something like that to register your device from its public site? At least that's what I think it does since it's somehow magically grabbing a serial number during sign up despite the URL entry point not having any identifying parameters...) Let's just hope this pushes support for better options like mdns further.

southerntofu 5y ago

> I feel like this is going to break many IoT devices (definitely my ones) On one hand i'm sorry for you. On the other hand, the less IoT there is as a whole, the better humanity will fare. IoT is a disaster for security, for the environment, and repairability... I have yet to see a single useful application of IoT which does not bring major downsides.

nybble41 5y ago

> Since there's still no mdns (resolution of .local domains) in android nor in chromium despite long standing feature requests… If you run your own DNS resolver for your local network, you can use a Discovery Proxy (RFC 8766) to allow unicast DNS resolution of multicast DNS records. I'm using mdns-discovery-proxy[0] (slightly modified to support a newer version of the zeroconf Python library) with a forward-only zone rule in bind9 so that xyz.local is mirrored in unicast DNS as xyz.home.arpa. The latter address will work for any program on the network regardless of mDNS support. [0] https://github.com/nybble41/mdns-discovery-proxy https://github.com/nybble41/mdns-discovery-proxy

jabbany 5y ago

IoT onboarding has always been less than ideal. I've personally never been of fan of the "spray (local) and pray" approach as it always felt _super_ sketchy... (IIRC, Magicjack does something like that to register your device from its public site? At least that's what I think it does since it's somehow magically grabbing a serial number during sign up despite the URL entry point not having any identifying parameters...) Let's just hope this pushes support for better options like mdns further.