New-ish Chrome API proposal: chrome.mdns for packaged apps

[mark a. foltz]

[Re-post from @chromium.org]

Red is in the process of refactoring the already-launched chrome.mdns extension API for use by packaged apps.

https://code.google.com/p/chromium/issues/detail?id=426500

I wrote up a Chrome API proposal to make sure there was visibility around this change and to ask if there were any open questions:

https://docs.google.com/a/chromium.org/document/d/1IpAr5tuYg1UhdxjQZQs0Rz7m_FtUQThtQ1ohpmogDzA/edit?usp=sharing

I am unable to edit the tracking spreadsheet for some reason - can someone give me edit permission?

https://docs.google.com/a/chromium.org/spreadsheet/ccc?key=0AjdhTmpdv-vvdENKZUI0cGloUGZrY2NJcWVRX3RvV1E#gid=0

[Benjamin Kalman]

re-posting from chromium.org account:

lgtm. I don't understand mdns very well and all my context comes from the doc, but it looks great.

Mark, it looks like the document is only editable for google.com addresses. It would be good to move this to chromium.org to fix that. Sriram?

On Tue, Jan 6, 2015 at 11:14 AM, Benjamin Kalman <kal...@google.com> wrote:

lgtm. I don't understand mdns very well and all my context comes from the doc, but it looks great.

Mark, it looks like the document is only editable for google.com addresses. It would be good to move this to chromium.org to fix that. Sriram?

[Benjamin Kalman]

It says "anyone with the link can view", could you change that to "comment"? My main question will be whether there's a strong reason this can't be exposed to Extensions as well as Apps.

[mark a. foltz]

Fixed that, sorry for the confusion.  I am fine with opening it up to extensions if we feel the benefit outweighs the potential security/privacy concerns. 

Also some guidance on what level of user notification should we provide for extensions/apps using this capability would be welcome.

[mark a. foltz]

Follow up from threads in the document:

(1) Suggested adding a user visible message at install time for apps that use chrome.mdns that it will "Discover devices on your local network".   https://code.google.com/p/chromium/issues/detail?id=451526

(2) Suggested adding limits on how many service types/service instances may be returned by the API per client.  https://code.google.com/p/chromium/issues/detail?id=451527

We discussed having a global whitelist of service types for all extensions.  My concern is that I have no way of knowing whether it is appropriate to add a new type to this list, and I don't want to review patches from third party extension developers adding random things to this list so they can use the API.

We also discussed refactoring the API to declare service types in the manifest for extensions.  This was attempted, but based on implementation concerns we implemented the current API which uses event filters.  Moving back to manifest declared types would be significant work and my team doesn't have the bandwidth.

I propose we maintain the status quo for extensions - a global whitelist of service types and the API remains private to first party extensions. For apps the API is public and we have no whitelists.

If there are additional concerns please voice them, otherwise we will move forward with the issues filed and Red's patch in progress.

m.

[Benjamin Kalman]

I'm in favour of opening it up to extensions without the private whitelist regardless, but I'm open to a veto :-)

[Mustafa Emre Acer]

Opening the API for apps is LGTM. 

I don't have an objection to opening this API to extensions in principle, but I don't know how to feel about extensions having continuous access to the device list on the network. I'm not sure the proposed permission message sufficiently communicates this capability (I think it's fine for apps though).

I would be more comfortable if the API was exposed to extensions through a chooser, as alluded in the design doc. The extension asks for device list and the user decides which devices the extension can see and that sort of thing.

I guess what I'm saying is: In a way this API is similar to usb / hid / bluetooth in that it can list local devices, and it would be good to have a similar permission model for that kind of capability for extensions.

[Benjamin Kalman]

Ok, LGTM.

[mark a. foltz]

Thanks for the input.  The chooser model doesn't really fit our user interaction paradigm for Cast and I am assuming it is also not appropriate for Red's situation.   If there is developer demand for extension use then we can revisit this.

I am also thinking we can make a small change to keep the API the same, but require that service types be declared in the manifest for both apps and extensions.  Only declared types could be listened for via the API.   This assumes it's not too onerous to declare and retrieve new manifest keys.

m.

[Thomas Purnell-Fisher]

Where can I register my "developer demand" for extension use cases for chrome.mdns?

Cheers,

Thomas

[Ritchie Argue]

Is chrome.mdns a silent fail for extensions at the moment? I made a small app that will successfully discover services with chrome.mdns, however I can't seem to accomplish the same thing in an extension.

