Kia kato. We're here from the Arts Digital Lab at the University of Canterbury and we're going to be telling you about the Understanding Place project and the Red Zone Stories app that we've developed for that project. I'm Jennifer Middendorf. I'm the manager of Digital Lab and with me I've got Samuel Hope and Jennifer Rees who are our digital content analysts. So Samuel's going to be talking about some of the background to the project and the theoretical ground it comes out of. Jenny is going to be talking about the more technical aspects and how we actually built this app. And then finally I'm going to tell you about some of the lessons we learnt in the course of the project. So I'll hand over to Samuel now. Kia kato, nami hima hana. Thanks, NDF, for inviting us to talk today. So as Jennifer said, I'm one of the digital project specialists at the UC Arts Digital Lab alongside Jenny and we have been employed to work on a National Science Challenge funded research project called Understanding Place. So Understanding Place is a part of building better homes, towns and cities which is a small contestable fund that was started up in October of last year and we'll be running through to June of 2019. So this particular challenge invites participants to respond to changing conditions in New Zealand's urban and built environments. Our project Understanding Place offers a cultural perspective on the issues presented by Christchurch's post-disaster urban landscape. Many of these issues have been covered extensively in the media, for example the loss, displacement, dislocation, fractured memory, both individual and collective. And we're in many ways focusing on an urban landscape which is characterised by a loss or an absence. We're focusing on landscapes that have been red-zoned and houses have been removed from them. So Understanding Place therefore seeks to develop approaches for capturing and representing multiple meanings and histories in these landscapes that have been abandoned or have had homes removed from them. So I'll just give you a start-off, talk about our research aims. Firstly we want to capture regeneration narratives in red-zoned areas of Ōtatahi Christchurch, in particular the residential red zone which I'll describe in detail shortly. In doing so we want to present not just one but many stories and many narratives of quite effective spaces in the city and connect up what we've been calling micro-stories. As a part of this we also want to foreground the stories of Māori and include the mana whenua story as a layer on a cultural map of the city. So we found the best way of approach of doing this was to build an app that people could take out into the field and use in situ, use in their spaces and explore them and use the app to record their stories. So I'll just play a little short video of us taking a early prototype of that out into the field and describe a little bit about this space. So this is the residential red zone which is probably not too familiar to people outside Christchurch but you may have heard about it in the media. It's this kind of 630 hectare large space of land which resides in the east of Christchurch and in truth there's not just one residential red zone but many red zones. There's some on the Port Hills which is on the Banks Peninsula and some to the north of Christchurch as well. This space once housed over 5,000 residents. There was after the earthquakes in 2010 and 2011 there was a big push by Sierra which is Canterbury Earthquake Recovery Authority to do something with this land because it had been severely damaged by the quakes and was considered red-zoned and unable to be built on in the short to medium term. So as of I think 2012 there was a large project to start removing homes from this land and in total the government bought, purchased and removed 5,422 houses which is you'll see the sort of traces of these spaces and here's us testing it in the field at the moment. So as part of this project we linked up with some collaborators and partners. One of them for the funding set up by National Science Challenge we had to select a real end user and for us that was Regenerate Christchurch who are the successor to Sierra and Canterbury Earthquake Recovery Authority and they have really taken hold over the planning and consultation over what is going to happen with this space in the next 10 years or so. So alongside Regenerate Christchurch we also sought out the Ngai Tahu Research Centre which is based at the University of Canterbury. Tamari Tau who is the Orpuku or the leader of Ngai Tua Hureti which is the hapu which has mana whenua status in our part of Christchurch. They came on board with us and offered up their own story of this space. So we wanted to tell these multiple narratives of this space and get as many different views as possible and when we approached Tamari we said well what are the Māori perspectives how do we engage Māori to do this and he said well there's not one single there's not many Māori stories about this place necessarily but there's the one hapu story the one Ngai Tua Hureti story so we're just in the process of going through and getting a video which will plot on this map and show throughout the residential red zone so I'll just pass over to Jenny now who's going to showcase the app a little bit and you'll get a sense of how it will fit together. Thank you, hi I'm Jenny I'm one of the team in that digital lab you see as well I'm going to give you a bit of an overview of the technologies behind the red zone stories app and show you some screenshots I'm not going to go into a huge amount of technical detail so feel free if that's your thing to come up and ask us more questions at the end so red zone stories made up of two parts is the app that's primarily the data gathering tool and there'll be a website that goes with it that will be for storing and displaying the data the app is built using Ionic which is an open source framework for building hybrid or cross-platform apps it describes itself as the dev-friendly app platform for building cross-platform apps with one code base for any device with the web building a hybrid app meant we could use our existing experience with website development and we didn't need to create and manage separate native code bases for Android and also iOS Ionic provided a lot of tools that help speed up the development such as being able to preview the app in a web browser as we built it and to quickly deploy the app to real devices for testing as well it also comes with a library of front-end building blocks such as buttons, form fields, page loading, spinners all those things you expect to see in an app so we didn't need to reinvent the wheel for the user interface we did need to extend Ionic with a few plugins to achieve some functionality most importantly accessing the device's camera and the GPS location data which is critical to the project so once a user has used the app to record their story and submitted it, it sent to the website site of Red Zone Stories the website is built using Drupal also an open source project Drupal had the REST API tools we needed to have the app talk to the website as well as being a user and content management system people can also will be able to submit their stories through the website if they can't make it to the Red Zone themselves once enough data has been collected the website will display analytical and visualisations for the use of both researchers and for the general public who have been contributing for the maps which you'll see in a moment we've used the leaflet JavaScript library along with map box and data from open street maps and land information New Zealand some imagery layers that you'll see in a moment and we're capturing and displaying users traces of their movements as they walk around the Red Zone using the GeoJSON format I've just forgotten completely about the slides I'll bring them up now so that's Ionic on the left there previewing how the homepage of the app looks on Android, iOS and Windows and on the right a sort of high level architecture diagram of what's involved so this is the map as the main interface of the app and when you're out in the Red Zone you'll be able to toggle on the layers at the top there the one on the left there is from before the earthquakes and the one on the right is from two or three years ago the 2015-16 era the Red Zone area marked out in the red once you've logged in you have the option to record a journey or a story it's sort of been using both words interchangeably by hitting the button in the bottom left there it will check at that point that you're actually in or near the Red Zone and give the option to start flagging places, a little flag icon or take photos or record video and at that point once you're recording it's also keeping track of where you're moving to draw a line of your movements on the map the flag option allows people just to say this place is important to me and to explain why but they don't necessarily need to take a photo or upload a video and after taking a photo or a video or flagged a place is important we're asking people to enter a little bit of metadata just to tell us why that's important maybe what it is if they've taken a photo and add some tags as well you can see on the right those are sort of a sample of the sort of things we expect people might use and those will come through and the analytical features will come later on once you've finished recording your journey you'll be able to have a look at all the things that you've recorded maybe delete a photo or a video if you've had second thoughts about it and on the right there is just a scroll down view of the same page that shows recorded trace that's not in the Red Zone it's at the University campus but it gives you an idea of the kind of data that we'll be collecting of where people have walked or biked or driven while they've been wandering around it gets a bit jagged closer to the buildings I think out in the open where the curved lines are gets a lot clearer and then people can upload to the website once they're happy with that that's everything for me, thank you so all of this might have inspired you to maybe build your own app because we've made it sound so easy well I'm going to tell you about some of the challenges we faced along the way and the lessons we learnt we definitely bid off way more than we could chew with this project as Jenny said building an app in Iona is actually pretty easy for the basic stuff but it was some of those details that got really hard Jenny and Samuel have actually banned me from ever using the phrase theory it shouldn't be too hard because it always is just one example recording audio you'd think that would be something really simple especially on a phone but it turns out that recording audio is really hard because every model of phone has a different built in voice recorder so what works on one phone is not going to work at all on another there was a lot of problems like that so a few months out from our proposed launch date we were starting to panic we had an ever growing to-do list and the bugs just kept getting worse and that's when we made what I think is the most important decision of this entire project which was to admit we were in over our heads admitting that let us stop trying to do the impossible but instead pause for breath, step back and look at the research aims of the project and we asked ourselves what's the minimum we could launch with and still meet those aims so audio doesn't work well, video ironically is really easy to do and it achieves the same aim of letting our participants tell their stories orally so we scrapped audio altogether and we just stuck to video and we did the same thing with all of our to-do lists we went through and we divided it into the must-haves the things that this app just wouldn't work without and the nice-to-haves which we put aside and said we'll work on that later we just concentrated all our effort on the must-haves the other really big thing we decided to do was to bring in some external help getting our data from someone's phone into the database turned out to be difficult if we wanted to do it securely we could do it but there's a lot of security issues there but we don't want our participants or the university to be at risk of hacking or data loss and we just couldn't figure out how to do that so we decided to outsource that part because we couldn't put it on the nice-to-have list the whole point of the project is collecting data we kind of had to do it now we already had a really good relationship with Catalyst IT and Jonathan's over in the corner there and because they had worked on the Quake Studies project which some of you might have heard us talk about that in previous years so we went to Catalyst and we said can you build the database side of this app take that off our hands and we'll carry on with all the other stuff and that worked out really well now of course we were only able to do this because we had a budget for it right from the start we budgeted in the possibility of needing external help and that's probably the biggest lesson I want you to take away from here is that when you're taking on something totally new like this plan to fail make sure that your budget and your deadlines can cope with things being a whole load harder than you expected them to be but alongside the technical difficulties we also had the usual practical problems that any big project has biggest of which was a key staff member left which put us behind by several months while we recruited a replacement for him and that delay moved our launch date right into the middle of the time when Regenerate Christchurch would be doing their consultation and proposed uses for the Avan o Takaro River corridor Regenerate were understandably concerned that this might cause some confusion with the public if they had a consultation going on at the same time as we're gathering data on the same area so they said to us, well just postpone your launch until February we couldn't do that because we actually have to start gathering our data now so we're going to meet the output deadlines that were set by the National Science Challenge so our solution was to split our data gathering into two phases in phase one which starts this weekend we are going out to community groups to marae to rest homes places where we can get a group of participants together we can go through the consent process and teach them how to use the app and most importantly we can make sure they are really clear about the difference between our project which is research and Regenerate's consultation so that keeps Regenerate happy and it also means we can start collecting data straight away and it has the bonus that we can collect data from some key groups like Māori and Pacifica the elderly who might otherwise be underrepresented in our data in February we're going to launch phase two and phase two we'll release the app on the Google Play Store for anyone to download you'll only be able to use it if you're in Christchurch but anyone can download it people can then just download sign the online consent form and go and start recording data and we've got that extra little bit of time between now and February when we can start working on those nice to haves and maybe get a few of them back in there so what we recommend building your own app yes but be realistic about the size of the job you're taking on plan for failure be prepared to scale back if you have to and don't be ashamed if you need to ask for help and I've done the same thing I forget which slide I'm on now we're about to open up the floor for questions but before we do I'd just like to acknowledge Donald Matheson who's the principal investigator on the Understanding Place project and of course the Building Better Homes, Towns and Cities National Science Challenge say that three times fast who are the funders of this project thank you so we've got a roving microphone if anyone has any questions I'm sorry, do any research prior to understand if an app was the best way to gather these stories and if audiences would actually want to use an app? Yeah, so there was a bit of initial research which mainly was just compiling of everything that was out there we used we looked at a few key texts one of them was Hyper Cities which is this text by a couple of digital humanities scholars out of Harvard and they they had done a project prior which was cultural maps of various different cities like there's one in the Philippines so there's the old heritage sector in the Philippines and they looked at how different people engage with those platforms so we looked to these sort of cultural mapping projects coming out of universities we also looked at what's called volunteer geographic surveys so these are often run by sort of urban developers or government organisations to try and extract data from citizens about what they think about certain developments in the city and the third thing was looking at participatory archival practice so there's this text called archive everything mapping the everyday which came out a couple of years ago by Gabriela Gianacci and she talks about archives 3.0 which was this kind of participatory reflex of user generated kind of archive where people were describing things themselves and really curating the archive in a way that's meaningful to them so our project sits in between these different things the kind of thick or the cultural mapping the volunteer geographic survey and the participatory archive and the app side of things is we wrestled with all sorts of accessibility problems and I don't think it's ever going to be perfect I mean there's lots of people but currently we're going to roll out an Apple version early next year but so there's technological issues there but also we want to reach different generations as well and that's obviously going to be a problem as we go out to community groups and some of them will have higher digital literacy some won't so that's why we've done this stage as well where we go out and sit down with communities and walk them through it I don't know if we mentioned there's also a website version as well so that's for people that don't have or not in Christchurch have moved elsewhere that can contribute to it that way I think the other key thing about using an app is that it lets us really pinpoint where the important because this is as Samuel said a massive area of land and so by using the app and people having to actually move through that space we can see where the important places are and that's something that's not easily measured by just saying where do you think is important you get more of a sense of that from people actually going out into the space and how they move through that space What sort of repository do you envisage this being housed in in the future and what sort of systems are in place in terms of technology and that sort of thing to keep it from coming obsolete At the moment and for the first probably two years of its life it's going to sit in that Drupal repository and catalyst of providing some support to us to make sure that that's going to keep updated At the end of the life of the project we're going to transfer everything over into quake studies so it will then be available in quake studies in Seismic and in digital New Zealand so anyone else? I also forget to mention that Jenny has a version of the app on her tablet which works in Wellington so it's a special demo version so if anyone wants to have a look at what it actually looks like in practice just talk to Jenny later


