Can we use wifi as a medium to transmit URL's? Will Physical web on chrome scan for url's if broadcasted through wifi?

[kanodia]

Hello

I have been talking a lot of people about physical web. Their only concern is, people do not keep their bluetooth on. However, wifi is something that people never switch off.

Do we have wifi strategy or any plans of it in the physical web service.

In the physical web book page, towards the end there is mention of wifi

"We also support finding URLs through Wifi using mDNS and uPnP.""

Does that mean, physical web on chrome will scan for URL's if broadcasted over wifi?

[kanodia]

have we added discovery of URL's through wifi in physical web?

[scottjenson]

This has been discussed quite a bit actually. We were experimenting with mDNS which uses wifi until we found a horrible bug in Android that chewed up battery. We'd very much like to get back to this as it opens up many more used cases. However, it does raise a security issue as most likely wifi discovery will offer local IP addresses which can be filtered by the PWS. We'd have to be ok with users having access to 'raw' URL pages. We hope we can find a reasonable way around this.

[kanodia]

@scottjenson Thank You for the reply. Could you please explain this in simpler terms

"However, it does raise a security issue as most likely wifi discovery will offer local IP addresses which can be filtered by the PWS. We'd have to be ok with users having access to 'raw' URL pages."

[scottjenson]

Our implementation of the Physical Web filters all found URLs through our Physical Web Service (PWS) this allows us to remove known spam/phishing sites to protect the user. If we were to use mDNS (wifi) most URLs found would likely be local IP addresses which would be invisible to the PWS. This provides a way for some bad actor to offer a web page directly to the user.

This risk is fairly small and many people in their homes or at work likely have enough control of their network that this isn't a problem. We are exploring a way to ask the user's permission to show them URLs on Wifi networks they trust.

[oscarrdg]

"If we were to use mDNS (wifi) most URLs found would likely be local IP addresses which would be invisible to the PWS."

Maybe I just don't get it, but would'nt it be enough if PWS set valid URLs those having public IP DNS resolution? TLS certificate check will then take care of possible DNS Spoofing by some bad actor.

[scottjenson]

If the URLs we discovered through wifi were publicly viewable (could be seen by the PWS) we'd be fine. We could let those through fairly easily. But we've heard from many people that the reason they'd like to use wifi is to have pointers to local IP addresses (e.g. https://168.10.0.1) those are invisible to us and can't be filtered. Now by requiring HTTPS we are likely removing ANY local IP address as no local device would be able to support HTTPS easily (that's another issue) Most folks would want not only local IPs but also HTTP in order to make this viable.

I agree this is confusing. We are considering updating our Physical Web app to do just this so we can explore this use case a bit more.

[oscarrdg]

I agree that it must be clearly explained why it is not valid to point to local IP addresses, the same way that it is not possible to use HTTP (instead of HTTPS).

But done that, I reckon that broadcasting URLs (HTTPS + public IPs) through mDNS/wifi has a lot of nice use cases.

Thanks!

[louaybassbouss]

you can also use SSDP for this. With this Node.js Tool you can advertise one or multiple URLs in local network. Example:

$ node phyweb https://google.github.io/physical-web/ https://www.example.org/ 

In the Physical Web Android App you should see these URLs if your smartphone is in the same network as the Node.js Tool. I just tested it by running the Node.js Tool on my Mac using above command and the Physical Web App on my Nexus 7.

[scottjenson]

The main reason we had to postpone mDNS work was a pretty bad bug on Android which caused battery usage to skyrocket. As mDNS scanning on Android matures, or we can figure out a work around, we hope to be able to use it again

[kanodia]

@scottjenson :So, this appears to be a android issue, right? AS the battery usage is very high because of using mDNS. Are the people in Android team looking to improve it?

[scottjenson]

We have filed a bug, they certainly know about it.

[matthuisman]

Are there any way to do it without mDNS so the user need not be connected to the WiFi? Maybe adding the URL to the beacon frame or something?

Maybe WiFi Direct? http://developer.android.com/training/connect-devices-wirelessly/nsd-wifi-direct.html http://developer.android.com/training/connect-devices-wirelessly/wifi-direct.html

it looks like WiFi P2P (Direct) can advertise details about it's service. The Physical Web details could be stored in here. The App just keeps a list of P2P clients nearby and displays them along with Bluetooth devices.

The device itself only uses P2P to get the data broadcasted, not actually for connecting clients.

1) Physical Web App iscovers all P2P networks in range that "conform" to the standard The URL is stored in the P2P's data that is available without connection. 2) User clicks the URL and it sends off to a non-local site as normal. 3) This site communicates with the device like normal (over internet)

