2019, the year of an open source phone. I almost can't believe it. I'm super happy they're not reinventing the entire wheel and are using an ecosystem that already exists (GNOME). Much of the non librem specific work is being done upstream which is great.
Hopefully also the year of Linux (with the standard desktop stack) on touch-first and small-screen devices, thanks to Librem 5's choice of cooperation with the overall Linux community. Admittedly, we were there before with environments such as QTopia, GPE and Hildon, but these were niche efforts targeted to a handful of very expensive and low-performing devices (thus, their code was never shared "upstream" as is happening now)-- the situation today is quite different.
An Open Source phone would only be actually beneficial if there will be an automated transparent and trusted global support infrastructure for it that would require zero user interaction.
I use an iPhone because it’s the most secure hardware and software combination you can get and you are guaranteed to receive support for 5> years.
I don’t want to have to compile my own kernels, set up my own chain of trust or deploy my own patches.
It’s too cumbersome which would lead to procrastination that is if you don’t screw up something in the process to being with.
Also as far as the hardware goes I have currently more faith in Apple being able to get and secure its supply chain than a small company which completely relies on Chinese OEMs for its design.
The baseband will not be open source, it will have to use blobs as such other than running a more vanilla flavor of Linux I don’t see it being any different than any phone that can run AOSP.
Yet you get hardware kill-switches for the baseband and mic that assures you of your privacy when you require it. Much better than any 'assurance' from Apple that you can trust them to be the good guys. Has everyone forgotten that Apple, along with every other major platform, complies with FISA requests or their foreign equivalents? How do you think Apple operates in China?
They will be good guys until they decide they will not be good guys for arbitrary reasons or if they are forced to comply with a Government decree.
I'd much rather put my trust in a good-enough hardware platform that I _know_ I can control when required.
As long as your network traffic is sanitary before it hits the baseband (Tor, VPN, or something you trust) you're good on that end. A better design would be to have three settings for the mic: baseband, app processor, killed, so you could run the audio path through free software as well (VoIP). The idea is to minimize what the baseband is doing in the system, and assume it's malicious. It's hard to duplicate PhD person years on the signal processing side, and, if you get that far, then navigate the IP minefield.
Yep. It’s a bad philosophy when it actively deflects from possible changes to the circumstances comprising progress. In this case, it’s much easier to make an open source phone than cell network. Not to mention no one has the sort of capital to setup an open cell network.
Being imperfect relative to the flagship commercial phones is a problem, because ultimately end-users have to use these things for them to remain going concerns, and it's hard to see which users are better served by a less secure phone stack.
That would be imperfection in terms of features, not security. And yes, users do need to be able to actually do what they want, but the bar isn't that high and it certainly isn't uniform; some of us are happy with web browser, SMS, and a shell. Further features will widen the appeal, but for starting out they seem to be doing fine.
I believe that it is at least an equally secure phone stack vs most Android (granted, with the root of trust in the user rather than manufacturer, which I think is a good thing), and only might lose against Apple and Google flagships thanks to hardware features.
"Versus most Android" is, of course, a dodge, because the Android ecosystem ranges from comically insecure phones to expensive devices that asymptotically approach the security of iPhones. Achieving parity with commodity Android devices doesn't help end-users; every user who uses a Librem device to obtain that weak level of security has probably been harmed by the project.
This isn't to say that it's impossible to build a device that is more secure than an iPhone! It isn't. Librem simply isn't doing it; they have other priorities, including feature parity with modern smartphones. They're not willing to make the serious tradeoffs needed to get security given their circumstances.
By "most Android", I mean "everything without a Titan chip". I'm not convinced that it's meaningfully less secure for anything but targeted attacks by abnormal skilled attackers. Should be better, if its kernel is better maintained.
Considering the plethora of ARM trustzone and bootloader attacks against Android devices I don't think an abnormal skilled attacker means what you think it means the average repair shop can extract data from the majority of android phones today.
You also have successful key recovery/bypass attacks against most non-hardware backed crypto Android devices as well.
Like Thomas said it's not impossible to build a secure device, it's not even impossible to build a secure open mobile device but it doesn't seem that they are doing it.
Their focus is on having feature parity, using commodity hardware and just having an FSF approved stack.
Having an FSF approved stack doesn't make you more secure by default.
And usability has a great impact on security, I remember the early android days where getting a file off the device was PITA so myself and many others were running an FTP server on the phone, and since most of our phones were rooted im pretty sure it was running as root.
The other side is things like permissions while mobile operating systems aren't that great still they've began taking application permissions really seriously going through the Librem documentation I don't see anything that is even remotely close to the level of granularity that Android and iOS offer today.
Sure they might add that in the future but the point being is still that there is little chance that the first phone they launch would be more secure than an android phone yet alone a modern iPhone in fact I would bet at least one paycheck that they would be considerably less secure at least initially, and then it's the question of how they would be able to maintain and support their platform given their size to begin with.
I don't doubt the intentions of the developers I just highly doubt that anything they set is even remotely achievable.
>An Open Source phone would only be actually beneficial if there will be an automated transparent and trusted global support infrastructure for it that would require zero user interaction.
I think that's a given except for the zero interaction. Even my android phone alerts me of updates. Anyways, you make it sound like it's nearly an impossible task, but nearly every day my ubuntu laptop alerts me of updates and then updates in the background far more seamlessly than my windows workstation. Plus the distro has over 4 years of support. This is something linux distros figured out years ago.
I don't know what Librem 5 will offer in the end, but I think your response argues a false dichotomy with zero evidence. There is no "automated transparent and trusted global support infrastructure [...that requires] zero user interaction" for anything and (given how we improve things in real life) apparently such a thing is unnecessary. If you want to know how something works, you either learn how it works and do the vetting & improvement yourself, or get someone you trust to do this work on your behalf. Computer hardware and software is no different. The question is whether you're allowed to do this work at all, whether it's possible for you to hand someone you have good reason to trust the device and software to do this vetting for you.
There are many good reasons not to trust Apple or any proprietor. You claim an iPhone is "the most secure hardware and software combination you can get" but you offer no evidence to let us understand how you arrive at that conclusion. Proprietary software (such as iPhone's default OS, iOS) is untrustworthy by default because nobody but the proprietor has permission to inspect the software's source code, alter the software to fix problems or improve the software, or help the community by distributing improved software. You don't have the freedoms of free software (running, modifying, sharing published computer software including commercially). So in order to estimate Apple's trustworthiness we can't examine the thing itself in the most reasonable and thorough way. We have to fall back on something else such as Apple's reputation and consider how they treat their users. Apple left years-old remotely-exploitable security bugs in programs thus leaving users vulnerable (see http://www.telegraph.co.uk/technology/apple/8912714/Apple-iT... or https://truesecdev.wordpress.com/2015/04/09/hidden-backdoor-... for details). When it comes to iOS issues things are no better: iOS is the prototype of a software jail (hence the term "jailbreaking" to liberate one's device, and thus the user, from such control). Apple can and regularly does extract data from iPhones to give to the state (per http://arstechnica.com/apple/2014/05/new-guidelines-outline-...) and Apple's claimed security improvements rely on software users can't vet, improve, or share. https://www.gnu.org/proprietary/malware-apple.html has lots of examples of various kinds of Apple proprietary malware many examples include software iPhone users run. Apple also works against letting users get fixes without going through Apple, slows down iPhones users won't "upgrade", and disallows using older versions of iOS or non-iOS operating systems (because why let users control their computers).
This is all par for the course with proprietors; proprietary software (nonfree software, software that doesn't respect a user's freedom and community) is often malware (software designed to mistreat its users). The worst part is that because these programs are proprietary, motivated and knowledgeable users are not permitted to vet, improve, or distribute software that could benefit themselves and the entire community.
Maemo phones did not isolate the cellular modem from the rest of the system. Also, a number of essential packages on the Nokia N900 were (and still remain today) closed source.
Jolla doesn’t make devices any more. Their only business case is licensing their OS to paying customers. While many packages in Sailfish are open-source, naturally the company is holding back a lot of things in order to serve as the exclusive provider of the OS.
A number of under the hood elements are being reused. Telepathy still drives the messaging system, and ofono is being used for the modem. The GTK2 UI from Maemo was dead in the water even before the shift to QT when Meego was released, so it makes sense that they would base a new GTK UI on a modern Gnome. A QT UI is available in the form of SailfishOS.
Regardless, the "interesting" work on the Librem 5 sits with none of these levels, but further down the stack, with mainlining the kernel work needed for the device. After that, the userland work provided by Gnome/Plasma Mobile/Ubuntu Touch/Mer all become interchangeable.
Sorry off topic but if I could follow one person for experience, not bring biased and knowledge of the state of the art of software tooling (and tonnes of other things... but tools are useful and not easy to find) then I would follow you. Your comments are very informative.
While I use Gnome, and like the way it looks, I feel it's a mistake on a phone unless they are doing a lot of heavy editing. While it's gotten better, the JS -still- leaks and randomly pegs the CPU. In a phone I would imagine a battery life measured in minutes.
The in-development "Phosh" shell does not use JS at all; it is not based on GNOME Shell, even though the work on Phosh is being done as part of the GNOME project.
Without running the exact numbers I feel like running down an entire average size cell phone battery in a few minutes would lead to everything bursting into flame. I don't think an average cell phone cpu can actually exhaust an average battery in that time frame.
I feel like if it were going all out at all times for no reason it would still last a few hours.
Also pretty sure this thing runs gtk apps NOT gnome which renders your analysis flawed.
Yours and other comment did reveal my analysis was flawed, thanks for that.
Re: the first two points, I really don't think so. I have a Nexus 5x that would kill the battery in around an hour if video chatting (to your point, it did get very very hot). There is also a recently revealed 'bug' in the NXP SoC being used by Librem themselves, who claimed it was killing the battery in an hour. I figure anything under 2 hours is fair game to be 'measured in minutes.'
How old is the battery in the nexus 5? It's a 5 year old phone at this point. Daily charging could have put it through 1000 or more charge cycles at this point.
Pardon my ignorance but what is the criteria for a linux desktop being a thing? Is it a certain minimum market share?
There's plenty of linux desktops out there. There is certainly a ways to go, I'm not trying to deny that, I'm just wondering what constitutes a successful linux desktop. User-friendliness? Where are the goalposts exactly?
How about you commit to buying their device if they do ship it this year. I'd read those blog posts about your experience - along with any doses of humble pie you ~may~ have to eat.
To quantify this now. Are you counting a final product as them going GA, allowing anyone to buy and get one? Or are you counting a final product one that you do not consider beta. The latter is very open to interpretation.
The work puri.sm are doing and the way they are doing it is just fantastic. I really hope they manage to get the phone out sometime this year. If they can make a project as big as this work, then it could really show the industry that you don't need to make restrictive, secret, proprietary software to make a success.
so some of the "hurt" GNOME used to introduce on major versions will pay off in user friendliness in a hybrid user story on handheld devices? the long con ! - I wish them luck, the presentations are impressive. So too the kde-neon folks had a convincing technological argument last I checked them out end of 2018.
Smartphones always were a downer to me. Having flashed some devices and using f-droid exclusively I sure saw good apps by good folk, but "desktop computing" always felt friendlier. The slick Apple and Google ecosystems never attracted me - and with the breaking-news stories on whatnot App SDK had some data sending somewhere I think the browser is a better sandbox for some companys and use-cases than deeper OS integration. Not that it is benign, but still.
I'm incredibly thankful to the people driving the GNU/Linux effort and foss ecosystem, offering their ingenuity for inspection by a wide audience. Computing got actually simpler as I got older and discovered tools sometimes made before my time. I never had that feeling with handhels - but this might change soon.
One thing that I think is a strategic mistake, they should've used UBports for the OS, instead of also developing their custom OS for the device.
This market is too small and fragmented to have the wasted effort. Its difficult enough to build the open hardware device, no need to split energy / IQ by also worrying about the OS.
They're working with UBPorts and KDE to get Ubuntu Touch and Plasma Mobile running on the phone. PureOS is where they do their work, but they're made a point of trying to upstream everything. They're doing it right.
They're not building their own OS, they're building a few apps and dealing with hardware specific driver issues - but otherwise a lot of stuff is projects that already existed and needed improvements (which they have done upstream) or working directly with those upstream projects.
To emphasise, I think this is far less work than it would be to actually get UBPorts to a point where you could reasonably ship it on your device to match customer expectations.
I think skipping UBports was the right call. UBports is too design constrained and they shell they've been working on in its place uses much better design and should support a much wider variety of applications OOTB.
Full disclosure: I am the maintainer of a critical open-source component that influenced this design decision.
Happy to see lots of progress in this update. Each month I'm saving towards purchasing the Librem 5 after I hear confirmation that it works on T-Mobile networks in the US.
I'm sitting in the same boat, but for Verizon. This blog post actually comes with some hope, with the specific statement that the SIM7100E is supported. Verizon has already approved another SimCom chip, the 7500V: https://opendevelopment.verizonwireless.com/design-and-build...
One could hope that the code used to support the former could be adapted to support the latter. And as long as the Librem 5 is able to support an already-approved Verizon module, it shouldn't be a problem to activate the phone on Verizon.
This struck a chord with me, since I find the price a bit high as well. My consumer thinking is that if it's expensive enough that I'd have to save for it, and there's no important reason to buy it over something cheaper, it's a waste of money. Of course, thinking this way, I don't end up having the hip new stuff; is it about that?
Same, my current Nexus phone is pretty busted up and literally held together with scotch tape, I'm just hoping the Librem 5 releases before I have to buy a new phone.
It's very unlikely to be. The Fairphone is one of the only phones making an effort, and it's a lot of work [1] and even then they're still long ways of from being actually fair. I can't imagine Purism to have the time to invest in this, nor to do that without even so much as mentioning it.
Eco-friendliness and fair-trade would hike up the price and would require more work, unfortunately. If it were those things, they would probably actively advertise it.
On the bright side, this work, since it's opensource, might facilitate a similar future projects that could aim for higher responsibility standards.
Personally, this platform caught me a bit off guard, and I'm currently ecstatic with the possibilites.
I'm very compelled to pre-order one but has anybody heard any news about the touchscreen or the CPU issue? I worry that there is no word on either in the recent update (like what is being done, what is missing...?)
