 So, I am here to talk about the physical web, but this is going to be a little bit more of a change, a little bit more of a personal conversation because I want to talk a little bit about the journey about what I've discovered along this process. First, I have to ask just how many people here know about what the physical web is? Can I just see a show of hands? Because I don't think not many people of you know about what it is and so I'm happy to talk more about that. The one thing I will tell you is that the physical web is shipping right now and it's available to you right now. Beacon has been here the whole conference, has been broadcasting the agenda for this conference. If you have an Android phone and you have Bluetooth turned on and you've got data, you can see the various beacons that are in the room. And by the way, is Tim Perry here? Tim? He's not here today. He was basically broadcasting the URL as well so it wasn't just him. And you can actually see the URLs that are being in the air around you and pull it down. If you happen to have an iPhone, that's okay. You can also just have Chrome and it's not quite as easy. Android, it's built into the operating system. But for Chrome on iOS, you basically just turn on in the TodayView widget the Chrome widget. It's a few steps. It's not the easiest thing to do. It's not as easy as Android. But you can also see these URLs in Chrome as well on iOS. So I've been speaking about this for about four years now, both initially at Google. I left Google for a couple years and then I came back. And this is just a list of a few of the conferences that I've spoken at over the last four years. And it feels like a long time. Someone once said that the physical web is Scott Jensen's personal quest. And I feel like that sometimes. But I feel like I've learned so much in the process and it's been so interesting. But too often, people don't really appreciate what it takes to bring an idea to a product. They often think that you have an idea. You sit down and you work for a little while and then you just ship it. And actually, the process looks a little bit more like this. And this idea of how long it takes and how it works and what you have to do to kind of get it. And honestly, for the physical web, we're kind of somewhere in the middle. I think we've got it shipping in Chrome. We've got it on Android. We've got an iOS. Opera has got it. So it's an interesting state that it's kind of getting started, but it has a little ways to go. But more than anything else, this whole process has just taught me just how amazing the web is and what it has kind of given back to the physical web project. So the subtitle of this talk is really how I stopped worrying and loved the web. Because the web has added so much to the physical web, it makes us look better than actually I think we originally started to be. So let's take this talk in three parts. Part one, what is the physical web? I think I'll take a few minutes explaining it to you guys what it is. Part two, what did we learn? How did it kind of influence what we learned of the web in general? And part three, where can we go? What can we do with this technology? First, what is the physical web? We've all seen these smart devices that are coming out now. There's smart TVs, there's smart vending machines, there's even smart bus stops. And the problem is every single one of these devices has its own application. Even this conference has its own application at a web conference. Sorry, I can't help but just teasing the guys a little bit about that. But if we were to believe in Moore's law at all and there's going to be even more of these devices in our lives, what's going to happen in six months when we basically have a few more devices? In a stadium or an airport or a train or even a little bit longer and we have even more devices? Are we really going to be installing an app for every single device we want to talk to? They just can't possibly scale. Well, we actually have a technology at our disposal. The superpower of the web is interaction on demand with a single tap. You can be anywhere, within seconds. That kind of seems useful in this situation. So how would we do that? Because over the last 25 years the web has made amazing strides and so many neat technologies like WebVR is there, but all the magic goes in this little white DOM box. We've hardly ever really touched this area on top. You know, the URL bar. Now, really, there's only two ways you can leave a web page either by clicking on a link or by typing something at the top. We've taken the most amazing rendering engine on the planet and we've strapped a goddamn DOS prompt on top of it. Really? This is how we aspire to do. It's about time that the web became mobile like the phone that it is in. In effect, we are living in this lovely island where we can go from room to room with a click but we don't ever really escape out of that into the rest of the world and that's the whole point of the physical web. How do we have a discovery service for the web so that I can walk up to something and get it to URL without having to fiddle around with it too much? So the intention here is let's say I walk into a space where these devices have a URL. I'm in there and I want to be able to discover what is around them but I don't want to just see the URL. I want to basically fetch and get some information about them and rank them so I can get a list that says oh, here's a vending machine and here's a bus stop and then if I pick one then it just takes me to the website. I kind of get in and out very quickly. So let me show you how this works. Here's a parking meter demo that we built where I'm pulling down the notification manager. I can see the URL being broadcast. I pick it and now the physical web is done. The physical web is done. We're on a website now and all you're seeing is web sockets. It's just setting a web socket event. So I hit up, up, it makes that go up. I hit pay and then it starts counting down. Whenever I show this in San Francisco people cry a little bit because we have smart parking meters and nobody uses them because the app is so irritating. But that's all it really is. I'll admit I cheated a little bit. I assumed I had already gone through it once before but it was kind of a payment system. But even then you'd be like, well, what do you want to use? And people always ask, well, what's the payment system? I don't know. It's the web. Pick whichever one you want. That's the whole point about the web. You just would pick something and then from then on it would just work really easily. So the idea of the physical web is to bridge the web in physical devices. And so I would walk up to the payment meter. It broadcasts. I see it. But there's a couple of critical things to say about it. First of all, it's open like the web. You're trying to sell you a Google product. This is like web sockets or React or any other type of open web service. It's meant to be used by any company. It's also just a web page. Too often we think of a web page as being like Coke.com and you see the whole Coke experience in front of you as opposed to every single vending machine that you walk up to. It flips the whole thing on its head because every individual device could have its own unique web page. And it's really meant to be a walk-up and use type of thing. If I'm up in a park and there's a really famous statue that's there and I want to learn more about it, I'm not going to download the app. I just want to pull it up and get more information about that particular thing. But here's the most important thing. This cannot be an interrupt thing. This cannot vibrate in my pocket. This can't generate because it will be the most amazing spam vector on the planet. If I could walk into a mall and my phone would dance out of my pocket anybody who remembers Bluetooth messaging in the 90s it would be like that. So this has got to be a user-driven thing. We have to respect the user's attention span and only do it when they ask to see it. So how does this work? The intention is that that parking meter has a little beacon and it's just broadcasting. A URL. If you know Bluetooth Low Energy, it's called the advertising packet. It's a small packet and it sends out a URL inside of it. That's really important. We don't use some ID that requires a Google server. It's just a URL. That means any scanner can see that and take you to that web page. By definition, this is not going through any company's specific server. The phone comes by, sees it and goes, hey, you want to see it? And it shows it to you. So the simplicity of this is meant to be quite... a device that's broadcasting a URL that takes you to the web. But I always get two questions, and so I might as well answer them right now. The first one is, isn't this just QR codes? Well, yes. Technically. But QR codes kind of suck. And I kind of describe this as saying, we're like QR codes, but we're awesome. There's a big difference to it because we've seen QR codes. QR codes have been tried for many, many years. We've seen them in malls with things like this. Have you guys seen the Tumblr? There's a Tumblr page that's called Pictures of People Scanning QR Codes. Have you seen this one? Now, to be fair, the QR codes have been successful in some countries, but they tend to be on things like receipts and posters, and they're very, very limited in very, very simplistic use cases. So it's not like QR codes are by any means a failure, but they're very, very narrow. And it's so much easier to imagine a room with multiple things in it. And how can I see what's available to display to me? Or what about something that's far away? Do I really want to go really, really far away and go over and try to scan it when I just want to pull it down? So, and by the way, no one's putting QR codes in their products. That'll just never, ever happen. I can promise you that. So it's also just simply a matter of just making things look a little bit nicer as well. So the second question I get a lot is, isn't this going to be spam? A little spammy? And I think there's two aspects of that. One is the fact that it could be spammy, like phishing and so forth. And the other one is just simply lots and lots of things. The first one is, yes, I think there is a little bit of a risk, but it's inherent within the web itself. The browser will already protect you to a certain extent. But just to be safe, the scanner that we wrote actually has a proxy, takes all the URLs, puts them through a spam filter to try to filter out some of the worst offenders. This operas browser does the same thing, but it uses their own scanner, right? It's a feature of that particular one that can be implemented by different people. As far as being able to handle lots and lots of devices, that's going to be a really great problem to have. And I expect that over time, we're going to kind of have this UX evolution. Initially, it will show you what we find. Then we'll start to rank them based on distance. Then we can rank them based on your preferences. We could even then start to group them into folders. So there's a lot we can do as this grows to handle more and more items. So that was just my quick 10-minute overview of the physical web, just to give you a rough idea of what it was like. But now I want to talk about what we learned, because honestly, we started off with kind of a simplistic idea. We're just going to find URLs and show them to people. And in the process, I got a much deeper appreciation of how awesome the web is. So the first is this fact that we use a URL. I want to talk about what we learned about URLs. And the second is to talk about the web itself. So URLs. The actual advertising packet for Bluetooth Low Energy is currently 31 bytes. That's fairly small. Bluetooth 5, which has been ratified this month, in fact, will be shipping next year. We'll actually let that be significantly longer. But right now, it's only 31 bytes. And if you actually take a look at what you can put into the actual frame, it's 20 bytes. And after you include a couple of, you know, header bytes in there, really the URL that you can fit is 18 bytes. It's a little small. Now we have a compression scheme in there. So things like HTTPS colon slash slash dub dub dub dot can be compressed into a single byte. A lot of the demos I'm going to show you today are on pwdemo.org. And that can compress down to six bytes. So you can fit an awful lot in there. But most people have to use a URL shortener. And this is kind of what happened. Whenever I tell people I have to use a URL shortener, I kind of get this reaction. Which is like, you're kidding. Really? I have to use, like, no. Just get the hell out. No. But it's actually not that bad. In fact, I was initially really frustrated with the fact that I had to use a URL shortener because I didn't want to do it either. I wanted to put it in my website. But it turns out that URL shorteners are kind of awesome in a way that I didn't really expect. Because what can happen is if you have a URL redirector that takes that. The shortener is one thing, but then it redirects as a three or three, right? You can actually change that dynamically. So there were companies that immediately jumped on this and created a timing system. So in the morning, it would go one place. At noon, it would go to another. And in the evening, it would change. So you could actually have a timing and it could kind of dynamically go. I had never expected that. It's kind of cool. So in fact, when people use a URL shortener, I recommend that they use one like tiny.cc. Because tiny.cc lets you change it after the fact. Good.gl is fixed. And we're actually working on that. But the other thing that we also had when the URL goes nowhere, it's 404 is into nothing. We won't show it. So this company was actually clever enough to actually intentionally 404 and in effect, it turns the beacon off. So you can actually have this beacon broadcasting all you want to and nobody can see it because it's 404s. And then when they want to turn it on, they flip the switch. They've effectively taken beacon management and put it entirely in the cloud. That kind of blew me away. The other thing that's annoying physical web beacons compared to iBeacon is about ten times cheaper because you don't have to fiddle with specific beacons in specific locations. You just ship people a box and you just stick them up. And then after they're up, you can then redirect them to wherever you want to go. The other one is this company called Ruvio. They just was on Kickstarter. They have a new open source beacon that's really quite good. And what they do is they have a URL that actually encapsulates and they just compress it so that when you hit that web page, it takes that off and then tells you the temperature and the pressure and the speed and so forth. So the URL becomes a carrier of dynamic information. Even though every beacon takes you to the same domain, what you see every time you use it is unique. That's quite clever. And the final one is the fact that, again, beacon and another company, another actually open source project by IO, effectively takes a time code on the end of the URL. And actually when you redirect it, they wrote their own redirector as well and they can actually validate that it was actually the correct URL at the correct time. So they can do things like coupons and so forth which have a time limited aspect of it. So I've always been really surprised how much value, and this is just how the web works. URLs is this universal thing that can be changed. Cool. Changes things a little bit more. The second point was about the web itself and we started three years ago at Google and it's been shipping now in Android in the last couple of months. But the web itself has gotten so much better and it just keeps making us look really good and it kind of makes that saying no one fails who bets on the web. I'm beginning to feel that way. Take a look at this restaurant buzzer example. In this case, pull the physical web down. You can see Bob's deli right here. You click on it, physical web is done. We're just going to the web. But now we're going to a website that actually is registering for push notifications. There's eight people in front and you say get in line. You've now subscribed to a push notification. In this case, you've opted in. Now when it's your turn in line, your phone will vibrate in your pocket because you asked for it and then it's your turn, you go in and you can kind of get your point in line. So you know those restaurants have a $25 coupon and it changes it all to the whole thing. So it's kind of an interesting way of thinking about it. We didn't do a damn thing. The web just got awesome. Here is a little remote control Bluetooth toy called Ali. And in this case, we're going to broadcast a URL to a web page and then when we connect to it, we're going to use Web JavaScript Bluetooth, Web Bluetooth, and we're going to connect directly to the device and control it with the web using JavaScript. So it says, yes, this is a debugging command we're going to get rid of, so we won't have to do that in the future. And then now you have a joystick and as you move the web page up and down, it drives it across the floor. No app, no nothing, and that device, by the way, has no internet connectivity at all. It's basically stealing all the connectivity from the phone itself. So this is a really quick and lightweight way to kind of have anything to be controllable just using standard web technologies. I think that's kind of awesome. Oh my God, the web is still awesome? We've had this kind of been beaten up. For those of us who've been around for five or six years, we've kind of been beaten up by the fact that native is awesome and web sucks. And it gets kind of old after a while. But recently, I think we're finally beginning to realize the web actually is getting quite good and so many interesting things are happening. And to me, it all kind of came together how we can do this one little technology and these new layers are happening on top and it all kind of, you know, works together quite nicely. Because URLs plus the web, and again, maybe I'm just preaching to the choir on this, but I was really kind of deeply appreciative of the fact that they're just so damn flexible. We are doing a tiny thing with URLs and web pages, but people are doing really crazy inventive things on top of it that are kind of independent of us. And because we are doing this very thin discovery layer of just a URL, it allows people to do crazy stuff on top. But I don't want to pick a fight. About four years ago, I wrote a blog post called Mobile Apps Must Die. That was probably a mistake on my part because it kind of created, it set up this fight like web versus native and it got a lot of press and traction. And in hindsight, I realized I was picking a fight that we shouldn't do. There's no reason web and native can both do very, very different things and it's okay for them to both be around. What I have discovered with the physical web is the fact that the physical web enables interaction when apps just aren't practical. You want to play World of Warcraft? Great. Get an app. But if you just want to give somebody a little bit of information, well, then just use something a little more lightweight. So it's like each to each their own. So now that we've talked about URLs and we've talked about the web, there's a third point I'd like to bring up, which is thinking small. Because the issue with the physical web is that we came out with a Bluetooth beacon after Apple did iBeacon. And so almost 90% of all the questions that I ever get is trying to reinvent iBeacon with physical web. And so in this particular case I want to show something really, really lightweight, which is to say here is a fake pill bottle and it's a fake pill bottle with a fake prescription but my name on it. And the intention is to show what it would be like to have a very low power, very cheap beacon. They're actually expecting in less than a year to be able to buy these things, make these things for less than a dollar. In which case it just simply broadcasts a URL to the prescription, clicks on it, and then because the web browser knows my default language it can show me exactly the language I want. And it's nothing fancy. It's just showing a YouTube video and some information. Just lightweight, simple stuff that can be done very, very simply and easily. More about just information. And I feel like these lightweight scenarios are a totally different way of thinking about it. And I mentioned before about the smart toaster. You guys have all seen this before. You buy some new, brand new device. It comes in a box with URLs and QR codes and you unpack the device and it's the first thing you do, you throw the box away. And some poor marketing person loses their wings. Because the idea is they desperately want you to go to their website but we don't make that possible. Again, a toaster could just simply be a lightweight way to tell you a little bit of stuff. It could be how to clean the crumb tray, how to recycle it. It could even give you, once a month, give you a new toaster recipe if it wants to. But the intention is that we don't necessarily have to think complicated thoughts for this to be useful. The web is famous for this idea, this long tail of content that was talked about in Wired Magazine. The idea that the millions of tiny websites are significantly bigger than the three or four biggest ones. They really add up to this big, big, big amount of usage. And I think whether you believe in the vending machine example or the bus stop or the pill bottle or the toaster oven, each one of those is kind of ok, but taken together they create this big, much more long tail of interaction. How can we like interact and talk to almost any device effortlessly? And that's what we're trying to do and that's why this has to be a web standard. This can't be anything by a particular company. And by the way, people love to equate the physical web to the Internet of Things. The Internet of Things is cool. It's slightly overhyped right now, but this is just simply access to information and yes, it can bridge into smart devices but that's kind of an extra use case of it. So the final thing that I learned, number four, is that it's not just beacons. We have these beacons right now and whenever they think of Bluetooth they just think of these beacons and it's not cheap to be around. But it's actually also quite interesting to use your phone. So the guy before that was broadcasting here actually installed an app called Beacon Toy. And if you install Beacon Toy your phone can become a Bluetooth beacon. You can type in any URL you want to and now everybody here can see your beacon. Now, we originally made a physical web app and that physical web app was meant to scan, but it also does in effect broadcasting. So it's now demo time. So what I'm going to do is take a photo of you guys. There we go. Not that one. Delete. Here we go. Can you smile please? Thank you. Now let's just see how good the Wi-Fi is here for me to tweet this. Tweet. Okay. Now what I'm going to do is I should have realized under a slow Wi-Fi might be a problem. Okay. Now what I'm going to do now is simply hit the share button in Android and then when I share instead of picking Gmail or anything else I'm going to pick the physical web app itself because our physical web app gives you effectively the ability to share anything from any Android app. And now I hit it it's now broadcasting. So anybody right now that has a physical web running on their phone can see that tweet I just took. It'll probably reach, I'm not sure it'll reach to the back of the building because I haven't set a low power but probably almost everybody here in the first 15 rows can actually see this tweet right now. I can't confirm it but has anybody seen the URL? Can anybody tell me they see it? No one's looking. Anyway the point though is that I'll just leave it here if you want to see that. But the intention is that this opens up a whole different kind of way of looking at it. Imagine if you were to have just simply a vendor that could actually make their own little web page and hit go and then they could then simply just broadcast it or you could share something with your friends. So what did we learn? Quick summary you are all shortners for the win. They're actually quite good. The web just keeps getting better. It's the small use cases that I think are really interesting. Not these big corporate ones. There's nothing wrong with big corporate ones but I think the small personal use case of sharing I think it's quite interesting. And it's not just beacons. We can actually build this into the phone itself as a new way of sharing. So that's part two. Part three, where can we go? And I find this is the part that I'm going to get a little bit more maybe not philosophical but more like where does this technology take us? The first thing I really want to stress is that everything that we do is open source. This is my first open source project. It's been very eye-opening how it works. We have an amazing community on GitHub of people that help us out. So the application that we did is open source. The scanner that we built in the proxy service we built is open source. We're working on this beacon image right now. This is all written in ARM embed. We're going to make that open source. People have written Node servers or Arduino code. All sorts of different things have all been done in this open source community and it's been so much more interesting because everyone's kind of working together with us. So initially we released a single app on Android. We also released it on iOS. And that was just to get started. Then it got built into Chrome. That lasted for about six months. We had enough traction that the Android team got interested and they integrated the code into ... I'm sorry, Opera also did it. Then we integrated it into Android. So right now it used to be in Chrome and now it's in Android itself. And then there's a mystery vendor who's going to be releasing their own browser. We hope in about four months it's going to do it as well. So there's a little bit of momentum going on behind this. So it's really kind of fun to see that if you give it away people are actually going to use it. And this is what you do. You just simply just open it up and let people play around with it and kind of go back and forth. So who is the actual we part though? Because yes, I work for Google, but more importantly I represent, I like to think I work for the Chrome team in Google. I think there's a certain kind of esprit de corps that we have in the Chrome team that's very kind of more of the web. And what we do is to make the web better. But I don't want to be this shill for Google product. In fact, a lot of companies that are using the physical web right now are actually getting angry with us because we're not pushing this. We're not taking out ads. We're not really making this like a corporate thing. Because the point is this has to be of the web. This can only succeed if the web wants it to succeed. If we were to push this too hard, it actually would backfire and it wouldn't be considered to be part of the web. So this will only work if we kind of as a community wanted to work. And I do think that means it's going to be a little bit slower to get adopted. But I also feel like that's the natural, better way for this to go. This can't work if Google wants it to work. So we are continuing to experiment though. We keep pushing out crazy ideas in our Android app. So just recently we've put in Wi-Fi direct support so that you can broadcast not using Bluetooth but using Wi-Fi direct. We've also added MD&S support, just a variation on that. That's actually quite useful for industrial use cases. And then we've invented this new thing called a fat beacon. And a fat beacon is the same Bluetooth beacon, but instead of broadcasting a URL, it just broadcasts a title. And then when you click on it, it makes a connection back to the beacon, yanks the web page out of it and displays it for the user. So that way you can use it without having data. That makes no, there's a lot of questions that come up about this. And that's why we do this as an experiment. We kind of put it out and have people kind of throw rocks at us and ask questions, because there's obviously a lot of security concerns about putting up any random beacon that goes through absolutely no, you know, vetting of any kind. But it's worth talking about, and people are getting quite excited about the possibility of being able to have something work without any data at all. This is especially useful in developing countries. But I really want to stress, this is the tricky part. I work for Google, but I'm on an open source project. This is an experiment. We're just trying things out, and people keep saying, oh, Google has a new thing called a fat beacon. It's like, no, no, it's an experiment. Okay? It's really I'm sort of really underlying the fact that we're just playing with these things, and that's, but we want to be more of the open source side of things and play around with it. So now it's time to talk about my starry-eyed vision of where we can go with this stuff, because I think there's lots of different directions we can build on top of it. Because right now the simple scanner that we have to find a list of URLs that you click on feels kind of like Mosaic. Right? It's just kind of the first baby steps of what we could do. So let's talk kind of a range of things from near to far and where we can go. The first thing that I don't think people appreciate is just how rapidly hardware is evolving. This has got a coin cell in it, and it lasts for about three years under the existing battery. It's the new Nordic chip that came out is called the NRA 52. ARM also has one called the Cordio. These things are significantly more efficient, and it will probably last upwards of a decade on a single coin cell battery. In addition, they've now got it down to only one volt part versus a three volt part, which means it can run on a single photovoltaic cell. Which means these things are quickly going to become powered by light, and therefore we won't be having the ecological disaster of throwing millions of batteries and landfills every year. So these are quickly going to become kind of permanent long-term type beacons that will just run forever. I think this is quite interesting. It's the hardware side of things. So that's the first step. Step two is URL services. Much like we initially had websites, and then we went to Blogger, and then we kind of went to Twitter, and then we went to Facebook. We just had easier and easier techniques for people to work. I think that eventually we're going to have more and more interesting services built specifically for the physical web. We had a summer intern that basically created a URL dynamic page creator. It was basically kind of like mycard.com with an ampersand name and an ampersand phone number and photo, and I didn't know this, but a URL could be 2,000 characters long. So if you were to create a gigantic URL with all of the parameters that you want put into a URL shortener, you now have a web page that's yours. So to me, that's a very lightweight way of people being able to do that. I think there's a lot of interesting things that can be built with that. The other one would be fixed function beacons. You can imagine, say, a for sale sign that you would have for your car or whatever and then it comes with a beacon built into it. You just basically go to it first, register it, type in the information you want to and it works. You don't even care about the service or anything like that. So a lot of things can be built on top of that. What I get more interested in is effectively this idea of getting rid of the beacon entirely. And if we were to have a type of mobile dream weaver, imagine an app that you would write that you could then specify a template and information and pictures and photos and do whatever you want to and hit go and then your phone becomes the actual server itself. And people could connect to it or it could upload it to a server and you could point a link to that. I mean, that's the whole point. There's many different directions that you can go. But it means that effectively people are now going to be dynamically creating content with their phone and then just broadcasting to anybody around. This is especially interesting in the fat beacon case with markets in say rural areas where people could then create information that they want people to see and everybody else could see it and connect to it and there would be no data anywhere. But you could interact and get information on each of these places. I did mention briefly about JavaScript Bluetooth, the web Bluetooth standard. This is part of the W3C and it lets you interact to the specific beacon. But in January-ish or first quarter of next year there's going to be a scanning API and that to me opens up an amazing amount of work because we did do I don't know if you've heard about the Computer History Museum in Mountain View, it's right next to Google. We put in 31 beacons there to try to see what it would be like to walk around and we found out that not surprisingly if you walk up to some exhibit and you pull on the physical web and you see exhibit 6 and you pick it that's fine and then you go over to exhibit 8 and then to pull on the physical web again it gets kind of tedious to keep pulling on the physical web. It's like once you get in stay in the web environment well once you get scanning it means that all of the beacons for the museum would broadcast one URL, it would just say oh you're in the Computer History Museum but once you open that web page it would scan and say oh you're next to exhibit 6 I'll show you exhibit 6 and as you're reading it and you get close to exhibit 7 a little thing could pop up and say oh so and this now completely unlocks the whole UI paradigm because now each hospital or museum or venue can do their own UI the physical web is basically we'll just get you started and then you can have your own experience I'm getting super excited about that we actually built a rough prototype of how this would work for museum and the results were very encouraging but again this is going to happen not too far in the future about 6 or 7 months but then the last point I want to mention is that I think that the scanner that we're building is really primitive and the whole reason that we've built it this way is that other people can build scanners the running joke I have been saying about open source is that everybody loves open source as long as you do all the work and the idea right now is I think people are waiting for Google to say hey if you think this is a good idea you make the market but if it takes off you damn well better give it to us and I'm like fine that's exactly what we're doing we just want to make this part of the web and so yes maybe Google does have to push it a little bit harder but the whole point though is that we're going to do this really basic primitive scanner and we really hope other people do really exciting even better things to kind of move things forward so for example someone has talked about they wanted to do for a summer project beacons that have JSON LD embedded in the page that actually have markers in it so you could browse it as a regular page but it also tells you a little bit more about the fact that it actually has an audio clip to it they would build their own custom scanner that would pull these things up and then for blind visually impaired people they could walk through an environment and then get an audio tour as they walked around I also talked to a researcher that wanted to use this for augmented reality you could actually look across a room find the physical web beacons just through the air but each physical web beacon would have a link to actually what its mesh is what it actually physically looks like you could then pick that out of the various pages and then do visual recognition with what you're seeing and then be able to look at something and know exactly what it is and pull it up again research farther in the future type stuff but this is what happens when you can build on top of kind of the data substrate that the physical web gives you so I was just a couple of the ideas that I came up with but this is why I'm so excited about the physical web so here's the summary so far I talked about what the physical web was I talked about kind of the journey we went on I gave you just a few ideas of the things that were going on but the bottom line is it's only going to work if it's part of the web community sometimes people think that I'm pushing this as a Google product but nothing can be further from the truth this is only going to work if we as a community want it to happen so I hope you're excited by it because I am lots of other companies are and I'm going to stick around afterwards and answer your questions so thanks very much for listening I hope to talk to you guys later lots of questions of course I think you touched on this in the talk maybe you and I know more about this so I'll ask it again isn't the physical web a security nightmare with people being tracked as they walk around etc the big thing about the physical web and our sweet spot use case is this public ephemeral interaction it's the bus stop that's giving the URL we strongly recommend that the user does not have a beacon on their body because for just that reason you could be tracked so we don't recommend that if though you're worried that because you're using the Google scanner and it could scan for all the devices that you could be tracked there's two things to say one is I hate to break it to you but any app on the planet can do that with GPS already and second you don't have to trust Google if you don't want to use Google's physical web use Opera's physical web so pick the company that you trust most and use them cool which was the first browser to implement the physical web gee I'm trying to think some tango thing something like that is there a physical limit on the size of a beacon can it be the size of a grain of sand or as big as a mountain there are beacons that are literally actually smaller than this there's a beacon that was actually Verily Verily's Google's health group they had made a custom beacon that was the size of an American nickel that was 21 millimeters wide and it lasted for about 3-4 weeks because it was a really tiny battery so these things are going to get significantly smaller and how practical is the physical web if you walk by a trash can full of pill bottles each giving you a notification on your phone I get the pill bottle question a lot you can do clever things with changing the antenna design and also turning the power down so to me the pill bottle example is going to be really viable if it only has a very very tiny radius of say maybe half a meter however there are people that probably have 50 pill bottles in their room and honestly I don't have a good answer for that my expectation is that this would only be used for very very high value things and not necessarily for everything but that got to my point about how we will get better and better scanners as we have more and more of these devices cool and what about power consumption of the device that's doing the scanning constantly battery we actually so many people actually do not turn on bluetooth at all because they think that bluetooth is actually a power hog and the new modern browsers or the new modern chips is actually not an issue at all so just turning on bluetooth will not hurt your battery we only scan when you turn the screen on and we only scan for 10 seconds so our battery impact is almost insignificant excellent thank you very much Scott great