Re: [dnssd] Setting device friendly names

[Tim Chown <[e-mail]>]

Hi,

On 24 Jul 2016, at 11:14, Ted Lemon <[e-mail]<mailto:[e-mail]>> wrote:

Yes. There are two separate problems here: how to name services that are being advertised, for which presumably we do not want privacy, and how to deal with devices whose identification should be private, but with which there might still be a need to rendezvous.

The reason I was so enthusiastic about your presentation in dnssd is that it very nicely solves this second  problem.  But we still have the first problem.

Indeed :)

Well, the hosts have names, and those are coupled with service information, where the service names are well-known. For example, I see "Living Room Apple TV._airplay._tcp.local.” advertised while sat here in my lounge, for a device with name living-room-apple-tv.local, and the airplay service for screen sharing.

As an example of default names that are far from ideal in a “coffee shop” environment, an iPhone will have default name like freds-iphone.local, an iPad will have sarahs-ipad.local. A 30-minute harvest of multicast DNS in a recent event harvested me the names (first, or full) of over half of the attendees.

I note my employer very thoughtfully gave my Mac a name of the form JNTXX0012345. That’s obfuscated in a sense, but also quite likely to be a globally unique name, and one I could therefore be tracked by.  So as Christian says we definitely want privacy support when we expose names via service discovery protocols.

On name clashes, my own Mac is simply “Tims-MacBook-Pro”, which is a more friendly name, but I’ve been at meetings big enough before that such friendly names will clash, and thus my device then appears on the network as Tims-MacBook-Pro-2”.  That’s not the network renaming me, it’s my own host picking a new name. But if we flatten a multi-link homenet, we will need this capability unless we embed link names, which as we discussed at the meeting is not desirable. Ted suggested some ideas on this front.

How you change the name will depend on the device; it might be via a GUI, command line, or web interface. Seeking a new common standard for this seems, well, optimistic. But I’d expect to be able to change my device’s name whenever I chose, if I had appropriate privileges on it, and then DNS-SD protocols would propagate the change. So I’d disagree with an assertion that devices must not allow the name to be trivially changed, once set.

I think the requirements will become clearer once Ted and whoever offers to help can formulate a -00 of what I think we’re now calling the “flat homenet” model.

Tim


On Jul 24, 2016 11:02 AM, "Christian Huitema" <[e-mail]<mailto:[e-mail]>> wrote:
On Thursday, July 21, 2016 7:24 PM, Ted Lemon wrote:

> Right, the issue would be if we changed it in the database operated by
> the homenet, and didn't tell the host.
>
> On Thu, Jul 21, 2016 at 7:07 PM, Stuart Cheshire <mailto:[e-mail]<mailto:[e-mail]>> wrote:
>> On 21 Jul 2016, at 09:06, Ted Lemon <mailto:[e-mail]<mailto:[e-mail]>> wrote:
>>
>>> Hm.   That's not what I'm saying.  The point Barbara made that I agree with and restated was that the device should report the same name no matter who asks or how.
>>
>> For the most part, this is universally true today. Of all the devices I’ve seen that support both UPnP and Bonjour DNS-SD/mDNS, virtually have a single place in the web UI to set the name, which is then used for both discovery protocols.

Please let's not forget the privacy issues for mobile devices. There is an intarea draft about that, "hostname practices considered harmful." In short, volunteering a name to the network allows tracking; volunteering a user friendly name like "Ted Lemon's laptop" allows for even better tracking.

For DHCP, the "privacy" recommendation is to not volunteer a name at all to the DHCP server, or to use a one-time random name.

Now, I can understand that these one-time random names should be more user friendly than "F78AC123", maybe using something like "correct-horse-battery-staple" in the tradition of https://www.xkcd.com/936/.

-- Christian Huitema



_______________________________________________
dnssd mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dnssd