Mike Tauchman he was two for five with an RBI and really it's been all season long in five games that he has started He is seven for 16. I asked Aaron Boone why he thinks Tauchman has been able to find so much consistency at the plate He's talented first of all, I mean he's a guy that you know has power can run can defend And I think he's just finally kind of gotten an opportunity at the big league level I think he's done a great job of coming in here and learning how to prepare learning how to Prepare for a pitcher and game plan You know, I think he's done a great job of getting on time early You know, he's getting ready to hit early and that's allowed his talent to you know, finally Show itself at the big league level. This is a guy that's had a lot of success through the minor leagues and you know, it clicks at different times for people and and I think last year getting here with The the players on this team, you know, PJ and Marcus I give a lot of credit to of you know, just helping him realize his potential With the way he plays defense and the way he's been swinging the bat Are you gonna need to find a way to continue to find him at bats and get him in that lineup? Yeah, he'll get his at bats I mean, you know Yeah, I mean That's the tricky part You know with our club right now is obviously trying to make sure guys are are getting those regular opportunities Or if they're not in there every day trying to keep them as sharp as possible and and hopefully we're we're Juggling that all season long because you know me would mean we're healthy Talkman has also been very good against left-handed pitching take a look at these numbers since last season 10 extra base hits 13 RBI is a 951 OPS that's fifth best in the American league against South pause and although it is a small sample size He is three for four with two doubles against Lake Snell switching


