At MozFest I got speaking with someone who is working with Purism on the Librem phone. It’s a free and open source phone all the way down the stack.
Their focus so far has been privacy, but they are following ethical design principles, and they were keen to hear ideas on how they can make it a long-lasting phone too.
Off the top of my head some repairability suggestions I had:
screws not glue
provide repair manuals (they have open schematics)
provide spare parts (and maybe partner with someone like iFixit to offer repair kits and possibly ease some of the logistics of supplying parts)
From the software side…
guarantee minimum 5(?) years of security updates (it’s built on top of Debian so hopefully that would’t be too much of an issue, and as I understood they have control of the code for all firmware)
make it easy for community to build/install their own OSs
Any thoughts and other suggestions you would also pass on?
29th of October. Today 5 years ago since the Thunderclap of Phonebloks. A graduation project. It was never my intention to spend a lot of time on this. Wasn’t super interested (or felt I was able) to develop a phone myself. I felt I could be more useful working on the plastic problem. Developing machines, designing products etc.
So I made a video to share the phone project with the world. A lot of stuff happend in that time, from a school project, viral on the internet, hanging out in Silicon Valley to a thrown away Ara.
Years later that is still my most common question, “what happend with phonebloks.” Just for this jubilee I made this video. So if you ever ever come across someone on there on the internet asking. Show them this.
To make a long lasting phone there are two main things to consider.
Any parts that are known to have a finite lifespan should be easily replacable, preferably by the user and not having to take it in for specialist repair. The obvious one is the battery. However memory can also fail, so I would suggest all memory should be on SD card or similar.
The phone should be manufactured without any changes to the design over a very long period. Thinking of the car world, think of things like the 2CV, original mini or Landrover. A 30 year life for the overall design should easily be possible. As technology advances it gets smaller, so it should always be able to fit into the original casing so case, screen and keyboard could be very long lasting.
I would suggest making the operating system a choice for the user.
Original Fairphone 2 phones are now well out of warranty. A person bought one at the Hackney Restart Party. She was keen to keep using it, but mobile data connectivity kept dropping and she couldn’t even log onto wifi. She contacted Fairphone who only offered to replace everything but the screen, obviously a (too) expensive solution.
By doing some research she found out that someone had fixed a similar problem by clicking the aerial connection further in place. So we opened that module (bottom left, just left of the USB connector block). The cover was held by two Torx screws (so second level of difficulty of repair, i.e. not a module swap, held with Philips screws). I cleaned the two contacts with some IPA and reclicked the coaxial connector, and we put things back together. She was able to connect to the local Wifi and got on the mobile network (when outside the building as the school has very poor mobile connectivity). So the initial diagnostic is that this is fixed with just a bit of cleaning when Fairphone’s solution was to replace most of the phone.
It’s interesting that Fairphone’s design did help fix this easily (assuming this is a lasting solution), but its out of warranty support appears, in that case at least, similar to that of other brands: replace most/all of the device at high cost.
Very interesting @Panda! I think we should send this feedback to Fairphone. Is the module you repaired the one called “Bottom” in this list of spare parts provided? https://shop.fairphone.com/en/spare-parts
I’ve noticed that they have recently (finally!) released Android 7, as well as lowered the price of the device.
They should already be fully aware of this, but feel free to share.
No, it’s the one at the bottom left of backplane marked 4 in https://shop.fairphone.com/media/wysiwyg/sparepartsheader.png
You can see the aerial wire going along the backplane and under that cover. You can also the other contact, next to the bottom left screw, that will press on the cover covering that backplane.
That isn’t, - You want to take the ownership back, right, as I do ?
You can install LineageOS to Fairphone2, the guy called chrmhoffmann (Fairphone2 Lineageos maintainer) is amazing, he has developed LineageOS 15.1 (8.1) for a very small number of FP2 users. Without him, Fairphone project itself is a plain disastor.
Even you can use your FP2 without Google Account very comfortably. If you wish still you are able to use even google application such as Gmap, youtube as well as the majority of standard application such as Banking App etc.
MicroG is not a restart topic, as without MicroG, you can extend your device life. but you would be interested in this ?
Then, nobody forces you to use which application has to use or when you have to give up (due to software support ends) Take full responsibility and freedom by yourself (this is not for the everybody’s solution !!!)
MicroG for Lineage won’t use Google Location service, instead use Mozilla location service for instance. (So this is not only about user Apps but also background services)
MicroG is a free and opensource alternative to proprietary Google Playserivces. Installing MicroG used to be complicated and messy but it is now very straightforward and very stable as well. Recently I have upgraded to LineageOS 15.1 for microG, .
I would like to see a fully open source phone design.
All the modules to make a phone from scratch exist, single board computers like the raspberry pi zero, touchscreens and SIM modules are cheap and readily available. When everything is modular, and maybe you assemble the device yourself, fixing broken parts becomes much less daunting. Developing a mobile operating system from scratch that worked reliably would be very tricky though.
As for a wish list of things i think the big players could implement, it would be a lot of what has already been said, mechanical fixings, removable batteries, and swappable (maybe even tool-less?) displays. Basically build repairability into the design.
That is unlikely to happen as to connect it to the network you would need to go through a (complex and expensive) type approval procedure, so the phone/modem part of a phone that deals with the mobile comms aspect of a phone will remain a black box for the foreseeable future. The app side can indeed be fully open source. Most, if not all, mobile phones are conceptually two devices put together: a phone part and a computer part, with two operating systems.
The point I was about to make. And worse, the baseband module as it’s known, being closed source, has had little scrutiny from a security point of view. Not long ago it was reported that it typically responds to a large range of AT commands (the same type of commands which were originally used to control dial-up modems 30 years ago) - a hacker’s paradise! Vulnerabilities to malformed data packets received over the air likely exist and it’s very possible, some would say likely, that the spooks of several nations are already using these for surveillance.
AT commands interpreters were already pretty solid by the time modems stopped being common place. That’s not the source of most security issues. What keeps happening is for malformed packet data units (PDUs) to crash or cause memory leaks in the software dealing with them. In particular SMS PDUs have exhibited several vulnerabilities.
How to do reliable transmissions is well known so it is more likely that the packets are malformed at one end (with good CRCs) rather than when transmitted.
The easiest and cheapest way for spooks from a nation state to do surveillance of a mobile these days is not at the mobile phone level but at the SS7 level right from their desk.
What do you both think of Purism’s approach to this? If I read it right, they kind of recognise there’s not much you can do about it, so they describe it as IP-native (AKA pushing the use of encrypted VOIP), and offer a VOIP only version of the phone, in addition to the one that works with the public telephone network (kind of funny to have no sim as a feature, but I guess from a security perspective you could argue that it is?!). This could then make it fully open source (but also arguably not a phone.)
And recognising that it’s closed-source, they also say:
CPU separate from baseband, isolating the blackbox that the modem may represent
Also with a hardware killswitch for the baseband. Does this make sense?
Like all phones the have two CPUs, one dealing with the baseband and that’s basically a proprietary black box, and another for the computer/PDA side on which they run their PureOS. Nothing conceptually new there.
That good for security… as long as both ends have the same encrypted VOIP system and the implementation has been reviewed by qualified independent professionals. It’s also been done before (Blackphone IIRC) or just using Signal.
The SIM is an easily replaceable security enclave so from a security point of view has some positives for it. It also allows you to easily, and cheaply, move between networks so it reduces the power of the network operators, which could also indirectly be beneficial from a security point of view. Of course none of these are a given.
We used to call these PDA (for personal digital assistant) before smartphones existed. If you want to go completely open source, get a PDA running your favourite version of Linux and connect over the mobile network using a proprietary dongle. You’ll then have a physical separation.
That’s economical with the truth. If apps can communicate over the mobile network, some communication happens between the baseband and the application processors.
How is this implemented? Can you trust it? If you’re paranoid about the baseband, go with a two box solution comprising of a PDA/computer and a dongle.
Pre-smartphone I did run Emacs on a Palm OS telnet app running on a Palm connected over infrared to an Ericsson SH888; the whole thing connected to a Unix host. Not the most usable two box solution but that’s logically what you need to go back to if you want one side completely open/free.
Software engineers don’t learn their lessons. More examples of poor software engineering parsing PDUs. At least these issues are now gaining a visibility that similar issues with SMS PDU parsing mistakes never got so there’s a chance resources may eventually dedicated to get this right.
Researchers call them “interaction-less” bugs. Hackers can exploit them to carry out an attack without first convincing a user to visit a malicious website or open a dangerous file.
An interaction-less bug uncovered in WhatsApp in May allowed spies to gain access to a user’s smartphone simply by calling it — even if the user didn’t answer.
Now similar flaws have been discovered in iMessage by Google Project Zero researchers Natalie Silvanovich and Samual Groß.
If you want to understand better how these bugs are found and the concept of attack surface, check out this technical post by Google’s Project Zero team: The Fully Remote Attack Surface of the iPhone.
