 Everyone, Bedel is going to be giving us a Freedom Box update. Yeah, thanks very much. So thanks to all of you for getting up and being here for the first talk of the day on what is now the last day of DevCon for 12. Woo-hoo, we made it. Not surprisingly, it kind of looks like all the usual suspects. So out of curiosity, are any of you in the room people who have not yet had a chance to hear at least one of my talks on Freedom Box? OK, a couple of you. All right, so what I've put together for this morning is a little bit of what is, for me, review to sort of remind everybody what it is we're trying to accomplish and set a little bit of context. And then I'd really like to spend most of the time talking about what some of our recent progress has been. In particular, it's been sort of exciting this week because we both had activities underway here in Nicaragua at DevCamp and DevConf. And simultaneously, there's been a freedom-oriented hackfest happening in New York City where a number of Freedom Box developers were able to get together and make parallel progress on other things than what we were working on here. So it's been an interesting week, and hopefully I can capture a little bit of that. Those fans are kind of exciting. OK, so what's the problem? Out of curiosity, how many of you have a Facebook account, a Google Plus account, a Flickr account, YouTube? Yeah, OK, so actually I have all of those things, too. And in fact, in modern society, it's surprising how many of the things that we communicate with each other are being communicated through these sorts of free-to-us cloud oriented services. The problem with this, though, is that we're handing an awful lot of our personal data to companies to manage on our behalf. And we really don't spend very much time thinking about the consequences of doing that. And we're doing this at a time when our lives are under increasing scrutiny. There is so much data being collected about us with our willing participation all the time and the tools for correlating all of that and acquiring knowledge based on it are getting so much better that this is actually sort of leading us in an interesting and perhaps not such a great direction. And part of the reason for that is that for-profit companies, no matter how noble the intentions that they state in their terms of service must operate within the rules of the jurisdictions in which they operate, what does that mean? Well, that means that if you are using Facebook to organize a peaceful protest in the streets of your country and someone in your government is concerned about you doing that, they can demand that Facebook make available the list of information about who your friends are and who got the message about this. Would they want to give that information away? Probably not. Might they be forced to because they want to be able to do business in that country? We know it has happened. And lots and lots of other things like this are going on. As a consequence, many of us are now really quite concerned about the extent to which all of us as individuals are willingly putting lots of our information in the hands of other people to manage on our behalf. In effect, taking free as in beer services in exchange for letting other people have access to lots and lots of information about us in a willing kind of way. So what we would like to try and accomplish in the Freedom Box project, the vision that we have, is that we would like to take all of those things that people want to be able to do today, which many of us in the free software world already know how to do using tools that we have created that are free and open and that we can inspect using distributed servers where those servers belong to us and so forth and make it possible for other people to take advantage of those things too so that we can offer alternatives to these sorts of free as in beer but otherwise somewhat concerning centralized services. So the vision of a Freedom Box is that it's a personal server running a free software operating system and applications that are designed to create and preserve personal privacy. And one of the parts of this vision is that we'd like these things to be able to run on cheap, power-efficient computers that individuals can afford to install and operate in their own homes. And part of the reason that the in their own homes thing is so important is that in many countries around the world, the laws around what you may do in the privacy of your own home and the burden of proof required by the authorities to obtain permission to come into your home to take something from you are very different than the regulations around what happens with data that you have willingly uploaded into some other server run by somebody else in some other location. And so this is why you'll see that we've had quite a bit of attention being given to low-power arm-based plug servers and so forth. We hope in the process to contribute to building privacy respecting federated alternatives to contemporary social networks. That's a lot of big words. What we're talking about though is that we would like for all of the people trying to build software to do things like Facebook in a distributed manner to have a platform available that lots of people can use to be able to run that sort of software. And within the FreedomBox community, there's an intense interest by at least one sub-community in the idea of mesh networking. That if we're going to give lots of people small low-power devices that they'll run all the time at their houses that have good wireless network interfaces, wouldn't it be nice if we could use those wireless network interfaces to establish, in effect private backhaul networks so that if somebody takes your internet away, you don't completely lose connectivity with your peers. And certainly in times of natural disaster or civil unrest that there would be an opportunity to rapidly deploy replacement connectivity to allow people to be able to get on with doing the things they need to do. And if all of this stuff could happen, the sort of ultimate objective we have is to facilitate people collaborating safely and securely with others in building social networks that are capable of supporting demonstration, protest, and mobilization for political change. So we kind of start with this notion that, gee, we're all giving a lot of our personal data up to other people to manage on our behalf and we sort of end up with, and if we're not careful, we're going to lose the freedom to do some things as a consequence. So can we build an infrastructure that makes it possible for us to have these federated, distributed alternatives to these existing social network services? So all of this is kind of, you know, the work that we're doing was inspired by Evan Moglen and in fact, for many of us, his keynote at DEBCONF 10, almost exactly two years ago today in New York City, was a major turning point. It's the moment when many of us sort of wrapped our brains around this and said, ah, yeah, okay, there's a problem that's worth working on. It took several months after that DEBCONF to sort of begin to get organized and what happened is Evan founded something called the Freedom Box Foundation. It has a small board of directors. I agreed to join that board and have served on that board. That was announced, I believe, shortly after FOSDEM, roughly a year and a half ago. James was selected as our executive director. I agreed to put together a technical advisory committee. We began talking about this idea of creating working groups and Evan and others began trying to find some money because our original hope was that we would be able to find enough money to be able to pay some people to do some of the difficult pieces necessary to make all of this stuff happen and then this technical advisory board would try to guide the activities of those people. Didn't quite work out that way. We've ended up following a different path. I'll talk about that some more as we go along. In the context of the foundation though, what we realized very quickly is that this is more than just a free software project. If you really want this kind of technology to be able to be put in the hands of a large number of people, it has to in the end be something that people can buy at retail. They have to be able to walk in somewhere and buy something that says designed to be a freedom box or this is one of several types of freedom boxes. And to do that, there's more that has to happen than just making great free software. So the first pillar of the four that we talk about in the foundation is the technology. That's the free software work. That's the stuff that I and others have been spending a lot of time on. But it's also very, very important for us to have a reasonable user experience. For example, one simple example is it's pretty clear to us that using GPG keys as the root of identification and trust within the freedom box network makes lots of sense. But the GPG command line interface is sort of one of those horrors from the seventh circle. In fact, even this week, people here at Debconf who really understand this stuff have been struggling to make sure that they had all the right options set when they were creating keys so that they had all the right attributes. This is clearly a place where there's an opportunity for us to make contributions towards having the software be more tractable to people beyond our geeky friends. And so user experience at all levels, user interface design and so forth is something that we've been focusing on. And I'm pleased that after a fairly long dry spell, we finally had some people who know what they're doing helping us to make some progress on this. You can't run a foundation without making some noise about what you're doing and trying to raise some money. If anything, this is sort of interestingly the place where I think we've fallen down some over the last year. I've been giving talks about freedom box and what we're doing at lots of different conferences, but we realized recently that we've been remiss at doing things like going back and posting updates on the Kickstarter site to let the folks who supported us early in getting the money together to start the foundation know what was happening. There's been lots and lots of discussion on our mailing list, lots of things going on in our wikis, our IRC channel has occasional bursts of activity, but somehow lacking somebody who's focused on doing the public relations bit, not all of that has been sort of brought together and communicated back to all the folks that have been interested in our project as we might have liked. So we're gonna try and fix that going forward. And then finally, there's this pillar of the work at the foundation that I call industry relations. This is sort of a euphemism for working with hardware folks. And the problem is if you wanna work with people like system on ship manufacturers and the device manufacturers who build products using those systems on ship, you often have to be willing to sign non-disclosure agreements with them to talk about what they wanna do in the future. I think we all understand that there's sort of an incompatibility between doing that and working on free software. There is in fact an inappropriateness in expecting a free software developer to be willing to sign broad non-disclosure agreements. So one of the things that the foundation has been able to do is to go talk to some of these organizations to interact with some hardware developers. I actually have some very, there's some very exciting news in that area we are actually making progress towards some interesting hardware, but all of that can only happen if people are able to have those kinds of conversations and those kinds of circumstances. And that's something the foundation can do and act as sort of an interface between that other world around hardware and those who would like to just work on software. I won't belabor the membership of the technical advisory committee. It's actually not been where the bulk of the excitement has been recently. There are a set of working groups. Different of these working groups have been more or less active than others, but as I reported when I first started, there's been quite a bit of progress made recently at a couple of hack fests organized in New York City and things that have been happening here and these represent several of the different working groups. Okay, so enough about the foundation and its structure. When we began this work, we made a few early decisions and those decisions have sort of shaped the way progress in the project has gone since then. The first thing we did is we decided that we really had to bound the challenge a little bit. It's very easy when you start talking about Freedombox for lots of people to have lots of great ideas and before you know it, you have this huge sort of realm of possibility, but somehow you have to pick a path through that. So one of the early decisions was let's focus on software and not building a piece of custom hardware. In hindsight, I'm not really sure that was a great decision and I'll talk about that some more later. The second, but at the time, it seemed like the right thing to do because after all, software is something that lots of people in our community know how to work on and hardware is kind of a pain in some ways and there were elements of hardware we could go by that would do pretty much what we wanted. We also chose to focus on servers and services, not client devices. I would love for there to be completely free software, privacy and freedom loving phones too, but that's not the focus of the Freedombox project. And we decided we would be a platform for federated distributed social networks. We were not ourselves trying to build a federated distributed social network. There are other people working on interesting software stacks if we could provide them with a platform on which their software could run, that would be another good way to sort of bound this. Exactly what that means in the long term is we start to accumulate, accrete and integrate more software, that will change over time but for now these were sort of bounding conditions. And then the other big decision we made was there was a lot of discussion for a long time about, well gee, you can't possibly actually be free and be insulated from denial of service attacks from your government if you depend on the domain name system, for example. And to some extent that's true, but again, you have to sort of decide how many problems you think you can solve at once. In HP where I work, there used to be a wonderful saying that we would limit ourselves to no more than one miracle per product. And this is one of those places where choosing to bound the number of miracles we're trying to have happen all at once seems appropriate. So why is it that this is all sort of being done in the context of Debian? Well, I suspect a DebConf, I don't need to spend much time talking about why Debian makes sense for FreedomBox. Anyone have any questions about that? Yeah, okay, great. But the flip side of this is I think equally important. We decided very early on that we wanted to deliver FreedomBox ultimately via Debian. And what I mean by that is I wanted future stable releases to just have everything needed for FreedomBox available in the distribution out of the box. That we would build the FreedomBox with Debian packages that all new software that was created for the FreedomBox would be packaged and delivered via Debian. The real motivation for this frankly is that no matter how successful we as a project were, all of our work would survive, remain available, and be easy for other people to aggregate and incorporate and think about and use in the context of creating other devices and other services that would enhance and preserve personal privacy and freedom. In all honesty, in recent months, I think we've been, my report card on this would be maybe a C plus or a B minus. As I'll report in a little bit, there's been substantial progress towards getting the hardware enablement support for the initial platform we chose into Debian. But some of the software that's been developed for FreedomBox is still basically living on individual people's laptops or in their Githubs, and some of it hasn't been packaged yet. And that frankly is where going forward from here, now that we have some sort of positive results and some milestones that were reached in the Hackfest this week in New York, I'm really looking forward to spending some time in the near future helping to get the rest of those pieces packaged in. This is still the objective right now today when we build images, there are three or four things that we're pulling source repos of to build from instead of building the amount of Debian packages. And I'm a little personally disappointed in that, but we'll get past it. Okay, so hardware. Well, I said initially that this is gonna be about software and not about hardware, but the problem is that we made some commitments to people in the Kickstarter campaign that we would deliver them some actual FreedomBox hardware, and in order to be able to demonstrate that we could actually deliver on the promise of making stuff work on low power, physically small, low cost servers, we sort of had to pick something to use for that. So the initial hardware target for the reference implementation of FreedomBox that was chosen is the dream plug from Global Scale Technologies. I have a couple of them in my bag here. Let me pull one out just so you have a sense of physical scale. This, that's a dream plug. Some of you have seen me this week working with this with other people in the Hack Labs. Actually, that's the power supply. That's the server. And this takes five volts in at some modest number of milliamps, and I have very successfully run one of these for a number of hours on four AA batteries when doing a demo in Brazil. And so this actually is a very functional, very useful arm system on chip based server with modest amounts of storage capability, a bunch of interfaces and all of that as you can see here on the list. And it does run on really low power. And the low power thing is more important than you might suspect because there are some geographies where power is just not as reliable and available as many of us are accustomed to. And the notion that you can run something off batteries that you charge during the portions of the day when you can get access to some sort of utility power or solar panels or whatever, and then run off those batteries the rest of the time is important. It's also true that for some of our peripheral objectives around making it possible for people to use devices like this to build network supporting political and social change, that the idea that you can drop nodes into interesting places with a little bit of battery on them and get many hours or even days of use out of them is fairly exciting. For those watching the streams that couldn't see the hardware real well, that's what one looks like with sort of an artist rendition of the old Freedom Box logo on it. But the problem with picking an existing device that was available is we ran into all of the problems that everybody trying to do anything with free software on devices like this run into. And as you can imagine, deciding that you're gonna build a software stack in a project inspired by Evan Moglin on hardware that has GPL violations just isn't gonna happen. So unfortunately, we spent more time than I would have liked to chasing these things down. We were in the end able to resolve all of them. My only remaining frustration is that the micro access point wireless chip that's in these devices and which is in the same family as the part that was used in the original OLPC XO notebook machines requires an out of tree kernel driver because it uses some non-standard interfaces and their kernel community really doesn't want that driver in their tree. Not a huge big deal, just kind of annoying has to be packaged separately, can't be part of the kernel source tree. But there's lots of other interesting hardware out there and the last thing I want to have happen is for people to say, oh, you know, some limitation of the dream plug is an ultimate limitation of the Freedom Box. There are other plug servers out there. Many of the folks working on the Freedom Box project also have Shiva plugs which are the earlier plug server generation from global scale. It actually has very similar specs. It has the JTAG interface integrated which developers like me really like. There's something called the Teneto plug that I've played with one of. It's kind of interesting. It has one less wired network interface but it has room for an internal two and a half inch SATA notebook style drive. That's pretty cool for making a portable deployable file server in a hurry. I think it actually might be very interesting before DEB Conf next year for us to think about whether some of the conference infrastructure could usefully be deployed on one or another set of these sorts of devices. We've actually done really well I think this year with getting the point where all the services we expect to have working at a DEB Conf have been in pretty good shape but there's been a lot of running around to try and make that happen. One of the things I'm personally scratching my head about is whether we might be able to help an event like this be even easier to set up and quicker to deploy if we had some of these sorts of devices around. I don't know. There are a lot of set top boxes that have sort of fast video interfaces too and less networking that are also based on low power arm devices. Some of those can be relevant. And look on some level because of this objective and approach we're taking of having everything integrated into Debian, any hardware that can run Debian can ultimately serve as a freedom box. And as I was discussing with somebody over breakfast this morning, you could even run a freedom box instance in a virtual machine if you want. There's no reason that that can't happen and can't work. But as I mentioned earlier, sort of the fundamental objectives we have at the foundation is to make these be devices that people can afford to buy and deploy in large numbers in their personal residences on their own networking where they've got control. Okay, so that's all sort of background context, things that many of you I'm sure have heard me talk about before. Let me talk now about some things that sort of qualify as recent progress. Nick Daly went to work and built this thing called Santiago and then there's sort of a user interface called FreedomBuddy on top of it. This is a service discovery and management protocol. It's designed to make it easy for people's freedom boxes to find each other and for people to share services with each other without actually having to know a whole lot about where the other person is on the network or things like that. It uses open PGP sign and encrypted messages over an HTTPS connection to reduce the attack surface for man in the middle attacks. The mode in which it's being used at the moment most often is that you establish a single Tor onion address for the other Santiago instance that you're interested in interacting with or the set of them that you are. And then these devices can use the Tor network to establish initial contact with each other. I personally have not had time to spend much to put much attention into this code or to play with it very much. Everybody that's using it seems to be really excited about it. I'm looking forward to spending more time with it. The first release candidate was actually announced in mid-May of this year, so not terribly long ago. And this is now part of Nick's weekly builds of images based on the Freedom Maker tool set that I started working on a little over a year ago. Here at Debcon 12 and Debcamp over the last week and a half, the most exciting milestone that I can report is that hardware support for Dream Plug is now in Weezy. Friday night, a week ago, Hector Oran and I sat down and got the last little bit of the Flash kernel config stuff done. This is the utility that knows how to manage kernel images and initRD images and create the config files needed for booting devices like this. We got that done, we got it uploaded, we got it unblocked, and I was pleased to discover yesterday that the kernel images we need and Flash kernel are actually in testing now. And so yesterday, we were successful at doing some testing using those files entirely coming from testing. The user space tools for the Marvell Micro Access Point I packaged at Debcon last year, those are also in testing. We have not done the separate packaging of the device driver for those yet. The kernel packages that we were using until a couple of weeks ago were an out-of-tree build that included that driver in the kernel image package now that we've switched over to using the Debian pre-built Kirkwood kernel image packages. We need to get that driver turned into a module assistantable driver package. It shouldn't be hard, we might even get that done today. And then hopefully that can also be on the way to being released. And then thanks in part to Ian doing some quick work on config bits and pieces. We were yesterday underway in testing Debian installer. Given where we are in the beta one schedule for that I think what we'll try to do, sounded like the right answer was to try and merge those changes after the impending beta release, which means that hopefully by the time of the Weezy Debian installer beta two release that support for the Dream Plug would just be included. So for me personally, since I've been focusing some of my time available time on trying to get all this hardware enablement stuff done, this is a really huge milestone. I'm really excited about it. It follows through on that sort of commitment I made to myself more than a year ago that we would have the Dream Plug and the rest of the Freedom Box stack supportable in the next Debian stable release and turns that into something that's now actually true. And in parallel, there's been a lot, I've been doing a lot of work on the Freedom Maker tool because a lot of what it was doing was frobbing around with kernel bits and so forth. And now that we can use the packaged kernel and flash our kernel bits from the distro, I've been making updates to that. Nick Daley's been working history in parallel at the HackFest and there's a little bit of merging that needs to happen. He and I were chatting on IRC about that last night and again, hopefully over the next day or three a lot of that will get done. So as I mentioned, in parallel with what's been happening here at DebConf and DebCamp, this week there was also a HackFest held in New York City. I don't know a huge amount about exactly what went on there. I got a quick update yesterday and my understanding is that this involved not only people working on FreedomBox, but lots of people interested in related software. And so these folks were all hanging out on other communications channels than our normal hash FreedomBox channel on OFTC. So we had a little less live communication during these parallel events than I might have hoped for and we might try in the future to do that a little better. But there's some really interesting results. One of the things we wanna include in the initial images is a PrivOxy installation and James had built this really large PrivOxy config with a lot of Regex and apparently some folks spent some time going through and validating those and the confidence level in the suitability of that PrivOxy config went up a bunch in the last week. Again, until we have a little more thorough detail on what happened, I'm not sure exactly what that means, but I'm hoping that that means we'll very shortly be in a position to either package or to offer that config up as an alternate config for the standard Debian PrivOxy package. So work was done on this sort of first boot experience for a plug server running FreedomBox software. As you can imagine, a lot of these devices don't have a user interface in the sense of a keyboard and graphics display. And so what exactly it should do when you turn it on for the first time and how you should access that has been a topic of much discussion. I have opinions about this. I don't know exactly what they decided at the Hackfest made the most sense. Supposedly somebody's put some slides together describing what should happen in the sequence of that. I hope that that deliverable will be shared sometime in the next day or three and we can find out what they decided was a good idea and go forward from there. I mentioned earlier that there's been quite a bit of work happening on user interface. James wrote a Python framework called plinth that is a wonderfully lightweight web access oriented user interface construction toolkit thing. It's one of those deals where if you wanna add another function to the user interface, you write a little code fragment, put it in the right directory and it automatically assembles those into a user interface. I was quite a bit of work done apparently on that in the last week. Connecting some of the plinth UI pieces together to the actual action scripts that do things on the system. I have not, since I just found out about this last night I haven't had a chance yet to go look and see what if anything from that work has actually been pushed into their repos yet but I hope we'll be able to fold that into images very soon. Apparently Nick also worked on a command line interface to his freedom buddy thing so that that's easier to configure and use. I don't know exactly what that means yet but we'll find out soon. One of the things we've talked about quite a bit is making it possible to have automatic configuration or better configuration of using OpenVPN as a way to access your own freedom box from some kind of client device. For example, a lot of us now are running smartphones that are using alternate builds of Android like Cyanogen Mod which comes with OpenVPN client support out of the box. Being able to take advantage of that is a way to have a reasonably secure connection to your local box seems important and of course OpenVPN is well supported in Debian so my hope is that the work that they've done will actually be a big step in that direction. Jason Cooper who helped us a lot over the last year with getting the UBoot pieces merged and upstreamed and who also helped get some of the dream plug specific kernel content merged into the kernel.org tree also has been using OpenVPN in this sort of way and is described to me the config that he's using so between those two streams of consciousness I hope that sort of all comes to a useful conclusion fairly soon. And I understand there's also quite a bit of work done in New York on internationalization support starting to add a multilingual support both to the PLINT UI and to some of the other pieces in the system. I guess to the FreedomBuddy tool as well. So where do we go from here? Well we have started to talk about FreedomBox 1.0 and to describe a set of features that we think it really should deliver. This has been revised and updated quite a bit since other talks I've given in the past. And to some extent what's happened is we've sort of realized the difficulty of achieving some of the things that we had hoped initially might be simple and obvious. And so what we have now is a defined set of deliverables for FreedomBox 1.0 is a PrivOxy configuration with a rich set of rules that I was just talking about. The value of this is that if you're going to deploy a FreedomBox as a replacement for an existing wireless access point or firewall or router device of some type, using PrivOxy we can help provide additional privacy and security enhancements for all of your other client devices routing their traffic through your FreedomBox regardless of whether you actually take advantage of other capabilities that we might deploy. And that seems like a really worthwhile thing to be able to do. So one of the deliverables that we want to be part of this is a richly configured PrivOxy instance that people can use to increase the privacy and security of all of their web interactions. As I just mentioned, we're hoping to have a nice open VPN config for client connections. Wouldn't necessarily be the only way you could interact with the box, but it seems like a really good choice. The Santiago slash FreedomBuddy stuff will be integrated to make it easy for people to start to set up and share services with each other. And the plinth user interface with modules at least to support initial setup, some DHCP style configuration things, sort of minimum set of controls you need for a configuring tour and so forth should all be part of that. Exactly how much of that is implemented and how much more beyond that might be part of the plinth interface by the time we get to something I might start thinking of as a 1.0 remains to be seen. So going forward from here, I'm hoping that we'll be able to do sort of periodic releases of a reference implementation sort of to finish integrating the user interface framework. We're very interested in sort of integrating more monkey spheres style functionality and other SSH tricks, whether those things will actually be done, by the time we declare something 1.0, I don't know. I've talked in the past about the desirability of building a secure XMPP based chat stack. We've backed off of that slightly, at least for the short term until we figure out the client access to the device piece a little bit better. It may be that once we have the open VPN configuration to a point where it all makes sense that putting this back on the list of things to deliver is easy because after all, we've got things like JW Chat as an Apache hosted XMPP client and good XMPP servers in Debian. It just, the approach that we were talking about using of trying to support GPG key based access to the local node to have an initial chat service, just turned out to seem a whole lot more complicated than what anybody really wanted or needed right away. So we kind of backed away. I'm hoping we'll come back to that once we get the client access piece working. Then I hope over time that we can work up the stack and add more applications. In parallel, various folks have been talking to me here about supporting other platforms. I think one of the more interesting things to work on would be to add back in or add in explicit support for creating some x86 virtual images, virtual client images to the Freedom Maker tool. Again, we've had a couple of conversations here at Debian Conf about ways of doing that. Lars had done some work a while back on a tool for creating virtualized client images that was sort of in parallel with and never got integrated with Freedom Maker. Now that Nick Daly's done the work to build micro SD card images and integrated that into Freedom Maker, I think we actually have most of the pieces around that we need, and I'm hoping again that just a little bit of work will help us make that happen. And for lots of people who don't actually want to have to fumble around with an ARM-based device in the short term, this could be really, I think, helpful way to enable people to help us work up the stack and get more things done. Another thing that I'm personally working on, I mentioned earlier that the decision we made to not do purpose-built hardware early on is one that I have questioned a couple of times since then. And part of the reason for that is that I realized at some point the amount of time that I'd personally spent futzing around dealing with GPL compliance issues on other people's hardware exceeded the amount of time that I think I personally would have needed to take some new piece of purpose-built hardware and bring it up and get an operating system stable and happy on it. In fact, even in the last week, the amount of fumbling we've done dealing with U-boot, flag day issues with kernel configs and all of this, somehow when you're trying to deal with somebody else's hardware, all of this just ends up being immensely frustrating. And if it's hardware that you've built and are turning on, it's immensely exciting. And that's a huge difference. It's also the case that somehow, I think it's been, we've had a difficult time providing a focal point for people to rally around within the project. And I'm hoping that as I start to have a little bit more time to focus on Freedombox in coming weeks and months, that maybe we can resolve that in any case. But I'm really tickled that at least one credible hardware development community is now actively working on a purpose-built device for projects like Freedombox and Tor for the future. And it's gonna have some really neat hardware capabilities in particular. A lot of attention is being paid to details like hardware random number generation, the ability to do precise time stamping and other things that turn out to be really helpful and useful for building the kinds of services that we're interested in. There's also been a lot of discussion about this notion of creating some kind of a free phone instance. This is peripheral too and sort of different than what we're trying to accomplish with Freedombox. But there've been a bunch of attempts to try and build an open phone from scratch. Many of you here I think have done open moco things in the past. And it would have been nice if any one of those really achieved critical mass and became really useful. Do you have a question? Just want to advertise a bof later in the day. There's the Debian mobile bof. Anyone who's interested in freedom phone stuff should probably come to that. Yeah, absolutely. That's absolutely true. I put this slide together before that happened. I just wanted to observe that the fact that HP made a decision a few months back to release all of the web OS bits and pieces under Apache 2 licensing and that that work has been proceeding and they are anticipated to complete that process in a very short number of weeks from now means that there's another interesting sort of code base available there that we could try to maybe do something interesting with over time. This is not something I'm planning to work on. I've got sort of too many projects in the queue already. But several of us here at Debian have talked in various contexts including in the mobile bof about what to do here. I'd really like to see somebody come up with a truly free client device that we could all actually get excited about and be able to run on a bunch of devices. So what can you do to help? Well, the first thing I'd like to ask all of you to do is please be conscious about privacy and your other freedoms and everything that you do. I suspect everybody involved with Demian does have a GPG key now. If you don't, get with the program. Join a working group. There's a lot of interesting discussion sub things happening within the Freedom Box community. If you can actually get to one of the hack fests which have mostly been in places like New York and San Francisco so far, but could certainly happen in other places as well, please do that. It's an excellent opportunity to meet and work directly with other people who are excited about this stuff. Please, there's a bunch of Wiki content under the Freedom Box portion of the Demian Wiki. Some of that could use updating, lots of it though is directly relevant. You could certainly help me out a lot by helping me to select Demian packages and getting the configuration specifics right to deliver the various things that are part of our vision. And I would be remiss if I didn't mention that the foundation is a non-profit in the US. It's actually for financial purposes associated with software and the public interest and financial contributions are always welcome. Wouldn't be me if I didn't throw one of my sort of thought provoking quotes for the day in this one from Ben Franklin. Many of you've probably seen this before. They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. Every time we take advantage of a free service, we need to remind ourselves that nothing is ever free. What is it that you're actually giving up in order to have the right to use that service from that cloud service provider? In a lot of cases, you are willingly or unwillingly giving them the ability to mine an awful lot of information about you as an individual and in the process you're making it possible for lots of other people to get access to that information about you that you might not have even thought about. I don't wanna spend any more time today on the scary part of this, but I hope that as we go forward, everybody becomes and remains conscious about these things and continually looks for ways to take all of the good stuff that we have done and that we have developed in the free software world and make it more available to our peers beyond our community so that we can have a freer, safer, more distributed and more robust network experience going forward. With that, we've got a few minutes left. I'll be happy to take some questions. You can find more information about the foundation at freedomboxfoundation.org, including a report that was just posted on the Hackfest in New York and most of the technical details of what's going on are one way or another under the wiki.dev.org Freedom Box page. Okay, question? Yes, I see that one of the motivations you've mentioned is the importance of private and secure communications for people in a political context and I support that, that's all well and good. But I believe that it's also just as relevant to people in entrepreneurial pursuits, in free enterprise. To make an example, there was a recent, there was an Apple released their iCloud, iTunes match type service where someone had actually submitted an app, very similar to that to Apple six or 12 months before. Apple sat on the app and then they released something just like it. I mean, this is an example of big corporates sucking up people's ideas. No one knows whether Apple was already working on it or whether they duplicated the guy's idea. But this is another area where this should be getting people excited about Freedom Box. There's a lot of people who may not identify with political protests. There's a lot of people in my country in Australia who live a very comfortable life and they're not politically active like the people in Libya or Syria. But they still have reason to be concerned about surveillance and monitoring and big corporates and so maybe we need to wake up those types of concerns as well. Well, so my hope is that as we actually begin to deliver bits that are useful to users that will start to grow sort of the community of interest. It's absolutely true that those of us sort of in the core of the project and in the core of the activity surrounding the foundation have a particular combination of motivations. I certainly hope, as I mentioned, that by doing the work the way we're doing it that all of the things we're working on help to sort of enhance lots of different activities. I've commented before that if we were gonna start this over again, calling up the Freedom Box project instead of calling up the Debian Uber Freedom Privacy project and we could have all sorts of discussions about what will the net effect be versus what was the initial set of thoughts and vision. But you're absolutely right. There are lots and lots of things that the work we're doing hopefully will help people with. Thomas, you had a question? Yes. When the Freedom Box project started, one of the idea of software was having a backup so that I could save, let's say my laptops, files on my buddy's Freedom Box encrypted there and distributed in a distributed way so that we could have redundancy. Has any progress made, has it been made on that side? I've personally had conversations with Zuko, Hearn, and others in the Tahoe Lafts project about the suitability of the file system work that they've been doing to a Freedom Box kind of structure. And we all agree that at some point building the back end piece to make it possible for that to be a securely distributed file system that runs on top of Freedom Boxes makes a lot of sense. It's a place where work could stand to be done. The nice thing about the Tahoe Lafts stuff is it appears to me to provide the right kind of user interface, the right sort of layer to allow the sharing of redundant data across different boxes to happen in a way where I can agree to provide you some backup service for your data, but I don't ever actually have to see any of that data that those objects are encrypted in an appropriate place. And the API and the redundancy mechanism is in place so that the loss of a single node doesn't cause the data to go away and all that sort of thing. In all honesty, though, it has not, I don't think a lot of work's been done on that yet. So if that's an area you're particularly interested in, I would certainly encourage you to dive in and help. I'm happy to help make contacts between people to make sure that the right folks are talking to the right folks to be able to make progress. And anytime somebody hands me a, hey, look, this is shiny and it works. Would you put it into the config if it makes sense? I'm happy to work with Nick Daly and others to get those things folded into our freedom maker toolset and become part of the reference images we're building. Tom. So as you're working on free hardware, what are your thoughts about BIOS or bootloaders, in particular core boot, or any of the other free BIOS-like alternatives? The fewer bits that run between turning the hardware on and having a Linux kernel up the happier I am. Time's out. OK. Thank you very much for your time and attention and to all those who are watching remotely. I will be around the rest of today here at DebComp. I'll be in the hack lab when I'm not in talk sessions. Please feel free to come by and ask other questions or talk about things that you'd like to work on or would like to contribute. And beyond that, thank you very much again for your time and attention.