Congratulations to the Sailors selected for advancement to Chief Petty Officer. More than 4,000 Sailors were selected to put on anchors this year. Visit ah.mil for the full list of selectees. The Senate has confirmed Admiral John Richardson as the 31st Chief of Naval Operations. Richardson will relieve Admiral Jonathan Greenert next month in a change of office ceremony at the U.S. Naval Academy. And finally, as promised, a new NAV admin detailing Navy-specific maternity leave guidance was released today. Effective immediately, women who serve in the Navy and Marine Corps will have 18 weeks of maternity leave during the first year of their child's life. The new instruction will apply to both expectant and new mothers that have given birth since January of 2015. For these stories and more, visit Navy.mil.


So it is now 10.40, which means it's the start of the next awesome presentation in here. So we have David Rowe. He seems pretty cool. He's presenting about radio, and it's like radio, Rowe, how to remember who the presenter is. So let's give a warm welcome to him. Thank you very much all for coming. It's a real honour to speak to you. My name is David Rowe, and I'm pretty excited about what's happening to radio. For the first time we, the open source community, are starting to get control of the whole stack right down from applications to the physical layer. And in particular today I'd like to talk about that transition from where we are now with radio and software radio right down into the physical layer. I'm going to take a few case studies from my own personal journey through open source. I've been working on open software and hardware projects, mainly in the physical layer DSP type area for the last eight or nine years. And I've learned a few things and experienced a bit of frustration, which is sort of pushing me in the direction that I'm in now. I'd like to talk about why we want open source in the physical layer. Talk a little bit about chip sets and how we currently do software defined radio. I'm not a big fan. Talk about spectrum and pirates. People are legally using spectrum and regulation. And some of the challenges it might be facing in the next few years as software radio becomes more predominant. And then some trends and then some challenges for you guys where we actually need help to make this transition at the moment. So I'll start off just talking about what is a radio. This is just a very general model that applies to both the transmitter and the receiver. You'll find all these building blocks in any radio, whether it be an AM broadcast radio or a car radio or a Wi-Fi modem. First of all, we have some sort of filter. What that does is radio spectrum is pretty broad. That limits us to just the sort of frequencies that we're interested in at the moment. There's always some sort of amplifier, signals we receive off the air are very weak and need to be brought up to levels that we can process comfortably. And we want to send a signal and a transmitter. We take signals that are fairly weak and usually pump them up to quite a high signal level to transmit them. The next two circles there are a mixer and a local oscillator. What they do is they're your tuner. They let you take that particular part of the radio spectrum that you're interested in and just isolate that and work on that down at baseband. So they just do a frequency changing step. They might take your 2.4 gigahertz Wi-Fi and shift it down close to zero hertz. So it's easy to process by your baseband processing software such as your modem, which is the next step. That takes analog samples usually, the signal off the air, and converts that into bits and bytes. And in the opposite direction you'll take your bits and bytes and convert them into some sort of analog signal that can be sent over the air. How well you implement the modem often defines how high performance your radio system is. That's a pretty critical part. These days pretty much all digital systems will have some sort of FEC or forward error correction. That's where we add some redundant bits to the signal we transmit and we use those redundant bits to help us correct any errors that might be received at the other end. There's often some sort of codec that will compress the source information that we want to send over the air into something that's a little bit more manageable for the radio bandwidths available. Spectrum's fairly limited, so if we can squash the speech or video or even text signal into a narrow bandwidth, then that's a good idea. So we often have some sort of codec. And just aside for that there's things like the protocol and the application. I don't really play there. One of the reasons is it's been done really well by you guys. We have some really good open protocols and applications. But it's all these lower layers that are still stuck in closed source land and that's where I like to work. So that model was fairly symmetrical for transmit and receive. Some of the blocks will be in different orders and things but you'll find the same sort of blocks. Same sort of design for pretty much all frequencies from broadcast radio right up to optical. In case of optical it might be a laser as your transmitter and a photo diode as your antenna for the receiver, but the same principles will apply. Similar design, no matter what your payload data is, you can even use that similar model for analog radio. And as we transition from analog to digital radio it's kind of useful to make comparisons. For example, when we listen to a radio or a GSM phone call and part of the phone call gets chopped out or a few words and we tend to put it back together in our own head that can be viewed as a form of analog forward error correction as distinct from what a digital signal do which would automatically put it all back together for you. As I said, the protocol and application are already pretty well done by us but what I'm really interested in is how much further towards the antenna can we push open software in particular. This is kind of where we are today. Those of you who are lucky enough to attend the open radio mini conf on Monday will have built pretty much what I've got in that red box there for the hardware. So that sort of stuff, when you buy a software-defined radio today or build one you'll find out that's where the hardware will lie. Everything outside the red box tends to be software. So in the case of what we build on Monday the software was running on the laptop for the modem, the forward error correction and perhaps the codec whereas the stuff inside the red box all those building blocks were in hardware. This is where I'm interested in going. Can the only thing that be left be the antenna that's actually hardware. Now that's a real aggressive goal and a simplification. What might actually happen is that things like the filter and amplifier might be a combination of open source software and some very simple hardware but I want to keep pushing towards that vision. I'd like now to talk a few case studies from projects I've worked on and that have revealed to me I guess some of the issues that are in the current way we build radios and how they can be addressed by the open source community. In 2008 a group of open source developers set out to build a mesh void router called the mesh potato. I did speak about that a couple of years ago here so there's videos available if you're interested. But it was a router that you could plug an analog telephone into. You could put this thing up on your roof, TV antenna height and create a mesh telephony network in a village for example. The application was in the developing world where telephony in particular mobile phone calls were very expensive and this was a way for communities to build telephone networks and talk to each other over moderate ranges. So the application wasn't particularly commercial. It wasn't like a start-up in the sense of we were all trying to get rich. We were trying to help people. It was non-commercial. We needed to use commodity Wi-Fi chipsets and we chose one from Atheros and we soon discovered it was very, very difficult to get any sort of data. When we came to manufacture the thing it had to go down a production line that had expensive test equipment with proprietary hardware and software to calibrate the thing so that it would work properly and within the regulatory frameworks. This is what the device ended up looking like with a typical end user although it would normally be installed at some sort of height like on the roof of a hut or something like that. So we had pretty close to zero support from the SOC vendor. Pain, frustration and delay in the project. And that was because we were constrained by this proprietary hardware. They had this nice little chip that was the central processor. A system on a chip also had the Wi-Fi radio but we just couldn't get into the thing or get any data for it. In contrast, we had some far more complex parts of the system. If you think of what goes on in an operating system we were using asterisks, IPPBX, Speaks, speech compression. All those things just worked. We hit make and they were running and yet we were really just held back by this closed hardware radio device. So some very frustrating closed source bottlenecks. And just to disclaimer, the latest mesh potato apparently has had much better support from the vendor so it's good to see some things are changing. But what worked in that project, the open source software really worked well. We came up a small team, came up with an innovative design and put the thing into production, our own custom hardware. So that was great. What didn't, as I said, the closed radio hardware. The other thing we found out was the Wi-Fi protocols were really bad for voice over IP, very inefficient. And I'll talk a bit about that later on. So it got me thinking about the issues of standards compliance for radio novel applications and the issues around closed hardware for radio. Another project I worked on around about the same time was an eco-canceler. Now these are used at any time a four-wire telephone network hits a two-wire telephone network. And a good example is when your mobile phones hit the exchange and it goes back into a landline. And you'll often hear this on mobile phone calls where you'll hear a bit of echo at the end of the line that comes in and goes. What's happening there is that when we need to convert a transmit-receive signal such as you get from a GSM phone or a voice over IP system to a two-wire telephone line that goes to a landline you have a thing called a hybrid. That's a little electronic building block so the idea is it separates the transmit-receive signals and combines them. Unfortunately they're not perfect. So when the far-end speaker is talking let's see how I can get that mouse across. So they're talking to you from the other end saying one, two, three you're listening to them on your handset here. A little bit of that signal gets sent back up the line towards the far-end speaker and he hears his own voice coming back to him, echo which puts a lot of people off. What the eco-canceler does is it measures what's coming off the line here, what's going back down the line and it tries to make a model of that echo and subtract it so that the other person on the other end of the phone doesn't hear the echo. And that's called an echo-canceler. They're actually really hard to write. I tried it off and on for around 15 years. Couldn't get one working in a proprietary closed environment. It was a huge problem for asterisks, any of you who were involved in asterisks for 10 years will know what I'm talking about. Many people had a goal and it couldn't get it working and even all the asterisks guys were saying oh, you have to have a DSP chip. A DSP chip is a small CPU that's optimized for signal processing. Usually it has proprietary software mass programmed on it. They were screaming it's got to be hardware. You can't do it in software. You need to use hardware because it's so hard. It's all covered by patents. I experienced a lot of past failure myself. Open source gave us a bit of an edge. Things like crowdsourcing the testing. When I came up with a candidate echo-canceler design I just threw it out there. People would start testing it. That helped us discover some really weird corner cases. For example, what happens when a microphone like this that captures quite a wide range of audio hits that audio signal, hits the telephone network which is designed for very narrow bandwidths. So we got some really weird corner cases that usually break echo-cancelers and we discovered them just by crowdsourcing it. There was no need for painful formal speech testing. Normally when something like that involves speech needs to be tested formally, you get hundreds of speakers, statisticians involved, hundreds of utterances and spend a lot of money.  We didn't care that it wasn't perfect or complete. We added self-instrumentation. When people would complain of an issue I'd tell them to run a certain command line. That would dump the states of the echo-canceler and the input and output audio files. They'd email them to me and I could reproduce exactly what they were experiencing and debug it. All these sort of things are very difficult inside closed-source developments. So what we did here was open-source really delivered a better solution. The thing worked very quickly at minimal effort. Another case study was 3DV. That's what I guess my current area of work which is open-source digital voice for high-fringancy radio. Now high-fringancy radio is sort of the last area where analog actually outperforms digital and there is no real incumbent digital standard. It's a really tough technical problem due to the nature of the HF Radio channel. It tends to wipe out modem signals very effectively. And it's currently littered with proprietary modems, codecs and very expensive radio hardware. Quite easy to pay $8,000, $10,000 for a commercial quality HF radio. How people typically make digital voice systems for HF radio is you license a speech codec from one person, a modem from another and you might try and put it together with some FEC and some protocols. And I was told that you can't do layer violations. So you have to take these things as separate black boxes and just butt them up against each other without really considering what's inside. I didn't like that. I said, oh yes, you can. So I started mixing up modem and coding and FEC layers and breaking a lot of conventional rules. And we're coming up with a better HF digital voice system, basically. I did things like I designed the modem to suit the speech codec. So rather than accepting what was out there as a standard or a black box, I said, well, no. I need something a little bit different. I know how to write a modem. I'm an open source developer. This is how I'm going to do it. The initial codec I released, the bitstream format was particularly susceptible to a certain sort of errors that you get on HF Radio. So I hacked it. I changed it. I removed that part of the bitstream. It made it sound a little bit worse with no errors, but only a tiny bit, but a lot better when there were errors. So I designed the codec to suit the HF Radio channel. You can't do that if it's all licensed proprietary code. In fact, it's specifically illegal to touch it or understand what's going inside. You'll get in trouble. So I also have done things like used mixed analog digital techniques. One of the advantages that analog HF Radio has over digital is that the more important parts of speech, say when I speak louder or the parts of my speech spectrum that carry the important speech information, in analog speech, more power is allocated to those. They tend to be louder, so the power amplifier and the transmitter allocates more power. So I changed my modem to allocate more power to the important parts of speech. So it's this mixture of analog and digital techniques. Once again, simply not possible with closed source. And once again, we're finding open source developing a better solution. These guys, however, have done it all before. This is the SIG Sally Secure HF voice system from World War II 70 years ago. It's basically all the block diagrams of what I'm doing now. They've got a speech coder. It uses a very similar speech model to what I use. It's got a modem, a multi-tone HF modem, similar to what I use. And it even has encryption, which I'm not allowed to use. So it's a little bit more advanced technically. And like a lot of things in signal processing, it's all been done before. And if we look at a few trends, this is how it tends to work. So the example I'm using from is real-time speech compression, because that's what I do. So I have a bit of knowledge in that area. So in 1940s, we had custom vacuum tube hardware. And then by about 1970s, the same sort of thing, speech compression, this is several thousand bits per second speech compression, was possible with custom hardware. So you had to solder up the boards at a chip level. It wasn't reprogrammable, just gates and things like that. Then 1980s, the first programmable DSP chips came. And that's about when I started my engineering career. And we were very excited that we could have these little processes that were optimized for doing signal processing. And the key thing there was they could do a multiplier accumulate in one cycle. So we had fairly fast processes for the day as well. So suddenly, it actually became possible to do speech compression in software in real-time. And that was a real breakthrough, because for a long time, speech compression algorithms were so computationally complex, we simply couldn't do them in real-time in software. But then we could all of a sudden. The next step was it was running on a general-purpose computer. Suddenly we could run speech compression on something like an x86 of the day, using mid-90s sort of processing powers. By the 2000s, we were running speech compressor. It wasn't having to run the processor flat out. It could just use a fraction of a general-purpose CPU. So now we're talking about running, say, eight channels or four channels in real-time. And maybe we're running a voice-over IP client or a gateway at the same time or some protocol work. And now, we're running the same sort of speech compression technology on a fraction of a microcontroller. So we're now talking a $2 or $3 chip or $10 chip as I'm using in one of my projects that's running speech compression on a fraction of a microcontroller. Now, these trends are the same for all sorts of other signal processing. I've also seen things like forward error correction units. They used to be hardware. We had to solder up together, only just possible. Then they went to FPGA software, et cetera, et cetera. And now they're a trivial complexity on sort of current CPUs. So this trend is very similar in a lot of signal processing. So hardware migrates to software. It always does. It's going to keep going. What's hardware today and only just possible is going to be software running on trivial CPUs tomorrow. Software can be free. That's something we've all discovered. That means radio communications can be free. And that means free in all senses. It'll be essentially zero cost, and it will be free in terms of speech. So we can modify it, examine it, play with it, and come up with cool new things. I would say that communications must be free. I'd like to talk a little bit about chipsets now. Recently, there's been a wealth of new chipsets for radio. A lot of these, some of these are tiny little ones that will do an RF modem and... Oh, the whole thing right up to, you know, UHF, which is on a single chip for a few milliwatts, and you can put them in a balloon or on a satellite. They're wonderful little chips. There's also a lot of up-and-down converters that are being used for the current crop of software-defined radios that have just come out. However, I don't get excited about chipsets because I've been through this before, and what we're essentially doing is giving hardware vendors control. They always have some area where they won't let you into, won't let you play with. Sometimes that's for commercial reasons, other it's because there's bugs or problems they don't want you to know about, and they let you discover it a little bit further down the production line. It can cause huge pain. It means lack of control, and it often means lack of the data you need to build whatever you're working on. You're limited in the support. If you can't look inside the thing today, you're limited on them, and they might not feel like supporting you on that day, especially if you're an individual or a smaller team working on things, and an open source, that's often what we are. There are bugs we can't fix. End-of-life issues, that wonderful chip will disappear one day. You can't move your functionality across if it's tied to some guy's proprietary hardware. You get to sign awkward legal agreements or you're forced into a position where you may have to, NDAs. Then there's the portability issue. You can't move it to the next chip along. It's in their interest for you not to move it to the next chip as it comes along. I'd rather move our radios around like software. A better approach, the one I really like, is general-purpose CPUs. Even design the system to minimise the hardware. What I mean by that is that when someone tells you to build a radio or you want to build one for your open source project, you've got a lot of choices. Take the choice that minimises the radio hardware, rather than just say taking what's the most convenient chip in 2015. Actually design the system for minimal hardware. You could be designing the modem waveform and even a standard to minimise the hardware using the principle that open source is best. Everything should be open source, modems, codecs, protocols, even the hardware. Don't rely on black boxes or binary blobs for any layer. Don't stop at the protocol or chipsets, which is where we're staying, where we are today. You'll find some really interesting things. There's so many advantages in development effort. If you're bringing a product to market and it's software, it's so much faster than some sort of proprietary hardware chip that you need to depend on. You can learn more if you can see inside the thing. Education is a wonderful thing about open source. Learning about radio is really cool. Innovation, if you can get in there, modify it and tweak it, you can do some really interesting things. I've shown you some previous examples about how we're outperforming closed source systems in all sorts of areas of signal processing. Cost, essentially, open software means your bill of materials, your hardware costs drop towards zero. Portability, you can move it across from my PC to an embedded machine back again. Security, that's a huge one. If you understand and can see every single bit of hardware, no special chips with unknown firmware, no software you can't examine, then it can be far, far more secure. And ultimately, the performance. I'm an engineer. I want to make things that work well. I don't want to be constrained. So I can make things perform better with open source. Spectrum Safari. A friend of mine called Steve Song has contributed to these couple of slides. He's been looking in how much radio spectrum is actually used. Now, spectrum is interesting in that it's a fairly scarce resource. There's only sort of so much available in the universe. There's more and more people clambering to use it. It tends to be government regulated worldwide in most countries. Most of it's tied up or reserved and this has been going on for a long time. You know, getting on 100 years now. These sort of laws have been in place. And it's starting to run into issues of technology, which we'll talk about in a moment. So Steve and some of his colleagues have been researching spectrum usage and basically it's not being used, most of it. There's an average of 15% occupancy. There's great chunks that are tied up that simply aren't being used.  This is sort of an example of them doing that. People have done this. They've done audits in various countries of spectrum to work out what's really being used out of all this stuff that the government says you shall or shall not use. Now, here's the problem. Spectrum regulation is going to get really hard to police as the cost of access comes down. And there's already some noted failures. If you try and use a HF radio like a shortwave radio in urban areas you're surrounded by noise from switch mode power supplies and other high-speed digital kit. Technically, those products all get approved but we can't use our HF radios in urban areas anymore in a lot of parts of the world. And then there's also some wonderful things that have happened when spectrum regulation isn't so tight. One example is the public park model of how Wi-Fi is regulated. One of the best examples I can think of is some friends of mine in India called Air Joudy and they've been doing this for I think over 10 years now. They started off with sort of first generation Wi-Fi APs and put their own dishes on them and things. But what they've done is made a rural internet network, rural India and the last time I visited they brought internet to over 30,000 poor and disadvantaged people which is a wonderful thing that they've done with essentially an unlicensed spectrum. Once that spectrum was sort of loosened up so you can do what you want with it. And I encourage you to check them out on the internet and read up. The innovation that people have come up with once they've given a little bit of freedom people playing with open WRT routers, putting antennas on it. However, there's some limits. We still can't play with the radios. Big business still controls all those chipsets and tells us what we can and can't do. Another way to use spectrum is pirating. There's always been people who will illegally or use some sort of dubious use of radio spectrum for transmission or receive. Sometimes they do that just to annoy you but other times it's just people who want to use the spectrum and they want to use it in some way that's outside the current rules. As we've seen most of the spectrum is unused anyway. Soon the cost of accessing that spectrum is going to be close to zero. We're all going to have SDRs in our laptops or something. And already there's people who monitor all these sort of old 20-year-old satellite services using SDR radios and little antennas. Some of them aren't even encrypted and things so it's already happening. To me there's some analogies with movie downloads. The technology extended to a point that the previous legal models starting to fracture and break and not make particular sense. A lot of people are scrambling to keep all those rules in place but I kind of think the direction is more in that public park Wi-Fi area where we need to be. And to me there's some ethical questions around pirating. What if you aren't bothering anyone? And in particular there's some applications in countries where the government may decide to restrict your communication for their own purposes and not for your benefit. The other thing is if we wanted to stop pirating, can we? It's very hard to detect especially if they're not monitoring anyone and not doing any harm. One of the things that came out last year and got me thinking about this was this air chat system and this is based on it uses these little commodity walkie-talkies that you can get for $40 or $50 some laptop software and it's fast enough to send things like emails and chat data across ranges of tens of kilometers with zero infrastructure. So it does serve quite a purpose. All this sort of stuff is possible with other services like ham radio or commercial services. It's basically quite illegal in most places but how can it be stopped and do we want it to be stopped? This sort of thing. In particular if they're not bothering anyone. So some ethical questions there I think. I've also had some thoughts about standards. As I said with the village telco mesh potato system one thing we thought was a real positive was standards compliance. It was all built around Wi-Fi standards but I found that once we started testing it didn't work very well. This idea of VoIP over Wi-Fi and this horribly inefficient protocol 802.11 for IP packets. The technology of the day was 54 megabits per second 802.11G I think and we were lucky to get one megabits per second of voice data through the system because it was all optimized for great big web downloads and things like that. Also the paradigm of mesh Wi-Fi of omnidirectional antennas didn't work very well and a lot of that was due to the protocol as well. So we were kind of limited at the time because you bought the chip came with the binary blob you had to run 802.11 but when I started thinking theoretically it was something like a thousand times less efficient than what we can do with similar sort of voice quality if we had our own sort of protocols. So you can get some huge gains if you maybe take a step back from the standards and think what do I really want to do? Standards have their place obviously you want interoperability but they shouldn't necessarily be a constraint and don't confuse standards with the laws of physics. Just like I've been told you can't do layer violations they also tell you you must stick to a certain standard. A lot of these standards are just there as thank you Timothy for pointing this out though just to support someone's patent pool. So there's sort of other interests involved and not necessarily yours. So ask yourself very carefully whether the standard makes sense and I've had a lot of fun breaking them and made things work a lot better and I like to be constrained by what the laws of the universe of physics tell me in particular for radio communication that's the fundamental limit and my imagination not big business. Now with open source culture it's generally individuals and small teams that we're not content to be told what to do and to me chipsets and standards that promote patents in particular that's what people are telling us we must do it their way and they try to understand us in that direction whether we want to or not we have other motives like profit and fun or helping people and to me it's all underpinned by this concept of GCC portable software now it could be your language of choice but the idea that you can take this software and in a moment move it across to another device not being constrained by the hardware or chipset. So to me the future is pure software radios and as hardware agnostic as possible you know I have my chipsets and microcontrollers I like to play with they'll be gone in two or three years time just like the last one but the software will still be there and when hackers get control wonderful things happen now the last few years there's been an explosion of SDRs I encourage you to have a look at all those they're all doing very cool things they tend to be based around the paradigm of being digital up and down converters and they interface to your host PC somehow what they do lack is power amplifiers and filters that commercial radios have that make them a complete radio that makes them more like a piece of test equipment but quite useful for hacking very useful, very cool and extremely cheap for the amazing capabilities that they offer now having a purely open software radio compared to other ways there's portability free as in beer and speech, secure as in Snowden very difficult for anyone to listen in if you've got complete control over everything right down to the hardware or if you've even disassembled it yourself like we did last Monday it's really easy to get these things going we got a software defined radio going in a few hours on Monday try assembling an old school pure electronics radio that way and fast, if you're a business time to market I've seen people struggling for years with these other sorts of radio architectures but we can get things going in much shorter time and time to market and one of the greatest thing I like is accessibility and learning the ability for all of us to learn and understand this stuff which traditionally being it's too hard and I've had the geeks tell me the asterisk guy say oh you can't go there suddenly they run away, it's not that hard we can get into it, we can play with it and a lot of the work that I like to do is talking about it, putting my simulations and code up there so others can play so I guess to summarize we want open software in our radios that's the only thing that will work we want as much open software as possible that's the priority and the smallest possible amount of hardware and that hardware must be open some challenges, as I said the whole theme here is pushing open software it's got to be open towards the antenna one of the challenges at the moment and these are things that you guys might have some ideas on how to work is just getting data off and on the CPU this is a problem with narrow bandwidth data and with wide bandwidth data we experienced for example the other day with the open radio mini comp just getting hold of, we needed two channels stereo left and right sound blaster inputs very hard to do, very hard to find the software for that so we need a way to get these samples from our radio into our processes and I'm not sure what that is maybe it's not a couple of cables maybe it's something else, but that's a problem that needs to be solved on the other end, if you're grabbing several hundred megahertz of samples how do you get that into your PC then you're starting to hit limits of USB and Ethernet bandwidths and also driver issues you might be okay over the Ethernet but they're not used to running that flat out and they're not used to getting the data into a big array where you can start playing inside your CPU one big challenge is filters and power amplifiers even today's most advanced software defined radio still have a bunch of clunky relays switching filters in and out and big hard to get expensive transistors for power amplifiers what can be done to make those open hardware and software make them much simpler now that's a real challenge because a lot of these things by definition 100 watt digital analog converter for example but maybe it's not impossible maybe there's a way to do it or ways that we can combine software and hardware in clever ways and I'm starting to see a few people work on those sort of areas another thing that I'm playing with at the moment is good quality open source modems that are fully explained that anyone can use in their applications and sometimes if you get the modem right or wrong it can mean a difference in 10 to 1 in terms of performance of how much power you need another issue is power consumption that's one thing today where chipsets do win however a lot of really low power microcontrollers and DSP chips coming out that we can program ourselves and keep the device open okay that's it and I'd like to throw it open for questions, thank you how long do you think it will take having in mind that open software now runs on proprietary hardware like Intel processors and ARM processors and you don't have the sources for it or the access to it when you look at this it makes perfect sense in terms of time how long you think this will take yeah I don't know I think there'll be some steps in that direction for example someone will come out with a radio chip that's completely open rather than proprietary and that'd be a nice step in the right direction yeah I really don't know but I don't think it's less than a decade I've I've built a pirate radio as in Pi as in Raspberry Pi it's not exactly open hardware as such can you recommend a platform that we could be using which is open hardware these days for the signal processing work yeah the Raspberry Pi's a great one once again challenges there on IO getting things into an RF system and out again I've been playing with some little microcontrollers the STM32F4 there's a $18 development board that's fun for the baseband processing and take a look at our open radio platform as well so you seem to jump from chips that do protocol level or encoding level work and through to GPIO into an antenna there are a bunch of chips that are DAC straight into a mixer with a straight LFO they obviously do have limitations but much less and several of them are coming from vendors who actually do know how to document and do indeed document is it are you working for the end goal because that is the end goal or yeah I kind of like that, that's fine if they're fully documented and open and to support that sort of thing I think that's wonderful any more questions yeah you mentioned there's the cost comes down to zero it's a lot easier to get before defined radios and do things like create pirate radios does that also mean that it becomes a lot easier to detect when others are using license yeah good point that's a very good point and it might become more easier to surveil what's going on I know there's a bit of a loaded question but in the open radio we did the first building block what's the next building block that you have in mind the next building block I'd like to play around with things like the power amplifiers and filters that area as that's the next tough problem there was a lightning talk yesterday that talked about communication issues on islands that have restricted access to all sorts of communication infrastructure would there be a possibility to have low powered radios that transmit just enough data to have a basic channel of communication that is hard to moderate let's put it that way yes I believe so that's probably more the protocol level that sort of thing so would that air talk project be one of them or are there others hard to say yeah I'd have to look into it a bit more I haven't started it in depth but that is designed to be difficult to intercept and to be secure as well do you ever see the potential CPU dies becoming open source any time in the future yeah good question it's possible you can synthesise CPU cores and FPGAs and things like that I don't know if it's necessary I just like the idea of general purpose mips being out there and using that it might be running on my phone as an app for example with some minimal hardware next to it so I just see them as the engines but just don't get hung up on the particular one you're using and it's advantages or it's integrated peripherals it's got to be something you can move portably around thank you