Per https://developer.chrome.com/extensions/permission_warnings, I should at least get an install-time warning if I have "mdns" in the extension permission list. However I don't see anything at .crx install time, nor does chrome.mdns exist in any scope/context (popup.js, eventPage.js) I've tried so far. Curiously, I do get an error if I try to load an unpackaged extension with the "mdns" permission.

How do we get this pushed the rest of the way through to extensions, or where I might look for implementation help?

Or better yet, when will Chrome include a built-in dns-sd browser so I don't have to write my own? :)

Thanks for considering!

[Ritchie Argue]

I forgot to note that I'm using Chrome Version 47.0.2526.80 m (64-bit) to test this if it makes any difference, and the API docs say the feature is available as of version 31.

[Antony Sargent]

Re: no install time warning, this might be a bug in our permissions checking warning logic - the API is available to any packaged app, but has a whitelist of allowed extensions:

https://code.google.com/p/chromium/codesearch#chromium/src/chrome/common/extensions/api/_permission_features.json&l=717

(Sorry, I don't know anything about plans to expose this to extensions. Note that our standard advice for a workaround for these situations is that you can always have both an app and an extension and use cross app/extension messaging)

[mark a. foltz]

chrome.mdns is a private API for extensions at the present time and it only works for a whitelist of service types.  It should be available and unencumbered to chrome apps (as you have found you can write a client yourself using the socket APIs).

You shouldn't be able to load an extension with the mdns manifest permission, that seems like a bug.

There aren't any plans at present to expose full mDNS functionality to extensions that I'm aware of, in the meantime, Antony's suggestion is the way to go.

You may also want to monitor the Network Service Discovery API.  However there is no active work on it at present.

https://groups.google.com/a/chromium.org/d/topic/blink-dev/HT0KZKuTLxM/discussion

m.

[Ritchie Argue]

Thanks for the update Mark.

I saw the whitelist in Antony's reply, though it seems to whitelist for build types (Dev/Beta/Canary) rather than service types (though I can't see into the crbug.com links)? If _http._tcp.local was a whitelisted service type that'd be fine - I'm not looking to define/use a custom service via an extensive custom client right now, just discover http servers which out-of-the-box Chromium/Chrome seems well suited to interact with once they're discovered. I'll experiment more to see how the whitelisting mechanism works.

I originally found chrome.mdns via a discussion asking for general Safari-like Bonjour http server discovery mechanism in Chrome (https://code.google.com/p/chromium/issues/detail?id=13573). I thought that an extension might be a somewhat clean interim way to solve this, but seems unlikely for the moment. In my limited testing Chrome Apps don't integrate as well into the browser experience, but it might be acceptable as a first effort. Our current suggestion that people discover services via Safari and then cut-paste the address into Chrome is a bit rough.

I didn't know about the Network Service Discovery API, will look into it though development does seem to be stalled out on chicken+egg security concerns like you mentioned.

Regards,

Ritchie

[Stephen Eisenhauer]

Any movement on opening this API to extensions? With packaged apps being kicked out on Windows/Linux/macOS, it seems all the more important to consider.

[Vincent Scheib]

My opinion (relevant being that I've worked to bring Bluetooth, assist USB to web APIs) is that MDNS is something we should consider bringing to the web after we make progress with Bluetooth and USB. In a recent conversation I agreed with jschuh@'s (security team) opinion: we should prefer to add 'more powerful website capabilities' via web APIs, and keep extension APIs focused on modifying the user agent (not granting sites more power).

Stephen, sharing use cases is always helpful as API decisions are discussed, if possible enumerate what you'd do with MDNS.

[Stephen Eisenhauer]

I don't necessarily feel like there's a need to expose mDNS to sites/pages, and it wasn't my intention to write an extension that would bridge data from chrome.mdns to a page.

My use case involved trying to implement a Browser Action that would list nearby FlyWeb services (a type of HTTP-based mDNS service being standardized by Mozilla, see: https://flyweb.github.io) and launch those discovered services in a new tab when clicked. Firefox Nightly has this functionality built into the browser, and it would be straightforward to bring to Chrome if chrome.mdns were made available to Extensions too.

In light of this restriction, I just wrote it as a Packaged App instead, but it would make much more sense as a Browser Action extension (particularly as Chrome Packaged Apps are not long for this world). Here's the source: https://github.com/BHSPitMonkey/flyweb-browser-chrome