Google's Search, Development and Enterprise Discussions

Google on Ulitzer

Subscribe to Google on Ulitzer: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Google on Ulitzer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Google Authors: Kevin Jackson, Mehdi Daoudi, Shelly Palmer, Progress Blog, Cloud Best Practices Network

Related Topics: Cloud Computing, Cloud Expo on Ulitzer, Mobile Enterprise Application Platforms, Google, Internet of Things Journal

Blog Post

Beacon, Oh Beacon, Wherefore Art Thou Beacon? By @ScottJenson | @ThingsExpo [#IoT]

The Physical Web aspires to be an extension of that success so we can embrace this new beacon technology

Beacon, Oh Beacon, Wherefore Art Thou Beacon?

Juliet's lament is often mistakenly thought of as ‘where are you Romeo?' when it actually means, ‘Why must you be a Montague?' It is Romeo's family and their struggle against the Capulets that keeps these two star-crossed lovers apart.

Beacons, like Romeo, also have a bit of a name - a heritage - that seems to set them apart from the mainstream. In fact, the term ‘beacon' has grown into such an odd mishmash of apprehension and potential, it creates as much confusion as it inspires. Several Capulet tech articles brand beacons as a Montague technology, a rival family that is out to get us: watch out, don't trust, be afraid.

What is so sad is that this Capulet narrative is based upon a naive understanding of what is actually happening. This XKCD comic captures it well:

Whenever there is ignorance, people tend to overreact

‘The Physical Web' Scott Jenson'2 @ThingsExpo Presentation ▸ Here
Download Slide Deck: ▸ Here

We have a rich history of this. Horror movies from the 1950s were notorious for taking some scientific or medical breakthrough and turning it into a horrible science-out-of-control scenario: someone receives a heart transplant from a murderer and so becomes a murderer themselves, some kind of radiation creates some kind of monster, or some well-intentioned invention is perverted by some greedy industrialist. It's a never-ending stream of fear-the-future. This is one of the reasons why ‘Star Trek' is so beloved; it's one of the few science fiction visions optimistic about humanity.

The out-of-control scenario for beacons is that they will track our every move. But that fear is overblown. By understanding the technology and designing it properly, we can maintain control. Fear of something doesn't guarantee inevitability; it can instead motivate and inspire.

The web is a great example of how to transcend this. It's a decentralized system that allows anyone to play. Are there bad sites out there? Of course. But the important point is that we believe in the general promise. The Snowden revelations shocked us to our core, instigating far-ranging discussions and improvements. We never considered for an instant to throw the web away. On the contrary, we double down to improve it, trusting that we are on the right path.

This is a never-ending process. We believe in the web's aspirational purpose but use the bumps in the road to motivate us. The real question is whether we can create that type of system for beacons. A system that provides value and trust yet when it falters, we'll want to fix instead of abandon.

1. Build on the web
That is why the Physical Web project is built upon the web. It is the web, just pushed into the physical world. Using the web browser as the user-facing front end is critical as it has a long, proven track record of protection. The "web sandbox" as it is often called, is a very restricted place, one that allows web sites and their code to be run safely. The web is also universally accessible across nearly any device. This is even more important in a world sprouting new screen types by the week.

2. Enforce one way beacons
Is the browser enough? No, we must go further. Beacons must advertise their information one-way. If 1,000 people pass through an airport with 1,000 beacons, those beacons should have no idea anyone walked by, unless of course the user chooses one. We must design the flow of information so rogue beacons can't take advantage of a user's passage.

3. Enforce protection through proxy
If the phone were to naively contact each beacon nearby (and its associated website), that has a slight risk of being a privacy violation, potentially leaking the user's location. By using a proxy to fetch the information on the user's behalf instead, we can gather information without exposing the user. The proxy even acts as a cache, returning the information without hitting the website every time. This protects users from rogue websites by preventing them from a) knowing exactly how many users asked and b) when they did so.

4. Make an open marketplace
But what if you don't trust the proxy? That is why this project is open source. We are encouraging multiple receiving clients and proxies to be written. By making sure there are a wide range of clients, we enable not only experimentation but also competition. If one version starts to make mistakes or violates the users trust in some way, there are alternatives. A market encourages not only competition but rewards trustworthy behavior.

5. Start in the foreground
What about a website on the phone, working in the background, discretely finding beacons and pestering the user with notifications? By default, the physical web works in the foreground, running only when the user asks. By default, the system does not intrude on the user or ask for their attention. This is a huge restriction and limits many extremely valuable types of use, but it's important that we start safe and build up from there.

6. Ask first
But should we lock out background tasks forever? There is great potential in the new web standard called service workers, which allows websites to work offline and also in the background. This would allow a website to offer very useful automatic services (like turning on your driveway lights when you approach your house). While it may be possible to collect beacon information safely, actually contacting the website should be an opt-in request by the user.

Of course I could go on and on. Security and privacy are a never-ending quest. In fact I'm sure people will point out some security concerns with the very examples in this post. Absolutely! That is to be encouraged. We can only fix a system if we work on it together, in the open. There are lots of issues I haven't had time to address here but just like the web, this should never stop. We will always be finding ways to improve it.

"The which, if you with patient ears attend,
What here shall miss, our toil shall strive to mend."

The real issue
The real issue is whether or not we can find that initial vision that protects the user yet still excites our imaginations, motivating a continual path of improvement. This post hasn't tried to sell the vision of the Physical Web. I've done that enough in my previous posts. Instead, this article is an entreaty to have a thoughtful conversation about how to build it. Can we avoid forming into extreme camps with curmudgeonly luddites at one end and naive technologists on the other? In this age of the hashtag twitter storm, hurling strawman arguments at each other accomplishes nothing and only entrenches positions.

The web is celebrating its 25th birthday this year. It's been a bumpy road, but frankly, it's looking pretty good right now and we as a community are proudly behind it, warts and all. The Physical Web aspires to be an extension of that success so we can embrace this new beacon technology in a respectful, open, and even human manner. It is also the only way we'll outgrow the myopic insistence that every new technology must be under corporate control. It can't possibly succeed if one company pushes it as a product. That it is the core learning, in my mind, of the web: the only way this will take hold and grow is if we, as a community want it.

The post Beacon, oh Beacon, wherefore art thou Beacon? appeared first on Scott Jenson. Republished with permission.

More Stories By Scott Jenson

Scott Jenson has been at the forefront of user interface design for over 25 years. He was the first member of the User Interface group at Apple in the late 80s, working on System 7, the Apple Human Interface Guidelines and the original Newton. Following that he was Director of Product Design for Symbian, then managed the mobile UX group at Google and was Creative Director at frog design. Scott is now back at Google, on a quest to bridge the physical and digital worlds.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.