I was a killer out there and they got that Whatever we were saying look whatever we seen Guarantee you wouldn't bro Leave the team and tell But I let my team and everything I did I ain't play offense for girls to me anyway. I don't play out.  I'm from my coach. No.   I'm going to him See, I play I play dm before I play cone.    You know how many games I see Huh?  That's my heel That's why I like about him like he's long. You hear his toe. What are you gonna do?  You hear him toe then stop.  I ain't never jam.  I swear to God, bro No kelp, bro.  Bop, bop, where you going? You can't even run.  You cannot throw it on my side I was a lockdown Conan. I played it like the end so see I would love you, bro.  I went to the youth Square Bennett No, I just love basketball See, I had two.  I still ain't do it See, I had two. I ain't had no toes They tried. They tried. Put it like that. They tried She is.  Boy, I had that boy best.     What's Buster? What's Buster? These are coaches Yeah I'm like, bro, why am I going to class? I played baseball Bro, those niggas told me I got hit in the neck No, I'm talking about that football I played, I played baseball I quit baseball.


Good morning Hank, it's Tuesday. I want to ask you a question. Do you think the violent crime rate in the United States has gone up or down or state about the same since 1990? The answer is that it has gone down dramatically. In fact, there are about half as many violent crimes per 1,000 Americans as there were 25 years ago. Overall, crime rates are also down dramatically. But every year since 2006, at least 60% of Americans polled have said that they feel that crime is going up. And I am among them. In fact, I wanted to make a video about why crime is going up in the United States, only to find out, you know, that it's not. Okay, so if you are an American, this is how likely you are to die of various causes. You see violence down there in the bottom right corner. That's all interpersonal violence. War, terrorism, murder, etc. Now, because its victims are disproportionately young, violence becomes a bigger problem if you change this visualization to measure disability-adjusted life years, which is like a measure of how many years of healthy life are lost due to various causes. But it's still a relatively small public health problem in the United States, smaller than suicide or drug overdoses or asthma or complications from preterm birth or traffic accidents. And also violence is shrinking faster as a cause of death and disability in the United States than any other major cause except for HIV. So I think several studies have shown that on the internet we like to share what makes us outraged. And that incentivizes media companies, even very small ones, that make videos in their basements, to find outrageous stories because we know that you will share them. I've done this like in 2010 I made a video about how outrageous it is that we continue to mint pennies even though they cost two cents a piece to make and are never used to buy goods or services. The problem is the penny, while it's an obvious outrage, is an exceedingly small outrage. I mean, the U.S. government could save far more money just by passing a long-term highway funding bill which Congress has been unable to do for the last six years. But that isn't as narratively simple or as easy to get outraged about so we don't talk about it much. And then there is Martin Shkreli, the Bond villain-esque former hedge fund manager whose company acquired the rights to a drug that treats people with toxoplasmosis and promptly raised the price from $13.50 a pill to $750 a pill. The internet boiled with outrage until the company promised to lower the price. Two months later they've just announced that for some customers they are going to lower that price all the way down to $375 a pill. But the outrage at this ass hat masked a much more complicated and interesting problem, like even before the price hike, the drug cost 30 times more in the U.S. than it did in the U.K. And these price hikes aren't even particularly new or rare. Long-time nerdfighters will remember back in 2011 when Warner Chilcot raised the price of its drug Azacal 1200% overnight.  It's happening because there's a huge web of problems with pharmaceutical markets in the U.S. Point being our collective outrage may have slightly decreased the price of one rarely prescribed drug, but it's done nothing to address the larger issues that affect every American who takes medication. Now of course the internet can and does grapple with big and complicated problems and it's also given a voice to people who traditionally have been discriminated against in public discourse. And I also don't think there's anything wrong with being angry. Anger combined with sustained effort can lead to real change. But when we allow ourselves to casually move from one outrage to the next from pennies to Martin Shkreli, nothing ever really changes. Well, except that maybe we've become more afraid and pessimistic. Like since January of 2010 crime is down, the U.S. joblessness rate has fallen dramatically, the economy has grown, and we report being happier on average than we were five years ago. And yet every single month since January of 2010, more than two-thirds of Americans have felt that the U.S. is headed in the wrong direction. And I feel like we're unnecessarily inundated with bad news because we seek it out and when we find it we share it and so we become more afraid and pessimistic than we need to be. But then again, as a nation we've never been healthier or claimed to be happier, so maybe we're getting exactly what we want, even if we don't know it. Hank, I'll see you on Friday.


