Civil society depends on the continuing ability of citizens to communicate with one another, without fear of interference, deprivation or eavesdropping. As the international political climate changes alongside that of our physical climatic environment, we must find ways to create mobile communications systems that are truly resilient and sustainable in the face of such shocks. We have therefore identified a number of freedoms that are required for resilient mobile phones: Energy, Communications, Security, Innovation, Maintenance and Scale-Dependency. These can be summarised as making it possible for people to create, maintain and develop mobile communications solutions, without requiring the capital and resources of a large company to do so. In this lecture I will explain why each of these is necessary, as well as describing how we are incorporating these principles into the MEGAphone open, resilient and secure smart-phone project. In the humanitiarian sector we talk about how without energy there is no communications, and without communications there is no organisation, and how without organisation people die. As we see increasing frequency of natural disasters, man-made disasters like wars and unrest, and the distressing intersection of these events, we have been convinced that we need to be able to create mobile communications devices that can not only survive in such events, but be sustained in the long term, and into what we call the coming Digital Winter. The Digital Winter is the situation where the freedoms to create and innovation digital systems will become impossible or highly limited due to any of various interrelated factors, such as further movement towards totalitarian governments, the failure of international supply systems (or their becoming so untrustworthy to be usable), the failure of various forms of critical infrastructure and so on. Fortunately the Digital Winter has not yet arrived, but the signs of the Digital Autumn are already upon us: The cold winds chilling our personal freedoms can already be felt in various places. Thus we have the imperative to act now, while the fruit of summer and autumn still hangs on the trees, so that we can make a harvest that will in the least sustain us through the Digital Winter with resilient, secure and sustainable communications systems, and hopefully either stave off the onset of the winter, bring it to a sooner end, and/or make the winter less bitter and destructive for the common person. It is in this context that we have begun thinking about what is necessary to achieve this, and have identified six freedoms that are required to not merely create digital solutions that can survive the Digital Winter, but hopefully allow such solutions to continue to be developed during the Digital Winter, so that we can continue to react to the storms that will come and the predators that will seek to devour our freedoms like hungry wolves. The six freedoms are: 1. Freedom from Energy Infrastructure, so that we cannot be deprived of the energy we need to communicate. 2. Freedom from Communications Infrastructure, so that we cannot be deprived of the communications we need to organise and sustain communities. 3. Freedom from depending on vendors for the security of our devices, so that we can patch security problems promptly as they emerge, so that we can sustain communications and privacy. 4. Freedom to continue to innovate and improve our digital artefacts and systems, so that we can react to emergy threats and opportunities. 5. Freedom to maintain our devices, both their hardware and software, so that our ability to communicate and organise our communities cannot be easily eroded by the passage of time. 6. Freedom from Scale-Dependency, so that individuals and small groups can fully enjoy the ability to communicate and exercise the preceding freedoms, without relying on large corporations and capital, and also allowing minimising of environmental impact. In this lecture I will explore these issues, as well as describe how we are putting them into practice to create truly resilient and sustainable mobile phones and similar devices, including in the MEGAphone open-source/open-hardware smart phone.
 Good evening. And welcome to day two of the congress. Our next speaker, Paul Gardner-Steven, is fighting for free, secure and resilient communications. He's known as the leader of the server project, building cell phone mesh networks, and also is the creator of the Mega65 computer that you can see right here. So he's going to tell us about his next project right now and also explore some issues that we face about building networks and keeping them secure and resilient. So please welcome Paul Gardner-Steven, creating resilient and sustainable mobile networks. Around the house. Okay. Thanks for coming along tonight. It's getting a little bit late in the night. Certainly for me it is past my normal bedtime. So apologies if I yawn. It's not that I'm bored or disengaged. It's just I flew in from Australia yesterday and still haven't really had enough sleep. But we should be fine. So cool. So what we can see here, we have the Mega65 prototype and we have a prototype of the megaphone and I'll talk about those two in a minute. So the entire presentation is actually going to be delivered with the technology that we're creating. So a bit of a dog food eating session for this kind of thing is a bit of a proof by example that we can actually do useful things with 8-bit systems. Because the whole pile of advantages when it comes to the security and digital sovereignty with that. So we can switch the screen to the screen. Super. Excellent. So we can have a look and make sure I've got the correct disk in there. Yes we do. We'll drop to C64 mode. And we'll load the... Oops, wrong one. Let's go. Fortunately we don't have to wait the long time. If I press and hold down the cap slot key the CPU runs at the full speed instead of normal speed. And so now it'll load up. It's Commodore 64 software right? So of course it has to be cracked. Even if I had to supply the original to the cracking crew because it's 2019. So we'll let that go because the graphics have changed a little bit as we go along and let the greets roll out there. So all of this has been created in FPGA. So we have complete sovereignty in that sense over the architecture so that we can really start trying to make systems that we have full control over from that full hardware layer and that are simple enough that we don't need to have a huge massive team of people to actually work on these things. A lot of what we're talking about here has been created in maybe three or four person years over the last few years. So it's quite possible to do a lot with these systems without needing to have the huge resources of a multinational company or something which is kind of key. So we'll do Mega 0, 36C3. OK, and I'll press F5 for presentation mode which really just hides the cursor. And then I can use my clicker. So we have moved, we'll switch the camera here for a moment. We switch the camera. Yep. So it's a genuine homemade Commodore 64 compatible joystick and it makes the most satisfying click noise when we use it. So if we can switch back to the slides, that will be great. Oh, yeah, super. Cool. So I am indeed going to be talking about creating resilient and sustainable mobile phones and hopefully that link when we already have the artifact there of the megaphone prototype and that will become a little bit clearer as we go through. So actually the last talk was kind of interesting talking about this whole, a different angle, this whole thing that communications has actually become really weaponized over the last decade or two in particular that we're seeing that where it used to be natural disasters that are the main problem, that now there is this whole problem of man-made disasters which is a major problem for us. And so we see internet shutdowns, communication shutdowns, we have surveillance happening in different places where it really oughtn't be happening. These state level actors that are very well resourced able to find zero-day exploits and the attack surface as we know in modern communications devices is simply huge. And so this is very asymmetric in the power equation between forces that seek to oppress people and the vulnerable people at the coal face who are just trying to get on with their lives and live good and decent lives and need communications to help protect themselves and enable that to happen. And that we're seeing that the value of communications is so well understood by these, you know, oppressing forces that it really has become quite a, you know, it's quite high up, there are a list of things to do. You know, you don't send the army in first to quiet and people down, you cut off their internet as the first thing. So this is part of the backdrop of what we see. And so what I would say is that the digital summer has actually finished. We're now in the digital autumn. We can see, like with farms and trees and things, there's still plenty of fruit to see in the early autumn, right? And there's lots on the ground. It feels like this time of plenty will continue. And we can all eat as we need, that there is enough more or less to go around. But the risk that we have is from this parable of the grasshopper and the ad. Who here knows the parable of the grasshopper and the ad? Hands right up, it's really hard for me to see up here. We'll swap and say who doesn't know. Okay, cool. I thought it was originally a German kind of proverb. This is the story of where the grasshopper is lounging around and enjoying the summer while the ants carry all the seeds back into the nest. And the ants tell the grasshopper, hey, you need to get some food and stuff and put away for the winter so that you can actually survive the winter. And the grasshopper is basically in denial about the fact that the season will change. And then of course the season changes, it snows and gets cold. And then the grasshopper goes knocking on the door of the ant hole. Not that they really have doors, but that's fine. It's like, oh, I'm starving and cold out here. And the ant is like, well, I told you so kind of thing. And I think actually in the end, it lets it in because we don't want to scare children too much with these stories. And so this is actually the challenge that we have. I love every time I come to these events, all the creativity that we see. We're enjoying the digital summer and all of the things that it's letting us create and the great open source software and tools and everything that's going on is absolutely fantastic. And we want that to be able to continue indefinitely. But we know that as we said, the chilling winds are beginning to come that tell us that unless we actually do something about it, that this isn't actually going to continue indefinitely. And just a statement that I really want to make here is this last dot point that I've got. The freedoms of the second half of the 20th century, post World War II, if you look at history, they are an aberration. To my knowledge, never before, and I fear perhaps never again, will we have that degree of personal liberty focus on individual freedom and agency and everything that was in this post-world era and is now starting to unwind. And starting to unwind back to the normal, totally asymmetric, well, to say sharing of power is the wrong word, it's the greedy collection of power and deprivation of the mass population from having anything resembling a fair share of what's going on. And so we have to act if we want for the digital summer to continue, or at worst, for the digital winter to be as short and shallow as we can have it. So that we can come back to a new digital summer. Because once we hit the digital winter, it will actually be too late. Because if we push this analogy, the digital winter is the time when there is no food on the tree. It isn't any longer possible, or at least practical, to create new technologies to enable us to feed our digital needs. And we can't plant any new crops, so to speak, until the digital spring comes again after that. And so the opportunity, like with the grasshopper, is now before the winter comes to say, right, what do we need to have in our store of technologies, our store of protocols, all of these different things so that when the digital winter comes, we don't starve. And fortunately, we can actually change the length of the digital winter. We can empower people so that the bitter cold of the digital winter is moderated, and that the spring can come as soon as it can. And the trouble that we have with this, we actually don't know when the digital winter will come exactly. We see these challenges around in the way that different governments and non-state actors as well, working in propaganda, and all of these things that are becoming, sadly, more intense and acute around us, we don't know when that tipping point will happen. But given the complexity of supply chains and things that are necessary in this, and I think Bunny was talking about that earlier today, that this is actually quite easy for it to actually quite quickly flip into the digital winter mode. And then, as with the real winter, at the very beginning of winter, there might still be enough to eat. But it gets harder and harder very rapidly, and if the winter gets too deep, then it's just not going to be possible to continue with these things. And so we've tried to think about what's needed to actually overcome this. What do we need focusing on mobile communications as a key piece of that? And there's a reason for that, in that it's a way that we can communicate, organize, you know, collectively protect communities against the threats that come in. If we look at things like the Great Hate of Earthquake just back in 2010, the breakdown of communications and law and order meant that there were quite horrible things going on within only about three days, actually, of the earthquake there. So there were militias that were basically robbing medical teams, trying to transport people between different hospitals, and there were much nastier things with, you know, gangs of people going around from village to village, basically doing whatever they want to whoever they want. It was really not cool. And so we want to avoid that kind of problem that comes when people are not able to collectively work together effectively as a community. And so the GPL for freedoms that we know from software, they're a great starting point. But I think actually we've seen enough things like with devolization and all of these sorts of other challenges that this is not sufficient when it comes to hardware. And there's actually some even more complicated things when you start talking about mobile phone kind of hardware as to how we can do that, which I'll talk about in a moment. But these are a starting point of what I've come up with as things that I see as being necessary. There's ample room for improvement. And in fact, with any of what we're trying to do in this space, we need folks to come along and help us. We can't do it alone. We need to work together so that we can help one another when the digital winter comes. So the first freedom is simply the freedom from energy infrastructure. We know critical infrastructure is disturbingly vulnerable, that the security of it is quite bad. But also you have these large centralized places that produce the energy that we need. And we see power cutoffs in Venezuela and all of these sorts of things regardless of who's actually doing it, whether it was sabotage or whether it was purposeful from the government. I don't know. It actually doesn't matter. The fact is it happens. But also, of course, in natural disaster, power goes out. Fortunately, this is actually one of the easiest things to solve. We just need to include some kind of alternative energy supply into the kind of devices that we're creating. So that could be solar panel on the back. Or you could have the Faraday, you shake it like a martini kind of thing to generate power or both, whatever you feel like. Or if you can find a good supply of ex-NASA radio isotope, then we'll generate this. That would also be fantastic. And we'll keep you warm through the winter as well. But if anyone has a supply of those, let me know. I'd love to hear. So then the second freedom is actually quite similar to the first. It's the realization that we need energy to communicate and communications to organize ourselves and be effective. And again, the communications infrastructure is in many ways actually even more fragile than the energy production infrastructure. It's much easier to guard a couple of power stations in a country than it is to guard every phone tower and all of the interconnecting links and all of these sorts of things between them. You know, communications deprivation is already being weaponized against the vulnerable around us. Again, fortunately, there's been a whole pile of work in this space. So the previous work I've done with the Servile Mesh and there's, you know, Fife-Hunk and, you know, a whole bunch of groups working on a whole bunch of different things in this kind of space for peer-to-peer secure authenticated communication. So yes, there's work to be done, but this is an area where there's actually already like the energy one. There's been quite a lot of work done that makes that quite feasible to work on. So then we start getting to some of the harder ones. We need to make sure that we are not dependent on, you know, the major vendors of our devices when it comes to the security of our devices. So this starts with simple things like that the GPL provides. So you know, full source code has to be available. But more than that, we actually have to make sure that we can actually exercise those rights in practice. So it needs to be simple enough that we can actually, you know, go right, okay, there's a security vulnerability in such and such, like, you know, Yusuke was talking about earlier today with some of the Bluetooth things, and then to actually be able to patch it yourself. It's quite obvious that this is not the case for whether it's firmware or whether it's the regular operating system on modern mobile phones. So who here has actually built Android from source themselves? Excellent, I expected to see a few folks here. Who's tried and gave up in disgust? Right, more hands. Yes, myself as well. Like, you know, I work on the server project and we do a whole pile of things and basically just, you know, after spending a number of hours on it, just went like, you know, this is actually, this is a lot of work for something that ought to be straightforward if we want to be able to make rapid progress. And so we want to have systems that are simple enough that we can patch, but in fact there's another really key advantage to simplicity that I'll probably come over a few times in this talk, and that is that simplicity reduces the attack surface. If we are in an asymmetric power environment where there are, whether they are state or non-state actors seeking to deprive vulnerable people of communications, they're going to have potentially the ability to put whole teams looking for vulnerabilities in software. In contrast, we might be lucky to have someone who's going to try and madly find when things are being exploited and to patch them. So we need to have ways around this kind of thing. And to my mind, reducing the attack surface is the only way that we can actually have any real hope of, you know, being able to keep up in that arms race of security. So freedom number four is related to this previous one. It's actually saying not only do we want to be able to patch it, we actually want to be able to change, enhance, do all of these things. And again, it comes back to the same basic need that the software is actually able to be compiled. And the hardware designs are simple enough that we can actually, you know, to work on these things so that we, again, not merely in theory have permission to innovate, but that it's in practice feasible to do so. And again, the simpler the system, the more probable it is that we can actually succeed in this kind of space. And then, you know, again, a lot of these are quite interrelated to this part of why I say it would actually be great to get feedback on how we might restructure these to make the boundaries really clear between these freedoms that we need. So we need the freedom to maintain the devices for the long run. So who here has or has had a fair phone, for example? I love the fair phone, by the way. Yep, a number of us. I've had one as well. And if you talk to the people at Fairphone, I think they have a team of a bunch of people just trying to maintain Android on the Fairphone 2, for example, and also now on the Fairphone 3 as it comes out. And this is actually really hard work. But again, the complexity and the barriers that are there make it really difficult to be able to just keep the thing running with the same hardware, let alone each time you want to target new hardware with new capabilities, this is just going to be, you know, as a community, we can probably do one or two devices if we kind of all collected our effort in, but to actually do it for devices that meet individual needs or appropriate for a particular area might have, as we say, a different energy source, someone might want to try putting some thermal electric thing or whatever, that at the moment, to do that with mobile phone hardware is just prohibitive in the complexity and the resourcing and effort that it would require. So we need to find solutions around this. And then again, related to that, overall, we have this problem of scale dependency. I think this is one of the really key things at the moment to make a mobile phone. You need to have a big enough market and you need to have a big enough enterprise and enough capital and all of the rest of it to actually be able to go through the very expensive process of, you know, designing the thing, getting injection molding tooling and all of that kind of thing made, that, you know, to do that for a modern phone, I suspect it's a few million euros to do it reasonably well. And if you did it on the cheap and skinny, it's probably still going to be something like a million euros to achieve. So we have to somehow break this down to make it feasible to do. And as I said earlier, simplicity is a key theme to my mind. But it's the only way I think that we can actually do it. So we've already talked about the challenges of just building an Android ROM, let alone modifying it to do new things in any kind of sophisticated way. And even if you do, the hardware is actually too complicated and there's a whole pile of trust issues around the complicated hardware. If you can't understand something by definition, it's a black box. And if it's a black box, by definition, you can't trust it because you don't know what's inside. So, you know, we have this point, again, in the digital winter, you don't want any black boxes or if you do, you want them very carefully monitored and managed. And so the system has to be not simple enough to make once. It needs to be simple enough that we can actually remake it again and again and again as we have need. It's a bit like the difference between a chainsaw and an axe, right? If you want to be in a remote area and have to be self-sufficient, much better to depend on axe to chop your wood because if you need to, you can make a new handle for your axe and, you know, with a bit more effort, you could do some very simple metallurgy and, you know, metal smelting with iron or if you happen to be lucky enough to have an area or copper or whatever. It's going to be a much easier proposition than having to do that and then somehow make fine machine tooling and making new chain parts and motor parts and all of this kind of thing. So it has to be, if it's going to be resilient and survivable, it has to be simple enough that you actually can build it with relatively simple tools going forward. Electronics is always going to be a bit challenged in this area because, you know, you need to do PCB fabrication, you need to get components and things, but we have to try and reduce the barriers as much as we can so that at least, for example, components scavenging, for example, might be an option. Or devices that will be available because they're still needed by other industries that have more protection as we head into a digital winter environment that we can take and repurpose that kind of hardware. So then this kind of leads into this tension then of saying, okay, if we make something which is simple enough, we know we as a community, we only have limited resources available to us to make this kind of resilient device, do we make one or do we all kind of like run off and make different kind of things? And I think this is a tension. I'm not going to claim that I know the absolute best setting for this. I think we need to have, as I say, kind of multiple germ lines so that if one system gets critically broken or proves to be ineffective and that there are others kind of in the wing that can kind of fill that niche in the environment, but we don't want to have so many that we actually don't get anywhere. And so this is a bit tricky. My gut feeling is making an initial device that can kind of demonstrate some of these kind of positive properties and then so other people will look at it and go like, well, that's really great. That's got us forward. But you know that was a really stupid design. I think this is a way better way to do it in the way that we have that freedom in the open source community to do is probably a pretty good way to do things. And I would say we're not yet at that end point of that proof of concept, but we're trying to move things forward to that and that point. So come actually to the megaphone that we're trying to create. And so in terms of what we've actually set out to do for the goals and kind of the methodology, we want something which is simple, secure, self-sufficient and survivable. A lot of the work that I do is, for example, with NGOs. We've worked with folks from Red Cross. We've worked with folks from the UN World Food Programme who, pardon me, interestingly are the distributors of communications in the UN cluster system for disasters because they kind of like hand out blankets and they hand out rice and things. Someone basically said to them, well, you should also be handing out the communications. And so that's just kind of how it's fell. And so, you know, and it needs to be able to do smart phony kind of things. Like we're great to have some navigation. It would be great to have in the disaster context the ability to fill in forms on the screen with a touch screen and the rest of it and have that uplink through. So for example, you think, you know, an Ebola outbreak in Africa, for example, to be able to collect, you know, that case information to track down the, you know, the case of heroes and all that kind of thing. You need communications that can work. Often these outbreaks happen in places where law and order and civil society is not really working because if it was, then they wouldn't have had the outbreak there. It would have been managed more effectively. And so you need this kind of, you know, dependable device that can work independent of everything else that's going on. And that might have to do software updates, for example, over a really expensive narrow band satellite link that might be, you know, tens of bytes per second or less. So that was kind of some of the, you know, the motivation around this to create it. And separately have been working on the Mega 65 project for a couple of years at that point. And it just kind of dawned on me that actually this kind of simple 8-bit architecture is powerful enough to actually be useful to do some things. And that's kind of, you know, why are we doing this, you know, the fun proof of, you know, proof by example, really of delivering the slides with this machine to show that you can do useful things if you write the code carefully and carefully written code is more likely to be verifiable and secure. And it's probably, I don't think you can get any simpler than an 8-bit system and still be useful. Like, I don't think we want to be trying to use an Intel 4004 derived 4-bit CPU to do things. By all means, if someone can find a way to do something with a system that's that simple and they can still do everything we need and it makes it even easier to verify, fantastic. My gut feeling is it would actually be worse on every point because the amount of work that you would have to do to do each useful thing, you end up with code which is actually larger in size. That I think my feeling is that the 8-bit architecture is about that sweet point. And so anyway, as a result of the Mega65 work, it's based directly on that. So the phone actually is a Mega65 in portable form and we'll show that in a little bit. And so we're getting towards that kind of proof of concept stage. We had the first phone calls back in Linux Conf. So if you kind of dig back through the video of that talk where with a much earlier prototype, we actually had people calling the machine, which is quite fun. And I'll talk a little bit later as well about some of the audio path kind of issues around that. So let's look at those six freedoms again now in what we're trying to do with the megaphone. So energy independence. The first step is we've got a filthy, great big battery. I hate it when phones go flat and when you're in a disaster zone or these kind of vulnerable situations you really don't want it going flat at the wrong time. So we've put a 32-watt hour lithium-ion phosphate battery that should have 2,000 full charge cycles in there. The device is about the size of a Nintendo Switch in terms of surface area. So putting high-performance solar cells like you would put on a solar racing car or on your roof, we can probably get about 7 watts with that. And you do the kind of math that's four or so hours of charge time. But we know in reality that the solar environment will often be much worse than that. It might be only 10%. It might only be 1% of that if you're talking about these kinds of latitudes under cloudy conditions. And so you really want to have the big battery and as big a solar panel as you can. And you want the power consumption to be as low as possible. So we've got CPLDs, which are kind of like little teeny tiny FPGAs that are managing the whole power environment and wake up the main FPGA only when something important needs to happen. So we believe with 32 watt hours we should be able to get about 1,000 hours standby with a 4G off-the-shelf cellular modem. And that's assuming that the solar panel was actually in a black box. Even the light here, if we had the 7 watt solar panel and had it sunny side up, we would be able to maintain charge indefinitely on the device because we only need to have about 8 milliwatts coming in. So we're talking about 1,000 of the capacity of the solar panel. So for communications, for independence, we really want as many possible ways to communicate as we can. And the naughty little things that we can't trust, in particular the cellular modem, we want to have a sandboxed and quarantined so that it can't spread its naughty plague of whatever vulnerabilities it has in there. Again, there are black box, we can't trust them, they're too hard for us to implement. And so this is kind of a decision that we've taken. We'd much rather have a fully open 4G modem. If someone makes one, fantastic, we'll incorporate it straight in because the system is designed to be easy to change. But in the meantime, we have to kind of do with what there is. The great thing is that these M.2 cellular modems are used in vending machines, in cars, in all sorts of things. So they're just the common as, again, if you had to scavenge them in the future, this would be quite feasible. And it also means we can upgrade. So we have two of these slots, so we could actually have a dual 5G Commodore 64. Because who wants to have to wait extra time when you're downloading your games, right? And 40 kilobytes can take a long time to download if you only got one 5G link, right? So we'll have two of them so we can do it in parallel. Because who wants to wait more than about four milliseconds to download new software? And again, limited communications availability in these kind of oppressive environments, this is actually key. You might only have short communications windows. So while it's a little bit tongue-in-cheek, it's not entirely. And of course, with several mesh, we've been doing UHF packet radio. So we've put in tri-band Lora compatible radios in there. Not Lora-wan. We're doing it fully decentralized. We're just sending out radio packets and listening in with the modules. We've also got ESP8266 Wi-Fi and some Bluetooth in there. So that's some other potential options. Acoustic networking, so we've got four microphones that are directly connected to our FPGA. So we can do crazy signal processing on that. And we've got a nice loud speaker that should work up into the ultrasonic range. So we could even have quite decent communications over 10 or so meters in the acoustic band. And there's a crazy bunch, and I've forgotten the name of the research group, that do air gap jumping. And they've done some quite crazy things with acoustics with, you know, if you leave your headphones plugged into your computer on your desk in a headphone jack, you can software reconfigure that and make that so it's a speaker and microphone. Because anyone that's interested in that, hold on a minute after and we can have a, and I can try and find the links for you. We've also got infrared LED. And so the idea with all of these kind of things and whatever else you can kind of do is that it should be really hard for an adversary to actually jam all of these things at the same time. You know, you might be able to do broadband RF jamming, but that's not going to stop the acoustics or the LED. And even if you can kind of make a lot of noise, it's going to be really hard to block, you know, the IR LED of people are kind of holding the devices near one another to do delay tolerant transfer. And of course, any other crazy things that people come up with, again, a simple system design that you can extend it easily yourself. Okay. Security independence. So the operating system runs in our little 8-bit CPU, which is basically a slightly enhanced version of the Commodore 64 CPU. It has an 8-bit hypervisor, which is 16 kilobytes in size, hardware limitation, because we don't want it getting bigger. If it gets 16K, then you have to throw some other things out and go, right, what does it actually really need to do so that you still have a system which is actually much more verifiable? And this kind of small software, it should be quite possible on this machine to run a simple C compiler, for example, to be able to compile the software that is actually running the core operating system. So we can have that whole complete off-grid operation. We've already talked a little bit about having the untrustable components fully sandboxed. So, for example, the cellular modems only have an AT command serial interface to the rest of the system. And so this is going to make it much harder for an adversary to work out how with a fully compromised cellular modem, you can compromise the rest of the system by giving presumably bogus responses to AT command requests. And because we know that's where the vulnerable point is, we can put a lot of effort in our software to really interrogate the command responses that are coming back and look for any AT command responses with semi-colon drop tables and all the rest of it in there. It should be pretty straightforward to pick up. So we also have an integrated hardware and software inspector so that you can real-time verify. So this is a little bit fun. So I can hit MegaTab. And so we call it Matrix Mode, for good reason. So the system is still running in the background. So the slides are still there. So I can go back to the previous slide. I can begin to say it was a joystick actually when I'm in there. There you go. I'll file a bug for that. But we can, if I go back into it, we can look at all of memory in real-time. So if you are truly paranoid and you're about to, for example, do some encrypted email on your digitally sovereign device, you could actually go into this, stop the CPU, and then inspect every byte of memory and compare it to your physical printout of the 30 or 40 kilobytes of your software and go, what the fuck is that? Well, you might, every time you might do half a kilobyte or something, right? And verify it so that progressively over time, you've actually verified that the system is always byte identical at that point in time to what it should be doing. And again, the simplicity, we only have one program running at a time. So you know exactly what the system is doing. We can task switch. We've got a built-in freeze cartridge. If I press the restore key, anyone who's used a Commodore 64 with an action replay will probably recognize the inspired format. And so that's our program. They're running with hardware thumbnail generation. The colors are a bit wrong. We need to fix that. But we've got other software that we've had running on it. And so if we wanted to break up the presentation with a quick game of Gyrus, for example, we can do that. I need to switch the joystick port. We can do that. And then we can go back and pretend that we weren't doing anything naughty at all. And of course, I forgot to save what I was doing first, right? So I have to load the program again. So that's my bad. But that's right, because reboot time is about two seconds. Oops. So the worst part now is that we actually, we haven't got a command to jump through the slides. And so it actually takes a little bit of time for it to render each slide as we go through. So that's my punishment for not saving first. But actually, what we might do, we'll skip that for the moment. And we're kind of at the right point anyway to talk about it, which is the audio powers in a mobile phone. This is a really important area to protect. So it's so important that it's the only diagram that I've put in the entire presentation. So at the top, we have a normal mobile phone. So basically, what we see is that the untrustable cellular modem is not merely untrustable. It's like an evil squid that has tentacles that reach into every part of your mobile phone that you really don't want it getting into. So it has the direct connection to your microphone and speaker. The normal CPU on your mobile phone usually has to say, pretty please, oh, untrustable, completely untrustworthy cellular modem, may I please have something which you're going to tell me is the audio that's coming in through the microphone. Whether or not it's actually the audio or not, that's a whole separate thing. They might be doing all manner of crazy things first because you can't tell because there's a big fat black box in the way. And then just to make sure that it can fully compromise what you're doing, often it's on the same memory bus. And so you might go, oh, I'm being all secret squirrel from the cellular modem and not asking it anything. And it's just quietly lifting the covers and looking at what you've got under them going like, oh, no, no, no, that bite's wrong. You really want that value in that bite. And likewise, the RAM and the storage. So the cellular modem can totally compromise your boot loader and all of that kind of stuff along the way. Just to say that that's not really a very survivable model or a very resilient model or a very secure model for a phone. So what we have instead is that we've basically put the fully untrustable thing completely out in its own little tiny shed. We've got the tin can and string between us and it with a very controlled interface. And the microphone and speaker, thank you very much, are directly connected to our FPGA. So we can do encryption at the microphone and decryption at the speaker. And the storage is secure, so we can even have massive one-time pad. So we could actually do SIG-SELY style, provably secure communications over distance, if you can set up the key material beforehand for one-time pad. So it's a radically different approach to what we see with devices out there at the moment. So we'll just get the last few slides up again. Oh, I never got them. Oops. So even simple software can have bugs, this is where we need many eyes. Think if I load this one first, yep, and now I can load the other one, because it just hadn't loaded the fonts in. Yep, cool. That's coming. Yep. And you can even use the joystick to move around in the text if you want to. Okay. So if we think then about this whole, what are we actually trying to achieve around this, and what are some of the things that we need? And the Commodore-derived 8-bit platform, to us, has a whole pile of advantages as a basis for doing this. Now, we could have done it with a completely different platform. We're thinking like RISC-5, for example, is a nice open platform, could be an idea. That could be that the RISC-5 CPU is actually too complicated to verify and trust yourself, is my kind of view, but I'm happy that other people might disagree with me. Multiple germ lines, totally different ways of doing things, so at least one of them keeps working at any point in time would be really, really good. And we're going to show you combination things as well. One of the things we're looking at is having, for example, a Raspberry Pi running the Pi port of Android that somebody else maintains, so I don't have to do it. And then having the 8-bit layer actually virtualizing all of the I.O. around that, including access to the SD card storage, including access to the screen. And this actually also makes it possible for us to make custom mobile devices for people living with disability. And actually, so that the Android, again, is easy to maintain because we don't even have to recompile it. We can just get the standard version and then make it think it's got a normal touchscreen when in actual fact it might have some completely different input method going on. So there's a bunch of advantages, and I've run out of the official time that I allotted, so I'll quickly go through and then we'll go into questions. So the 64 platform is really well documented, so there's a whole pile of tools and everything, programming languages, so this is pretty straightforward to go through. We've already talked about capability maintenance. Again, so there's actually another key point, making the hardware big actually is a massive advantage because then we can do normal PCP fabrication. We don't have to do any BGA part placement, which is a real pain to do in your home oven, it is possible, but you don't want to have to learn how to do it in the digital winter. And yet it's actually this kind of similar size to existing kind of devices out there. So there's a bunch of advantages with that. There's a whole pile of different things that we really would like some folks to help us with to try and get this finished and out there for people to try out and to be able to mature it and make it work. So it doesn't matter whether you ever program an 8-bit computer or have ever done any FPGA work or PCB work or whatever, there's lots of space for people to join in what is quite, we think it's actually both an important and actually a really fun and enjoyable project to work on. And so really I just want to finish by saying that I think as I was thinking about this talk and preparing for it, I think actually it is a call to action. The digital autumn has begun. Digital winter is on its way. We don't know when it's going to come and it might come a lot quicker than we would really like it to come. Myself and the people who are already working on the project, we can't do everything alone. We're doing what we can. We're going to try and organize another event in early April up in Berlin. But there's no need to wait for that to get involved. We'll be around at the vintage computer area if anyone wants to come and have a look or ask anything about how you might get involved or just play around with the platform. It's quite fun to use. And yeah, we'll leave it at that point. So any questions would be really welcome. That was incredible. You have the best presenting set up that I've ever seen at the Congress. Thank you. The joystick is amazing. And the joysticks also open source hardware. I can give you the plans to make one of those yourself from parts. It's a spare joystick part for arcade games, basically. Yes, please. Yeah. Okay, we're taking questions. I remind you, we have six microphones in the audience. We also have the amazing signal angel that's going to relay questions from the Internet. And we're going to take one right now. Okay, so you already talked about some events, but maybe can you bit more elaborate on how you're planning to involve the community? Okay, so how are we going to involve the community? Basically any way the community would like to be involved, the moment in terms of with the phone is myself and kind of working at a university. And we have kind of a couple of part-time students working on things. So the bus number is disturbingly near one at the moment. So there's Ample Scope to help. We've got a few other people who are helping with the Mega 65 project itself. And so there's obviously this crossover in that. But what would be really great would be to find, for example, a couple of people who are willing to work on software, primarily coding in C. So you don't even have to know any 6502 assembler to begin with, to do things like finishing off the dialer software and things that we demonstrated back in January and get it all working so we can actually walk around with a pair of large plastic bricks by our heads talking on the phones that we've actually created. That would be a really great way to get some initial forward movement. And then things like case design. There's a whole bunch of stuff that we'd welcome involvement on. Thank you. Do we have more from the Signal Angels? Yes, we do. So OK. There's a question, when a prototype will be available? OK. When a prototype will be available, I'm happy to give out blank PCBs or post them to people. So I've got to actually pack them with me. We've got the next prototype is actually being built at the moment. So these can be built for about 400 euros at the moment. So you can buy five of these instead of an iPhone. So it's economically survivable as well in comparison. It's actually one of the really quite funny things is we're kind of making this and going like a few person years of effort and we can already make a mobile phone. OK, it's not as small and schmick, but it's got a joystick port. Does your iPhone have a joystick port? So it's amazing what we've actually been able to do quite quickly. So it's the kind of project where if we do have people kind of come in to help us, by next Congress, we ought to have people running around with megaphones and being able to communicate in fun and independent kind of ways. So yeah. Thank you. Microphone one, please. Sure. Thanks for a cool talk. And I have another question because you want to reduce black boxes, but what's about encryption because it's really complex and how do you plan to reduce this black box? OK, so an excellent question. So the best encryption there is is actually the simplest. It's called one time pad. So if you can actually meet with people. So again, if we're talking about focusing on supporting local communities, well another, if you get your megaphone and the other person's megaphone and you come in infrared range, for example, and then you shake them like martinis to generate some random data and you do that until you've decided you've got enough one time pad and that one time pad is secure enough in your device, then actually like X or is pretty easy to debug, right? Thank you. Microphone number three. So you talked about the form factor right now, the Nintendo switch. Yep. Do you have plans on going smaller than that? More like a classic mobile phone? Yeah. I think it's actually quite possible. So this is, if you like, the first version is this one. So you can see it's about five centimeters thick. The second one, we think we can get down to about four centimeters thick, but it's otherwise the same size as PCB. We've got a student at the moment who's going to try and work on making one that's about the size of only the screen, still probably about four centimeters thick. And we think that that's going to be quite, the PCB layout, he's basically been cursing me for the last three months to try and get all the tracks routing without it needing to be a 15 layer sponge-tort kind of PCB, but that should be quite possible to do. And again, that's the kind of thing, once you've got a working prototype, then some people are like, okay, we're going to be on the miniaturization team to try and make something which is even smaller. But there's always trade-offs in these things. Again, the smaller you make it, the less solar panel you can have on the back. So there's kind of these things. But certainly trying to make it as thin as we can, I think, makes a whole pile of sense. Honestly, you can make it smaller, but I don't think you should because when the zombie apocalypse happens, it's a communication tool and a weapon. Yeah, exactly. That's right. It's kind of, you know, exactly. Or you can use a full-size one as well, right? It's kind of got, you know, quite a nice solid metal keyboard in there as well. A question from the internet, please. Sure. So what do you think about the OpenMoco phone? The OpenMoco phone. So I'm trying to remember the details about those. I mean, the whole, again, everything that's being done on all of these fronts to make fully open devices with as few black boxes as possible is fantastic. So as I say, if OpenMoco can make an M.2 form factor cellular modem that we can put in the megaphone, I would be so, so happy. But we can do a whole pile of stuff while we're waiting for that to happen. Thank you. We actually had a talk yesterday about from one of the people behind the OpenMoco. So you can watch the recording if you want. Next question, microphone one. Sure. Hey, thank you for the great talk. I was interested in the Mega65 itself. Is that available? Is it sold? Yes. Okay, so the two most common questions we have about the Mega65 is, can I buy one now and how much does it cost? Unfortunately, the answer to both of those is we don't yet know exactly. It will be a three-digit number in euros for the price. This is pretty certain. But at the moment, our big challenge is we, so this one is, it's a prototype made with vacuum form molding. So each case costs upwards of 500 euros for the case. This is not really sustainable. So we know we need to make injection molding tooling for that. And so the guys from the German part of the Mega65 team are running a fundraiser. I just said to be a little bit careful with that, is that Australian law for fundraising is a bit weird. So I am not doing any fundraising. Some people here in Germany are doing some fundraising to try and raise the money for the mold. So if you look at mega65.org, you can find out what they're doing in that space and have a look at that. Thank you. Do we have more internet questions? No? Cool. Cool. I think that's it. So thank you again for the wonderful talk. My pleasure. Thank you. Thank you.
 Good evening.  And welcome to day two of the congress.  Our next speaker, Paul Gardner-Steven, is fighting for free, secure and resilient communications.  He's known as the leader of the server project, building cell phone mesh networks, and also  is the creator of the Mega65 computer that you can see right here.  So he's going to tell us about his next project right now and also explore some issues that  we face about building networks and keeping them secure and resilient.  So please welcome Paul Gardner-Steven, creating resilient and sustainable mobile networks.  Around the house.  Okay.  Thanks for coming along tonight.  It's getting a little bit late in the night.  Certainly for me it is past my normal bedtime.  So apologies if I yawn.  It's not that I'm bored or disengaged.  It's just I flew in from Australia yesterday and still haven't really had enough sleep.  But we should be fine.  So cool.  So what we can see here, we have the Mega65 prototype and we have a prototype of the  megaphone and I'll talk about those two in a minute.  So the entire presentation is actually going to be delivered with the technology that we're  creating.  So a bit of a dog food eating session for this kind of thing is a bit of a proof by example  that we can actually do useful things with 8-bit systems.  Because the whole pile of advantages when it comes to the security and digital sovereignty  with that.  So we can switch the screen to the screen.  Super.  Excellent.  So we can have a look and make sure I've got the correct disk in there.  Yes we do.  We'll drop to C64 mode.  And we'll load the...  Oops, wrong one.  Let's go.  Fortunately we don't have to wait the long time.  If I press and hold down the cap slot key the CPU runs at the full speed instead of normal  speed.  And so now it'll load up.  It's Commodore 64 software right?  So of course it has to be cracked.  Even if I had to supply the original to the cracking crew because it's 2019.  So we'll let that go because the graphics have changed a little bit as we go along and  let the greets roll out there.  So all of this has been created in FPGA.  So we have complete sovereignty in that sense over the architecture so that we can really  start trying to make systems that we have full control over from that full hardware  layer and that are simple enough that we don't need to have a huge massive team of people  to actually work on these things.  A lot of what we're talking about here has been created in maybe three or four person  years over the last few years.  So it's quite possible to do a lot with these systems without needing to have the huge resources  of a multinational company or something which is kind of key.  So we'll do Mega 0, 36C3.  OK, and I'll press F5 for presentation mode which really just hides the cursor.  And then I can use my clicker.  So we have moved, we'll switch the camera here for a moment.  We switch the camera.  Yep.  So it's a genuine homemade Commodore 64 compatible joystick and it makes the most satisfying  click noise when we use it.  So if we can switch back to the slides, that will be great.  Oh, yeah, super.  Cool.  So I am indeed going to be talking about creating resilient and sustainable mobile phones and  hopefully that link when we already have the artifact there of the megaphone prototype  and that will become a little bit clearer as we go through.  So actually the last talk was kind of interesting talking about this whole, a different angle,  this whole thing that communications has actually become really weaponized over the  last decade or two in particular that we're seeing that where it used to be natural disasters  that are the main problem, that now there is this whole problem of man-made disasters  which is a major problem for us.  And so we see internet shutdowns, communication shutdowns, we have surveillance happening in  different places where it really oughtn't be happening.  These state level actors that are very well resourced able to find zero-day exploits and  the attack surface as we know in modern communications devices is simply huge.  And so this is very asymmetric in the power equation between forces that seek to oppress  people and the vulnerable people at the coal face who are just trying to get on with their  lives and live good and decent lives and need communications to help protect themselves  and enable that to happen.  And that we're seeing that the value of communications is so well understood by these, you know, oppressing  forces that it really has become quite a, you know, it's quite high up, there are a  list of things to do.  You know, you don't send the army in first to quiet and people down, you cut off their  internet as the first thing.  So this is part of the backdrop of what we see.  And so what I would say is that the digital summer has actually finished.  We're now in the digital autumn.  We can see, like with farms and trees and things, there's still plenty of fruit to see  in the early autumn, right?  And there's lots on the ground.  It feels like this time of plenty will continue.  And we can all eat as we need, that there is enough more or less to go around.  But the risk that we have is from this parable of the grasshopper and the ad.  Who here knows the parable of the grasshopper and the ad?  Hands right up, it's really hard for me to see up here.  We'll swap and say who doesn't know.  Okay, cool.  I thought it was originally a German kind of proverb.  This is the story of where the grasshopper is lounging around and enjoying the summer  while the ants carry all the seeds back into the nest.  And the ants tell the grasshopper, hey, you need to get some food and stuff and put away  for the winter so that you can actually survive the winter.  And the grasshopper is basically in denial about the fact that the season will change.  And then of course the season changes, it snows and gets cold.  And then the grasshopper goes knocking on the door of the ant hole.  Not that they really have doors, but that's fine.  It's like, oh, I'm starving and cold out here.  And the ant is like, well, I told you so kind of thing.  And I think actually in the end, it lets it in because we don't want to scare children  too much with these stories.  And so this is actually the challenge that we have.  I love every time I come to these events, all the creativity that we see.  We're enjoying the digital summer and all of the things that it's letting us create  and the great open source software and tools and everything that's going on is absolutely  fantastic.  And we want that to be able to continue indefinitely.  But we know that as we said, the chilling winds are beginning to come that tell us that  unless we actually do something about it, that this isn't actually going to continue  indefinitely.  And just a statement that I really want to make here is this last dot point that I've  got.  The freedoms of the second half of the 20th century, post World War II, if you look at  history, they are an aberration.  To my knowledge, never before, and I fear perhaps never again, will we have that degree  of personal liberty focus on individual freedom and agency and everything that was in this  post-world era and is now starting to unwind.  And starting to unwind back to the normal, totally asymmetric, well, to say sharing of  power is the wrong word, it's the greedy collection of power and deprivation of the  mass population from having anything resembling a fair share of what's going on.  And so we have to act if we want for the digital summer to continue, or at worst, for the digital  winter to be as short and shallow as we can have it.  So that we can come back to a new digital summer.  Because once we hit the digital winter, it will actually be too late.  Because if we push this analogy, the digital winter is the time when there is no food on  the tree.  It isn't any longer possible, or at least practical, to create new technologies to enable  us to feed our digital needs.  And we can't plant any new crops, so to speak, until the digital spring comes again after  that.  And so the opportunity, like with the grasshopper, is now before the winter comes to say, right,  what do we need to have in our store of technologies, our store of protocols, all of these different  things so that when the digital winter comes, we don't starve.  And fortunately, we can actually change the length of the digital winter.  We can empower people so that the bitter cold of the digital winter is moderated, and that  the spring can come as soon as it can.  And the trouble that we have with this, we actually don't know when the digital winter  will come exactly.  We see these challenges around in the way that different governments and non-state actors  as well, working in propaganda, and all of these things that are becoming, sadly, more  intense and acute around us, we don't know when that tipping point will happen.  But given the complexity of supply chains and things that are necessary in this, and  I think Bunny was talking about that earlier today, that this is actually quite easy for  it to actually quite quickly flip into the digital winter mode.  And then, as with the real winter, at the very beginning of winter, there might still  be enough to eat.  But it gets harder and harder very rapidly, and if the winter gets too deep, then it's  just not going to be possible to continue with these things.  And so we've tried to think about what's needed to actually overcome this.  What do we need focusing on mobile communications as a key piece of that?  And there's a reason for that, in that it's a way that we can communicate, organize, you  know, collectively protect communities against the threats that come in.  If we look at things like the Great Hate of Earthquake just back in 2010, the breakdown  of communications and law and order meant that there were quite horrible things going  on within only about three days, actually, of the earthquake there.  So there were militias that were basically robbing medical teams, trying to transport  people between different hospitals, and there were much nastier things with, you know,  gangs of people going around from village to village, basically doing whatever they  want to whoever they want.  It was really not cool.  And so we want to avoid that kind of problem that comes when people are not able to collectively  work together effectively as a community.  And so the GPL for freedoms that we know from software, they're a great starting point.  But I think actually we've seen enough things like with devolization and all of these sorts  of other challenges that this is not sufficient when it comes to hardware.  And there's actually some even more complicated things when you start talking about mobile  phone kind of hardware as to how we can do that, which I'll talk about in a moment.  But these are a starting point of what I've come up with as things that I see as being  necessary.  There's ample room for improvement.  And in fact, with any of what we're trying to do in this space, we need folks to come  along and help us.  We can't do it alone.  We need to work together so that we can help one another when the digital winter comes.  So the first freedom is simply the freedom from energy infrastructure.  We know critical infrastructure is disturbingly vulnerable, that the security of it is quite  bad.  But also you have these large centralized places that produce the energy that we need.  And we see power cutoffs in Venezuela and all of these sorts of things regardless of  who's actually doing it, whether it was sabotage or whether it was purposeful from the government.  I don't know.  It actually doesn't matter.  The fact is it happens.  But also, of course, in natural disaster, power goes out.  Fortunately, this is actually one of the easiest things to solve.  We just need to include some kind of alternative energy supply into the kind of devices that  we're creating.  So that could be solar panel on the back.  Or you could have the Faraday, you shake it like a martini kind of thing to generate  power or both, whatever you feel like.  Or if you can find a good supply of ex-NASA radio isotope, then we'll generate this.  That would also be fantastic.  And we'll keep you warm through the winter as well.  But if anyone has a supply of those, let me know.  I'd love to hear.  So then the second freedom is actually quite similar to the first.  It's the realization that we need energy to communicate and communications to organize  ourselves and be effective.  And again, the communications infrastructure is in many ways actually even more fragile  than the energy production infrastructure.  It's much easier to guard a couple of power stations in a country than it is to guard  every phone tower and all of the interconnecting links and all of these sorts of things between  them.  You know, communications deprivation is already being weaponized against the vulnerable around  us.  Again, fortunately, there's been a whole pile of work in this space.  So the previous work I've done with the Servile Mesh and there's, you know, Fife-Hunk and,  you know, a whole bunch of groups working on a whole bunch of different things in this  kind of space for peer-to-peer secure authenticated communication.  So yes, there's work to be done, but this is an area where there's actually already  like the energy one.  There's been quite a lot of work done that makes that quite feasible to work on.  So then we start getting to some of the harder ones.  We need to make sure that we are not dependent on, you know, the major vendors of our devices  when it comes to the security of our devices.  So this starts with simple things like that the GPL provides.  So you know, full source code has to be available.  But more than that, we actually have to make sure that we can actually exercise those rights  in practice.  So it needs to be simple enough that we can actually, you know, go right, okay, there's  a security vulnerability in such and such, like, you know, Yusuke was talking about earlier  today with some of the Bluetooth things, and then to actually be able to patch it yourself.  It's quite obvious that this is not the case for whether it's firmware or whether it's  the regular operating system on modern mobile phones.  So who here has actually built Android from source themselves?  Excellent, I expected to see a few folks here.  Who's tried and gave up in disgust?  Right, more hands.  Yes, myself as well.  Like, you know, I work on the server project and we do a whole pile of things and basically  just, you know, after spending a number of hours on it, just went like, you know, this  is actually, this is a lot of work for something that ought to be straightforward if we want  to be able to make rapid progress.  And so we want to have systems that are simple enough that we can patch, but in fact there's  another really key advantage to simplicity that I'll probably come over a few times in  this talk, and that is that simplicity reduces the attack surface.  If we are in an asymmetric power environment where there are, whether they are state or  non-state actors seeking to deprive vulnerable people of communications, they're going to  have potentially the ability to put whole teams looking for vulnerabilities in software.  In contrast, we might be lucky to have someone who's going to try and madly find when things  are being exploited and to patch them.  So we need to have ways around this kind of thing.  And to my mind, reducing the attack surface is the only way that we can actually have  any real hope of, you know, being able to keep up in that arms race of security.  So freedom number four is related to this previous one.  It's actually saying not only do we want to be able to patch it, we actually want to  be able to change, enhance, do all of these things.  And again, it comes back to the same basic need that the software is actually able to  be compiled.  And the hardware designs are simple enough that we can actually, you know, to work on  these things so that we, again, not merely in theory have permission to innovate, but  that it's in practice feasible to do so.  And again, the simpler the system, the more probable it is that we can actually succeed  in this kind of space.  And then, you know, again, a lot of these are quite interrelated to this part of why  I say it would actually be great to get feedback on how we might restructure these to make  the boundaries really clear between these freedoms that we need.  So we need the freedom to maintain the devices for the long run.  So who here has or has had a fair phone, for example?  I love the fair phone, by the way.  Yep, a number of us.  I've had one as well.  And if you talk to the people at Fairphone, I think they have a team of a bunch of people  just trying to maintain Android on the Fairphone 2, for example, and also now on the Fairphone  3 as it comes out.  And this is actually really hard work.  But again, the complexity and the barriers that are there make it really difficult to  be able to just keep the thing running with the same hardware, let alone each time you  want to target new hardware with new capabilities, this is just going to be, you know, as a community,  we can probably do one or two devices if we kind of all collected our effort in, but  to actually do it for devices that meet individual needs or appropriate for a particular area  might have, as we say, a different energy source, someone might want to try putting  some thermal electric thing or whatever, that at the moment, to do that with mobile phone  hardware is just prohibitive in the complexity and the resourcing and effort that it would  require.  So we need to find solutions around this.  And then again, related to that, overall, we have this problem of scale dependency.  I think this is one of the really key things at the moment to make a mobile phone.  You need to have a big enough market and you need to have a big enough enterprise and enough  capital and all of the rest of it to actually be able to go through the very expensive process  of, you know, designing the thing, getting injection molding tooling and all of that  kind of thing made, that, you know, to do that for a modern phone, I suspect it's a  few million euros to do it reasonably well.  And if you did it on the cheap and skinny, it's probably still going to be something  like a million euros to achieve.  So we have to somehow break this down to make it feasible to do.  And as I said earlier, simplicity is a key theme to my mind.  But it's the only way I think that we can actually do it.  So we've already talked about the challenges of just building an Android ROM, let alone  modifying it to do new things in any kind of sophisticated way.  And even if you do, the hardware is actually too complicated and there's a whole pile of  trust issues around the complicated hardware.  If you can't understand something by definition, it's a black box.  And if it's a black box, by definition, you can't trust it because you don't know what's  inside.  So, you know, we have this point, again, in the digital winter, you don't want any black  boxes or if you do, you want them very carefully monitored and managed.  And so the system has to be not simple enough to make once.  It needs to be simple enough that we can actually remake it again and again and again  as we have need.  It's a bit like the difference between a chainsaw and an axe, right?  If you want to be in a remote area and have to be self-sufficient, much better to depend  on axe to chop your wood because if you need to, you can make a new handle for your axe  and, you know, with a bit more effort, you could do some very simple metallurgy and,  you know, metal smelting with iron or if you happen to be lucky enough to have an area  or copper or whatever.  It's going to be a much easier proposition than having to do that and then somehow make  fine machine tooling and making new chain parts and motor parts and all of this kind  of thing.  So it has to be, if it's going to be resilient and survivable, it has to be simple enough  that you actually can build it with relatively simple tools going forward.  Electronics is always going to be a bit challenged in this area because, you know, you need to  do PCB fabrication, you need to get components and things, but we have to try and reduce  the barriers as much as we can so that at least, for example, components scavenging,  for example, might be an option.  Or devices that will be available because they're still needed by other industries that  have more protection as we head into a digital winter environment that we can take and repurpose  that kind of hardware.  So then this kind of leads into this tension then of saying, okay, if we make something  which is simple enough, we know we as a community, we only have limited resources available to  us to make this kind of resilient device, do we make one or do we all kind of like run  off and make different kind of things?  And I think this is a tension.  I'm not going to claim that I know the absolute best setting for this.  I think we need to have, as I say, kind of multiple germ lines so that if one system  gets critically broken or proves to be ineffective and that there are others kind of in the wing  that can kind of fill that niche in the environment, but we don't want to have so many that we  actually don't get anywhere.  And so this is a bit tricky.  My gut feeling is making an initial device that can kind of demonstrate some of these  kind of positive properties and then so other people will look at it and go like, well,  that's really great.  That's got us forward.  But you know that was a really stupid design.  I think this is a way better way to do it in the way that we have that freedom in the  open source community to do is probably a pretty good way to do things.  And I would say we're not yet at that end point of that proof of concept, but we're  trying to move things forward to that and that point.  So come actually to the megaphone that we're trying to create.  And so in terms of what we've actually set out to do for the goals and kind of the methodology,  we want something which is simple, secure, self-sufficient and survivable.  A lot of the work that I do is, for example, with NGOs.  We've worked with folks from Red Cross.  We've worked with folks from the UN World Food Programme who, pardon me, interestingly  are the distributors of communications in the UN cluster system for disasters because  they kind of like hand out blankets and they hand out rice and things.  Someone basically said to them, well, you should also be handing out the communications.  And so that's just kind of how it's fell.  And so, you know, and it needs to be able to do smart phony kind of things.  Like we're great to have some navigation.  It would be great to have in the disaster context the ability to fill in forms on the  screen with a touch screen and the rest of it and have that uplink through.  So for example, you think, you know, an Ebola outbreak in Africa, for example, to be able  to collect, you know, that case information to track down the, you know, the case of heroes  and all that kind of thing.  You need communications that can work.  Often these outbreaks happen in places where law and order and civil society is not really  working because if it was, then they wouldn't have had the outbreak there.  It would have been managed more effectively.  And so you need this kind of, you know, dependable device that can work independent of everything  else that's going on.  And that might have to do software updates, for example, over a really expensive narrow  band satellite link that might be, you know, tens of bytes per second or less.  So that was kind of some of the, you know, the motivation around this to create it.  And separately have been working on the Mega 65 project for a couple of years at that point.  And it just kind of dawned on me that actually this kind of simple 8-bit architecture is powerful  enough to actually be useful to do some things.  And that's kind of, you know, why are we doing this, you know, the fun proof of, you know,  proof by example, really of delivering the slides with this machine to show that you  can do useful things if you write the code carefully and carefully written code is more  likely to be verifiable and secure.  And it's probably, I don't think you can get any simpler than an 8-bit system and still  be useful.  Like, I don't think we want to be trying to use an Intel 4004 derived 4-bit CPU to do  things.  By all means, if someone can find a way to do something with a system that's that simple  and they can still do everything we need and it makes it even easier to verify, fantastic.  My gut feeling is it would actually be worse on every point because the amount of work  that you would have to do to do each useful thing, you end up with code which is actually  larger in size.  That I think my feeling is that the 8-bit architecture is about that sweet point.  And so anyway, as a result of the Mega65 work, it's based directly on that.  So the phone actually is a Mega65 in portable form and we'll show that in a little bit.  And so we're getting towards that kind of proof of concept stage.  We had the first phone calls back in Linux Conf.  So if you kind of dig back through the video of that talk where with a much earlier prototype,  we actually had people calling the machine, which is quite fun.  And I'll talk a little bit later as well about some of the audio path kind of issues around  that.  So let's look at those six freedoms again now in what we're trying to do with the  megaphone.  So energy independence.  The first step is we've got a filthy, great big battery.  I hate it when phones go flat and when you're in a disaster zone or these kind of vulnerable  situations you really don't want it going flat at the wrong time.  So we've put a 32-watt hour lithium-ion phosphate battery that should have 2,000 full charge  cycles in there.  The device is about the size of a Nintendo Switch in terms of surface area.  So putting high-performance solar cells like you would put on a solar racing car or on  your roof, we can probably get about 7 watts with that.  And you do the kind of math that's four or so hours of charge time.  But we know in reality that the solar environment will often be much worse than that.  It might be only 10%.  It might only be 1% of that if you're talking about these kinds of latitudes under cloudy  conditions.  And so you really want to have the big battery and as big a solar panel as you can.  And you want the power consumption to be as low as possible.  So we've got CPLDs, which are kind of like little teeny tiny FPGAs that are managing  the whole power environment and wake up the main FPGA only when something important needs  to happen.  So we believe with 32 watt hours we should be able to get about 1,000 hours standby with  a 4G off-the-shelf cellular modem.  And that's assuming that the solar panel was actually in a black box.  Even the light here, if we had the 7 watt solar panel and had it sunny side up, we would  be able to maintain charge indefinitely on the device because we only need to have about  8 milliwatts coming in.  So we're talking about 1,000 of the capacity of the solar panel.  So for communications, for independence, we really want as many possible ways to communicate  as we can.  And the naughty little things that we can't trust, in particular the cellular modem, we  want to have a sandboxed and quarantined so that it can't spread its naughty plague of  whatever vulnerabilities it has in there.  Again, there are black box, we can't trust them, they're too hard for us to implement.  And so this is kind of a decision that we've taken.  We'd much rather have a fully open 4G modem.  If someone makes one, fantastic, we'll incorporate it straight in because the system is designed  to be easy to change.  But in the meantime, we have to kind of do with what there is.  The great thing is that these M.2 cellular modems are used in vending machines, in cars,  in all sorts of things.  So they're just the common as, again, if you had to scavenge them in the future, this  would be quite feasible.  And it also means we can upgrade.  So we have two of these slots, so we could actually have a dual 5G Commodore 64.  Because who wants to have to wait extra time when you're downloading your games, right?  And 40 kilobytes can take a long time to download if you only got one 5G link, right?  So we'll have two of them so we can do it in parallel.  Because who wants to wait more than about four milliseconds to download new software?  And again, limited communications availability in these kind of oppressive environments,  this is actually key.  You might only have short communications windows.  So while it's a little bit tongue-in-cheek, it's not entirely.  And of course, with several mesh, we've been doing UHF packet radio.  So we've put in tri-band Lora compatible radios in there.  Not Lora-wan.  We're doing it fully decentralized.  We're just sending out radio packets and listening in with the modules.  We've also got ESP8266 Wi-Fi and some Bluetooth in there.  So that's some other potential options.  Acoustic networking, so we've got four microphones that are directly connected to our FPGA.  So we can do crazy signal processing on that.  And we've got a nice loud speaker that should work up into the ultrasonic range.  So we could even have quite decent communications over 10 or so meters in the acoustic band.  And there's a crazy bunch, and I've forgotten the name of the research group, that do air  gap jumping.  And they've done some quite crazy things with acoustics with, you know, if you leave your  headphones plugged into your computer on your desk in a headphone jack, you can software  reconfigure that and make that so it's a speaker and microphone.  Because anyone that's interested in that, hold on a minute after and we can have a,  and I can try and find the links for you.  We've also got infrared LED.  And so the idea with all of these kind of things and whatever else you can kind of do  is that it should be really hard for an adversary to actually jam all of these things at the  same time.  You know, you might be able to do broadband RF jamming, but that's not going to stop the  acoustics or the LED.  And even if you can kind of make a lot of noise, it's going to be really hard to block,  you know, the IR LED of people are kind of holding the devices near one another to do  delay tolerant transfer.  And of course, any other crazy things that people come up with, again, a simple system  design that you can extend it easily yourself.  Okay.  Security independence.  So the operating system runs in our little 8-bit CPU, which is basically a slightly enhanced  version of the Commodore 64 CPU.  It has an 8-bit hypervisor, which is 16 kilobytes in size, hardware limitation, because we don't  want it getting bigger.  If it gets 16K, then you have to throw some other things out and go, right, what does  it actually really need to do so that you still have a system which is actually much  more verifiable?  And this kind of small software, it should be quite possible on this machine to run  a simple C compiler, for example, to be able to compile the software that is actually running  the core operating system.  So we can have that whole complete off-grid operation.  We've already talked a little bit about having the untrustable components fully sandboxed.  So, for example, the cellular modems only have an AT command serial interface to the  rest of the system.  And so this is going to make it much harder for an adversary to work out how with a fully  compromised cellular modem, you can compromise the rest of the system by giving presumably  bogus responses to AT command requests.  And because we know that's where the vulnerable point is, we can put a lot of effort in our  software to really interrogate the command responses that are coming back and look for  any AT command responses with semi-colon drop tables and all the rest of it in there.  It should be pretty straightforward to pick up.  So we also have an integrated hardware and software inspector so that you can real-time  verify.  So this is a little bit fun.  So I can hit MegaTab.  And so we call it Matrix Mode, for good reason.  So the system is still running in the background.  So the slides are still there.  So I can go back to the previous slide.  I can begin to say it was a joystick actually when I'm in there.  There you go.  I'll file a bug for that.  But we can, if I go back into it, we can look at all of memory in real-time.  So if you are truly paranoid and you're about to, for example, do some encrypted email on  your digitally sovereign device, you could actually go into this, stop the CPU, and then  inspect every byte of memory and compare it to your physical printout of the 30 or 40  kilobytes of your software and go, what the fuck is that?  Well, you might, every time you might do half a kilobyte or something, right?  And verify it so that progressively over time, you've actually verified that the system is  always byte identical at that point in time to what it should be doing.  And again, the simplicity, we only have one program running at a time.  So you know exactly what the system is doing.  We can task switch.  We've got a built-in freeze cartridge.  If I press the restore key, anyone who's used a Commodore 64 with an action replay will  probably recognize the inspired format.  And so that's our program.  They're running with hardware thumbnail generation.  The colors are a bit wrong.  We need to fix that.  But we've got other software that we've had running on it.  And so if we wanted to break up the presentation with a quick game of Gyrus, for example, we  can do that.  I need to switch the joystick port.  We can do that.  And then we can go back and pretend that we weren't doing anything naughty at all.  And of course, I forgot to save what I was doing first, right?  So I have to load the program again.  So that's my bad.  But that's right, because reboot time is about two seconds.  Oops.  So the worst part now is that we actually, we haven't got a command to jump through the  slides.  And so it actually takes a little bit of time for it to render each slide as we go through.  So that's my punishment for not saving first.  But actually, what we might do, we'll skip that for the moment.  And we're kind of at the right point anyway to talk about it, which is the audio powers  in a mobile phone.  This is a really important area to protect.  So it's so important that it's the only diagram that I've put in the entire presentation.  So at the top, we have a normal mobile phone.  So basically, what we see is that the untrustable cellular modem is not merely untrustable.  It's like an evil squid that has tentacles that reach into every part of your mobile  phone that you really don't want it getting into.  So it has the direct connection to your microphone and speaker.  The normal CPU on your mobile phone usually has to say, pretty please, oh, untrustable,  completely untrustworthy cellular modem, may I please have something which you're going  to tell me is the audio that's coming in through the microphone.  Whether or not it's actually the audio or not, that's a whole separate thing.  They might be doing all manner of crazy things first because you can't tell because there's  a big fat black box in the way.  And then just to make sure that it can fully compromise what you're doing, often it's  on the same memory bus.  And so you might go, oh, I'm being all secret squirrel from the cellular modem and not asking  it anything.  And it's just quietly lifting the covers and looking at what you've got under them going  like, oh, no, no, no, that bite's wrong.  You really want that value in that bite.  And likewise, the RAM and the storage.  So the cellular modem can totally compromise your boot loader and all of that kind of stuff  along the way.  Just to say that that's not really a very survivable model or a very resilient model  or a very secure model for a phone.  So what we have instead is that we've basically put the fully untrustable thing completely  out in its own little tiny shed.  We've got the tin can and string between us and it with a very controlled interface.  And the microphone and speaker, thank you very much, are directly connected to our FPGA.  So we can do encryption at the microphone and decryption at the speaker.  And the storage is secure, so we can even have massive one-time pad.  So we could actually do SIG-SELY style, provably secure communications over distance, if you  can set up the key material beforehand for one-time pad.  So it's a radically different approach to what we see with devices out there at the  moment.  So we'll just get the last few slides up again.  Oh, I never got them.  Oops.  So even simple software can have bugs, this is where we need many eyes.  Think if I load this one first, yep, and now I can load the other one, because it just  hadn't loaded the fonts in.  Yep, cool.  That's coming.  Yep.  And you can even use the joystick to move around in the text if you want to.  Okay.  So if we think then about this whole, what are we actually trying to achieve around this,  and what are some of the things that we need?  And the Commodore-derived 8-bit platform, to us, has a whole pile of advantages as a  basis for doing this.  Now, we could have done it with a completely different platform.  We're thinking like RISC-5, for example, is a nice open platform, could be an idea.  That could be that the RISC-5 CPU is actually too complicated to verify and trust yourself,  is my kind of view, but I'm happy that other people might disagree with me.  Multiple germ lines, totally different ways of doing things, so at least one of them keeps  working at any point in time would be really, really good.  And we're going to show you combination things as well.  One of the things we're looking at is having, for example, a Raspberry Pi running the Pi  port of Android that somebody else maintains, so I don't have to do it.  And then having the 8-bit layer actually virtualizing all of the I.O. around that, including access  to the SD card storage, including access to the screen.  And this actually also makes it possible for us to make custom mobile devices for people  living with disability.  And actually, so that the Android, again, is easy to maintain because we don't even have  to recompile it.  We can just get the standard version and then make it think it's got a normal touchscreen  when in actual fact it might have some completely different input method going on.  So there's a bunch of advantages, and I've run out of the official time that I allotted,  so I'll quickly go through and then we'll go into questions.  So the 64 platform is really well documented, so there's a whole pile of tools and everything,  programming languages, so this is pretty straightforward to go through.  We've already talked about capability maintenance.  Again, so there's actually another key point, making the hardware big actually is a massive  advantage because then we can do normal PCP fabrication.  We don't have to do any BGA part placement, which is a real pain to do in your home oven,  it is possible, but you don't want to have to learn how to do it in the digital winter.  And yet it's actually this kind of similar size to existing kind of devices out there.  So there's a bunch of advantages with that.  There's a whole pile of different things that we really would like some folks to help  us with to try and get this finished and out there for people to try out and to be able  to mature it and make it work.  So it doesn't matter whether you ever program an 8-bit computer or have ever done any FPGA  work or PCB work or whatever, there's lots of space for people to join in what is quite,  we think it's actually both an important and actually a really fun and enjoyable project  to work on.  And so really I just want to finish by saying that I think as I was thinking about this  talk and preparing for it, I think actually it is a call to action.  The digital autumn has begun.  Digital winter is on its way.  We don't know when it's going to come and it might come a lot quicker than we would  really like it to come.  Myself and the people who are already working on the project, we can't do everything alone.  We're doing what we can.  We're going to try and organize another event in early April up in Berlin.  But there's no need to wait for that to get involved.  We'll be around at the vintage computer area if anyone wants to come and have a look or  ask anything about how you might get involved or just play around with the platform.  It's quite fun to use.  And yeah, we'll leave it at that point.  So any questions would be really welcome.  That was incredible.  You have the best presenting set up that I've ever seen at the Congress.  Thank you.  The joystick is amazing.  And the joysticks also open source hardware.  I can give you the plans to make one of those yourself from parts.  It's a spare joystick part for arcade games, basically.  Yes, please.  Yeah.  Okay, we're taking questions.  I remind you, we have six microphones in the audience.  We also have the amazing signal angel that's going to relay questions from the Internet.  And we're going to take one right now.  Okay, so you already talked about some events, but maybe can you bit more elaborate on how  you're planning to involve the community?  Okay, so how are we going to involve the community?  Basically any way the community would like to be involved, the moment in terms of with  the phone is myself and kind of working at a university.  And we have kind of a couple of part-time students working on things.  So the bus number is disturbingly near one at the moment.  So there's Ample Scope to help.  We've got a few other people who are helping with the Mega 65 project itself.  And so there's obviously this crossover in that.  But what would be really great would be to find, for example, a couple of people who  are willing to work on software, primarily coding in C. So you don't even have to know  any 6502 assembler to begin with, to do things like finishing off the dialer software and  things that we demonstrated back in January and get it all working so we can actually  walk around with a pair of large plastic bricks by our heads talking on the phones that we've  actually created.  That would be a really great way to get some initial forward movement.  And then things like case design.  There's a whole bunch of stuff that we'd welcome involvement on.  Thank you.  Do we have more from the Signal Angels?  Yes, we do.  So OK.  There's a question, when a prototype will be available?  OK.  When a prototype will be available, I'm happy to give out blank PCBs or post them to people.  So I've got to actually pack them with me.  We've got the next prototype is actually being built at the moment.  So these can be built for about 400 euros at the moment.  So you can buy five of these instead of an iPhone.  So it's economically survivable as well in comparison.  It's actually one of the really quite funny things is we're kind of making this and going  like a few person years of effort and we can already make a mobile phone.  OK, it's not as small and schmick, but it's got a joystick port.  Does your iPhone have a joystick port?  So it's amazing what we've actually been able to do quite quickly.  So it's the kind of project where if we do have people kind of come in to help us, by  next Congress, we ought to have people running around with megaphones and being able to communicate  in fun and independent kind of ways.  So yeah.  Thank you.  Microphone one, please.  Sure.  Thanks for a cool talk.  And I have another question because you want to reduce black boxes, but what's about encryption  because it's really complex and how do you plan to reduce this black box?  OK, so an excellent question.  So the best encryption there is is actually the simplest.  It's called one time pad.  So if you can actually meet with people.  So again, if we're talking about focusing on supporting local communities, well another,  if you get your megaphone and the other person's megaphone and you come in infrared range,  for example, and then you shake them like martinis to generate some random data and you do  that until you've decided you've got enough one time pad and that one time pad is secure  enough in your device, then actually like X or is pretty easy to debug, right?  Thank you.  Microphone number three.  So you talked about the form factor right now, the Nintendo switch.  Yep.  Do you have plans on going smaller than that?  More like a classic mobile phone?  Yeah.  I think it's actually quite possible.  So this is, if you like, the first version is this one.  So you can see it's about five centimeters thick.  The second one, we think we can get down to about four centimeters thick, but it's otherwise  the same size as PCB.  We've got a student at the moment who's going to try and work on making one that's about  the size of only the screen, still probably about four centimeters thick.  And we think that that's going to be quite, the PCB layout, he's basically been cursing  me for the last three months to try and get all the tracks routing without it needing to  be a 15 layer sponge-tort kind of PCB, but that should be quite possible to do.  And again, that's the kind of thing, once you've got a working prototype, then some  people are like, okay, we're going to be on the miniaturization team to try and make something  which is even smaller.  But there's always trade-offs in these things.  Again, the smaller you make it, the less solar panel you can have on the back.  So there's kind of these things.  But certainly trying to make it as thin as we can, I think, makes a whole pile of sense.  Honestly, you can make it smaller, but I don't think you should because when the zombie apocalypse  happens, it's a communication tool and a weapon.  Yeah, exactly.  That's right.  It's kind of, you know, exactly.  Or you can use a full-size one as well, right?  It's kind of got, you know, quite a nice solid metal keyboard in there as well.  A question from the internet, please.  Sure.  So what do you think about the OpenMoco phone?  The OpenMoco phone.  So I'm trying to remember the details about those.  I mean, the whole, again, everything that's being done on all of these fronts to make  fully open devices with as few black boxes as possible is fantastic.  So as I say, if OpenMoco can make an M.2 form factor cellular modem that we can put in the  megaphone, I would be so, so happy.  But we can do a whole pile of stuff while we're waiting for that to happen.  Thank you.  We actually had a talk yesterday about from one of the people behind the OpenMoco.  So you can watch the recording if you want.  Next question, microphone one.  Sure.  Hey, thank you for the great talk.  I was interested in the Mega65 itself.  Is that available?  Is it sold?  Yes.  Okay, so the two most common questions we have about the Mega65 is, can I buy one now  and how much does it cost?  Unfortunately, the answer to both of those is we don't yet know exactly.  It will be a three-digit number in euros for the price.  This is pretty certain.  But at the moment, our big challenge is we, so this one is, it's a prototype made with  vacuum form molding.  So each case costs upwards of 500 euros for the case.  This is not really sustainable.  So we know we need to make injection molding tooling for that.  And so the guys from the German part of the Mega65 team are running a fundraiser.  I just said to be a little bit careful with that, is that Australian law for fundraising  is a bit weird.  So I am not doing any fundraising.  Some people here in Germany are doing some fundraising to try and raise the money for  the mold.  So if you look at mega65.org, you can find out what they're doing in that space and  have a look at that.  Thank you.  Do we have more internet questions?  No?  Cool.  Cool.  I think that's it.  So thank you again for the wonderful talk.  My pleasure.  Thank you.  Thank you.
36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_5592_9659.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_11376_12431.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_13308_13967.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_13968_14195.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_14196_16859.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_17520_19655.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_19944_22235.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_22236_22487.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_22488_22703.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_22704_25379.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_25380_26387.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_27300_28907.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_28908_29687.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_29688_29783.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_29784_29927.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_31992_33047.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_39108_39635.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_39636_39887.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_39888_42467.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_48180_50207.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_51924_52367.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_52608_54371.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_54648_55835.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_55836_56387.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_56388_56627.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_56628_56747.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_72852_73259.png 36c3-10800-eng-deu-Creating_Resilient_and_Sustainable_Mobile_Phones_hd_73260_73837.png