You could also have if the P2P network is open (no pbc or pin needed), that when the URL is clicked and is a local URL, that the app connects the user to the device and then opens the local URL.

Or maybe WiFi Aware? http://www.wi-fi.org/discover-wi-fi/wi-fi-aware

[nickcastel50]

@matthuisman I would also like to see WiFi Direct support, and I envisioned the process the same way you did. I think this would be a great way to enhance the experience of the Physical Web and allow it to reach a much wider audience. I am eagerly awaiting a response from the PW team to your comment.

[scottjenson]

We are happy to consider Wifi Direct support. It's just not clear to us that it is a standard that is really taking off (happy to discuss of course) One of the issues we've found with any local technology (mDNS, Wifi-Direct, even local IP addresses) is that it should have a vigorous discussion around security as all of these approaches expose the user to unvetted URLs.

In the case of mDNS, the user is likely in a known environment (e.g. work or home) so a single prompt to the user to proceed with caution may be enough. We're going to be experimenting with this later this summer. However, wifi direct is truly public and anywhere. It would be helpful to discuss ways to make sure the user understands they are taking a potential risk.

[nickcastel50]

@scottjenson Thanks for responding! I'm curious, what is the difference in security between routing the physical web through Bluetooth or WiFi Direct? Surely the user would have to opt in to either, and the capabilities of what is allowed through the WiFi Direct connection would be handled by the Chrome browser, would it not? Maybe I misunderstood your statement.

[scottjenson]

The issue is how publicly accessible the final URL is. Both BLE and Wifi Direct can broadcast "www.cnn.com" or "192.1.1.1" The first one, our PWS can find and vet, the second one it can't. The reason mDNS and Wifi-Direct tend to encourage this use case is that they are already on a wifi network so so local addresses are more strongly encouraged.

Scott

[ferencbrachmann]

Wi-Fi Ha-Low has also been announced and looks to be relevant: http://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-introduces-low-power-long-range-wi-fi-halow

[matthuisman]

Being able to broadcast URLS via WiFi instead of Bluetooth opens up quite a few more possibilities. Example: ESP8266! Would bring the cost down a lot.

I don't know enough about WiFi, but there may be a way to send some extra packets out while transmitting the SSID?

What about something silly like BASE64 encoded URL as the SSID? Obviously would need some common prefix to identify it. But, pretty sure SSID has quite a small max length (32 chars?).

IDEA

Could 'Physical Web' provide a registration service?

1) I go & register my site 2) It provides me a unique short ID (It also checks and caches the sites details) 3) I then simply broadcast this ID. eg. PWSefG56e4 (PWS a common prefix)

The app picks up the ID, and can get the site info direct from it's database which will be nicely cached and therefore FAST.

These would be short enough to use as a SSID name and could just hide the SSID's so they don't populate every-ones WiFi list.

This also adds the ability to change your site without needing to update the device. It's also more secure as the site needs to be registered and therefore can be checked before allowing.

[scottjenson]

Sorry for the slow reply! The Physical Web is philosophically opposed to any central registration sevice. We want this to work as the web works. Our scanner in Android as a proxy service to cache meta data and protect the user but that's a value add. Any scanner can add their own, it's not required for the system to work.

