If they were "entirely" ethical (which is a silly concept but it's already been deployed on this thread so I'll run with it), they'd be more up-front about the features and limitations of their security model. So:
* Modern phones (and all the flagship phones) have had separation between their basebands and APs for years; a modern smartphone baseband is essentially a USB peripheral.
* The two largest smartphone vendors have large, world-class security teams that do things like audit their basebands. Has Purism?
* A modern flagship smartphone will have some kind of secure enclave. Apple's has dedicated silicon, and an encrypted memory bus linking it to the AP. How does Purism's hardware security model compare?
* I don't know how much Apple and Google spend annually on outside security research for their flagship phones, but it's a lot. Who has Purism engaged to evaluate their designs and spot flaws?
If you want to use a niche phone as a fashion or political statement, more power to you. But if you try to market that phone as "transparent code is the core of secure systems", I'll take issue with that; it's neither a necessary nor a sufficient condition for security.
This phone may very well be more "fair" or "ethical" than an iPhone. But if it's not as secure as an iPhone, it's unethical to claim otherwise.
> a modern smartphone baseband is essentially a USB peripheral
Since when? I'm going to need evidence for a claim like this -- as far as I was aware, Apple is the only one that does this, because they make their own SoC and then use a physically separate Qualcomm/Intel(?) modem.
All the other flagship smartphones use a Snapdragon eight-something with everything on a single die. How could you possibly claim with a straight face that it's "only" (really, truly, pinky swear) a USB peripheral, with no other route to main memory, which oh-by-the-way is also on-package?
Update: as far as I can tell (qualcomm datasheets are annoyingly hard to come by), everything was still over PCIe as of early last year. Their modems are getting faster, not slower, so I would be surprised to see this change to USB.
PCIe would give the baseband full access to main memory unless the mmu is set up correctly (there's lots of evidence that phone manufacturers have been lazy about this), and also assuming that the mmu based protection actually works correctly, which is next to impossible to verify.
I think you're understating how long IOMMUs have been in common use on SoCs. It's not new tech.
(And I think tptacek's "essentially a USB peripheral" might be intended to be read as "metaphorically a USB peripheral" -- i.e. with only the capabilities you'd expect a USB peripheral to have, even when hooked up over PCIe, because of the IOMMU.)
Have you seen how these smartphone manufacturers handle software development? The majority of them bring up the hardware just barely enough to make it look like all of the peripherals work, then they ship it.
They're not even going to bother configuring the iommu, because there won't be a perceivable difference in behavior to their boss or to the average user. It has nothing to do with how long the feature has been around, their priorities are just fucked.
I don't know about the US, but in Germany nobody except nerds cares about Pixel phones. I think I have only once seen in the wild with friends and acquaintances.
You're either an iPhone guy or a Samsung Galaxy guy.
Or you want to save money, than you probably have a OnePlus or maybe a Huawei.
Wouldn't say the nerds care about Pixel phones. Google's older Nexus phones were and are really popular, Honor isn't too rare, and yes - OnePlus and Huawai. Too bad HTC seems to lag behind.
I'm personally hoping my 5X will survive and be updated for a long time because I haven't anything in my preferred price range that speaks to me in a long time.
I don't know what information Apple collects, but Google is definitely the opposite of ethical. If you have Google Play Services, then they continuosly ask you to enable track your location, track what cell towers and WiFi networks are around and so on.
And on Android 5, every time you enable GPS, a popup appears asking you to let Google track your location [1]. If you tick the "Don't ask anymore" checkbox, the "Decline" button becomes disabled so that you don't make the wrong choice.
The iPhone is probably the only major device where the modem is a USB peripheral. Qualcomm, Samsung, and Meditek all offer DMA between their radios and ARM cores.
I certainly don't trust any of those players to even ship relatively secure or even modern code to boot the ARM cores, let alone properly protect memory.
With the Purism stance of ensuring the baseband is on separate silicon, on a relatively limited (and easily hardware isolated) bus, they're able to effectively treat the baseband as an untrusted device.
If when you say "ROM" you're talking about the persistent storage holding the modem's firmware, then absolutely -- that firmware lives in a "vendor" partition on the same emmc as the OS.
When talking about "RAM", things get a bit more complex. Most usb and even pcie modems are going to ship with enough built-in (that is, on the same die) RAM to get the job done. They have absolutely no need for the quantities or qualities of external DDR (where your OS is running from most of the time).
That said, when the modem is embedded in the SoC, all bets are off -- it's really convenient to share as much as possible, and is entirely possible for the modem cores to depend on the same DDR memory as your ARM cores.
On Qualcomm SoCs, a chunk of the memory area is reserved for the baseband, and another section is reserved for TrustZone kernel, but it does the same as an integrated GPU in a PC. Then it connects via a pseudo tty with a kernel driver, but as the baseband has more privilleges than the main cpu, it really could do whatever it wants, just like TrustZone.
I'm pretty sure he's got very little idea about it, but it isn't stopping him from attempting to undermine this project. I find that fascinating.
Five-eyes have just finished re-dedicating to each other that they'll strong-arm and backdoor any popular platform and company product that they can get their hands on. What point is there to your nicely built Apple device then? That's rhetorical; there is no point having a secure device that your government can pry open at it's whim - be it hardware or software backdoored.
> But if it's not as secure as an iPhone, it's unethical to claim otherwise.
This seems silly, you can easily flip this on its head and say "Well the iPhone is closed, so there's no way to verify it has any security". You can't separate the ethics of security advertising from the ethics of everything else about how the device works.
I agree--after all, security is generally unverifiable anyway, even with perfect visibility.
However, in the context of ethical security conversations, the two are anything but orthogonal. The security expectations of someone buying an open phone, and the security expectations of someone buying "private" access into a proprietary platform, will be different. Sure, my baseband could be compromised, but if I'm more worried about leaking information to ad networks, what I really need is a firewall and hosts file, not an isolated baseband unit. If we're talking about an ethical security conversation, maybe we should mention the fact that this is the security Apple has to control what code runs on your phone, not the security a user has to control the flow of their data. Though, presumably you can have both goals, Apple shows interest only in the former.
My point being the two phones are extremely different products, especially regarding ethics, so the straightforward comparison and verdict struck me as extremely narrow-minded about how people use their phones.
I don't understand the hand-waving here. Does the phone have a comparably secure design to that of an iPhone or not? What other question is there to ask about the security of the phone?
I bring it up because the project makes a very big deal out of how much security their ethical approach adds. From what I can tell, their approach nets them materially less security than either flagship phone.
The security of an iPhone is completely dependent on what Apple decides to do with iCloud and with the applications that come from the app store. Sure, Apple may be more secure against $random_blackhat, but the user still isn't in control of what is happening on their phone.
Most users care much more about the decisions that Apple and Google make with their data than they are about $random_blackhat.
Even more, a lot of the security features you mentioned are very difficult for an open source phone to achieve because the hardware ecosystem is so endemically closed source and proprietary. We can fix that by pushing hard for open source hardware that starts to make inroads and break those barriers down.
I generally value tptacek's comments on security matters, but this position doesn't make sense to me.
When Apple decides to take away an app I paid for, I have no security to block them. When Apple decides to quit posting security updates, I'm out of luck. When Google reaches in and takes my location data without permission, I can't stop them.
With open software, there's no guarantee I'm more secure. But when some security issue does come to my attention, I'm more likely to have some say in how I respond. Somebody claims to have a more secure or privacy-respecting driver? Strongly recommended by experts I trust? I'll look into it. With Apple, I can't. There is no such alternative.
The ssl lib has known vulnerabilities? Wait for Apple? Or install some shim until there's a fix? Oh wait, on Apple devices, you don't have an option.
Apple is not only closed. It's walled. As the owner I am kept on the wrong side of the wall. And there are parties on the other side of the wall that I don't want to be on that side.
This is a security model that is hard to lose to. If Purism let's me control the wall, I'd say that's a welcome change.
And I generally vehemently disagree with tptacek and most of what he stands for, but he's correct here.
> When Apple decides to take away an app I paid for, I have no security to block them. When Apple decides to quit posting security updates, I'm out of luck. When Google reaches in and takes my location data without permission, I can't stop them.
This is not security. This is some weird definition of security you're using here.
> With open software, there's no guarantee I'm more secure. But when some security issue does come to my attention, I'm more likely to have some say in how I respond. Somebody claims to have a more secure or privacy-respecting driver? Strongly recommended by experts I trust? I'll look into it. With Apple, I can't. There is no such alternative.
Software security doesn't much matter with phones when the hardware security is crippled or non-existent.
Software security means fuck-all if you can pull from the phone's memory via a cable, via the modem, or via JTAG. The iPhone is the most secured hardware of any phone on the market and by quite a long shot.
Reading through the comments here is frustrating because tptacek seems to be talking about hardware and all of the responders are talking about software. It's not like your personal computer where you "need to get physical access in a powered on state". Getting access to an adversary's phone is _beyond trivial_.
> I don't understand the hand-waving here. Does the phone have a comparably secure design to that of an iPhone or not?
To understand means to see beyond security design to see security principles. If one company magically decides to move your data to a government controlled cloud without any public discussion around why or if they even agree with it, the design is not going to matter. When the next internal decision occurs negatively affecting security in some undiscussed opaque way, you won't be able to point to security audits to explain the folly of human traits.
Sure, it can be compared, but it’s not a one-dimensional comparison to my eyes—you’d have to pick a dimension of security to compare to get a proper ordering.
For instance in this case it seems like the iPhone has (considerably) more hardened hardware for many scenarios where you lose control of your phone. That’s not the only sense of security people care about. From the perspective of securing the phone from doing unwanted things without your permission, you have to trust Apple entirely to make the right decision. If you don’t trust Apple to make these decisions, the phone does not reflect a secure interaction.
How can they be orthogonal when eventually you need open software of some kind to make a verification?
If the software I use to verify the closed source software is closed, then I will need another piece of software to verify that the verify-ing software is what it says it is and so on until we reach a piece of software that I can verify with my own eyes (or a friend has verified with their eyes).
We all eventually have to place our trust somewhere but we shouldn't have to agree with where you decided to trust.
If you didn't trust the closed source disassembler you use, for whatever reason, you would verify the assembly output, not the actual software. In practice this is often done unintentionally anyway: it's common to run a debugger (ex: gdb, windbg) alongside an annotating disassembler (like IDA). objdump (from GNU binutils) also supports many non-Unix executable formats, including PE (Windows) and Mach-O (OSX/iOS).
For fun I just compared objdump's entry point function assembly of a downloaded Pokemon Go IPA to the Hopper representation, and, no surprise, they are identical.
It sure helps though. And being able to compare source code to binary is good for checking blobs.
No one knows what nasties are hidden in these blobs that run on EVERY phone out there. I’d actually go as far as saying cell phone processing modules are completely insecure. Unlikely to receive updates. Poorly documented. Security standards are likely to be weakly implemented with gaping holes.
As for proof, I’d point at the lack of source code as a starting point. Open source doesn’t guarantee security but it at least lets interested parties try to the degree they want or need to.
Sure. Go and have a look at GSM and friends. I’d say the cellular network in general is routinely being manipulated. The protocols and standards for over-the-air are demonstrably insecure and assuming the actual hardware is also insecure is reasonable as well.
Part of the point of this thread is that 'modern flagship phones' are designed with problems like that in mind. You're the one claiming to have 'proof' they are trivially insecure.
I pointed at the lack of source code as a starting point for proof of complete insecurity. I pointed at the ease of the existing protocols in active use as an example of that insecurity. That insecurity is the basis for Stingray fake towers. If you can fake the tower then the cellular modules can’t be much better.
I’m sure various agencies are quite frustrated by their inability to use the cellular modem as an entry point into Apple’s phones. That by itself is another pointer.
You shouldn't flip things around, because there is observable evidence beyond source code. Not knowing everything about the world doesn't mean we know nothing.
The fact that there is still the potential for jailbreaks in iOS surprises me and doesn't seem to help the secure-by-default argument.
Why is a trillion-dollar company which designs their own silicon only two steps ahead of some hackers? Instead of $200 billion in the bank, unspent, shouldn't those devices be reviewed and redesigned until impregnable?
Computing devices are usually insecure due to limits on experience, time and cost. None of those applies to Apple in any meaningful manner.
Personally I'll just stick with cheap Android phones running custom ROMs and treat them as insecure, disposable terminals.
So long there is a hardware input source (usb) it's impossible to guarantee security, this is the reality. There is not a single device with an input source such as USB that is secure. Physical access guarantees lack of security.
Also, it's not some hackers. There's quite a big community out there looking for bugs and every time, such 'hacking' requires unlocked phone.
> Instead of $200 billion in the bank, unspent, shouldn't those devices be reviewed and redesigned until impregnable?
The problem is the Mythical Man-Month. Apple's devices are built on a mountain of ancient C code. XNU is a bizarre Mach/BSD hybrid, built for the sake of expedience. (This is not to bash Apple; most other devices aren't much better.)
Apple has been working to improve the situation, but there's a limit as to how rapidly all those millions of lines of code can be changed.
I accept that "transparent code" isn't sufficient in itself to provide a secure system, but saying that it is not necessary is just false.
As governments are pushing more and more to have back doors(or side gates here in Aus) it is becoming very important to have fully open code, as it is the only way to get around the vulnerabilities governments will be requiring phones to have in them.
Realistically the security research community who find things like phone exploits are very well accustomed to a lack of source code, and in many particular niches of infosec -- it's a baseline assumption for almost all analysis work. Apple's security team is the reason the iPhone is an extremely secure device, not because it's closed source, and not for lack of trying. Go ask people who find major security vulnerabilities -- binaries are rarely a true obstacle, time and mitigations are. (And you'll probably come away surprised at how easily most systems fall to even basic intrusive analysis, no source code needed.)
Source code is merely convenient for the security community in cases like this. But it's hardly a requirement at all, and you can absolutely build a secure system if you design for it.
All that said, I think source code for a device as personal as a phone is largely more of a question of ethics and this is what Purism heavily leans on as an angle for their marketing. I think that's a good angle, independent of any security aspects: owning the code and having the right to it (even if you don't ever touch it) is an important aspect of owning a device as deeply personal as a phone. People like us who believe that should totally advocate for it -- I think it's a fairly simple case to make. But it really has little to do with _security_ on its nose, if you ask me.
(Also, if your government mandates backdoors, they will not be thwarted so easily by simply recompiling AOSP or whatever and loading a new ROM, if they do not wish to be. Any belief to the contrary is a fairy tale that people like us enjoy telling themselves. But I'll give you a hint: writing a Makefile cannot get you out of jail, and you are not that good at covering your tracks.)
> Realistically the security research community who find things like phone exploits are very well accustomed to a lack of source code
Realisticaly, though, a manufacturer or intelligence agency will be the one paying security people for thorough reviews. Anyone doing this in the open would do this to build a reputation or for their own security, and will need much more time to review something that first needs to be reverse engineered. They will almost certainly not be able to look at everything.
It's not a logical argument to say that we security people are used to reading obfuscated binaries anyway and conclude that therefore no fewer bugs will be found compared to the situation in which it is open source.
This is one of the rare instances in which there actually is a liquid market for viable vulnerabilities and exploits, so no, I don't think it's safe to say that the only people doing this kind of research are in the IC or vendors.
Apple is the gold standard of mobile security and also a shining example of a closed source, proprietary ecosystem. This is coming from a dedicated Android user who has a preorder for a Librem 5. I did not order it for security reasons, I ordered it for ease of development. If I had sensitive information on my phone, it would be an iPhone. I just prefer living in the wild west.
If a developer does not reveal the source of a program, then surely a user of this program is not secure against that developer, who can make that software do anything without easily being discovered.
Therefore if we are talking about security from the users perspective, transparent code is definitely not sufficient for security, but it is a precondition.
If you make the (IMO wrong) assumption that a developer on principle can never be a security threat to a user, then sure, you can claim that something non-free like iPhone is "secure". I guess it's secure in that Apple can be very secure you won't use it to run GPL'ed software?
Having the binary is enough if you know the architecture. But therein lies the problem with modern systems - you don’t always know the architecture or have enough access to explore. Intel ME is a great example.
You seem to be totally focused on and upset about security, but I don't know that security is the only or number 1 point of this phone, or they ever claimed security parity with Apple. (Unless Apple or a government with power over them is part of your threat model, of course.) I think it's primarily about respecting user freedoms to control their software, which the iPhone and Android score terribly on. So your post comes off a bit unfair in my view.
Yeah, I'm mostly interested because the software is designed simply to be a useful tool, rather than with Google or Apple's motives in mind (lock-in, advertising).
It will just be a more pleasant tool to use, without crap getting in my way.
It's funny, most people are concerned with security (rightfully so). But my main frustration is the inability to fix the parts of my OS I don't like. It's just convient that most security professionals agree open source is the best way to achieve security as well.
> So does all this mean Open Source Software is no better than closed source software when it comes to security vulnerabilities? No. Open Source Software certainly does have the potential to be more secure than its closed source counterpart. But make no mistake, simply being open source is no guarantee of security.
"The two largest smartphone vendors have large, world-class security teams that do things like audit their basebands. Has Purism?"
(and some other points that, I think, miss the point)
Once the baseband is isolated as a USB peripheral and the radio modules are physically pluggable modules ... and have kill switches ... the appropriate comparison is no longer to other phones. The appropriate comparison is to a PC, like a laptop.
... has the shape of a phone, but that sure looks like a PC to me.
I am happy running a PC without a secure enclave, with a USB cellular modem attached, and with only hazy knowledge of the baseband running on that (in my case) USB stick.
All modern cryptography relies on random key generation. But the current state of the art is that there is no way to distinguish between truly random numbers and pseudorandom numbers generated deterministically from a key. So how can we even begin to talk about security without openness? Maybe the key generated in the secure enclave of your iPhone never left that enclave - but maybe the NSA has a copy of it all the same.
Nor Google nor Apple can – to the best of my knowledge – decide what code is run or not run on my PC. That is evidently a plus point for security, if one doesn't blindly trusts these companies.
That isn't enough to protect from kernel bugs, as discussed at Linux Security Summit, hence kernel self protection project and related initiatives, mostly driven by Google regarding Android security.
You are being unreasonable because you equate the hypothetic possibility of malicious code execution by Apple or Google due to bugs with running an OS from either on hardware from them.
You have a completely different security model on PC, though. PC is designed as a minified version of multi-user workstation, where system administrator itself is responsible for securing the system. iPhone, on the other hand, is designed for novice single-user use case, where manufacturer is responsible for securing the system.
Ethical isn't a silly concept; it sounds like an abstract term, a proposition, while it is actually more nuanced; it is a spectrum, not an absoluteness. And it goes beyond technology.
There's also social ethics which the company Fairphone tries to tackle with their products (Fairphone, Fairphone 2, and the upcoming successor). They're transparent about their ethics [1] which contains examples about sourcing ethical cobalt, the supply chain of the displays, and so on.
> But if it's not as secure as an iPhone, it's unethical to claim otherwise.
Do they, or is it a convenient claim to argue against? (honest question as I'm unsure about what they've claimed compared to iPhone specifically). By using volume and money spent as security metrics, it's quite easy to see why large players would be the best.
For many, I suspect that principles drive some of their security assumptions. Companies that are opaque and do things behind users' backs are always going to appear less trustworthy than those that are open about their software and processes. While that doesn't translate to empirical security, it's enough of a paradigm shift from secretive approaches that I hope that facet alone helps them succeed.
>* I don't know how much Apple and Google spend annually on outside security research for their flagship phones, but it's a lot. Who has Purism engaged to evaluate their designs and spot flaws?
At its inception you could make the same argument for most open-source projects which usually don't start decked out with cash. But most trusted and respected projects of today (especially in comp sec) are open-source as a prerequisite.
Utter and absolute b.s. ,the purpose of purism is privacy,not security. They are not claiming greater security than the iPhone or Pixel,they are claiming transparency,open hardware and a non-commercial alternative mobile OS.
The price of having "a large team of ______" is either closed hardware or complete loss of privacy.
It pisses me off so much when I read well reputed people like you say ridiculous things like this. How big was Linux's security team when it started out? Look at duckduckgo and protonmail competing with google search and gmail. Are you saying they won't be able to afford a dedicated security audit team once the product starts profiting in the tens of millions?
> If you want to use a niche phone as a fashion or political statement, more power to you. But if you try to market that phone as "transparent code is the core of secure systems", I'll take issue with that; it's neither a necessary nor a sufficient condition for security.
I will make that fashion statement. And you know what,security is all about risk(and I know you could teach me an entire course on this). As an individual, hardware or software that cannot receive an independent review either due to lack of openness or transparency in the development process carries an enormous amount of risk. Even someone as talented as yourself cannot unilatetally audit android's codebase,you can't even start with iOS(even if you could you 'd be breaking a fineprint somewhere). The fact others can audit the code and design is a relevant factor when assessing risk and evaluating security. More transparency == less risk == better security.
> This phone may very well be more "fair" or "ethical" than an iPhone. But if it's not as secure as an iPhone, it's unethical to claim otherwise.
What happened to threat modeling? As an individual,I care much more about Google tracking my activity and sharing it(I'm sure you read the recent AP piece revealing google doing just that even when location was turned off) than I am worried about russians using a 0 day kernel rce or the FBI trying to decrypt my phone. Many of us are just normal people seeking the basic dignity of privacy and property ownership(as in freedom over the phone you own). Their product has a very real and significant impact to the reduction of the amount of risk I have to accept as an individual who has to use a smartphone, I don't see why you need to bilittle their work with obviously non-constructive criticism.
Edit: to all the '*' points you mentioned,how exactly and practically would purism's lack of those features impact the privacy and security of purism under real world threats. Also,in case it wasn't clear already,Google and Apple are considered threats to privacy and security by many who support works like purism's.
If your phone is not secure against outside, malicious actors, then all the privacy you gain is entirely pointless.
A phone needs to be secure and protect privacy.
Having a security team doesn't mean you get closed hardware, it means you have a security team.
>How big was Linux's security team when it started out?
Not very large and nowadays there is lots of people working on Linux security and they discover a lot of CVE's that are fixed in the kernel and then backported. Early versions of the Linux kernel weren't very well guarded against outside attackers (in fact, we're only just seeing the tailend of when vulnerabilities get introduced to the kernel lift from the beginning of the git history at around 2.6).
>Are you saying they won't be able to afford a dedicated security audit team once the product starts profiting in the tens of millions?
I think, and this is pure speculation based on the text of the OP, that the statement they made is intended to highlight that security teams cost money and Protonmail and DDG aren't able to afford as good security teams as google as a simple function of "how much money can we spend on it".
>As an individual, hardware or software that cannot receive an independent review either due to lack of openness or transparency in the development process carries an enormous amount of risk. [...] More transparency == less risk == better security.
Sing along kids: "It all depends on your threatmodel!"
But seriously, this conflates "open source = security" which isn't remotely true and can be easily disproven by adding a backdoor to any open source project and sending you the result. How many people out of 100 would even understand the code, how many of those are able to find the backdoor, how many of those can patch it out and compile it without backdoor?
Open Source gives security for people who understand code, not for the people I meet at work that have difficulties opening Facebook if you remove it from their homepage setting.
>What happened to threat modeling? As an individual,I care much more about Google tracking my activity and sharing it(I'm sure you read the recent AP piece revealing google doing just that even when location was turned off) than I am worried about russians using a 0 day kernel rce or the FBI trying to decrypt my phone.
Same trap as before. Lots of people don't worry about facebook tracking and don't worry about russians using a 0day on them. Most people won't buy a phone on the premise that google won't track them, they buy phones based on the features it offers and the big numbers vendors print on the spec sheet. Of course lots of people still don't want tracking but together with the previous group they form the majority of people who might not want tracking but ultimately can't be assed to care enough to spend more than a couple dollars per year on avoiding it.
>to all the '*' points you mentioned,how exactly and practically would purism's lack of those features impact the privacy and security of purism under real world threats
First point; separation of concerns is good here, a separated baseband means if for any reason the baseband is compromised, and even open source gets compromised, it cannot damage the phone itself. This makes hacking the phone from the outside through the telephone network rather difficult.
Second point; Auditing by security teams improves code security. As mentioned above, the Linux kernel and many other high profile projects receive a shitload of auditing by security professionals combing through the code because if they don't the world would spontaneously combust about 32 seconds later.
Third point; A secure enclave is very useful. Even some open source projects have them such as the U2FZero because they enable the software to operate on a zero-knowledge principle; it cannot leak your private key if it has no access to the private key. Similarly on a phone, your encryption key for storage can be a very safe 512 bit key and your password is compared using on-enclave software protecting the key itself. This way a state-actor or malicious mussad-level actor can't get your phone (though mussad would just replace it with a uranium bar and kill you by cancer because mussad doesn't care) encryption key because the software will delete the key or simply not grant access if it detect manipulation.
Fourth point; Getting third parties to evaluate your design is helpful, again as mentioned, a lot of high profile OSS projects have third parties scanning the code because two pairs of eyes is better than one.
> If your phone is not secure against outside, malicious actors, then all the privacy you gain is entirely pointless.
Not true,even the most insecure phone is secure against some subset of attackers. If you don't trust the maker of your phone,all other security is useless. Imagine going into war but you suspect your body armor and vehicle is boobytrapped by your own side...
> Having a security team doesn't mean you get closed hardware, it means you have a security team.
Didn't claim othetwise. Closed hardware is needed to control the market well,alternative being to control user data and open up hardware and software.having a security team dedicated to a baseband audit means your profit a very large sum and you're already succesful...
> Not very large and nowadays there is lots of people working on Linux security and they discover a lot of CVE's that are fixed in the kernel and then backported. Early versions of the Linux kernel weren't very well guarded against outside attackers (in fact, we're only just seeing the tailend of when vulnerabilities get introduced to the kernel lift from the beginning of the git history at around 2.6).
Same can be said about windows seecurity,the point was lack of dedicated security teams early on. Even making $10mil profit a year,you'll find it difficult to find one security guy and dedicate resources to support his work. My whole rather obvious point you missed here was the correlation between adoption of a product and ability to dedicate resources like a security team.
> I think, and this is pure speculation based on the text of the OP, that the statement they made is intended to highlight that security teams cost money and Protonmail and DDG aren't able to afford as good security teams as google as a simple function of "how much money can we spend on it".
Somewhat,I understood it as "more money means more security and transparency is much less valuable". Which I disagree with. Transparency and good security hygeine are much more important than throwing money and bodies at it.
> But seriously, this conflates "open source = security" which isn't remotely true and can be easily disproven by adding a backdoor to any open source project and sending you the result. How many people out of 100 would even understand the code, how many of those are able to find the backdoor, how many of those can patch it out and compile it without backdoor?
I made a point out of security being a measured evaluation of risk. Transparency and being open source are variables,just like having skilled developers,a good security procress,good project management and resources like money and time. You need some of each but completely ignoring a variable means everything it multiplies is also 0. Opensource helps improve security,but only as a variable.
> Same trap as before. Lots of people don't worry about facebook tracking and don't worry about russians using a 0day on them. Most people won't buy a phone on the premise that google won't track them, they buy phones based on the features it offers and the big numbers vendors print on the spec sheet. Of course lots of people still don't want tracking but together with the previous group they form the majority of people who might not want tracking but ultimately can't be assed to care enough to spend more than a couple dollars per year on avoiding it.
Most people didn't have sex with condoms either until sexed came along. After fb's facebook fiasco,something like 42% of their users either stopped or dramatically reduced using fb. People have no choice but to buy apple or iphone therefore you're purely speculating here. Most people don't know exactly how bad things are,try showing someone you consider average their google activity and location history and offer them a purism phone and prove me wrong. Most people want a fancy featured phone but they also believe their hard earned money should be enough of a price to pay. They would buy the privacy enabling phone with the same looks and features for a higher price.
For the rest of what you said,it seems you ignored the part where I said 'real world threats'. Name one real world compromise using baseband firmware and I'll donate $100 to a btc wallet of your choosing.
I'm a bit confused on the comment "Modern phones (and all the flagship phones) have had separation between their basebands and APs for years; a modern smartphone baseband is essentially a USB peripheral."
As far as I can tell [0], the flagship phones (i.e. everything except the iPhone) are pretty heavily invested in the Qualcomm integrated baseband CPU + general purpose CPU [1]. And unless something has changed radically in recent years, the baseband CPU has had direct DMA access to the same memory as the main CPU, and thus any vulnerabilities or backdoors in the baseband CPU have the ability to directly access memory.
With the rising prevalence of devices like the LimeSDR [2] putting the ability of intercepting and communicating with the baseband CPU, vulnerabilities in the baseband like this one [3] are even more of a risk than before.
I don't think anyone is arguing that Purism is going to have produced the world's most secure software, but the design space they've put themselves in allows them to be audited internally and externally - something that while you say "Apple and Google have spent a lot of money on it" I can't really verify that it's lead to a quality product. As flaws like Intel Management engine fiascoes have shown [4], even heavily audited code can have terrible flaws. The thing people don't like about the current approach with cell phones is that if the phone is too old you just have to throw it away because no one will update it. Purism is offering you something where you can throw away just the vulnerable modem or wifi card, and keep your phone. Even if you don't know of a flaw, you could purchase a different vendor's M.2 4G LTE card and swap it in, and make your attack surface different than other owners of the Librem 5.
There are other things which Purism will doubtless be way worse at catching/auditing, but honestly this is going to be like Linux: the benefit in terms of security is going to be that you are one of maybe 1,000 people using that device in that specific configuration, and you won't be worth exploiting.
Even though I generally agree with your comment, I don't know where you got that replacement part from. AFAIK Librem 5 is not supposed to be modular and I certainly wouldn't pledge my money for such project unless it set its fundraising goal many times higher than they actually did. In devices like that, there's not much you can do to achieve hardware modularity without fighting with lots of constraints everywhere. The best I expect to see in similar devices is what Dragonbox Pyra does (and what Neo900 planned to do) - a sandwich with two PCBs, with one having the CPU and expected to be upgraded, and other one containing stuff that doesn't need to be upgraded as often, like various sensors, baseband etc. It wouldn't work for Librem 5 though, as it seems to be already very space constrained.
Librem 5's design makes it relatively easy to safely disable and not use the part you think is vulnerable, but you can't really replace them - that would put this project into a completely different budget category.
> We went with Redpine Signal as their chipset does not require a firmware download at runtime like other vendors; having a downloadable firmware would violate the Free Software Foundation’s RYF requirements.
This really does not resonate with me. In most of these chips there is a functional or partially functional firmware in ROM, then the OS applies a RAM patch to provide full functionality or address functional or security issues. I'm not sure how I would be more free or secure if Broadcom or Intel placed the full firmware in the ROM and never updated it, than if the continued to supply updated firmware blobs.
The firmware for these devices historically is riddled with security issues, just recently this CVE affected most of the Intel AC WiFi cards [1]
Also Redpine supports firmware blob updates with some versions of their hardware, so I'm not sure if they are just playing word games here by saying it will WORK without extra blobs, but then expect everyone will really still use the blobs to stay up-to-date. [2]
I believe the FSF position is that non-updatable firmware can be considered "part of the hardware", while updatable firmware cannot. I think they're concerned that updated firmware could change how the device functions in ways you can't control.
Except that I am almost 100% certain [1] that they are using the RS9113 which as I suspected IS updateable (in some cases wirelessly) [2]. In fact in the Linux Firmware tree they have multiple firmware images depending on how you want the device to function. [3]
>The host MCU can update the RS9113 module FW over UART using the kermit protocol or over SPI using the proprietary binary protocol. The default UART baud rate is 115200 kbps 8N1 with xon/off or no flow control. For baud rate >900000, hardware flow control must be used. Refer to the WiSeConnect PRM for more info - the "Upgrading the Firmware in Module" section discusses the SPI mode and "Firmware Upgradation" section discusses the UART mode.
There are a lot of games overall. They made this entire post about how using a blob on a co-processor is fine because FSF guidelines have an exception for that. So after some gymnastics, you can make it look like your main processor needs no blobs. I don't know how they wrote this article with a straight face: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...
>The i.MX 8 has some A53 cores and an M4 core all on the same silicon.
The FSF guidance on the co-processor exception is breathing room. I haven't read the fine print on what they mean by co-processor. My conjecture is that it was written at a time before these sort of architectures, and referred more to traditional GPU over pci-e like co-processors so that non-essential stuff can be excluded from requirements. In this case, you have single silicon, and single RAM. RAM needs blob for init. You claim that if you squint, you can see single silicon as multiple processors, and voila RAM init quandry is solved. That is purim's gymnastics.
Just letting another chip do the loading seems to be only part of the solution. The other part is to load it from read-only memory so it cannot be modified after production. That is what I consider to be the crucial property: the firmware must not be updateable.
- either you give your users an ability to upgrade the firmware, so they can RE it, write and use an open replacement
- or you don't give your users an ability to upgrade, which doesn't help anyone since they can never be sure if the chip manufacturer didn't put some undocumented interface somewhere that even you weren't aware of; so now only the chip manufacturer can upgrade the firmware and the user can't
Realistically, in a context of mobile phone components, there hardly such thing as "not updatable firmware". You can never be sure.
I understand why FSF has this "no downloadable firmware" rule (they have to put a line somewhere), and I'm by all means a 100% Free Software zealot, but I honestly believe that this rule simply makes it not worth pursuing FSF certification in a device like a mobile phone, as you're ending up with actually less freedom as a user and no way to verify that it's really worth it (after all, a possibility to upgrade your firmware may simply be undocumented and you have no way to be sure that it's not there).
Just speaking as one free software lover to another, I am happier that the Redpine Signal doesn't need downloadable firmware to function.
It means that there will be just one version of firmware shipped. Just one version of firmware that the whole community will focus on analyzing, patching (only for the librem phone, it's only pure chance if that helps any other device), and if a patch is needed:
* Redpine can either tell the entire community how to flash the firmware, or else the egg is on their face for shipping a broken firmware. *
(There's basically no chance that the Redpine chip is actually not field-upgradeable if you have the right vendor tool and probably also a windows box to run the tool on.)
The rest of the world seems to think, "flash it every time it boots up and I don't really care where that binary blob came from."
I'll also just add, I can respect your position. Thanks for supporting Free Software, and I get it that there's value to being able to upgrade. That's kind of what I'm hoping happens later, if (cough, cough, when) there's a bug or exploit or worse.
If purism waited until a manufacturer offered a perfectly open device, they'd have to wait until GNU Hurd ships on a phone... j/k
Well, of course, not having to deal with distributing and handling the firmware in your OS is a very nice bonus. However, I could have worded myself better: FSF's RYF certification actually isn't about "downloadable firmwares", it's about "upgradable firmwares". IOW, if the user is able to install the software by themselves, the preinstalled one must be free, period - and no closed alternatives can be advertised or suggested. Redpine releasing a tool to flash the proprietary firmware would likely make the Librem 5's RYF certification void, which is a thing that IMO isn't helpful to anyone involved.
Openmoko already went through that route, although AFAIR there was no formal RYF programme yet back then. Freerunner was all fine from FSF PoV until Openmoko released a firmware upgrade for the Calypso baseband that fixed some ugly bugs, suddenly making it not free enough for FSF. Which is especially funny considering that it basically opened the way to run OsmocomBB on that thing.
Yeah, the Openmoko situation and OsmocomBB really highlights the nuances of the situation.
I wish the FSF RYF requirements explicitly allowed a later release of a flash tool. (It seems like this only improves the user's freedom - suddenly you can treat your device as programmable, but only if you want to.)
But I don't think people will be nearly as upset if the Librem 5's RYF certification becomes void later.
I think the impact will still be large if it has RYF certification on launch.
A very laudable effort and hopefully it goes well. But to be clear, the first ethical smartphone is Fairphone. I don't see how exactly this one could get even close to trying to be ethical in the way Fairphone does, but it might just be me having a different understanding of 'fair'.
This seems to be a mirror of the old language debate in open source. So the Librem 5 is ethical as in speech and not ethical as in beer. "Ethical" being a philosophical designation here rather than a physical designation.
Well fairphone was even more of a gimmick than this one. Other than word fair, it was equally useless as all other phones due to the usual planned obsolescence and lack of software. This one, assuming it ships, will at least be serviceable if they get a mainline stack running without too many blobs. That doesn't make it practical or attractive, but at least you won't be forced to chuck it in the bin after a couple of years due to lack of software.
Which Fairphone? The original or Fairphone 2? Mistakes were made with the original Fairphone. The SoC couldn't be updated to a newer kernel version and the binary blobs meant they couldn't get any update past Android 4.x. Which sucks if you bought that smartphone, but doesn't mean the company did not learn from that mistake. Also, replacement parts weren't available either because the company couldn't source them in great amounts due to lack of funds. Some replacement parts required components which weren't made anymore. They had some initial problems with this in the release after FP2 but they tackled these.
And I really really hope this is better than the Fairphone 2 in terms of function. I bought one very much excited by the prospect but to be frank it was the worst phone qua phone I've ever owned with basic functionality continuously breaking. A massive shame because the cleared up supply chain was something I really wanted to work out.
I wonder if it would be possible to implement that feature on an Android device that allowed you to flash your own custom appsboot/lk? I've only spent a little bit of time in LK stuff, but it seemed to me that that was where that functionality lives.
From leaked LG LK code it shows that's definitely where their bootloader unlock keys lived [at one point a couple of years ago].
Since the Librem device is a different beast, though, I wonder what their bootstack looks like? Super curious now!
I this is due to the overloading of the word ethical. The librem phone behaves ethically, but the Fairphone is ethically sourced (based on comments here). It'd be really neat to have something that's both ethical in behavior and ethically sourced for the parts.
Other than the physical switches (which sounds not all that interesting, since if I'll be in control of the software/OS, I can trust the GPIOs controlling some MOSFETs switches pretty much the same), this phone can only really differentiate itself by being very friendly to the FOSS developers/enthusiasts crowd.
A phone where you could get creative and manipulate every aspect of it without the artificial [security/functionality/SDK] limitations imposed on apps you can write for Android or that other comapny's phone OS I don't like even more.
A phone that will not get planned obsolescence.
A phone with OS that can be managed just like any other linux distro, where you can write apps in any of the readily available languages, etc.
Failing this, it's just overpriced wannabe Android clone.
I'm with you there in not really buying into the whole security, trust, and ethics story line which mostly seems to be appealing to a bandwagon of sentiments around corporate and government spying. Unfortunately, these sentiments are probably the only reason otherwise-average people - the kind of people who don't care about recompiling the kernel for their phone, on their phone, or jiggling GPIOs to remove power from subsystems - would probably buy anything other than an Android or Apple phone. Without this both comparatively large in one respect (with respect to the set of all reasonably tech-savvy people) but comparatively minuscule in another (with respect to the set of all smartphone consumers) set of people, you're going to end up with another OpenMoko Freerunner type situation where the only people using it are the frankly ultra-fringe types like us who care more about having a pocket computer that behaves like, well, an actual computer should and are frustrated with the creative limitations of SDK-based lock-in.
I sometimes wonder how much Purism actually cares about all this security, trust, ethics rhetoric and how much of it is a bunch of geeks who just want to finally have a smartphone which can run an actual Linux distribution and figured "hey, consumers are pretty riled-up about this whole government spying thing - and it's pretty easy to audit open source software for that sort of stuff - maybe we can work an angle..."
> Unfortunately, these sentiments are probably the only reason otherwise-average people - the kind of people who don't care about recompiling the kernel for their phone, on their phone,
I guess that's true, but these people probably will not be the driving force of the community around the phone. They'll be helping sustain the vendor financially, which is also valuable though.
I already have a mobile device to play with with a similar design to this phone, that has a separate 3G modem and can also be made to make calls. It's a bulkier 7" tablet. It will never get an opensource GPU driver, and suspend to ram is also out of the question for now. But it's fun to play with and explore.
Recently, I had fun with adding touch UI support for u-boot, to implement a boot menu and some battery indicator:
Also if you drop the typical Linux userspace, and replace systemd with a custom init binary, create a DRI based UI app it's possible to get cold boot times to useable GUI in 1-2 seconds from pressing a button. So I'm excited for what will be possible to do if the hardware of that phone ever materializes.
Something I'm also really interested in is the perspective that I may do advanced routing with my phone (although, I guess it could fit in the "manipulate every aspect of it" category).
4g has gotten really good those latest years, I've stopped using landline connection and just use my phone as wifi hotspot for everything. But this also means I don't have NAT and thus don't have a local network, which is super annoying when I want to transfer big files from one computer to the other (not that I don't have enough options between usb keys, bluetooth send or cloud sharing, but it's just not as convenient as scp).
Can't wait to finally be able to properly configure my phone as a router.
You could use a regular COTS wifi router running OpenWrt and tether your phone to it, instead of tethering directly to your computer. This would give you a network functionally indistinguishable from one that uses DSL, cable, or fiber as an upstream connection.
I initially checked if there was any possibility for my spare router (a d-link dsl-3782) to connect to my phone's wifi and then allow other devices to connect to the router, but it had no such feature (plus, if I got that correctly, you would need two wifi cards for that, one which would be in access point mode and one that will connect to other access point).
My router has an usb port, so it may just be that I could use it to flash the software, install OpenWrt, and then share phone connection with router through usb. Worth the try. (and sounds like a lot of fun :P )
EDIT : sadly, that model is not supported by openwrt.
Not directly related, but sometimes I do wonder how free software can compete with the services of the behemoths (maps, assistants, etc).
So the other day I hit this article [1] on planet.kde.org about KDE Itinerary, an application that can store your boarding passes and offer some additional services, such as calendar integration or notifications in case your destination has a different socket type, they drive on the left side, etc. It seemed quite useful and some parts are novel. Maybe there is a future for phones with just free software.
I have been using only open source apps for the last year. For basic stuff like podcast streaming and IM the Foss stuff is better than the proprietary stuff. For complex things like maps and assistants its like taking a step 5 years back in the past.
OSM and is no where near as good as google maps at most things but its still perfectly usable.
The average person probably won't be happy with a purely foss phone right now but if its something you care about then it can be done fairly easily.
As long as you can run your own software, you can build what you want. Not to say it will have the polish current solutions offer, but I don't want current solutions. I want mine.
There was an article recently here about someone using a RasPi (with golang) to build a custom GPS mapping solution. I've been doing something similar (though using raspi connecting to my head unit via composite video) as well as pulling sensor info from ODBII and currently looking into CanBus.
This kind of moral preening makes me sick. I will probably become a customer, but phrases like "the world’s first ethical" really, really rub me the wrong way. tptacek has covered many of my issues below, but, simply put, it implies that the rest of us who work for telecoms or who choose not to buy the Purism are lesser.
"Don't do evil" hit me the same way. I assume Google is well-intentioned, but there are many, many areas in which Google and I have moral disagreement regarding the way they operate. That's fine. Principled people can differ.
The same is true with Microsoft and Kroger's and Costco and lots of other brands I deal with. I know for a fact these companies support causes I believe to be immoral. I suspect in turn they disagree with some of the causes I support. But they don't rub my nose in their superiority with smarmy phrases like "don't do evil" this or "first ethical" that.
In the case of Purism, a much quicker way to my heart and wallet is say it's completely open for the following reasons. That's enough for me. I don't need your fundamentalist preacher bloviating on top of everything else.
Purism is a manufacturer that directly buys into the principles of the FSF - that closed-source software is probably the most important ethical issue in computing. You can read about why on the FSF’s website.
[random idea] Rather than worry endlessly about SOCs and radios not being open enough, why not build a protocol on top of blackbox components that eliminates, through some kind of encryption, the need for openness?
To push the argument to the extreme, even if you find a radio component that matches your requirement of free, it's still going to talk to a radio tower that you don't control, running a software stack that you don't approve. This problem never ends, unless you imagine some end-to-end channel that you control, and then you don't care about the lower layer's lack of openness.
I agree with you, but the issue here is that in traditional phone architectures, the baseband processor could interrupt and monitor the execution of the main CPU (for efficiency purposes). So theoretically you couldn't be certain that your plaintext wasn't being exfiltrated. With a separate baseband, it's a lot harder (but possible) for a blackbox CPU to exfiltrate your info.
The problem with the proprietary components is that it makes it very difficult for third party developers to install their own versions of the operating system. The complex system of mandatory proprietary firmware is the reason why the custom ROM ecosststem is so fragmented and unreliable.
I wish they would do more practical engineering work on the only real product that they do have, which is the laptop. I visit their forum from time to time, and there are multiple long standing posts with multiple people facing problems due to battery drain, fan issues, suspend/resume, freezes etc. All this grandstanding is useless if the product fails basic usability criteria.
I thought that was odd too. There is one instance of the word "ethical" in an otherwise technical article and it's hardly egregious compared to the marketing speech of nearly big tech company:
> We will continue to evolve as we understand better how this subset of the industry works. The success of our phone is critical, as it will provide us with the legitimacy and leverage we need to bend hardware suppliers to our way of thinking by showing them that we have the potential to be market leaders with ethical products that respect users.
See dang’s comment way down. The link was originally to a very self-congratulatory press release from the marketing person, and later changed to a blog post with details and exposition from the CTO.
Purism’s style in press releases is pretty annoying, but I really appreciate the blog posts.
I backed the phone. I’ve backed most GNU+Linux replacements for my iDevices.
If it half-works it will have wildly exceeded my expectations!
> The cellular modem is arguably the most complex part of a mobile phone.
Ok, so in the dev kit/final product will there be a physical switch to turn it off?
Or at least a CLI command? Possibly a GUI with a big toggle labeled "Turn off the insanely complex unauditable OS that I must run to live in the 21st century because patents"?
Their goal is to still to have "Hardware Kill Switches for Camera, Microphone, WiFi/Bluetooth, and Baseba" ( https://puri.sm/shop/librem-5/ under "Quick facts")
Yes, but the idea is that airplane mode can be faked in such a way by software that you cannot be sure its entirely off (remember Android still scanning WLAN/Bluetooth even whilst it was off?). With a hardware kill switch, you have more assurance it is off. With tinfoil, yet even more.
Tinfoil manifests a much worse UX than the kill switch. The foil is physically separate from the phone and can easily get misplaced or torn such that the phone is no longer able to be secured. Moreover, the user can be so physically exhausted that they neglect to retrieve the foil from their fanny pack and properly wrap the phone (not to mention checking for any areas where holes might let the signal escape which takes extra time).
It is at least an order of magnitude quicker for the user to toggle a kill switch that resides at all times on the phone. Negligence due to physical exhaustion is thus eliminated-- as long as the user can physically access the phone they have sufficient energy to click the kill switch. And as long as the user is able to reach the phone they can access the kill switch, which isn't necessarily true for the tin foil.
Additionally, there are a variety of social engineering attacks that can cause a user to become reluctant to wrap their phone in tinfoil, reluctant retrieve the foil, and even reluctant carry their fanny pack with them. None of those attacks exist for clicking a toggle, especially one designed as an elegant part of the phone's facade (which itself may go unnoticed by the would-be attacker).
Finally, toggling an unobtrusive switch on one's phone doesn't invite onlookers to come over and start discussing unwanted topics like PGP keysigning parties, onion sites, and how the average life span would have increased by 20 years if everyone were still using Gopher.
I am totally fine with PCs, which allow me to install any OS I prefer. And I am totally fine with smartphones, which allow me to flash any ROM I prefer. This way I get both, secure hardware and private software.
Looks good in principle. It meets a lot of my requirements.
I’m not sure what ethical means when a corporation says it. Purism at least state what they mean and how they apply it.
What I’m looking for in a mobile phone:
Good screen. iPhone X quality.
4gb ram.
16gb main storage.
Headphone jack nice but not required.
Linux OS. (Android is ok)
Ability to write my own apps for custom accessories.
Some kind of AppStore. (Debian apt repo is ok)
Secure Enclave.
Cellular is not directly on main system bus.
Accelerated graphics.
Decent sound.
Fast enough to play video with background tasks.
Removeable battery.
Repairable.
A shell that looks like it was built by blind people is probably a hard sell for an "open" phone which many will already believe to be lacking in polish.
So, when it is said that it is ethical, does that extend to labor conditions in Purism's upstream supply chain? I would buy such a phone for its more robust privacy, but I wouldn't call it ethical if it was produced with conflict minerals and virtual slave labor.
Not that you can really escape those realities the way things currently are.
I don't see anything on their sites about accessibility features. An ethical FLOSS phone is an awesome idea, but I'm concerned that if they don't think about accessibility at all in making it then it will be hard or impossible to add those features in after the fact.
I hope they dont go that way. The amount of engineering effort required to do that would be immense and it would be a constant game of playing catch up to android to ensure that all APKs work.
Disclaimer: Views expressed here are my own and do not have anything to do with my employer.
The way I'd do it, is support the kernel extensions needed (or some wrapper) for the android specific stuff and leave it to the community to start actually making things work. There's a lot of research and work already done out in the android community to strip off a lot of the google play stuff from android and leave you with a functional device. I suspect that a lot of that would make the job easier on the software side. The API side (display, sound, etc.) will probably be a lot more difficult but it has been done in the past. Google's done this with ARC Welder and running some APKs in Chrome. Not sure if it's open sourced or not but if it is then it'd probably handle a good part of the work.
Amount of engineering effort involved here would be immense and its unclear if a startup could achieve this and keep up with the developer/ecosystem velocity of Android.
Disclaimer: Views expressed here are my own and do not have anything to do with my employer.
I had not heard about anbox before but that looks fantastic. Given the work put into it I'd expect the same thing if they make official support that way. Combined with F-Droid for a package manager for android apps it'd let a lot of things get supplemented pretty easily.
I can see how for some this might be necessary for sure, but for me I don't use much more than termux, browsing and texting. To me I hope they rely on porting Linux apps and getting the most of that, because I know how much time has been poured into that whole infrastructure. And then if this catches on, it would hopefully fuel the open source community to keep advancing this technology, so that even if purism is gone, someone else can come and pick up where they left off.
I'm just saying, it would be a huge advancement for the Linux desktop to fit Linux desktop apps in a mobile context. (And a huge step for reactive design, if done well)
I'd be interested in this, as well. Also: What is the operating system's UI going to be like? Considering that https://pureos.net only shows the desktop version (a Debian derivative), I'd say there's a lot of work waiting for them on the software side alone to make the OS usable on a touchscreen.
I believe they mentioned this in the long document accompanying their initial crowdfunding campaign. Thought this would not be the case in first release, but to be added at a later time, and running 'compartmentalized' if I remember correctly. Don't know if things have changed since.
Every time I hear about the Librem 5, I get excited about the idea that I could run Debian, or Arch, or another open source OS on a phone. But I can find scant details about how this would be implemented.
Not sure what you mean? It gets implemented by using a touch-friendly Window Manager, touch-friendly apps, with apps for all the phone features you'd expect?
In Debian or Arch it's very easy not to install them and still have everything functioning properly. It's not the case with LineageOS, where Replicant needed significant effort to work and its hardware compatibility is still poor.
This is very interesting. I couldn’t find any details regarding the hardware for the initial device, I assume this is because it still in production. Is there a ball park we can expect?
I love the idea of an open source phone which could be used as a phone & laptop replacement. Even if I’m still likely to carry an iPhone as well (but probably as a wifi only device if PureOS can a handle my phone needs).
The article mentions they will use NXP's i.MX 8M which has 4 ARM A53's [0]. That would make it similar to Qualcomm's Snapdragon 410 as far as having 4x A53's, but the process and clock speeds could be different.
Cheap Chinaphone: €300
DNS66 and Yalp store so that nobody gets payed: priceless
There are easier ways to frustrate the tech industry. Oh and if you live in the US mobile networks will still sell you out no matter what brand your phone is. They all have to connect to cell towers.
how is it ethical? surely if it was ethical it would be spelled out what its ethics are and how it guarentees those ethics are maintained across it's entire business practices including its supply chain? I'd also expect if it is shown that it is not ethical in some way, then the phone isn't ethical, and a full refund would be provided :)
Last time I tried to order a purism... I waited for 4 months and then took about a few weeks and multiple payments for a refund. Have they worked out their supply chain issues yet?
> we foresee a delay in production until April 2019.
This is the only bit I read, the rest was blah blah. The first entirely predictable delay of many, if I might add. They are on a long road to "Sorry we tried, here are some discount coupons for purism laptops". Well, it won't be that long really, unless a badly needed funding angel swoops in.
Their delusion is in some sense laudable, as any startup should believe it's own bullshit. But when you know better than they do about their chances, it's still hard to watch folks put themselves through this.
> Their delusion is in some sense laudable, as any startup should believe it's own bullshit. But when you know better than they do about their chances, it's still hard to watch folks put themselves through this.
It doesn't look like they're a startup as far as I can tell, they're a laptop manufacturer with 2 products on the market for a few years, doesn't look like there's any VC money in the mix either.
When you take on a project that requires leverage of 100:1 over your current annual profit, I'd argue you are a startup again. That commitment will easily swallow the company.
Note: I'm generously estimating their profit at around $1M year. ~$100M was the cost to bring up the Essential phone.
So cynical! I don't blame you, but being a cynical and pessimistic spectator is easy. Instead of slinging shit you might indulge us with just how you know better. Is it from watching many failures from the sidelines?
They are wildly undercapitalized for what they are trying to do. They asked me to invest, I said no.
It will be tough for them to find investors, the phone industry is a ruthlessly competitive market.
The CEO is very headstrong. That's great when you are an expert in hardware projects, but he's not. In my opinion, they are trying to do too many things, and aren't learning from their mistakes or listening to the advice of others.
The best thing they could do right now to maximize their chances would be to lay off their software team and focus entirely on the hardware. Let the community supply that part of it.
Yes, I think they're crazy for not just focusing on the hardware and shipping AOSP. I think the point of having a completely open source/up-streamed kernel is that it's straightforward to run any mobile OS... that they're trying to invent their own at the same time is a little ambitious.
To have the completely open up-streamed kernel would be great and that's reasonably ambitious task they could focus on. But nothing more, there is AOSP with F-droid for that.
As somebody who was deeply into Openmoko community back in the day, I believe that it would massively hurt their marketability.
I agree that this delay was entirely predictable though. Some time ago when I heard at their Matrix channel that "we're still targeting January" I was all like "wait, what?". A plan that gives you just 2-3 months from sending out devkits to final shipping simply has to fail; I'm glad they didn't stubbornly tried to deliver and just delayed, although I'd rather have them delay to May or June already, as it's IMO still a bit risky.
I'd like them to do that too. It's a chicken/egg/bootstrapping problem. You don't get a community of developers without HW, and you don't get a useful HW running OSS OS/userspace without the community.
OTOH, I think they'll have trouble attracting that much of a community to sustain the project if they just throw out such an expensive initially useless hardware out there.
But at least people will have something to play with. Better than promisses and sorrys.
The software needs some sort of vendor polish.
Let's not repeat the mistake of OpenMoko, where its utility as a basic phone had its problems, thrown over the wall for the community to fix.
Though this works for plenty of SBCs produced by Chinese vendors, who just slap on SoC vendor kernel on some debian userspace and that's that from the software side for them.
HW must be appealing though, even if by being dirt cheap and with plentiful options. But it still takes years for community to produce something useful.
* Modern phones (and all the flagship phones) have had separation between their basebands and APs for years; a modern smartphone baseband is essentially a USB peripheral.
* The two largest smartphone vendors have large, world-class security teams that do things like audit their basebands. Has Purism?
* A modern flagship smartphone will have some kind of secure enclave. Apple's has dedicated silicon, and an encrypted memory bus linking it to the AP. How does Purism's hardware security model compare?
* I don't know how much Apple and Google spend annually on outside security research for their flagship phones, but it's a lot. Who has Purism engaged to evaluate their designs and spot flaws?
If you want to use a niche phone as a fashion or political statement, more power to you. But if you try to market that phone as "transparent code is the core of secure systems", I'll take issue with that; it's neither a necessary nor a sufficient condition for security.
This phone may very well be more "fair" or "ethical" than an iPhone. But if it's not as secure as an iPhone, it's unethical to claim otherwise.