Hi, everyone. My name is Elizabeth Morant. It's not that hard. And I am a product manager on Chrome where I work on security. So today, you've heard about a few new web APIs, like notifications and Bluetooth, that allow you to make amazing web experiences that are more engaging than ever before. And Owen alluded to this example earlier. Beyond the Rack recently implemented push notifications, which resulted in a 20% CTR. So 20% of these notifications users actually click through. And of those users who are visiting beyond the rack through notifications, the site is getting a 26% bump in revenue. This is huge. Notifications and other permissions, and other APIs like it, allow developers to create new levels of engagement. But in order for users to actually take advantage of these features when implemented on your site, they actually have to say yes first. They have to give you permission. So to set a baseline, what do you think is the opt-in rate for geolocation on the web? Now this number is specifically Chrome for Android, 28 days on a certain milestone. It's of every time that we show the Infobar, what percentage say yes? Someone said zero. Well, that is pessimistic. What, 20%? 25? Well, we're pretty close to that three number. Our opt-in rate today is 6%. And so we have a few guesses as to why this opt-in rate is so low. And our biggest bet is it's because sites are asking for this permission at the wrong time. And now this isn't your fault. This isn't the developer's fault. The geolocation API is built in such a way that in order to query whether a site actually has the geolocation permission, the site has to actually request it first. And so there's no way to check without annoying a user with a prompt. And so one of the things I'm going to be talking about today is how to use the permissions API, which is a new standards API that allows developers to ask for permission, not just geolocation, but any permission at the right time. And to round it out, the opt-in rate for notifications is a little bit better at 17%, but still, we can do better. So we've seen examples of runtime permissions models in the wild that work really well. So an example of this is iOS. There are certain apps on iOS that just ask for permission in a really respectful way. So this is a set of screenshots from the iOS Google Photos app. And during the install flow, they show an interstitial saying, get notifications. And they don't just immediately show the system prompt saying, you should opt in to get notifications from your cool photos app. Instead, they give you a reason why. And the reason being, they're going to do some magic in the background with all your photos. And then after a while, at random points in time, they're going to create awesome videos and then let you know when they've presented you with this gift. And so every notification is basically like a present. So I opted in to getting notifications. And so did 88% of users who saw the system prompt to opt into notifications. And now this is smart for another reason too. Not only does it manage user expectation, but it also means if the user doesn't hit Turn On in the app UI at this moment in time, the app still has the ability to ask for this permission again later when it's had time to prove value. And so this is iOS, but we've also seen good examples of this implemented on the web. The Financial Times recently launched a new version of their site where they send you notifications when exciting news happens on topics that you care about. And so the idea is that you switch notifications to on and then you can choose different categories that you want to know more about, like arts and entertainment or world news. And then the Financial Times will send you a notification when something interesting happens in that space. And with this UI, because they explain the value and they act on the promise that they display in this flow, they have a 90% retention rate. So of all the users who opt in to receiving notifications for the Financial Times, only one in 10 end up provoking the permission later on. So we all know, especially now, that not every user is going to say yes to a permission when you request it. So why do we have them at all? Why don't we just let any developer or any app use whatever API they want? Well, this is for two reasons. The first is usability, giving users control over what sites can do and can't do with their data. And the second reason is for security. I'm going to walk through examples demonstrating both. So say that you use Gmail or Twitter on the web. These are good examples of sites that you engage with pretty regularly. Daily, if you're on Twitter during the summit, probably pretty regularly during the day. And for that reason, when you open the site, it's really nice when you have all the content preloaded. And so native apps do this today.  And Background Sync is an API that we're working on for 2016. And it works great for these two cases. But Background Sync is not a fit for every site that you visit on the web. And as we learned from Darren earlier, people average around 100 different sites a month. So imagine if every single site you visit has access to Background Sync. Well, then your phone would functionally be a brick because you would run out of battery pretty quickly. So that's one reason why we have permission prompts, is that users can have control over what sites can and can't use given APIs. So the second reason, and probably the most significant reason why we have these permission prompts, is for security. So say that these 100 sites that you visit every month all get access to your camera. That's a pretty fast track towards a dystopian future. The movie writes itself. And so it's really important that we give users control to grant camera or other sensitive APIs to those websites that they implicitly trust. And this is also the reason why we're deprecating the support for powerful capabilities over insecure origins. So starting in version 47 of Chrome, sites that are served over HTTP no longer can request a camera or a mic. And likewise, we're planning to impose the same restriction for geolocation later next year. And all new APIs, like notifications and others coming soon, have a strict HTTPS only requirement. And the reason for this is because even if you have the most trustworthy site in the universe, like you are the best arbiter of sensitive data, if you serve your site over HTTP, then you lose all guarantee of security for that user's data, right? Like, I could be accessing your site in a Starbucks. And just because I trust you to handle all the photos I'm sending you over the connection, it doesn't necessarily mean I want everyone in Starbucks to see the photos that I'm sending using camera on your site. And likewise, HTTPS is important, as Emily alluded to earlier, for preserving the integrity of your site. So without HTTPS, there is no guarantee that I know, oh, sorry, I know who I'm talking to. And there's no guarantee that you can prove it to me. So permissions are great, and they're here to stay. So how do you actually build an app that asks for permissions in such a way that users say yes? So for the purpose of this talk, I am working on a demo app. And the premise is simple. If you live in the Bay Area, then you probably know that there are two types of weather. There is sweater weather. And then on the rare occasion, there is t-shirt weather. And because of the rare occasions when you got to wear a t-shirt because it's so hot, every morning you have to wake up and you're like, look out your window or check the weather and just confirm that what you're wearing is fine. So I made an app that eliminates that friction. It's pretty simple.  It's one page. It tells you whether you should wear a sweater or not. You opt in to giving me a location and whether you want to get notifications. And if you give the site both, then every morning it does a check and it sees if it's above a certain threshold to be t-shirt weather. And on those rare occasions when you want to wear a t-shirt, it will send you a notification. So I mentioned I'm working on the site. So it's worth mentioning that I have all the permission stuff down. The notifications won't actually send, but you should totally opt in anyway, improve our global opt-in rates. But you can play with it and see how to ask for permission. And that's really what the demo is for. And I'm working on finishing it up soon. Second thing to note is that for this app to work, I'm using a couple of features in the Permissions API that haven't actually been fully released yet. And so the Permissions API is an open standards API implemented by Chrome and Opera. And there are just certain features, which I'll call out during the talk, which are only available if you are visiting the site on Canary or Dev and if you have this flag flipped on. So the purpose of this demo is to show you some principles to follow when requesting permissions on your site. So I'm going to walk through five key principles. The first is communicate intent and provide clear value. So when you're requesting notifications, say, it's really important to say exactly what you're going to be bothering the user with. So in my example, I say notify me when it's T-shirt weather. It's very clear that the only time the user is going to get bothered is when I actually have something meaningful to share. And I know that I personally, as a user, I am very stringent with granting notification privileges apps. There are some messaging apps I don't even give permissions to. And so explaining exactly how it's going to be used is super important. And so you can imagine I could have said something like send me notifications, and it would likely get a far fewer user saying yes or tackling it on.  And this is because images localize better. If you're trying to have it, if you have an app and you want it to work cross locale, it's much easier to communicate value through user experience or through images rather than actual text. And so here, for location, I use this location icon that's shared with a number of other location-focused apps like Maps. It's also important because even if your app is in a language that the user speaks, people don't always read the manual. People like to play with things. And so the quicker you can get to communicating intent without actually using words, the more likely a user is going to understand how your app works and whether they should opt in or not. Second principle is ask at the right time. So Owen mentioned this. I mentioned it earlier with geolocation. The absolute worst time to ask for permission is on load. And now you don't have to do that anymore. The permissions API allows you to query for permission state at any time. So let's just stop doing this. Better practice is to ask on user gesture. So if you give the user an affordance and ability to indicate that they actually want to use a permission or use an API, then that's the right time to ask for permission. You can imagine an example of this being like a camera app where you take a photo and then you add some effect to it. A good time to ask for permission in that example would be when the user tries to take a photo because you know they really want your site to have access to the camera. In my example, for notifications, I use the switch of the toggle as that user gesture, the indication that a user wants notifications. So the way I do this is I just add an event listener to detect when the toggle state has changed. So if the toggle is switched on, then I request notifications and when a user toggles it back off, I revoke. Third principle is only ask for what you need. So say you have this amazing camera app. Well, just because you can ask for every permission that's available or every API that's available on the web doesn't necessarily mean you should. Your camera app probably doesn't need Bluetooth. It probably doesn't need notifications unless there is real reason for you to have it. That being said, we do make it pretty easy for you to bundle permissions requests. And so one of the new features of the permissions API is this ability to request all. And so there are some points where it's absolutely appropriate for you to ask for multiple APIs at the same time. So the example I have pictured here is there's a button that says, notify me when I'm near coffee. In this case, it makes sense. You do need to give up your location and the notifications permission so that the app can tell you when you are near your closest Starbucks or whatever. That being said, do not take APIs hostage. So it would not be appropriate for me, in this case, to add Bluetooth as a permission request just for the sake of it. And the reason for this is because I haven't communicated in my app what I'm using Bluetooth for. And it lands users into this weird state of confusion where not only do they not know why you're asking for this third permission, but they also now don't know if you're not being totally honest with what you're using the first two for. So what you request should map what your UI communicates. Fourth principle. Oh, sorry. This is what it looks like. It's pretty simple. You just add the parameters for the permissions you want to request, user request all. That's it. Fourth principle is give users control. So in a world of progressive web apps where users are adding your website to their home screen and they open it up in full screen as a service worker, where do users actually manage permissions with no Chrome UI? Today it's pretty simple. If you have the URL and you hit the overflow menu and you go into permissions, and that's where you do all your management. But in this world, it's not as clear. And so that's why if you have one of these awesome full screen apps, you should give users an ability to manage the permissions in the app itself. And so in my app, I use the toggle and the location icon to allow users not only to indicate that they want a permission, but also indicate when they don't want it anymore. And I do this with revoke, which is another experimental feature. And so this is the code snippet from the first example where I waited until the toggle was checked. And what it does is if the toggle's in the checks position, then it requests notifications. And if it's in the unchecked position, then I just revoke.  So the absolute worst thing you can do when a user goes in and manually revokes a permission or doesn't give it to you in the first place is to crash. And the second worst thing to do is to not communicate what's happening. And so in my app, what I do is if a user changes a permission state, then the UI updates accordingly to communicate why something might not be working. So in this case, if the idea is that the app would default back to set location, and if this isn't updated to your location, you see that you've declined the location permission, which means that it's not updated to your location, like Minnesota or wherever. So you want to design for resilience, so that when users go in and do wonky things that you're not expecting or you don't want, your site should continue to work and communicate why it might be behaving differently. And so what I do here for the location example is I query for the state of geolocation permission using the permissions API. And then when that state changes, I update the UI and I update the functionality of the app to reflect the new state of the permission. If the geolocation permission is denied, either through the UI or through Chrome Settings, I disable the button and I fall back to default location. Likewise, if a user goes back to the ask defaults, then I enable the button and fall back to default. And then if the state is granted, then I enable the button. It's big and blue and I query for the current location. So taken together, when asking for permission, you should provide clear value, ask at the right time, only ask for what you need, give users control, and handle failure gracefully. And now there's clear incentive for you to do this on your own site. It enables users to know what you're using your given APIs for and it just creates a better experience overall. But I'm going to add two additional incentives for why it's wise to follow these principles. And the first is Chrome is working on a way to moderate the abuse of certain APIs on the web. So we don't have an app store. We can't take down sites. But what we can do is monitor and make sure that they're being used effectively. And so we're still thinking about it. It's still mostly conversation at this point. But we're hoping to create some sort of policy for abuse on the web. And now this isn't the first platform that's thought about this. Facebook actually does a really great job of managing abuse of notifications on their own app platform.  And this is a great example of how platforms are thinking about allowing the use of these powerful features while also managing the risk of abuse and spam. And now the second incentive and the one I want to leave you with is asking for permission at the right time doesn't only help you, but it helps the web ecosystem on the whole. So what you're seeing here is we did an analysis on a small subset of Chrome users to see the effect of seeing multiple geolocation or prompts across the web on their tendency to interact with or accept a given request. And I say this is a subset because the CTR is hovering a little under 20%. And again, the total CTR is 6%. This graph in reality looks like this. So if you are more stringent with when you actually ask for permission, whether it be geolocation or other permissions, then this means that the next site that a user goes to, they're also going to be more likely to say yes there and there. And it perpetuates across a user's experience on the web at the whole. So I hope this was educational. And you're excited to use the permissions API. If you want to get your hands dirty, we have a code lab available. It's at the bottom of the code labs on the CDS site. And I'll also be outside taking questions if you have them after the talk. Thanks.