Thoughts on concept

[scottjenson]

Very cool that you are flipping the Physical Web concept to make me the beacon, and not a scanner for other beacons in the environment. This inevitably raises the issue of privacy and control. Their are a couple of solutions that come to mind:

1) Broadcast a beacon that only your office understands

If you were to broadcast a web address on your sever that gives some domain info (which company I'm at) but nothing more. There could be leakage issues but the goal is to provide some type of protection so only your company could use the ID, allowing me to always keep the beacon on and not worry that anyone else could use it. There is likely a lot to talk about (and my simple web address is likely not enough) but the goal is reasonable: Project a protected ID that only is of value in a specific location

2) Turn off the beacon when I leave work

Much like the plastic shrouds that you sometimes see on webcams, provide a means for a the user to turn off broadcasting. This would be a form of 'total control' the the user would have over the beacon. Making sure they can't be tracked when they leave the office. However, switches like this are VERY problematic, tending to stay off. The daily on/off switching would likely become very tiresome so I don't see as a viable solution. For those that claim this is the best solution, keep in mind that people are VERY likely to forget to turn it off so it is even worse.

3) Turn my phone into a beacon

No phones allows this at the moment as it would be a huge battery drain. However, it has a huge advantage that it could be easily automated. When w/in a certain geo fence (or when near a certain wifi hotspot, THEN start broadcasting. This isn't available on any platform but it's useful to discuss as it seems to provide the best, most secure solution.

[triblondon]

Thanks for the thoughts. 3 is the smartest solution but as you said it can't work today and depends on all smartphone OSes implementing a standard.

I was thinking the best solution that works today would simply be to use a private URL shortening service, so the beacon url becomes something like https://id/12345678. You could even resolve 'id' as a CNAME of bit.ly.

[scottjenson]

Interesting! Two (very separate) issues

1) your private URL w/ ID seems like the best short term solution, I agree. As long as it doesn't resolve into JSON w/ your name, you should be good. It could even be an '&id=' parameter so it's totally opaque. As you can tell, I get LOTS of privacy questions so I'm a bit concerned about it. Fortunately, I think we have a good solution here for your idea here.

2) This CNAME trick is an interesting one. I'm not well versed in DNS hackery. How would this work? It's not clear to me how you'd map 'id' (or the equivalent) to bit.ly. Seems like a very clever way to fit more in our preciously small URL space. Inquiring minds want to know.

[triblondon]

I don't think the CNAME idea is workable actually, because you only have to know that id is an alias of bit.ly and you can then get the full URL from bit.ly's public service. But you could do a 2-step redirect with bit.ly doing the complex mapping:

1. You emit https://id/12345 from your beacon
2. It's detected by a sensor that is on your company network
3. On your company's network, https://id/12345 returns a redirect to https://yourcompany.bit.ly/12345
4. Sensor requests the bit.ly redirect.

The benefit here is that your internal app is limited to just doing a single mapping, and doesn't need to worry about storing hundreds/thousands of URL mappings, providing admin UI etc. It's reasonably secure provided that your company's bit.ly domain is obscure and you're using HTTPS to connect to it.

My remaining concern would be anonymous tracking. ie if I'm emitting a signal that doesn't change, and is unique to me, then although a third party might not know who I am, they can tell that the same person who came before has returned. "Free" wifi networks in stores often do this to build demographic profiles of shoppers based on the stores that the same mac address frequently visits (the scary thing about the wifi situation is that you don't have to even join the wifi network!)

[scottjenson]

CNAME Hack Yeah, that is one reason we are using NDEF compression in our packet format so you can create an 'expansion code' with a single byte (e.g. 0x01 = 'https://www.' which saves some space. We've discussed having a few codes for shorteners but that feels like a fools game as new ones come a go. We've assumed that most serious users of this will just buy their own short domain or use and existing shortener.

Tracking That is a big chunk of my life and something you must consider whenever anyone is broadcasting anything. I often get the sensationalist 'but you'll be able to tracked ANYWHERE' which seems very very unlikely as you'd need a citywide network of scanners that would all cooperare. That would be insanely expensive. Your scenario is much more reasonable, a company like starbucks just monitors when you walk into their store. This is pretty much exactly why iOS 8 started to rotate your phone's wifi mac address (which conveniently encourages you to use iBeacons ;-)

This is why we've been shying away from putting something on a person (at least for now) This is hope however, we could emit a rotating URL (the thing does have a microprocessor in it ;-) so I could change the ID every minute (or 30 if you wish) you would then need to hash the number into something unique so you still get an ID but something that still can't be tracked. That shouldn't be very hard to code up and also shouldn't really affect battery life too much.

Hell, if you wanted to be really simple, you could even just rotate between 6 different IDs, it wouldn't be industrial grade but would confuse the hell out of most trackers.

My point is that using a URL is a very open approach that encourages a range of options. Broadcasting an untrackable URL is something we can add on top of this system.

Scott