 I'm here to produce the speaker, Amy-Marie, and she's doing a presentation on Firefox OS and its uses for Linux. Okay, I have a small disclaimer to put, and I'm really sorry Dietrich and the Firefox guys, because I've got a capital F in Firefox and there shouldn't be, but oh well. So just to let you guys know that. Thank you all for coming. Basically, what I want to just give a little bit of chat about is the architecture in Firefox OS and looking at its use of the kernel and how packets, et cetera, get passed up through it and back down. And a little bit on where our code base lives and how you can contribute and stuff, but a little bit less on that. To give you a quick introduction, my name is Amy-Marie Forstrum. I've been using, I used Slackware when I was a kid, but I really think my first use of Linux was probably with Debian Potato. I've contributed to various OSS web projects. A lot of things that I do is mentor children with Python and Scratch. And I've contributed to Mego and QT, which led me to the Firefox OS trail. And recently I was doing some stuff with Mozilla on the Firefox OS support team. So now this is going to be interesting because I've got two, sorry. So what is Firefox OS? Well, by now you've probably heard about Firefox OS. All right, I'll just leave that there. By now you've probably heard about Firefox OS. It's been out in the wild for just probably about over a year and a half coming into two years. First started life as the B2G project, aka B2Gecko. It's still referred to B2G in GitHub. It's Mozilla's attempt at entering the mobile platform area. It is aimed at lower-end smartphones. But this is not a limiting factor. It doesn't mean that you can't roll it onto your Nexus 5 or Nexus 4 or put it in higher-end phones. It is built with web standards. And a big thing, open web standards, and a huge difference about the Firefox OS approach is that there is a marketplace, but you don't have to put your apps on the marketplace. You can host your apps on your own GitHub. You can host them on your own website, and people can download them and use it from that. So you're not restricted into the marketplace model that Apple and the Microsoft restrict you into. So let's just jump into the actual... Layers, this is going to be a bit tricky because I'm kind of losing my pointer. Okay, sorry. All right, so basically what we're looking at here is what I like to call the 3Gs. And then under those layers we have the actual mobile device itself. So at the top you've got Gaia, Gecko, and then GONK. GONK is your Linux kernel. Gecko is Gecko. And Gaia is where your applications are sitting and running. From a security perspective, each layer, each application runs in its own sandboxed environment within Gaia, but we will actually go through and have a look at that deeper. What's that? Yeah, I'm on two different screens. Sorry. My speaker knows it's got to be corrupted. So basically Gaia is your interface application for Firefox OS. It comes with the standard stack of applications, phone caller, messaging apps, contacts, calendar, etc. When you roll your own Firefox Gaia, we'll include the basic stack of common applications in it as well. So you'll have your basic marketplace and etc. And Gaia communicates to GONK through the Gecko layer. So what is Gecko? Hey, sorry, all right, I'm going to work this out in a second now, I've got it, cool. So at the top we have, Gecko holds basically all out where our web APIs are running from. So Gecko is the application runtime of Firefox OS and implements the standards for HTML, CSS, and JS. Gecko is considered the middleware code, which is comprised among others of a networking stack, your graphic stack, the layout engine, and the virtual machine for running the JavaScript code. So GONK is a Linux kernel. It holds the device drivers. It holds a howl. It's isolated from Gaia, communicates through Gecko and BTG, and you could kind of call it, in a sense, a magic black box. It's isolated from the higher levels and it's all communicating through web APIs. So it's a core component that is adapted for differing chipsets as well, and we'll go into this a little bit more. So each device that you're going to have is going to really pretty much have its own version of GONK rolled onto it. So let's take a little bit of a deeper dive into it. So we're looking at some of the components in the GONK layer. What we can see is we've got the radio interface layer, the RIL, which interacts with the modem hardware in the phone. This consists of two components. So you've got the daemon and then you've also got the proxy. The proxy message is between the daemon and the BTG process. There is a media server in there which controls audio and video playback. Gecko communicates to the media server through the Android RPC mechanism and also a NetD process, aka the networking daemon, which then talks to the networking stack. Bluetooth and other service-level daemons providing access to the hardware capabilities. These are pretty much your common modules, but obviously there's going to be a lot more in there. The Linux kernel distro also utilizes libraries from Android, the GPS camera and some other open-source projects. LibUSB, BlueZ, et cetera, to name some through. And then we have the firmware and drivers at the lowest level. Now, how GONK handles a request? I think, cool. So as we discussed, Gaia speaks to Gecko. A single request from Gecko can trigger a complex series of operations initiated and managed by GONK and the device. In this example, what we're seeing here is a radio interface layer in GONK responsible for controlling the modem hardware that will dial through the requested number onto the radio interface daemon itself. The B2G process then communicates the dial request through the proxy, which forwards this onto the service-level daemon. The daemon controls the actual modem hardware and via the Linux kernel and any associated modem firmware, drivers and devices. The RLD sets up the modem and causes it to dial the number and any changes in the modem state, aka ringing, dialing, stopping the call, canceling, hanging up and then reported through the B2G process through the stack. So if we take a little bit more of a look into how they actually communicate. All right, so here we're actually looking at the full stack of layers. So as mentioned, Gaia is where the application will live. The app communicates to Gecko through the execution environment which in turn talks to the permissions manager, who is only able to access the web APIs to the underlying hardware. So it checks through the ACL, so you've got your access control list. It checks that you actually have the permissions of what credentials you're running, pass it through the web API, to the IR hardware, to the B2Gecko and then down into the GONK. GONK communicates to device. Now, the reason that you're looking at these all separate is because they really are separate layers in the sense that you're not going to ever get GONK going straight into Gaia. It does have to go through this full process. All right, so let's look at the how. So within GONK, it's a hardware abstraction layer. Now, this is one of the, called the porting layers of Gecko. It's C++ API. This hardware abstraction layer is not exposed directly to JavaScript, code into the Gecko for obvious security reasons. The sandbox implementation simply poxies requests by content process them and then forwards them onto the Gecko server process. The proxy requests are sent using the IPDL, which we will discuss later. So if we jump into having a look at our in-it process. So in-it process is basically stock Android. So the in-it RC is basically stock Android with patches to include things that are required to kickstart the Firefox OS. So they're very specific to Firefox OS. Therefore, device to device is going to really depend on the needs of the actual device. After the in-it process is running in GONK, handles... Sorry. Handles mounting required file, systems and spawn system services. After in-it is ran, a user space in-it process is launched. Once the in-it process is launched, the kernel handler system calls from the user space and interrupts from the hardware. After that, it stays around to serve as a process manager, which is very similar to other Unix-like operating systems in that sense. So the in-it D that you're seeing there So we have a look a little bit into the bootstrap. So execution always begins with the primary bootloader. From there, a succession of increasingly high-level bootloaders are called. The general system boot-up flow goes from the bootloaders in the kernel space to the in-it in-it native code to the B2G. It then spawns the system window manager and then executes the home screen. All your applications then run within the home screen as well there. So they're isolated there. When that runs, this process goes through, home screen is called, and that's the process that your apps are executed on top of. So I mentioned before, IPDL, and if you're not if you haven't kind of developed with iFox any on Mozilla, you might not be fully aware of it. It's the inter-process communication protocol definition language. It was developed by Mozilla and C++ code, and it's basically a way to pass secure processes and threads in a secure way. So app all apps communicate with the service-level daemons via the IPC. So now if we jump in and have a look into the IPC architecture. So in iFox OS, we have a multi-process architecture. As it means that each app is actually run in its own process. As you can see, there's a single parent process called B2G. The parent process spawns newer, which is the child, and newer then spawns the apps. As I mentioned, the default child process run with the most minimal set of privileges. So B2G parent has the higher privileges, it executes newer, newer then runs down to the apps, and that's where you're having those levels of permissions. When higher privileges are needed, you're going back up through to the B2G process and then back down to see if those are allowed to behave. Hopefully some of this is making a bit of sense. I'll pull it together in a minute. So IPC parent child relationships. So if you're familiar with using Unix sockets, then this system will not seem unfamiliar to you. iFox OS uses Unix sockets created with the socket pair system to call and send messages. The system calls send message and receive message each time. Each process has its own dedicated thread and handles that socket operations. This is called an IO loop. Each IO loop thread has a sound outgoing message queue. As you can see from there, all IPDL messages are sent between the parent and child endpoints, aka actors. An IPDL protocol declares how the app does communicate, and it declares the possible messages that may be sent in a state machine describing what messages are allowed to be sent back. So as we said before, the apps really only access via web APIs. Gecko is a sole gateway to the mobile device. So there's no native API, no backdoors, and the apps all run as we saw before in a sandbox mode. So this means that Gecko really does provide that sole gateway. So this kind of jumps us into looking into some sandboxing and the security. So we can see from this diagram that sandboxes use IPC to trust as a trust boundary for communications to the parent process. Each app, aka a child process, communicates to the parent process using the trust boundary. Fly Fox OS. And this is similar, so this parent process and how this trust boundary is happening with the IPDL, IPC and the sandboxing is similar, exactly the same as how Fly Fox OS runs on Linux. Sorry, Fly Fox desktop browser runs on Linux. Alright, so now we've kind of had our heads down to the bunch of things. Let's jump back into our layers again. So as we can see, the Gecko parent-child relationship is started at the higher levels. And note the communication to the lower levels need to go through the permissions manager to gain access to the lower levels in the Gecko layer. Like, hopefully not boring everybody. So what parts of the kernel? So, and I've got ace up wrong there, sorry. So basically it's pretty much an Android kernel. So it's got the users, as we said before, it's using Android libraries, it's got the GPS, it's using camera, etc. But it's also got an extra bunch of components in it. These changes are not upstreamed to the Android project, they're unique to the Fly Fox OS project. It is a very basic Linux kernel and it's, as I said, it's not the full Android, so it's done so as well to really provide a smaller memory footprint. Which is really important when you're running low-end devices, $25, $35 devices. So what is GONK in a sense, it's basically what we call our porting layer of GECO. GECO is full control over GONK, difference in the exposures of the interfaces. And that in saying that that there is a port of GECO to GONK just like there is a port of GECO to OSX as there is a port of GECO to Windows in the Firefox browser code. Since the Firefox OS project has full control over GONK, we expose interfaces to GONK to GECO that cannot be exposed on other systems and an example of this is the telephony stack. Obviously if you're running Firefox browser you don't need access to a telephony stack so where is in a mobile phone you do. So it's slightly different in that sense as to how the browser executes it. So GONK is covering under the Mozilla public license. Being mobile devices it also contains proprietary drivers as well. Vendors can modify the kernel. They can upstream if they choose. OEMs will also create as we said device drivers firmware and etc which will not be upstreamed they will be specific to the telecom provider, the device manufacturer. So implementing changes in GONK. So as we discussed certain aspects of the Firefox OS architecture and also certain components of GONK we could take a look at the process when people and companies need to make changes to GONK. When specific functionalities are required in GONK it needs to be added by the OEM the company, the human akaU. This means that GONK will need to be extended and the how files modified to expose new functionality to access device specific requirements. An important part of this process is what we went through before which is the IPC, the IPDL because that will need to be designed for when you're actually adding new changes in there. Integrating it into GECO. It shows how to have functionality not currently accessible via web APIs in GECO. So there's a particular thing that you want to get into there. So first you expose the functionality in GONK that's when you modify the GECO source to extend the web APIs. So you're adding those drivers sets and what you need into GONK itself but then you actually have to extend GECO to have those web APIs to be able to talk up through GAIA. Now I'm not really going to talk too much about licensing issues because it's not really a licensing talk but as we said there's proprietary code in there. OEMs must sign licensing agreements with the component suppliers. There's proprietary code in it which is unfortunately something you can't get away from when you're dealing with mobile phones but who is actually responsible for the GONK? So Mozilla is responsible for the GONK due to this Mozilla maintains the source repositories and any needed support files. It is maintained under as we said before the public license. Therefore you can fork it, you can clone it and you can do what you like to it. The upstream process is not as straightforward as one would like it to be though and this is due to the fact that there are also a lot of third party components and etc that cannot be included in the Mozilla repos. As with Android it is at the discretion of Mozilla if they wish to take up your code so it's not that you can't upstream things back to them. You can contact release managers and you can speak to them but it's not the simplest upstream process. So as we said it's pretty tricky to navigate the land of mobiles because of chipsets. So third parties in GONK you know really it's ensuring that, you've got to be really ensuring that seamless communication between GONK and the Gaia levels which is where you're looking at the IPDL and the IPC. So really in a sense falls to third parties to maintain their own stack. Brings us into the question of blockers. So your upstream process is not guaranteed there is proprietary drivers that will never see the light of the upstream which means that fragmentation starts to occur. Each LEM device or in a person can maintain their own fork or Firefox OS. So and fragmentation is a huge problem. It's a huge problem in the Android world. It's also becoming a really big problem in the Firefox OS world. So you're looking at probably about 60% of devices out there. At the last time I checked which was about four months ago that is still running 1.1 Mozilla itself is working on three. So to give you an idea 1.1 doesn't have copy and paste. So unfortunately it starts to become a bit of a thing where yes okay I've got my CT MoviStar device but MoviStar is only pushing 1.1 and it will be the discretion of MoviStar if they actually want to push down three. Mozilla is working with the Telcoms guys to get around that process and to look at ways of kind of alleviating a little bit of that. It's not the simplest thing. So which is what we said always limitations. The interesting thing about the Mozilla project is so if you're looking at Firefox OS if you look at Android I'm just taking a stab here but I'm going to say there's probably a good couple of hundred people probably thousands working on the support of that device. We had a team of six of us that were providing support and we had an army of volunteers. So it can be hard to provide support. It's really hard when you've got 60% of the people out there on a 1.1 and the problems that they're talking about have already been fixed in the newer versions there's not really too much you can do for them at that level. So it's frustrating. It's really frustrating because if you think of the end user who isn't necessarily technical they've got their phone, they're running 1.3 their friends got their device, they're running 3 their friend can copy and paste they can't they've got a better type interface than their friends I guess that's kind of where the frustration comes it but in saying that that's no difference to what happens in the Android marketplace as well. One thing and a really cool thing that you can do is you can make it what you want to, right? So it actually isn't too hard to flash a device. There is a lot of support and a lot of information out there that would tell you how to flash your own device. So if you do have 1.1 you can get onto the repose and upgrade that and flash that so as you said it's based on the Android kernel which is hopefully going to make it easier to support to existing device drivers firmware, service teams and other components supported device list can be found in the repo the B2G slash config.sh it's pretty much where all the list of devices there and if yours isn't there you can go in and add it yourself and you can add the drivers and etc you need. A great example of that is the APC project and I'll show you a little APC soon. How to contribute so everything is kept in Github so you can go into Github, you can fork it you can download it, you can contribute into it if you go into gong-misk it's pretty much the best place to go if you want to look specifically at gongfars cool toys and future projects so Mozilla is very heavily invested into Firefox OS so recently last year they said it partnership with Panasonic so Panasonic Smart TVs will be running Firefox OS there's an APC device that I've got there APC itself comes with a version of Firefox OS I've been using that at home as my main media centre there is some bugs and issues with that there's a repo for the APC if you can get on and you squash a bug they will send you an APC device which is pretty cool so more mobile platforms well choice is good being a monopoly is bad for everybody Linux was made from better devices so you know do we need there's always a question do we need another mobile platform yes we do need another mobile platform I'd like to see another 30 mobile platforms I don't see why choice is a bad thing I don't see why we need to have one, two or three if you really are into playing with embedded devices and wanting to have a go I would also tell you to check out the yokto project you can roll your own embedded Linux and you can start to kind of get around and play with the architecture set there Tizen this time I can actually get to say Tizen is going to be releasing Samsung is going to be releasing a Tizen device soon and straight away you're going to be able to run Android apps on the Tizen platform which kind of gets away the need of having a full Tizen marketplace there the other thing about the apps in Firefox OS as well as you can run them on your Android device so you can actually you've got an Android device you can go to the Firefox marketplace and you can run it on there what you will notice when you do that is because of how you're running it and because you're running it in a HTML5 space you're actually not accessing a lot of the permissions so you're bypassing that so your application then doesn't have access to the full stack in your Android phone so if you use Twitter from the Firefox OS marketplace you're not going to be giving it access to that full layer stack that you've got on Android but if you use the Android Twitter app you are so now I've really reached through that a bit quickly and I probably haven't made all the best sense so I'm going to kind of put out for questions I'm going to ask if people want me to explain a little bit more of the architecture go into the IPC a bit more or very very quickly sorry an off topic you mentioned scratch I'm really interested in that where can I catch up with you about that today where if you see me walking come and grab me and ask me would you be around yeah I'll be around but yeah so I want to keep the question to the Firefox OS and in regard to the problem of updating the device and the vendors don't you know update the devices Google has been getting around that by sort of fixing the sort of lower layers and then pushing all of the sort of user visible functionality into packages that they push out and control maybe that would be useful for Firefox OS as I said Mozilla is in I don't like as I said I was doing Firefox OS support and Mozilla the high levels of Mozilla are in communications and working out these things with the telecoms it's really only been around in the world for about a year or so so it's really kind of just picking up speed now and getting greater adoption so I think as you see that greater adoption and as it becomes a more important mobile player as well then you'll probably see the telecoms and that working a lot closer when I think of Mozilla I think about its commitment to work to control user control and such here you've described a platform that's very much based on proprietary drivers and proprietary code and facilitating that kind of setup and that leaves all kinds of pathologies a number of which you listed yourself and we've gotten around these sorts of issues in other markets when vendors insisted on free drivers for the hardware they were supporting why is Mozilla not doing that for Firefox OS and what is being done to get us away from this problem of binary blobs in our free systems? Same problem exists in the Android world right? Same problem exists in the Android world because it comes down to the device manufacturers themselves so there is really now I haven't looked at the full Tizen stack yet but I'm going to guarantee that there's proprietary code in that Tizen stack as well and it's just currently a big problem within the mobile world and a lot of it does come down to those device manufacturers and telecoms so it's a lot more I guess fragmented in that sense I can't speak for what Mozilla is doing personally to get around that because I'm really here to just talk to you and present the architecture it's yeah it's there's really not much I can say about that sorry Getting back to the architecture I hope it's not too an important question just in terms of the gecko and gong layers like gong keeps a lot of Android user space and in gecko things like the permission manager and other kind of abstractions seem very similar to the Android framework so I was wondering like how much of a win was it especially if you're already shipping and maintaining fennec and not able to make large reuse of the work you're doing with fennec and Firefox OS because you're not working to the Android layer like you're not using the functionality of the Android framework for things like IPC which you'd get for free if you kept at least part of the Android framework so I was wondering like how I'm trying to get I'm trying to see the question you're asking so I'm just wondering like how much I guess work goes into maintaining all the extra bits in the gecko layer and then I'm going to go back to Firefox OS which you don't need on other OS's that say fennec doesn't need because Android's framework provides all that so you're basically doubling up what the OS is on your desktop and Android framework only provides in the sense that there's a gecko port for Firefox OS there's a gecko port for your windows browser for your OSS for Linux etc so I'm not sure I'm kind of totally getting out of the mission manager. No and that's where it's different because it needs to be different because on an operating system level and etc you don't want to be accessing those lower level threads you don't need to be accessing that and you want to keep that everything fully away from that so that is where it is different in that sense of yeah it does and can get into the lower levels of that kernel which it's not doing on your operating system because it doesn't need to how hard is it to maintain or how much work goes into it the same way as porting the same way as you know there's a gecko port for windows there's a gecko port for like it's just yeah I think I don't know I didn't design the architecture so from an application developers perspective your code is all running in the JavaScript engine in the browser and so if I was to bundle up an app what's the contents of the app and like other tools in order to assist in building them like what does an application look like to be distributed either via the market or linked to from my web page okay so you're basically when you're writing the app there it's pretty much a html5 javascript css application so it is in a sense you're using full open web stand it's there so it's not like okay I'm developing for android I need to learn andro's codebase iOS I need to learn iOS's codebase et cetera so it's done in the way to lower the entry barriers as well so now all of a sudden all I need to do is equip you with html css and you can write an application that's going to sit on top of that and because you don't have to go through that marketplace as well it means that if I want to make my own to do app I can just quickly write an html5 to do app and push it onto my device so if you're providing a server yes you can exactly so you can run it on your desktop you can run it on a windows surface which actually has html5 so yeah it's not just restricting you to the Firefox OS so as I said right now you can get on your android get into the marketplace and start downloading applications and running them there and you will find the biggest difference you will find is that is the permissions that it's actually accessing in your phone and the other lovely thing that a lot of people love about it is there is an actual option in the operating system to say do not track I don't think any other mobile operating system has another question leading on from this it seems to me that this has the potential to be the perfect universal app platform for any phone like if you write an android app it only works on android you write a firefox OS app it can run on any phone that has firefox the only problem being like you said you lack access to those various APIs like location or I don't know whatever APIs on the phone so my question is are you going to develop firefox for android and for iOS and implement access to all of the phone APIs so that a firefox OS app has sort of equal status running on firefox OS or on android or on iOS so this could become a universal app platform with full access to all of those phone APIs. The awesome and lovely thing about Mozilla and firefox OS is that it's using open web standards so if Apple decides to implement HTML5 then you could run your app on that it's not that I think it's that you've misunderstood it a little bit in the sense that when you said you can't access location and GPS and etc you can and you are you're just accessing it through the gecko layer so it's a little bit different in the sense of and as we said because as I said before if you're wanting to add new things into it that's when you're going into gong you're going into the c++ that howl and you're going into those lower levels of additional things that you need there then you go into gecko and you expose those additional web API calls there so you do have that but as I said it is their HTML5 apps so you can run it across you mentioned for example that the twitter app the firefox OS twitter app running on android would not have the same access to APIs as the native android so what I mean by that is when you're running how does my twitter application need to have access to 25 different areas of my phone if you download a lot of these applications don't need the level of permissions when we're doing mobile app development we've come into this state of ask for every skill permission by default so a lot of android applications will ask you for everything by default not that they need it and it's also a problem when you're in the mobile app development world you're running that by default so it's not that you're not able to talk to the level you don't need to be accessing that you're running it's the same way as if you're in twitter on a web browser it doesn't need to go down and communicate with level levels of your kernel it's running in that user space that's where it needs to run so the user experience running native android twitter versus firefox OS twitter on android is the same user experience is the same you're not lacking anything no any other questions couple down there I'm sort of all new to this a number of questions pop up actually so let's say you're a web app trying to access something in the bluetooth stack has the api to that been standardised across the world like seeing what bluetooth mac addresses are out there that you can talk to what do you mean by that has the api be standardised across the world well okay our location api what position am I at now the web app wants to know that is that the same on all platforms I presume it's a javascript call is the parameter the same you're asking me to tell you if that's the same across all platforms it's not something that I could do because I haven't played with it across all mobile platforms well it's the same across all platforms but it's using the api so all the as we all know Mozilla is very strong in the web standards the other great thing is because Mozilla are Mozilla when they want to when they need some new stuff so there's been a lot of pushes that they've been pushing through with html5 etc to help and support the firefox os project as well and to help that standardisation so in that sense it's open standard code yes and your location and for example in the implementation of firefox os gps location etc at the lower gong is the same as android I guess that's why I chose something that wasn't location the first question is because I knew that was standardised it is I just wanted to make half comment and half answer question is that there are some api so for instance you might want access to the usb port to get an android you can't get it at the moment like there's a bug tracking that for web usb I think people started making a start on trying to define that as part of html5 but that's something like I think that's what you were talking about when you say if you want to add access to lower level things you can add it to gong and I guess do you need to define a web ideal for a new interface as well yes so you're designing so if we go back into so you do need to design that ipdl communication path yeah so you go as we said go into gong you're adding that into gong but you also do need to add and expose those web apis within gecko itself yes so you need to it's part of the parcel but that's also where if you interested in looking into it if you look into the ipdl and if you google up that on mazilla that'll kind of go through and explain it in a little bit more detail as well like how papers and everything are about that but that is the same way that's what firefox browser utilizes as well hopefully this is a bit more on topic it's more how it works the web apps I presume some of them have local data stores like if you're a contact app you store a whole list of them I'm not here to talk about web app development which is clearly what I put on the front of the talk is like this is not a talk about I'm not going to ask you about this is a talk about going to the architecture so yeah what I'm going to ask you about is how does permissions between getting that information go through your stack and permission manager so I've created a private data store I have another app that wants to access that private data how do you manage permissions how do I say app A is allowed to read my contacts which is managed by app B okay so if we're looking at it so as we said you're actually going to the permission manager in gecko and that's where the IPDL process comes into it as well and where we're talking about the newest spawns parent child spawns oops wrong one I've got to put it on here no so you beat everything the apps the way it's done is for the app to run with the minimal set of permissions that it needs so any request like that if it was going to want to do that then it would have to go back up to the B2G process and the permission staff would have to then come down through there and through the new R process as well so in a sense if that's not there in the B2G you're not going to get that access going across to it so the apps really do everything's really quite sandboxed and run with a very small set of permissions okay I think that's probably about all time we have for questions sadly but Amy you'll be around I'm sure people can track you down with hopefully it was a little bit worthwhile and sorry for being a little bit rushed on it all but yeah thank you