The original prototype of the Physical Web (when I was at frog design) actually used SSID's and it quickly became apparent that we were clogging up the wifi space for 'normal users' and didn't create many friends. If we could get everyone to ignore our beacons, that might help but that's a big ask.

We are looking into wifi direct (we're about to push a version of our android app that does this) and that does get around this problem. If you look at the commits, you'll see our work on this over the last month. We're about to push our app to the play store you can can experiment with it. Looking forward to your comments.

[scottjenson]

@ferencbrachmann I'd really like to know more about HaLow. It feels to me that it will likely follow in the same adoption footsteps as Wifi Direct, e.g. a few big companies trying it but nothing like the ground swell that has appeared around BLE. If HaLow takes off, we'd very much like to look at it some more.

[ferencbrachmann]

@scottjenson http://www.wi-fi.org/discover-wi-fi/wi-fi-halow Is a good start.

[scottjenson]

Yes, but that's just a PR page. Where are the specs/docs/RPi drivers? I'm worried it's locked up tight and only if you pay the expensive alliance fee can you learn about it. One of the key reasons IMO that BLE took off is that it was open and people get the docs and build things freely. You needed to be certified to ship a professional product, but you could 'kick the tires' easily. You can't seem to do that with Halow.

On Wed, Aug 17, 2016 at 10:46 AM, Ferenc Brachmann <notifications@github.com

wrote:

@scottjenson https://github.com/scottjenson http://www.wi-fi.org/discover-wi-fi/wi-fi-halow Is a good start.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/google/physical-web/issues/619#issuecomment-240490294, or mute the thread https://github.com/notifications/unsubscribe-auth/ABAbusNwttMNGL5GzEz-x811HU8atqXdks5qg0jwgaJpZM4H2A03 .

[matthuisman]

@scottjenson Looking at the WiFi Direct documentation - is it just for local services? Can I use WiFi Direct to broadcast an online URL just like Bluetooth? I'm more interested in just using WiFi as a broadcast method and not so much for local running server.

If the app can already pickup on PW-{title}-{port}, then could the app be modified to also look for PW-{Base64 encoded URL} , then decode the URL and then simply follow the same flow as Bluetooth (look up the URL meta etc etc)

[scottjenson]

The new version of the Physical Web app now supports wifi direct for any local file that you try to share on Android. I realize you'd like to just to URL. That's something we could add in the future.

[matthuisman]

That would be amazing. Then I can try to see if I can get a very cheap ESP8266 module working as a beacon.

[scottjenson]

That would be interesting. Most of our work has been done on Android as it has built in Wifi-Direct support. Interesting to see if there is an OpenSource Linux style version you can use.

Also, please keep in mind this is only for our Physical Web app which is our experimental branch of the project. This isn't in Chrome or Android.

[kanodia]

I have few questions with respect to the implementation of wifi direct?

What I am able to understand is, using wifi direct, we can transmit a physical web URL which can be read my android physical web app.

My questions: 1| How can we set up a wifi direct connection to transmit a physical web URL? 2| Once a wifi direct connection is successfully transmiting an URL, will the out put in physical web app be the same as seen through BLE. 3| Are we looking into integrating this into Google play services as part of nearby.

Reading through all the discussion above, I think the problem statement still stands:

"" How can we use wifi as a medium to transmit physical web URL and integrate it into Google play services securely? ""

[kanodia]

@scottjenson : Looking forward for your comment?

[scottjenson]

Sorry for the delay. The current Physical Web app is just experimenting with this concept. We're looking for comments/feedback from the community. At this point, the app is required to send a wifi direct URL that points to the phone. If another user of the Physical Web app has wifi direct turned on and finds that beacon, they will connect directly to the phone and not go through any web server.

The key issue we face here is security as anyone can now become a server. There is no chance for our PWS to vet the page. The more free-wheeling part of us just wants to let the web but wild and crazy and let this type of thing happen, possibly with a ranking of some type and just let this grow. There are people that are worried this opens up users to too much risk. We are just exploring this as an experiment at the moment.