 Control. All right. Hi everybody. Sorry for the small technical difficulties. I thought I was falling directions, but it wasn't. And I guess we're running a little behind schedule. So I'll probably be a little quick through some of the sections of this presentation. But thanks everyone for tuning in, spending some time with us to hear about my keynote here about precursor. Mario asked me to talk a bit about sort of how this device I'm making was made for sort of more everyday use. So we're going to be talking a bit more about some of the mechanical design aspects and the user facing features of it. So here's my talk. It's about trust well open harder for everyday use. And it's about a product that I'm making called precursor. So let's start the talk very briefly to review. Ask the question about trust. You know, where does where does trust actually come from? It's kind of an epistemological question. But basically, the root of the question is how do I know I'm running the code I think I'm running and it's not just my computer showing me a screen that looks very similar to the code they think I'm running. And a lot of the trust models today come from the idea that you have a root of trust. It's a piece of hardware that contains an unalterable trusted piece of ground truth from which you derive all other truths through cryptographic mechanisms typically. So the problem with that model, though, is that hardware itself is not infallible, right? So there are some well documented examples now. Thanks to a bunch of instances have happened, for example, of the NSA intercepting Cisco routers and inserting beacons on the inside of them to a reporter, Andy, who had reported that he had a listening device inserted in his crypto phone. So there's actually picture here in the middle of a small microphone amplifier that was soldered on to the codec wires and it goes to a transmitter board that was elsewhere inside the device. So, and then also there's, you know, JTAG implants that are just you can buy off the shelf and government programs to insert inside Dell PowerEdge service and that sort of thing. So it's established now that hardware is not infallible. Of course, a lot of people say, but buddy, I'm just a regular boring person. No one's going to hack me, right? I'm not worth the effort to hack. The flip side of that is that there's actually, thanks to modern supply chains and the way that things work with bug online, there's everyday hacks now for everyday targets. So the typical DIY supply chain attack, which doesn't require you to be a government agency to intercept the package and on the way to someone's door is to just buy item online, modify it, pack it back into the box and return it to the warehouse and then do whatever you're going to do in profit, right? So there's some document examples here of someone who, this is from the wall that Phil talked a couple years ago at CCC at the Congress, where someone had taken a tracer box and they managed to open it and basically close again without modifying the box too much. And, you know, demonstrates the idea that you can get something online, but you can't necessarily know what's on the inside of it. And it's not actually hard to execute the attack. In fact, actually it's almost zero cost to the attack and they get the money back for the thing they returned at the end of the day. You just have to be physically close to your targets that you're looking for. You can't specifically target it with a supply chain attack, but you can get within a geographical vicinity towards targets of interest. So what it turns out in general is that the roots of trust and practice is that within your own environment, everything looks solid, but just don't look down what's beneath your castle in the sky, right? Just don't try to figure out, go too far deep into what your roots of trust are. And the big problem at the end of the day is that the reason why we have this situation, why we have castles in the sky we can't look down too far is that we can't hash hardware. So in software, we have a hash function, it's a cryptographic function we can use to sort of very quickly inspect every single last bit inside a binary and confirm that nothing has been modified on route to our computer on route to our execution point. The problem is in hardware there's no way for us to go ahead and just do a hash of all the atoms in a particular piece of device. And so we have what's called a time of check to time of use problem. So the time at which you inspect your hardware piece may be different from the time at which you would use it. So perhaps the reporter who had his cryptophone hacked at one point had confidence in the device, but later on someone had tampered with it and installed the microphone. And so now you have a time of check to time of use problem inside a piece of a hardware. And, you know, I'll be the first one to sort of call myself out to say that I've always said you there's always a bigger microscope I'm a big fan reverse engineering and finding out how things work and that sort of stuff. And so it's true. Yes, there are like very sophisticated technologies I can use to image hardware down to the transistor level, even the most recent process notes, right? You can you can read some papers on it online. The problem is, is that, you know, the size of the microscope that was used to do that paper is literally the size of building this this round thing here is the light source that was used for the tecographic extra imaging that allowed people to to view those transistors at such a fine level. So it's not it's not something in a park in the back of your house and use it to inspect everything that comes in from Amazon or something like that. Second problem is that, you know, verifying one ship only verifies one ship right it's not the case that you can just selectively say I'm going to just check one of my RAM ships out of the dozen in my system and I'm going to be okay you have to check every single one of them just one compromise component is all you need to go ahead and install an implant. You know, we wouldn't random sample signature checks on our updates from that they would download online we do 100% check on all our software so why wouldn't you want to do that for your hardware as well. And so then, you know, this leads us to the question of can we build an evidence based case to trust your computers right now we feel that we can trust your computers because there's a brand on it people say oh Apple is, you know, invest all this money they're all about privacy and you know I would like the pixel phone because it's Google or whatever it is but you know do people have evidence based reasons to trust the specific piece of Harvard they have in front of at this point in time. And in order to sort of build that case. I've come up with sort of three principles I think that hard designers need to obey to be able to get to the point of an evidence evidence based argument for trust and hardware. The first one is that you know complexity is the enemy of verification. The second is that we have to verify entire systems and the third is that we need to empower end users to verify and seal the hardware. So very briefly, and I know many of you probably have heard these arguments from me over and over again but for the benefit of people haven't heard it yet. I'm going to go very quickly over it. When you know systems today are so complicated that even if you could take them apart and verify them like this is a picture of your typical smartphone over here, you would destroy it right like you know people who have tried to replace the battery in the smartphone themselves have noticed that they have adhesives on the back panel they're so aggressive that you essentially have to throw you the back panel put a new back panel on right so people don't even want to take off the panel to even check. If you know they have the gigabytes of memory that they were promised originally inside the system right it's they're really just sealed object at this point in time so that's that's one problem is also. They're just too complicated by the time you think it apart you don't you don't even know what to look for the inside you could spend the lifetime trying to figure out your phones built correctly and still not find the needle in the haystack. And so there's a trade off that now that you have you encounter sort of like sort of the verification the ease of verification versus features and usability so the example like to use is you have these airpods, which are magical they sticking your ears they don't have any wires in them, they probably have 100 million plus transistors on the inside. So good luck trying to find any sort of firmer bugs are in on the inside they could they could exfiltrate your conversations someone else, versus a very classic sort of headset that you would use with a boom mic on the inside has exactly one transistor which is the fat that's used to amplify that the microphone itself and everything else you can verify using you know I mean just it's a coil of wire Maxwell's law physics these types of things. These two objects actually perform nominally, almost the same thing their headphones right but one of them is incredibly much more complicated to verify has a lot more opportunities or things to go wrong. The other ones very easy but the trade off is that you now have you know a wire that you have to have hanging off your head which I have no problem with but a lot of people seem to say, think that is like the worst thing ever and it's completely worth all the tradeoffs and gendered in using it. So, the second principle is that we need to verify entire systems and not just the sub components on the inside. Very quickly, you know, a lot of phones already contain a secure element on the inside security enclave or whatever you want to call it wherever the wherever the brand is, and they're meant to keep your private so in the case of an OS exploit or something even if the CPUs hacked your keys are still safe. So therefore you should be, you should be good all right because it's like your trust route is not compromise. The promise is that in and I used to call this IO problem I think more directly, we can call it the input method editor from the IME promise that even if your security enclave is is locking down all of your messages and using signal and you've everything's end to end encrypted will feel very safe on all this. There's a thing that you did probably when you first booted your phone where you installed IME in it popped up a little note very much similar to the one on the right hand side which says, you know, this input method can collect all the text that you type including personal data, passwords and credit card numbers. Would you like to use it and people go okay, and then they're done right and so at this point in time you basically taking this entire, you know, you know, tree of security that you've done and just uprooted it and floated in the sky and just gave all the permission to whoever using for the IME at the end of the day and everyone does this right so this is this is why you have to verify the entire system and not just one particular component of it. And at the end and then you know the third principle is that we need to make sure that end users are able to actually do the verification of cells and ultimately seal the hardware. When I say verification, it means like verification at multiple levels so circuit boards, design level, chip level right like we have to go down, down, down, down all the way to the bottom because the problem is is that when you talk about these epistemological problems of trust. And you know where did where does the trust lie you really have to go pretty much down to the bottom level because because there's always there's another turtle underneath that that will that will cause a problem for you if you don't. So, you know, precursor itself is and this is the project that I had referred to earlier. It's a it's a case study and verifiable hardware so I wanted to put together a system that could sort of try to meet these goals. I think there are hard goals to meet but we're trying to move to the point where we can sort of facilitate an evidence based trust relationship with our hardware right so you know I want to build something that was simple and construction open and design yet sufficient and function at the end of the day. So, precursor itself, you know what are the functions that I envision it could be used for there's a picture here on the right. It kind of looks like a mobile phone ish it's not a phone, you know it doesn't have the ability to, you know, put it in a LTE card or something like this it connects by Wi-Fi. It's designed for secure text messaging. It's designed for voice chat. We give it multilingual capability from day one, which is very important because actually it turns out one of the hardest, you know, if you if you anyone here who's sort of programmed and rust and dug into the bottom of it what is the hardest data type and rest to deal with it's not, you know, the U32 or the U64 or whatever is it's the care, right because a care is a UTF-8 thing which has a variable length size you don't know how big is how big is your care you don't know how big a care is right. So human language itself is actually, you know, we take it for granted and see we always think of as oh it's obviously a bite right you know it's not. It's actually one of encapsulating human language in a small form factor design is one of the hardest things to do. So we focused on that from day one, because not the entire world doesn't speak English. And we want to be able to do things like password management or maybe a crypto wallet whatever you want it's open source right so there's a bunch of things to do with it but things we want to explicitly throw out from the design envelope from day one where things like web browsing. Because I kind of feel like you could do all this effort and you throw a web browser on it and you just immediately undo it that I don't think the web the web browser itself I think it's an unprovably difficult surface to trust right I don't think we're going to get to the point of a like a fully trustable web browsers because it has to do so much. You know video games, you probably play Tetris on this but I don't think you're like you're not going to play a 3D, you know shoot them up game on it. And it's not designed for doing photos and videos I think that's that's a that's a still a bit too high of a bar for today's open hardware capabilities maybe in the future. Yeah you can play mind sleeper audit. So precursor is simple and construction so the you know the this here is actually a picture of actually all the parts that go into it you can see it sort of see from the left. The case is a motherboard this screen backlight sort of some shields for anti tamper and our management keyboard and a front bezel and a battery. I mean that's that's kind of that's it's really if you think it's minimalist that's the whole idea it is though the idea is we tried to design out too much complexity so it could be something that we could verify at the end of the day. So for example, we went with a physical keyboard. You know, it's a controversial decision virtual keyboards are fast. You can swipe on them there you know they're really responsive. But the problem is is that virtual keyboards and have to interpret through your CPU at the end of the day. Our physical keyboard, you know, is is just bear wires physically inspectable switches. Right. There's no silicon chips and we solve the multilingual issue by having this overlay that we put on the top so there's like a little printed film that you put on top of these key switches and you actually just take some screws and you take out your your language you put your new language and you do a setting and you're inside your new language. That's the input method editor switching mechanism as a screwdriver right so it's a very it's a very physical simple mechanism but it's very easy to verify. At the end of the day. You can verify it by just holding up to the light so this is a picture of what the keyboard looks like you can see the the darkest areas where the switches are you can see the wires and the connector. That's it if there's anything else on it then then there's a problem at the end of the day. The on the flip side if you want to do a touch keyboard verifications very hard cap touch requires not only the whole input method at a problem but it requires proprietary chips with a with a microcontroller firmware blob we're talking in the earlier session about how everything if you if you look up the data sheets for sort of touch screen controllers you'll see like the same you know the firmware revision of your touch screen controller and the data sheet have to be in sync it's it's crazy how much code is inside of these things and we didn't want to add another code blob where we where we didn't have to the screen is also very important because not only do you have the input method editor problem you have the screen scraping problem. I mean one of the things that sort of blows my mind about web browsers today and I learned this during the pandemic is that you can now share your screen with a web browser, which is I'm like why why did we even add this feature why who thought is a good idea to have my web browser read my screen right like like to me that just sounds like you know two years from now I'm going to see some person like oh my god like people have been reading you know script script in my screen and getting all my other things I type how is this possible like well because we let them in we we added the feature we wanted it for some reason or the other right so I don't want stuff going to my screen I don't trust it right so we decided to build in a black and white screen. It's high DPI has a good resolution to it for the size of it and we want to be verifiable at the end of the day we want to sort of have the screen also meet the same bar verification. So, we actually picked a screen where all the drive electronics are built on the glass as transistors that are big enough that you can see them with an optical microscope so this is a picture here if you were to peel off the backlight and look at the screen you can actually see the individual transistors that form the construction of the of the pixel drivers. And the reason why we don't use a color LCD is that, you know, all of the, you know, color LCDs the incorporated driver IC it's a little fleck fleck of silicon if you ever get a chance to tear apart a screen that you broke or something like that. You think oh it's there's nothing on it there's no silicon you actually see a very it's a long thin bar it doesn't look like your normal chip that's squared it's actually a long thin bar along one of the edges. And it's it's implemented as some pretty high node process has a frame buffer as a command interface, you know, has everything you need to sort of sock out a couple lines and put them someplace else. So, this is actually what we sort of designed at the end of the day for the for the circuit board. And one of the things we also want to do is we want to help people validate the circuit boards is not just a matter of making it simple and single sided and whatnot but we actually will continue to publish diagram like this as our hardware, you know, goes through vision so people can look at it and say okay, these are the parts this is what these things do, and this is what we should look for. And if I see some something often is that just a manufacturing mistake or is that regular variants or is that something to be worried about. So part of part of the process also not just being open about it and making it simple to inspect but also teaching people how to do this themselves I don't want to, you know, sort of be in a situation where people are really relying upon us to render opinions about the trustability of their own hardware. The PCB itself, just a quick note on that we actually designed the whole circuit along attack surfaces so we want also think from the hardware for a standpoint of if you had physical possession of the hardware how might I go ahead and attack it so we have a trusted domain and an untrusted domain and we sort of divide them between each other. And the circuit board itself is laid out so there's actually there's a metal shield that will go over a region here I think you can see where I'm sort of outlining with this with the mouse cursor that will actually cover all of the trusted domain items. And then there's a set of attack surfaces on it that you have to really pay attention to and that's where that's where you would want to look at. So if you don't have infinite time you don't want to spend, you know, days learning about this. Here's like six things you should look at before you use your device and if they all look fine, fine. Like it's a five second check. You've got time of check to time of use. And so finally we get to the hardest problem which is sort of the silicon, the system on chip, the SOC. How do we get evidence based trust in CPU? Like, you know, it's very difficult to check and use a specific chip. So, you know, IBM has published wonderful pictures of like this where they show how a chip looks. You can see all the transistors but you know how they did this is they actually cut the chip. This is a cross section of a chip. You're not going to use that chip anymore. So it's not useful, you know, from the standpoint of usage. So instead of, you know, and also this, you know, trying to topside imaging is hard because you have to remove all the dielectric backside imaging is incomplete, blah, blah, blah. Instead of trying to rely on imaging for this generation, we're using the field programmable gate array. So an FPGA is a large array of logic and wires that are user configured to implement a hardware design. So it comes as a generic array. It doesn't actually do anything out of the box without the configurations you put into it. It's an array of gates as a name implies. The whole concept is that we actually ship you the source code for your CPU. We give it to you. It's written in Python of all languages, a language called Litex, and it compiles down to Verilog and then it goes, gets mapped into a set of gates which then are loadable into your device itself. And the idea is that since you can now compile your design from source, you can transfer trust, quote, unquote, like software. So there's, there is a question, of course, you know, can the gate array itself have like some evil back door on the inside or wherever it is. And there's a number of mitigating factors I can do. People who are familiar with the security thing will need to address basically a randomization on kernels to prevent, you know, exploits. You can sort of do some random mapping of the hardware to frustrate people's attempts to backdoor your devices. But at the end of the day, the whole idea is to narrow that time of check to time of use by allowing you to compile your own CPU from source. You don't have to. We'll ship you a reference CPU compiled. But if you want to go ahead and install the tool chain, it's not small, but you can go ahead and compile your own CPU from source. There's a very quick look on the inside of it. There's, we actually have, like I said, putting a lot of effort into documenting as well, not just trying to push code and hope people can understand it. If you look at some of our collateral, you'll see diagrams like this, which you can use to explore all the items on the inside of our system on chip. And the biggest potential at the end of the day is that by using an FPGA, we can move the point of check closer to the end of users. So the vision ideally is we want to have someday a one-click tool to verify a bit stream so people can say, I've got a bit stream does this do the right thing and it's all open source and you can do it. We're not there yet today. And to be clear, that's a hard problem because there's a lot of tool chain that has to be done to get there. But there's a path to it, at least we see it. And I think I think it's doable just a matter of time. So I think we'll get there. So this is the point at the talk where I kind of sort of pivot more into the into the main theme. Now that we've kind of gone over the background of what precursor is and why we're doing it what we hope to accomplish. Or we talk a bit more about sort of like the human computer interaction aspect of it, right? So I feel like the final frontier in security is HCI, human computer interface factors, right? Because if you build something that is perfectly secure at the end of the day, what you find is a people hack the people. Humans are the weak link at the end of the day and any type of security, phishing attacks, impersonation attacks, ID theft. These are all types of problems that we're going to experience actually more and more, unfortunately, as the security gets better and better. And we invest more and more in putting our stuff online. So some of you may be familiar with these bank tokens that the banks give out. This is sort of an example of a minimal attack surface, a simple inflexible interface device. But the whole idea that they call it a second factor of authentication. It's another device that is very difficult to hack, at least remotely. I mean, in person, you can do whatever you want with it. But at least remotely, it doesn't have a network interface. It can use it to prove that you have like the shared secret with the bank. On the other end of it, we have things like browsers. They're feature-further flexible. They're basically operating systems in and of itself. They have an intractable attack surface. And ironically, people are pushing people towards logging into banks using their mobile phone apps with browsers that are basically node packaged into some electron framework with whatever else going on. And they called a second factor. I mean, when you put everything into one device and you give it a huge attack surface, I'm sorry you have one factor again. So it's not really, you know, we've sort of taken two steps forward, one step back, you know, in this escalation of human-computer interaction form factors. So precursor tries to hit this balance of being right in the middle. We want to be just enough and no more. And we want to have a sort of a secureable attack surface on the device itself. Which means that, sorry, next slide here. So to try and illustrate what we're trying to do a little more clearly, I have this sort of Venn diagram chart. I like to do these things. I might talk to sort of talk about the three domains that we're thinking about. So there are things that are hackable. So they're unlocked and the design source is mostly available. It would be like arduinos and raspberry pies, these types of things. They're hackable, right? They're not pocket ready. You can't stick raspberry pie immediately in your pocket. If you did, it would poke you in the leg as a header sticking off of it, right? And it doesn't have evidence-based trust because it has that Broadcom SOC on the inside. You don't know what's inside that Broadcom SOC. It still could have a backdoor. It could have other issues going on the inside. It has lots of firmware blobs at the end of the day. Then you have things on the right-hand side that are pocket ready. They're like your iPhone, most Android phones. They're really beautiful. They stick in your pocket, but you can't hack them in the sense that they're not unlocked. Their design source is definitely not mostly available. And there's no evidence-based trust at all. You may trust them, but it's not because there's an evidence that this hardware does what it says it does. It's because you trust the vendor. It's a social reputation contract with the vendor is why you have trust. And it's not an evidence-based relationship. It's a faith-based relationship with your mobile phone vendor. And then you have some devices that allow for evidence-based trust. There's some of these devices here where you can actually compile your CPU from source, run it on the hardware, and say, this is actually executing instructions I think it's going to execute. And amongst these three domains, Precursor is sort of like one of the few devices that gives you all three of these properties in a single device. And Pocket Readiness is sort of one of the big differentiating points on that. So it's sort of belaboring that point a little bit more. So here's a functionally equivalent piece of open hardware to what we're shipping in Precursor. It's the ULX3S. It's this wonderful lattice-based FPGA system. It's easy to verify and trust. You can compile your CPU core for it. It's totally open. It's affordable. The bad side of it is that it's got no screen or keyboard. So you use an HCI problem, obviously, to it. And you can't carry it in your pocket. It does have some buttons, though, which is good. And it has a little thing for a screen that you can plug in and carry around. So it could get there. On the other side, we have some everyday use kind of open phones, open hardware phones like the Libran 5. The good news is they're pocket-ready. This is definitely a very pocketable phone. It runs an open-source software stack. It has a browser, so it's usable. The bad side is that it also inherits all the attack surfaces of Linux and browsers and SOCs at the end of the day. And the ugly is that you may just end up having to carry two devices anyways in practice because the Libran 5 may not get you all the way to being everything you need in terms of an app store and running all the native apps that you have to do to interact with everyone on a daily basis. And so you'll have this phone plus another device anyways. And so now you have, like, still carrying two devices, but you haven't gotten there in terms of the evidence-based trust. That was the thing that you cared about. So our point of differentiation is that we want to take open hardware, which is particularly stuff on this circle here, sort of things from the lineage of Arduinos and Raspberry Pis and Snickerdoodles and these types of things and move them towards the pocket-ready side. That's sort of one of the major thrusts that we had in the concept and design of this. We want to have a thing that looks and feels like a gadget, fits into your everyday life, so you wouldn't feel weird bringing it out at a dinner party and checking a message on it. It wouldn't be like, you know, I'm going to pull out a pile of wires and, like, an HDMI display and set my Raspberry Pi and start typing, you know, in the hawker stall or something like this. It would look a little weird, right? This one you would be, you know, it would not be out of place, but still is also trustable and has no compromises on simplicity verification or openness. Which means that in terms of making our case, it was much more than just having a pretty face to it. You know, we want it, and I want to talk a little bit about what went into designing the actual hardware, the actual mechanical stuff around precursor itself. So it was actually a multidisciplinary exercise in design, material science, mechanical engineering, and electrical engineering. So, you know, when we started the design, we thought about a lot of different concepts. We actually started from a place where we looked at a paper from Microsoft of all the places, where they did this phone cover. There was actually, you know, for their, whatever their Microsoft phones at the time, it was like a little cover of those E-Ink, and you could close it on top. And the idea is that you would have, like, the static E-Ink display that could display other content next to your phone. And the idea is you could sling your boarding pass over there. Remember when you get on an airplane? You could sling your boarder pass over there, and if your phone was dead, the E-Ink display would preserve your boarding pass, and it would actually scan because it's E-Ink. It's not like a reflective display, all sorts of stuff. So it had all these kind of nitty little features. Yeah, it had all these nitty little features from the human-computer interaction standpoint that I really liked. It was a really good way of having a secondary device next to your phone that I thought was very clean. So we started playing around with the E-Ink. We actually got some E-Ink samples. This is here as an example of a UI mock we did on a piece of E-Ink that actually had both red, black, and white colors on it. And we realized actually there's actually a security problem with using E-Ink in that we removed power and it's still showing the last message. So it's actually a little bit of volatility as a good thing because you want to be able to erase messages and not have them sort of just persist there, I thought. So then we went towards this smart memory LCD displays, which we're using in the final case. We sort of prototyped it hanging off here off of Raspberry Pi. This is an early dev board we're using to sort of test keyboard concepts, random noise generators. Basically, we just did a trash tape out of a circuit board just to see if we get anything to work. And we did some tests, put some incredibly small fonts, put some black and white stuff on, took an XKCD comment, stuck it on a comic and stuck it on there just to sort of see if we're even in the right zone in terms of UI standpoint. It seemed to be okay. And so then it got to sketching, just drawing a lot of sketches of what the hardware might look like. After doing that, we had to do a lot of learning. I hadn't really done a mobile phone before. It's not a thing that you're trained to do in college. And so we went to a bunch of factories and looked at how they made keyboards for them, took apart existing keyboards, and did teardown analysis to figure out sort of what were the tricks and what were the strengths and weaknesses of a variety of keyboards from a variety of keyboard-based devices. And finally sort of synthesized that all together into sort of some realistic-ish 3D renderings it could use to sort of talk about, are we getting there? Is this device thin enough? Is it going to be, is it the right size? There is this sort of a lot of people comment on this awkward bezel, availability on it because we're so used to sort of bezel-less phones today. It's like a big thing in smartphones. It's like a fad, I guess, I don't know. But we don't have enough money to make a custom LC display. And if we made the keyboard as narrow as the screen, you wouldn't be able to type on it. So there you go. That was like one of the design trade-offs we had to deal with. And so we played around with a lot of different renderings, trying to figure out what would go on. And then we went and made some hand-feel prototypes. Once you've gone and thought about the design and the screen, there's no substitute when you're building consumer hardware to just build the real thing, hold it and use it and see how it feels. And that really helped inform a lot more of our, like before we even got to the refinement stage of how everything packs in, we had these sort of hand-feel prototypes and playing around with different materials for the bezel and the design. And so the material science itself actually was a really difficult challenge in itself because picking the right materials, very important. If you remember, this is a picture of an iPhone 6. If you guys remember the bend gate thing where you could sit on an iPhone 6 and it would like bend and snap, they're using a certain alloy of aluminum, a 6,000 series alloy of aluminum that had sort of some weak spots. And as now having designed phones and understanding design, you can see actually the weak point and I can understand a bit like the trade-offs they made and how this ended up being a thing, but people weren't happy with it. So you have to sort of go through now this material science exercise of sampling steel, brass, different alloys of aluminum and comparing the strength to finish, the durability, their availability and price. So we sort of started this sort of continuous integration of materials into our design by essentially getting different swatches of material, hand them off to a really good CNC provider and then creating versions of our case with various types of material. We could pick them up, feel them, abuse them, scratch them, test them for conductivity, throw them in ocean water, take them out, dry them off. Do all these types of things to try and understand the material properties because it's one thing to read a book. It's another thing to sort of just experience them. And so we iterated a lot until we finally arrived at a couple of materials that we think that meet our sort of requirements in terms of durability, good-looking feel and cost most importantly. I mean, a lot of people ask me, like, why don't you use titanium? It's an obvious great material to use. It costs like $1,000 for us to mill a case out because we'd scrap so many of them on the way to making a single one that would work or something like that. There's some great materials out there, but they're just too hard to work with. And then we have to pick colors, which is really hard because everyone has a different opinion as to what looks good. And unfortunately, we don't have the budget. We don't have the budget to market to you like Apple does to make you think that this is the best color because they're smart and they had good designers and they picked the right color and you're dumb and therefore, you should like what they did. And everyone has a different taste for what they want to do. We also don't have the budget to make 100 different colors and put them in the supply chain. I think we're going to have two types of colors. One for the Omakase version and one for the regular version on this particular come out. So we're basically going with black or a darkest shade of gray, which is a safe color. Most people are okay with it, but we're playing around with some things like different bezel formats or whatever it is. Like this sort of firm pattern of the bezel has been a little controversial. It's one of the things where people either hate it. I'd say like 90% of people hate it or you really love it. There's a certain group of people who are just, oh my God, I have to have that. So it's very difficult to sort of get that line right. But at the end of the day, gadgets have transcended functionality. They really are a fashion statement. These people buy things a lot in part because of the color they have and the feel they have and what they can show other people that they have about it. And so this is part of the process that we have to deal with now as hardware designers. We have to sort of acknowledge that part of the HCI experience is the color and the feel and the look of a device. And so, yes, okay, see with it. We're starting to run out of time already. I'll sort of push this through this quickly. Then we get into sort of the mechanical engineering of the device itself. So this is the point at which we really start to get into the details. Make sure we've got a budget for all the heart of the components and that everything is put together correctly. We're starting to invest a lot more in terms of the drawings and delineating all the points. So there's a sort of figuring out where to pack all the components into something that's only a few millimeters tall is a bit of a game of Tetris. A lot of trade-offs on the inside in terms of durability, assembleability. And one thing we didn't want to give up was the ability for this thing to be easily inspected. So we couldn't do that cheat of let's just use glue and hold it down. Because that's the thing that happens a lot in mobile phones, we can lose a millimeter by just using glue because we don't have a screw anymore, something like that. So we really had to sort of figure out how to pack everything in and still make it easy to take apart. And then from the election engineering side we had to put a lot of rules upon ourselves. We wanted no component thicker than 1.5 millimeters, general component on the circuit board thicker than that. Which means the good news is from the mobile phone ecosystem there's a lot of things that are already quite thin and small that meets their requirements. We also had to think about the openness of the component. Was it easy enough to get? Was it easy enough to get the data sheets of it? Did it meet the functionality? Is this cost reasonable? Can we actually buy it? Is it an unobtainium? Is it a thing that Apple's purchased only and will not sell to anyone else? These are all things that we had to deal with in terms of getting stuff to fit. And then finally, we had to bring it all together. There's a lot of attention to the details of the finishing touches. We have custom finish on our torque screws. So I didn't want to use a hex head or a cross head Phillips because these things suck. They strip. They don't work well in my opinion. We've had torque screws for decades now. I don't understand we don't have them on everything. But they're hard to get actually. The torque screws are not common. So we had to find a vendor that would make them for us in the right size and get the right color on them so that we could go ahead and put them in the design instead of just using off-the-shelf crosshead screws. And then the edges of the case itself are done with what's called a diamond beveling. And so what we do is we actually, instead of machining and polishing it, we use a diamond bit that is so sharp that the cut of is mirror finish in and of itself. So you get this nice sort of, you can see this sort of shine on the edge. It's a very subtle touch, but I kind of like these sorts of accents that don't stand in your face but sort of give it a little bit of refinement, a little bit of something that's a little bit nicer to look at at the end of the day. And we are going to ship a torque screwdriver in the case with every single device because they are hard to find. So at the end of the day, we have a pocketable device with... I didn't read your mind, I read the comments. The... We have a pocketable device with no compromise on ease of inspection. So at the end of the day, we build the device that you can go in your pocket and you can actually take apart and inspect with the screwdriver. We put the screws in the front and we've made it so that the cables come out in a reusable fashion. You're not going to break anything. You take apart and say, this is everything, put it back together again and then use it. So the idea is you can have a time of check, the time of use loop that's very small. You don't have to always do it, but it's available to you. So that's the idea. So precursor, we try to embody those three principles I talked about earlier in the talk. We want to make it simple so you can verify it. A full system. So you're verifying the whole system, not just components. And we're empowering end users to verify and seal their hardware by publishing documentation, educating users and giving them the source code to do these types of things. The current development status is that the hardware is production ready. So you're verifying the supply chain as much as you can in a pandemic. It turns out that a confluence of things like huge amounts of economic stimulus going into the people are buying a lot of chips now in the supply chain plus the factories haven't really fully opened plus Bitcoin is through the roof. So all the Bitcoiners are buying all the silicon. We're going to be a little behind schedule in terms of our ramp because we can't get the parts because there's so much competition right now for electronics in the supply chain. But we're, you know, that's my headache, not yours, I'm worrying. That's what keeps me up at night these days. The good news is from the software side our OS, our full custom OS that we're working on it, which is written by Sean Zobbs Cross is coming together. We now have a minimum viable product shell chat app running on it and just giving a quick shout out to the Internet Foundation for giving us a grant which allowed us to get to this point quite far actually to give us the point of the crowdfunding without having to rely on all that continuous integration you saw of all the cases and all that design all that stuff. That was pre-crowdfunding. We didn't do that after crowdfunding. That was before crowdfunding and that was done in part thanks to this grant. And you can go to this website here, precursor.dev to learn more about it. That's our crowdfunding site. We also have a GitHub repo which I think you can see down here if you want to actually look at the application and the OS for it. Sean was actually really insistent and I think he's very right in doing this and creating his operating system to be multi-platform so Zeus actually can run on your desktop in this environment. It's a mini, it doesn't have all the security properties of it but it has all the API calls and you can start coding for your precursor today even without having one. So you can go to our Wiki, BetrustedIO which is our github.com or github site and you can visit the Wiki and you can see the instructions for how to run our app. This is an example of our initial shell test. It is you type actually to your shell as you're chatting to it and it comes back to you with what commands you have available and it shows that we have like Emoji and Hansa already live inside of our OS and those are things that we're working on. So these are things you can start playing with today even before you get the hardware in your hand. And that's it for the talk. I know that we were running a little behind schedule so I tried to push things ahead a little bit. There was originally time for questions but I'll leave it to Homfuck to see if we want to do that or just want to cut to the next talk and stand schedule. So thanks everyone for tuning in and it was nice actually to have the comments on the side. It felt a little more interactive than just screaming into the void as I usually feel in the pandemic. Excellent. Thank you Bunny. I'm taken over from here and I'm happy to say that we have a few minutes for questions also and we can just later on make up for it as we have some breaks and I see the first question is from Roland. Roland, would you like to ask your question directly? Yes certainly. Apologies for the background noise. I'm sort of fascinated by the inspection of the screen in particular but but I know very little about chip layout how much do I need to understand about chip layout to convince myself that the screen only contains what it's supposed to contain. Okay so the idea behind the screen let me see if I can just very quickly get to I think the slides should be easy to find I'm almost there. Am I? Oh no. I give up on the slide. Oh here it is. The idea actually you don't have to understand anything about chip layout to understand what's in the screen because what you're looking for is the lack of presence of the silicon chip. So the idea is that when you look at your screen you could look at the transistors one by one. It's going to take a long time and I don't think it's a very productive exercise because the transistors are so large you're not, you can't, they're big enough you can't really do anything with them other than drive the screen. It's pack full already. There's no place to, you can hide another flip flop in there maybe. What are you going to do with one bit of information? Okay maybe something but it's not a lot you're not. So and also there's another complication that we have a backlight on it which keeps you from being able to put the high power light on the back side to look at it. So what you're really looking for is you're looking for the lack of this flak of silicon on it. So if someone went ahead and put another extra piece of silicon on the glass, a little chip on glass thing like they do in most of the LCDs then you know that this is not the LCD you want to use, right? That's all you're looking for at the end of the day. It's a very binary one or zero thing. Thank you, thank you. Thank you very much and there's another question from Mr. Marco. Marco, would you like to ask your question? Sure. Hello Mani. So my question goes more like the target audience of this device do you think like the general public would and should be interested in something like this and then do you think it makes sense to have a device like this when the general public will have other phone and would do the connections to the different banks and all those through the normal browser because this doesn't cover like everyone's day-to-day needs in terms of technology, right? Right, right, yeah. Would or should are different, very different answers. I don't think I'm realistic. I don't think everyone's going to be clamming for one of these from day one. I mean obviously this is a bit of an academic exercise almost in trying to figure out how do we build a device that even looks normalish and starts to satisfy some of these requirements. So I look at it more as a starting point. That's why it's called precursor. We're definitely not there yet. This is not going to be it. But I think it hopefully moves the goalpost meaning me forward enough that we as a community can start figuring out how do we use this and how do we make it more mainstream? How do we get it into people's lives? I do think that and also to be clear I don't intend this device to replace your phone. There is a place for that complexity. That complexity gets us wonderful things like browsers and cats on the internet and these things that we just don't want to get rid of for the sake of security. And it doesn't matter if you look at cats on the internet because you just get cats on the internet. But when we look at it, you still also want to have the app on your phone to do banking, but you want a true second factor. You want to I think what we're getting at and unfortunately this is the case for most security products is that the general public feels they don't need it until it's too late. So the thing that will catalyze the popularity of devices like this is unfortunately going to be an incident that will affect a lot of people and when they say, oh crap, I thought my phone was trustable, but in fact we all had some terrible situation happen and people clamor about it and why hasn't the industry solved this and why aren't we getting these types of things and then finally based on that demand, people may be more willing to have a second factor or they may be looking for second factor situations. So no, I don't think it's a thing that everyone's going to need from day one, but there are definitely people today who are not developers but more users who have continuances. I definitely want one of these journalists who want to keep in touch with contacts, they want to keep very confidential and they have state level adversaries against them, obviously is a very small market but I think it's a very important market because it's important to get the truth out there. But then a slightly larger market that I am not terribly closely connected to myself but I acknowledge it's a very lucrative market is the crypto guys. Those guys rely a lot on digital technology to hold increasingly large amounts of wealth and so they have concerns about fishing and reliability and storage and these people are willing the types who are willing to carry a second device around to have a wallet that secures some portion of their assets. Those types of people are not necessarily developers but they are actually users who understand and would be willing to do it. And I think as time goes on we'll sort of gradually shift towards a slightly more mainstream application of this and hopefully as time goes on and if this project is successful we'll have a v2 that's a little more powerful, that's a little more mainstream and has a little more connectivity on it without compromising on simplicity, without compromising on trustability. Those are the big caveats because we don't want to just reinvent another mobile phone. I'm not just throw a bunch of crap on the inside and make it hard to verify and say yep, you know, we won. That's the really hard battle is making sure that we hold true to our mission without while still serving the general public. There's a final question from Juan. Juan, would you like to ask your question? I activated your microphone. Alright, so how do you plan to Hey, how do you plan to develop and get the people in the software community involved in the software firmware apps development and do you think the phone should have some sort of capability to auto update and why do you decide to start OS from scratch in other words, but just stronger argument for you know, writing the OS from scratch. Okay. How do you Yeah. That's a series of hard questions. I'll start with the last one. There's the honest answer and there's the technical answer. The honest answer is we wanted to write an OS from scratch. That's fundamentally an itch to scratch. But the more technical answer to it is that we wanted to build a lot of the OSes today are too complicated and too hard to validate from the bottom up. And we also wanted to take advantage of the opportunity to rethink a lot of traditional things like POSIX file systems and ABI's and all these interfaces that we care a lot of legacy garbage along with us that actually inflates the size of our OSes and makes it more complex. And so we have an opportunity to build a file system that is well suited towards systems with virtual memory and flash and these types of things that gets rid of a lot of legacy stuff. And so we're looking at taking advantage of the fact that we're writing the OS from the bottom picking up every piece we put in thinking about it and being like, hmm, do we really need that? Can we shave off this piece? Do that? Can we fit it in? Can we keep it in a small code size? And so one of the debates we have routinely inside is like, we could solve that problem with a new syscall. Like do we really need a new syscall? Do we really have to add this? Can we remove a syscall? If we add one, like there's a big, for me, it's actually a big win when we manage to remove lines of code from the OS because it makes it more inspectable and more maintainable. And so I hope we can keep that spirit alive as we grow the OS and grow the community and get people more involved in it. But that's a very big priority to make it so that an average person, an average coder I should say, could pick up the OS, read our documentation within a day. This is the boot instruction and this is the path that it takes to get to running my application and I believe it. I have confidence that I have been like, oh, there was a little weird scene change that happened that I didn't quite get that went through a blob. That's kind of what it is today on OS even if you spend like a month looking at these things. In terms of engaging the developer community, I'll be the first to like pretty actually not great at community management. I'm more of a technical person, but I hope that we can do better at this and we've, of course, we publish everything on GitHub. We're trying really hard to add a lot of documentation out there. So I think I put on the wiki let's see a link to our documentation here. If you actually go, if you actually visit that we're really as on the fly as we go through every component what I do after we get to a release I go back and I write all the docs and I fix the docs. I'm trying not to like do all the docs at the end. We're trying to dynamically keep generating, keeping them up to date. So people will follow on and then we're doing this thing where you can and hosted both start developing apps today. So you could you could go here. You could go to Zeus core and if you have Rust installing system, you can do cargo tasks run and it should just pop up this UI and you should be able be running our basic shell chat application. So developers today can start looking at it poking at it and getting a feel for it. It's different on hardware obviously because the performance is very different. And the hardware actually does, you know, memory protection and this doesn't do memory protection, all this sort of stuff and a lot of the hardware features are only emulated with like fixed numbers like the battery life is always going to be 50% because that's all we report. It doesn't emulate a battery but we're trying to find ways to improve and engage the community from an early basis. So it's early days from that standpoint. I think we're still about unfortunately several months away from shipping any hardware so we have some time to figure this out. So if you have any ideas or feedback or people want to contribute, we're very open to the idea. We have an IRC channel which is listed somewhere in one of these slides here. You can pop in there. We're mostly there. I mean, you'll have to be looking at the screen to see the message. It doesn't come up on my phone or anything like that. Or you can open issues on GitHub. We try to be pretty responsive there. So we really want to engage with people who are genuinely interested in developing and doing things. Doesn't mean we're always going to take your commits. We're going to be curative. We're going to be trying to keep focused. And the answer a lot of times is if you want to do like there's a big group of people who want SCL4 in it. Great. Love it. I want to see that on it. But that's not going to be our core effort. I think SCL4 is a potentially really interesting powerful OS has capabilities built into it. It has a lot of good ideas. It's mathematically provable, whatever it is. These are all wonderful properties. And I really hope the community ends up forking and doing their own thing. Everyone just really wants to run Linux on it. Whatever. You guys do it. It's open. How about the auto update though? How do you plan to fix something that is update? I personally dislike auto updates because you're just forcing code down someone's mouth and I don't know it's in half time the auto updates interact with something and break something. So this might be more of a philosophical issue. I guess number one, I hope we have a code release standard that's high enough we don't have to just put we don't rely on updates as like the way to be lazy. So I want updates to be rare. I want users to be in charge of accepting the update. And in terms of doing updates themselves we do have basically the entire kernel the FPGA image itself and the embedded controller image, all of these things run out of a flash ROM which can be updated. So for example the FPGA firmware itself, once it's loaded into the FPGA Sorry, my phone didn't stop that. Once the FPGA has loaded its firmware itself you can actually replace the FPGA image and the next time you reboot it you better have done it right because at least you have a brick but you can actually completely rewire your FPGA you can actually change, you can add instructions to your CPU on the fly in your device if you're careful about it, right? And so the process there would be you would have an FPGA, it's running live in your system you would download the FPGA binary it's about two megabytes into RAM validate it, make sure it's right and you would then encrypt it to the keys on your device which are unique to your device and then write it into the slot of memory where the FPGA goes right? And then at that point you can reboot it and then the FPGA will decrypt itself from your root keys inside of your device right? So that would be the general path but that would be a user thing you would actually type, you know, get update, do update that type of thing, that would be my idea. I don't know if I answer your question but it's not the most ergonomic experience but that's also partially my prejudice in that I don't like ergonomic of the experiences. I want updates I actually want them to be hard, they should be hard and I find that developers who rely on auto updates tend to use as a crutch to be like, just push it out, we'll update it later, right? Just whatever your really standard goes down as updates become easier inevitably inside projects and it's almost like going to the gym, it's like I'm going to make it hard for us to do an update which means that we're going to make it hard to push coach means you have to do a better job. I don't know if it's a good idea to do it but that's where we're initially angling towards, we'll see where we end up I think I've burned a lot of time for someone else at this point in time I'm sorry Okay so we have planned with some breaks in between where we can make up with it but of course, thank you very much Bunny, it's been a pleasure as always and I always have the feeling you say, I don't know what to talk about and so on and at the end of your sessions I just feel there's so much more we can talk about and so much people want to know and for the next time maybe we should also think about and ask me anything question, you just could give a short presentation and people just asking more and more and really want to get into detail so that would be a possibility maybe Yeah, I mean you're the one who suggested the topic for this so it's good the problem for me, I live in this little hole like you're here in Singapore and I don't know what people care about anymore I'm just like today I'm going to go solder 5 circuit boards that's what I'm excited about and no one wants to know about that that's boring why not? and I always like your examples I think at one point you gave the example if we go out in a hawker store and we eat something and we take out our device so I really miss Singapore I've been there and done that I've been that guy in the hawker store with the wires and everyone's walking by and the auntie is looking a little scoldingly what's this guy doing in the hawker store I don't want other people to have to do that Thank you very much for this session and for sharing these nice examples and of course thank you very much for your work it's very important and we all appreciate it really very much and very deeply so I hope you find some other interesting talks here at the event we have an open tap coming up we have Eric Pan from Seed Studio coming up a lot of interesting sessions and on Tuesday Greg Kroer-Hartmann the Dino's current maintainer thank you very much for joining us have a good afternoon and keep in touch see you around, bye