I get the point of low cost phone to keep the price low. I also know that there is a group that, rightfully, enjoys hacking on low-powered hardware to push it to limits. However, I wonder if there is also an opportunity to also sell high spec hardware, maybe in limited quantity. These phones are not for the masses anyway and I'm sure there is a Linux enthusiasts segment with pockets deep enough to afford the hardware - they know what they are getting into. Atleast what works will work fast and the software will only improve as we move along - which means improved overall experience. Plus it helps with the project funding too.
The iPhone 1.0 came out in 2007 and it ran on a single core arm cpu under clocked at 412mhz and with 120MB of ram and the scrolling was butter smooth. I remember being shocked at how responsive the touch screen was compared to other smartphones at the time. The PinePhone contains an AllWinner A64 Quad Core CPU with 2GB of Ram. Sure, its a crappy 5 year old Soc but it is MUCH faster than the original iphone. I know, modern smartphones have a much higher screen resolution, but still. I mention iPhones instead of android phones because it took quite a few years for Android phones to achieve that same butter smooth experience.
The perceived slowness of the PinePhone is due to layers upon layers of software used to draw simple 2D stuff to the screen. I think a really simple bare metal GUI would be better than running a full blown linux desktop environment like GNOME. Even if you "skin" and strip it down for mobile, it is still laggy as hell.
Linux on a smartphone => yes
Linux desktop environment on a smartphone (even with Wayland support) => no
I am less interested in the "daily driver" part of the PinePhone and more interested in the power consumption and responsiveness of the device itself. Stuff like this is exciting (extending the standby time of a PinePhone to 100 hours): https://github.com/crust-firmware/crust
During Librem 5 development, they considered using GNOME but, after talking with the upstream devs, they abandoned the idea.
Gnome is slow even on laptops, it was made for X and later ported to Wayland, it uses Clutter/Mutter, JavaScript, etc. So here yes definitively it's layers upon layers.
On the other hand, Posh is based on Wlroots and there is no layers. It's pure C code talking directly to EGL/DRM/KMS (And in the future Vulkan) stack.
Even more interesting, Wlroots allows the use of hardware layers and with that you directly write to the screen and compositing is done in hardware. You can't go more optimised than that.
With this kind of approach you can totally write a convergent, both phone & desktop, environment which is butter smooth on low spec mobile.
But of course then the whole question is which apps you run on that environment, the typical Electron app won't run smoothly (but it wouldn't either on a IPhone 1).
On the other hand, GTK 4 should be GPU accelerated and Qt too so those could run pretty smoothly
Phosh uses GTK, right? That's a pretty thick layer right there. You used to be able to put pixels on screen with a handful of ASM instructions https://www.cprogramming.com/tutorial/tut8.html
Yes this is totally true, I should've been more precise.
There are two parts : 'Phoc' and 'Posh'. Phoc is the Wayland compositor (Wlroots & C), Posh is the launcher UI (GTK).
Phosh is just "an app" (with special privileges to talk to Phoc). All it does is display app icons and windows thumbnails (which are not actual live windows but just screenshots of the apps (like on Android)) it does not composite windows, it does not stand between the apps and Phoc.
This is unlike Clutter & JavaScript which do stand between the apps and the Wayland compositor (Mutter) on GNOME.
So my point is that apps on the Librem talk directly to Phoc (not Posh) which is a super minimal layer and can draw pixels on screen with almost no overhead (and potentially none at all when they'll support hardware layers)
(Note : this is the Librem architecture as far as I understood, maybe I missed something)
Very interesting, thanks! I wish there were more videos focusing on UI latency and snappiness for the Librem 5 but all you see are "feature" videos. It's hard to tell if the phone is laggy (finger move to eyeball time) or not.
Let's not forget how much bigger iOS is now compared to 2007. I doubt it would run smooth on a 128MB device in 2020. Phone companies have to keep up with software's requirements.
> I doubt it would run smooth on a 128MB device in 2020
It would not run at all. No mobile OS has a swap partition as far as I know, and it would not make sense to add one due to performance and power constraints.
The problem with linux phones right now is not the price, but the usefulness/software. The UB Ports edition of the phone doesn't have a working camera, and the Mobian can only use one camera at a time, with a script to switch between them. In about a year when these issues are resolved I'm going to recommend them to everyone I know and probably buy them for my family.
As far as high end goes, Librem 5 from Purism has better specs (still a lot worse than high end Androids/iPhones. That's open source firmware for you).
This. I am fine with Pine hardware. On the surface it should be sufficient. Oddly, my experience with Ubuntu OS is just plain awful. It made me miss Android almost instantly. I genuinely expected more.
The physical switches are nice, but you still need to have some decent functionality to make it a daily driver. Sadly, it is not there yet.
Since we are talking about it, if someone can recommend good alternative to Ubuntu for my UBports edition, that would be awesome.
I am slowly preparing to try other OSs on Pinephone, but since it is not super easy process ( and since you have full access, you can easily brick your phone ), I have thus far spent more time learning about it than just trying to jump on one of the other OSs.
You cannot easily brick your phone. You just use dd to write any image to the microSD and the phone just boots from it. Also see here concerning the internal memory: https://forum.pine64.org/showthread.php?tid=9444
Many people like Mobian. It has a very nice UI (Purism's Phosh) and the full GNU/Linux under the hood.
> Sxmo, or Simple X Mobile, is a collection of simple and suckless X programs and scripts used together to create a fully functional mobile UI adhering to the Unix philosophy for the Pinephone.
Fwiw, I've tried UBports, pmOS, and Mobian on mine, and Mobian is definitely my favorite and the one I'm sticking with for now. And as you've said, installation is just like most other computers/SBCs, by flashing the uSD card.
I like Mobian. It's based on Debian and allows you to do the same stuff as on a normal desktop (technically).
That's also the reason why I almost immediately threw UBPorts off my PP UBPorts CE. You can't do anything like you would it in Linux. For example, mounting the SD card automatically on boot with fstab wasn't possible as it always reset itself to default values. The root partition is also read only. No thanks.
For trying other OSs. Just flash them to an SD card and put them in the phone. It'll boot from the SD card before booting from the eMMC.
> Librem 5 from Purism has better specs (still a lot worse than high end Androids/iPhones...
What I would say from booting linux on apple hardware is: apple has a LOT of fat to cut away.
macos/ios run an enormous number of unnecessary processes, and apps themselves use tremendous resources as well. So a lot of resource use is for business reasons and not technical ones.
Off-topic but IMHO what is really needed these days is a privacy feature allowing all the UIDs to be changed freely by the user (without the need for rooting and firmware thinkering).
Including randomized IMEIs and randomized Android ID (In addition to the already offered randomized MAC and Ad tracking ID changes).
Especially IMEIs which are commonly used by many applications and law enforcement to track users (see Banking apps for instance that all require your phone permissions to read such IDs).
Nor Librem nor Pinephone offer this functionality from what I know.
I don't have the reference, but I am pretty sure that in order to meet requirements for type-approval (e.g. FCC approval in the US) phones have to show they are resistant to IMEI modification.
Respectfully, I think you misunderstand the page. The Quectel EG25-G is the modem only, the main CPU on the Pinephone is an Allwinner A64 ARM Quad core Cortex-A53. The modem itself has its own linux kernel, app space, etc.
Oh I expected Qualcomm MDMs to run some proprietary RTOS with some NVRAM write protection, but if Linux is already in control then certainly an on-the-fly IMEI switch without resets or QPST/QXDM sounds more feasible.
They do. These types of Qualcomm modems run QuRT, a proprietary RTOS, on the Hexagon processor which handles the baseband and the LTE stack. There is also a shitty little core that runs "psuedo-Android" - you have adb and things like that, but it's mostly a more traditional embedded Linux environment- and handles certain AT commands (they actually go to the baseband first, but get IPCed over to Linux for handling after parsing if they match a registered command).
With root on psuedo-Android, you can probably get code exec on Hexagon - especially for the cheaper modems, they have an older version of the Hexagon architecture and to work under this architecture things like ASLR are relatively rare. But it's more work - there's no obvious "execute arbitrary shellcode" IPC message, you need to do more RE/VR.
I don't really see an issue for manufacturers there. We have the same regulatory issue with Wi-Fi power which will adjust transmission power differently based on the country it's sold in. The phone could easily enable to disable a feature depending on where it is. Remember Bolivia dBm limits ? :)
Regarding your German link. It's about tampering with evidence which I suppose means it's about changing the IMEI after a crime to hide yourself. I suppose that would be illegal everywhere?
" But a person does not commit an offence under this section if—
(a)he is the manufacturer of the device, or
(b)he does the act mentioned in subsection (1) with the written consent of the manufacturer of the device.
"
So I guess it's okay in the UK if the manufacturer allows it and is okay with it?
But of course I'm not trying to promote this feature for illegal use but mostly to hinder "inescapable" tracking from Advertisers , Mobile Operators, ISPs, Phone Manufacturers and ...
True, in some regions this is not allowed. It was mainly for the purpose of blocking stolen IMEIs though which is not really a thing anymore (since Apple/Google's activation lock is so good there's no more need).
Also, for avoiding tracking purposes there is really no point in changing your IMEI. There's many other ways they can track you. In fact I don't see any real reason to do it at all.
Easy: check if the imei on the back matches the one shown in the software as part of a theft check. Threaten the user with seizing it for suspected theft or whatever if they refuse.
That would only work if you are already under suspicion for something. I don't think many random cops knew how to check the IMEI, also because you'd have to open the phone up. (I think so?)
You're mixing a few different concerns together. With a properly designed permission system, applications do not get access to identifiers such as IMEI and MAC addresses. If an application demands some information as a condition of running, a proper permissions system should return appropriate mocked data.
The only place the actual IMEI should remain a concern is when talking to the cell network. Mitigating this is an unsolved problem, and it needs to be worked on. Some ideas - staying in contact mostly via Wifi (and only turning on the cell radio for dire situations), or a carrier that deployed sims that periodically rotate IMSI.
That is a persistent myth, because it is blanket illegal in other countries. In the US, it is only illegal to change an IMEI in furtherance of some other crime - eg theft or unauthorized access.
Also, swapping the modem chip would (well, should) be a permitted use, as the IMEI is meant to be bound to the modem. When a separate modem module is used, the modem is the communication device, not the phone.
The pinephone is more similar to a laptop with an optional LTE module rather than an integrated setup like an smartphone where the CPU contains the baseband. It's not illegal to swap out modem cards in a laptop anywhere AFAIK.
The old fashioned way was using QPST/QXDM to modify the ESN/IMEI of phones but that was questionable enough. This also includes bluetooth mac address too and other UID's in the baseband. :)
Perhaps this legislation gives you a clue about how on the ball some Govt's are when it comes to security matters?
What you are suggesting is a phone that changes its obvious identifiers, but the problem with that is some services may not work, maybe an app purchased from an app store, or the network services you get from your cell provider, like answer phone facilities when you are in a dead zone.
So if your phone is acting like a character out of Scanner Darkly, just how will it operate? How will your friends know its you calling if they dont recognise your number?
To have a cellular network that allows random identifiers, you would need a system which accepts prepaid communication time, but in todays age, just like bitcoins is a public ledger how would you convince someone to build a cellular network that accepted untraceable communication time tokens?
Whether you like it or not, Science stole your privacy the day you were born and continues to steal your privacy including your thoughts. Perhaps your best bet for some privacy is to limit your contact with other entities whilst also trying to change the laws for the better but as this requires interaction with other entities, it seems like you want a paradoxical situation to exist.
The IMEI just identifies your phone. The IMSI identifies your number.
So it's perfectly possible to change the IMEI if you leave your IMSI alone. The network will think you just stuck your SIM in another phone. Everything will work fine. You can't change your IMSI as it's hardcoded on the SIM (technically you could with an eSIM but it simply would be unrecognised and just not work then).
Of course they still know who you are, and they need to to connect your calls. But apps that look at the IMEI for identification will be confused. Not sure how much it helps in terms of privacy. I doubt it helps a lot as any app can just make up a random number and dump it in their long-term storage to know it's you (just like a cookie).
And yeah the illegality of changing it is an issue in some countries. Also, if you 'clash' with another live IMEI weird things happen :)
PS: IMEI changing was outlawed in those days to stop people stealing phones and changing IMEIs to resell them and bypassing carrier blocks of the stolen phone. It was never that successful as thieves are lawbreakers by nature and don't care at all whether they break an extra law or two. Apple and Google's activation lock were much more successful. I'm personally not a big fan of laws when there are technical solutions that are equally or more effective.
AFAIK, a SIM card itself has a card id (ICCID), which should not be changed and is not used often. The subscriber id (IMSI) is in the "application" layer of the card and theoretically could be changed by the provider, or as a speciality, multiple ones installed.
That being said, I've never actually seen a card's IMSI changed. They usually give you a new sim and IMSI, even for a replacement card.
Most SIM cards are one-time programmable, so they can’t change anything on the card. They do still have a small RW area, but thats generally for user data (contacts).
You can get SIM cards that have large amounts of storage for running applets and have better support for OTA, but most carriers don’t like the extra expense.
Yes they do almost all support it (with many security vulnerabilities as a result, Karsten Nohl did a really great presentation on this at OHM2010). But the IMSI is almost always provided at manufacture time.
I think it's also because the card would not be able to be provisioned over the air without getting connected to the network first, and without an IMSI there is no network connection :)
> Whether you like it or not, Science stole your privacy the day you were born
I don't follow.
I think you have 3 paragraphs describing that the problem comes from irresponsible government agencies, entrenched private companies, and existing public infrastructure. But then you conclude that the reason GP can't have privacy is because science is in the way. I don't see how you got from point A to B.
> your best bet for some privacy is to limit your contact with other entities whilst also trying to change the laws for the better but as this requires interaction with other entities, it seems like you want a paradoxical situation to exist.
This is a somewhat strange way to think about privacy. Privacy isn't binary, and personal information isn't fungible. It's possible to reveal some information about yourself in some contexts, and then hide other information in other contexts.
Of course, lobbying is harder if you're trying to be private (heck, voting in the US is harder if you're trying to be private). But engaging with the system doesn't immediately mean you lose all of your privacy across the board. Yes, we do sometimes talk about privacy in bits -- but the full scope of privacy ultimately can't be represented by a single number in a math equation.
> How will your friends know its you calling if they dont recognise your number?
Apps could handle this sort of thing quite easily. The app itself could have its own ID (i.e. the username you use to sign into that service) and then that's what's presented to your friends and kept in their address books. You could change that whenever you wanted to as well (and then your friends would have to update their address books), but you wouldn't have to in order to change the other IDs, and that ID would only be used for that one service rather than allowing correlation between different services.
> To have a cellular network that allows random identifiers, you would need a system which accepts prepaid communication time
Not at all. If you wanted to change your IMEI, you would just have to give your carrier the new one, which could be an automated process. And your carrier could be a MVNO you trust not to share the correlation between your current IMEI and your account information with anyone. Meanwhile the towers then only have to know that that IMEI is authorized as a customer of that MVNO and send the bill to the MVNO.
But wait, is that changing the on-device IMEI, or just spoofing it when communicating with some random app?
I assume changing the device IMEI would have the same affect of directly spoofing it when connecting to mobile networks, which may be illegal; but If I leave all that alone, and only give a false IMEI to some random app, while connecting to mobile networks with the legitimate one, then what's the issue?
This is the way to do it for legally mandated identifiers like that. Only the baseband knows the actually IMEI, otherwise the OS just blanks it out or randomizes it, down to kernel calls.
Still isn't a very good solution, since you need to have a consistent identifier for some parts of networking to work, such as MAC addresses, IPs, bluetooth MACs, etc.
I've got a Pinephone (the UBports CE, though I'm mainly running Mobian right now) Short term, the use cases are as hacker mobile Linux devices with most of the mobile hardware working (device drivers are still a WIP, Linux text/server software works flawlessly, GUI software is hit-or-miss right now) Long term, I'm expecting them to be perfectly serviceable basic mobile handsets. But they are still a ways off from being 'daily driver ready' (i.e. power management isn't in the same league as other mobile devices and quite a bit of flaky/missing functionality) Another area still needing work is that there are only a handful of desktop apps that have been reworked to have a scalable UI for mobile.
Generally things are still sluggish and battery life is not great yet, which is to be expected since no mobile devices really existed out in the wild for raw Linux until very recently. Now that they do exist, things are improving rapidly. For example: a month ago battery life was atrocious. Today it's merely bad (compared to what you're used to on iOS/Android)
So what does this feel like in terms of real world usage?
1) Want to use it to place/receive phone calls/text messages... it will work, to a degree... some/most (depending on distro) of the time.
2) Want to run a web server or open a terminal and ssh over to a server... pretty flawless.
3) Want to run a GUI app designed for or adapted to mobile... the list is growing weekly, if not daily.
4) Want to run a GUI app designed for desktops (i.e. no work has been done to adapt for mobile)... prepare to be disappointed, if you can use it at all.
5) Want to run your favorite iOS app? No.
6) Want to run your favorite Android app? If it's open source, probably will be possible soon-ish. Proprietary apps? Probably not if they rely on proprietary Android/Google services.
How is the battery life? On UBPorts a few weeks ago I got about 8 hours standby, which truly is atrocious. I would probably switch to it being my daily driver if I can get 3 days standby on a distro.
A huge recent improvement is support for Crust firmware (https://github.com/crust-firmware/crust) which should get you 12-40 hours of standby (the low end is with wifi and cellular on, the high end is with them turned off. A day to a day and a half is the best I'm seeing) That just happened in the past month on most distros. Even with that installed and enabled, there is still significant room for improvement on power management of wifi and cellular. Mobian still has issues with things like random wakeups and not turning off the screen digitizer. I'll be very surprised if we can't see the standby time increasing to 3-7 days depending on what's enabled, but it will take time.
That was reported but I've never seen anything close to that even with all wireless turned off. This could be due to other power saving issues on Mobian... I just don't know yet.
To be clear, this when the phone is allowed to be in a sort of 'deep sleep' mode, this probably isn't representative of day-to-day use. The point remains though that more and more power management is working and things are improving quickly.
I'm using a pinephone, and contrary to most people, it's actually my "daily driver".
This was made possible mainly because I have prepared for about a year for GNU/linux phones (thinking of the librem5 at the time) by replacing all my commonly used apps with similar webapps.
All in all, I don't have an advanced usage of my phone, so it may be what makes it possible to use the pinephone. I don't commute (no need for maps, games, durable battery), I don't often take pictures, my only real need for my phone is the hotspot (because it's my only internet connection) and calls/messaging.
The pinephone is extremely cheap hardware and it can be felt. Opening firefox takes a good 10 seconds, and browsing with it is a pain. Gladly, GNU/linux is very good at running on poor hardware. I just replaced the browser with elinks, which I run through tor, just like on my laptop, and it does the job. Lollypop works well to listen to music while I'm out. Calls and text messages are good enough.
The real cool thing, though, is how hackable it is. After a few months with the phone, I've played a lot around the idea : how to make apps that doesn't use much power? Because, the battery is very bad. And a few months after, my answer has been to build C applications that runs as CGI apps with html static interface rendered by nginx (the idea being to only run the program when I need it rather than constantly as a daemon). This is absurd, this is fun, I love it.
So, as far as I'm concerned, GNU/linux phones are validated. Now I'll want something with better hardware, so I'll wait for the librem5 to see if it delivers, then switch to it if it does.
EDIT: oh, I forgot to mention a step, it must not be clear that way : I made webapps on the phone rather than GTK apps, because that way I can use the apps from my laptop, using the IP address of the phone on the local network.
I am using Sailfish OS on a Sony Xperia XA2. I am using it now for about 1 year. Before that I used Sailfish OS on the original Jolla 1 for 5 years. I have also used a Nokia N9 with Meego Linux, which can be considered a forerunner of Jolla/Sailfish.
It uses Qt, Wayland, Systemd. The original Jolla 1 even used Btrfs, which was deemed a mistake. Sailfish OS is available on more devices, like the Pinephone, Fxtec, Cosmo Communicator and others. If you have the official version for Sony Xperia, you get Alien Dalvik, with which you can run Android apps. I am using Whatsapp and Firefox as Android apps this way. I am still hoping that Signal takes off for mesaging, a native app like Whisperfish is something I would really enjoy. With Whatsapp a native app is not possible, there have been threats for lawsuits.
I am very happy with Sailfish, and have been for 6 years. I enjoy having plain linux on my phone, being able to use ssh as root and having a device that I trust. There are some 'costs' involved, like having less shiny bling and less apps available. Companies like Apple and Google can spend billions on their phone platform. Jolla only has about 100 employees in total. You do have to adjust your expectations somewhat.
Jolla have received criticism about not having open sourced all their software. I do understand that criticism, but that argument doesn't make Apple or Google look any better :) I am curious about where linux phones will go in the next years, but currently Sailfish is good for me.
I got my Jolla 1 linux phone in 2013 and I'm still using as my daily driver. And I still love it!
The reason I'm keeping my Jolla 1 phone is that it still gets security updates after 7 years. I also have an Android phone for testing purposes (I sometimes write Android apps and web pages for work), but it only got updates for few years. I don't want to buy a new Android phone if it doesn't get updates after few years. I'll keep my Jolla.
What I remember (not a linux developer) is that sometimes you have to rebalance the filesystem. You can have free space in megabytes, but no inodes left. (If I am wrong someone might correct me). There have been instances, especially later on in its lifecycle, where a system update was aborted due to no space (inodes) which ended in a lot of trouble.
I've been using btrfs as my main file system for about 6 years now and have run into the "no free space" issue about twice.
It's horrible. Everything stops working and freeing space is quite hard.
Other than that I had no issues with it. Subvolumes and snapshots are pretty cool to me, but I can see how the added overhead might not make sense in a processing power and space constrained environment.
Yes, every few months. Communication is not always that clear, the same with the roadmap :) Early in the life of Sailfish it was decided that being behind on upstream software versions was not a problem, since in embedded software things are different then with desktop and server. In the past few years many work has been done to amend this situation.
There are some other factors in play. It is a small company which is short on developers and keeping the system Gecko browser updated has proven to not be very easy. Then there is the issue that some software is closed source, which works fine with Qt 5.6 which is LGPL, but with newer Qt versions it is either full GPL or full commercial. This is a business decision and developers don't have much say in this. What I suspect is happening now is that it gets postponed untill it can no longer be postponed, which does save money :) Then there is the issue that untill now Sailfish was tied to Android drivers and thus is using Android kernels. In that sense the Pinephone is an interesting development with mainlined drivers.
So yes, in the community there are some complaints, but in the real world I can understand it the situation from both sides. For my practical usecase, a daily driver with whatsapp, I haven't seen a better linux phone yet. Again, I am really happy with my phone, even though the situation makes it easy to be critical towards it :)
edit: Oh, just to add to this, updates can last a long time for a hardware iteration. The Jolla 1 from 2013 is still getting updates. Ofcourse the Android layer is not updated due to old Android drivers, but the rest of the system is just the same a the newest hardware that is being supported. I hop my Sony Xperia XA2 from 2018 will last me 5 years as well, or hopefully even longer.
I have it in addition to my Android phone. I am actually really impressed on how well it works (I use Mobian). Email, maps, calendar, and web browsing all work. The camera sort of but not really works.
The only thing stopping me from using it as a daily driver is MMS:
Ubuntu Touch seems to be the closest to be able to have MMS (it uses Ofono,all of the other distros seem to use Modem Manager). However, it is a bit disappointing as no ground seems to be done on it. I admittedly don't have experience in that, but I would be more than willing to donate time/money if I knew how to.
Heh, interesting. Even on the Pinephone? I know Ubuntu Touch supports MMS but does not on the Pinephone. Same with Glodroid (the Android Port to Pinephone).
The answers won't be complete without mentioning the Maemo/Meego series of phones, including the Nokia N900 and N9.
The N900 keeps its appeal today because it's fully programmable (even if toolchains are woefully outdated), and the community is still (after 10 years!) vibrant.
It's also small, offers a hardware keyboard, has decent battery life, and has the usual gimmicks expected from a smart phone: camera, GPS, GUI package manager, etc.
> The N900 keeps its appeal today because it's fully programmable.
While some of the userspace software has still been developed in the years since Nokia’s abandonment of the phone, the N900's kernel is stuck at an ancient version riddled with security issues, and also the SSL/TLS libraries are outdated. For some years I still used my N900 in airplane mode to listen to music because it had decent sound output on its headphone jack and ran MPD, but I would not recommend connecting an N900 to the internet in this day and age.
Just curious, but if you enjoy a Nokia N900, would you not consider the Cosmo Communicator or the Fxtec a good follow-up? It has modern hardware, still a good hardware keyboard. Together with the more updated Sailfish OS you get something much newer and faster.
I can imagine criticism about Jolla not having everything open sourced, but what I remember it was the same situation with Nokia for the N900 and N9. Also, in some respects the UI of Sailfish is somewhat different from Maemo/Meego, not everybody will like that.
Is the keyboard really good? I’ve tried one of Cosmo, Gemini, or Fxtec in person, can’t remember which, and utterly disappointed upon first touch. It looked like a proper laptop but keys tilted on roll and pitch axes like a TV remote. Good hardware keyboard seems to need a lot of iteration and investments to do so.
I've been using my Freerunner for over 10 years. I've tried it with a bunch of distros (including the first version of Android when that came out, which was nice but sluggish); I've generally stuck with QtMoko (although that was last updated in 2014).
The battery struggles to hold much charge any more, so I've been waiting for a replacement which isn't a "freedom downgrade". These newer offerings are exciting, but seem a little too beta for me to switch quite yet.
So, I like the accessibility of physical switches but how are they more trusting than software ones? Or light indicators such as Apple's green Dot?
Already trusting Open Source requires non technical people to trust others who can read the code to vouch for it. Here, we would need to expect an electronics engineer to understand (from looking at a disassembled device) that the switch actually does what it says it does, right?
And see exactly what the switches turn on and off. Heck, if you are really paranoid, you can inspect the PCB and the schematics of the individual chips to ensure it does what it does.
Physical switches typically are a lot harder to circumvent and a lot easier to verify than software ones.
> Here, we would need to expect an electronics engineer to understand (from looking at a disassembled device) that the switch actually does what it says it does, right?
Sure. This is a lot better than just trusting a manufacturer's word, since they have an incentive to hide vulnerabilities and independent researchers have an incentive to publish them.
Having designs available makes their work a whole lot easier and potentially lowers the barrier of entry so much someone with some interest and time could do the checks themselves. The more eyes, the better.
> Already trusting Open Source requires non technical people to trust others who can read the code to vouch for it
Maybe that's nitpicking, but I would rather say that trusting open source requires to trust the developer won't take the chance of adding malware if they know anybody could read their code. Although, granted, this does not shield from vulnerabilities created in good faith.
With software ones you still have to trust the hardware and firmware in addition to the software. With light indicators like Apple's you also need to trust the hardware - and since the designs aren't open it's more difficult to do so - but once verified that they work as advertised having kill switches is a much more active security function than an indicator light.
International standards can also be zero days. For example, the international standard for called ID, uses a dial up modem protocol which means the hardware has to have capabilities to read this data which means the hardware has dialup modem capabilities. So if you can compromise the firmware of the modem, a backdoor into a device is via the very telephone network you later rely on to communicate. https://en.wikipedia.org/wiki/Caller_ID#Operation
Chips fall into 3 categories, fused by manufacturer, fused by branding company, or not fused allowing future updates, like bios chips.
Even if the chip is fused, a backdoor may still exist, in some cases standard behaviour can be the backdoor.
I even think its possible to hack the communication systems of the new Lockheed Martin F35, because the manufacturers are walking a logical development path (their mistake), but I've yet to have a go at it, so cant say for sure yet.
https://www.youtube.com/watch?v=_C25CwNlVjA
Your comment is so in depth thanks. It really opened my eyes to some of the industrial subversion going on that I was unaware of, especially about the international standards being a vector for backdoors.
>>Already trusting Open Source requires non technical people to trust others who can read the code to vouch for it.
That is not the the benefit of OpenSource. With open Source you have MORE technical people looking at the code, finding things, and reporting things than you do with Closed Source
There is also less risk to researchers when reporting things to Open Source than to Closed Source Companies who often respond not with "thanks for the info" but with "I am Lawyer from X Bad software vendor, we are reporting you to law enforcement and reserve the right to sue you if you tell anyone about your finding"
Pine is using the Pinephone as a workbench to build open source, Purism is using open source as a workbench to build a phone. I'm not applying either of those negatively. In either case, I think one gets what they pay for and a delivery timeline to match.
I mean, I am holding one right now, and I am a customer (Well technically it's next to my laptop, typing with one hand is hard). So I don't understand what you mean.
With the Librem Phone, the extra money is also paying for the development of the software ecosystem. I would argue that's worth the investment.
For reference, a lot of the Pinephone distros are using the software developed by Purism. I am not saying that's bad, thats the whole spirit of open source!
Both PostmarketOS (if you use the phosh env) and Mobian use phosh, proc, chatty, libhandy, squeekboard, and a number of Purism packages. Mobian would take a lot more work (and likely would not exist) if they did not take advantage of Purism's work.
Feel free to go through https://puri.sm/posts/ to see their documentation of what they contribute, but here is one post I choose arbitrarily:
What are the killswitches acting on ? Are they acting only on the dedicated "enable" or "poweroff" inputs of various chips ? Are they cutting the power supply of the chips ? Are they cutting both the power and logic busses, thus isolating the target chips (at least electrically) ?
1 Modem | Pulls Q1501 gate up (FET killing modem power) | "On" enables 2G/3G/4G communication and GNSS hardware, "off" disables it.
2 WiFi / Bluetooth | Pulls up CHIP_EN | "On" enables WiFi and Bluetooth communication hardware, "off" disables it.
3 Microphone | Breaks microphone bias voltage from the SoC | "On" enables audio input from on-board microphones (not 3.5mm jack), "off" disables it.
4 Rear camera | Pulls up PWDN on OV5640 | "On" enables the rear camera, "off" disables it.
5 Front camera | Pulls up PWDN on GC2145 | "On" enables the front camera, "off" disables it.
6 Headphone | Pulls up IN2 on analog switch BCT4717ETB | "On" enables audio input and output via the 3.5mm audio jack, "off" switches the jack to hardware UART mode.
With the microphone bias floating, what prevents some digital signal processing form recovering faint and fuzzy audio? I'm sure the microphone loses at least several dB of gain with the bias floating, but isn't it much safer to either disconnect the bias and tie it to ground, or else pull up/down the the digital output of the ADC?
I understand that with the bias floating, the microphone output will be a combination of radio and quantum thermal noise, but won't that noise still be slightly modulated by the microphone? Or is it that the noise being modulated will be below detectable by the ADC and the digital output will always be exactly 0?
Depends on actual hardware implementation, but those microphones are REALLY good at picking up audio. I once fiddled with some microphone and wondered why it works so poorly (lots of "digital" noise, faint audio), maybe cable broke or smth. Turned ot, it was "disabled" with hardware switch on cable, yet still picked up enough sound to "somewhat work".
The Pine Microsystems becomes Pine Store Limited. Two reasons on such move:
1. Increasing complexity of business compliance and reporting paperwork when operates in California. Since Pine Store primary business is not in California, no interest to keep continue to have such burden.
2. Avoid legal mafia similar to what happens to Gnome on Q4 last year. Unfortunately, there are a lot of such legal mafias operate in State.
This move is not due to financial or politic reason. Pine Store Limited locates in Malaysia and Hong Kong.
-------------
Given the state of relations with HK and the US now this may makes things more complex for them as well
n January 2020, Pine Microsystems Inc. was dissolved[7] while Pine Store Limited was incorporated on December 5, 2019 in Hong Kong[8] and store.pine64.org claims to operate under the laws of Malaysia and China.
These are all behind the back cover, and are (from what I understand) pretty tiny, so I wouldn't imagine 'em to be all that convenient for toggling silent mode.
But yeah, my PinePhone's supposed to ship on the 25th and I expect I'll be missing that feature.
This is great functionality.
But on the other hand I already had Meizu MX4 Ubuntu based phone. Apart of bad network reception, main issue was lack of application support, literally I was struggling with simplest application. On positive note I could to development and bash very easy...
That’s cool, but hardware kill switches don’t help your privacy.
Why?
Because nobody is ever going to want to turn off that functionality. I don’t know anyone who turns off the software switches, why would they turn off hardware ones?
A smartphone without a camera, mic, Bluetooth, cellular data, and WiFi is basically useless.
What we need is a way to make these technologies more private while they’re in use.
Also, the PinePhone is barely usable, and I say that as an owner. It’s a neat toy but it’s got a long way to go.
If I could hard-off my mic, I would. I don't use it but once a day, maybe, while I use others frequently. I turn off location manually whenever I am not using an app that requires it. I leave bluetooth on because I use it frequently enough, but if it were an easy hardware switch, I could get in the habit of shutting it off.
> I turn off location manually whenever I am not using an app that requires it
Which is almost equivalent to teather from a security point of view. Either you trust the system, in which case you can trust that you can deny location to the programs that according to you "don't require it"; or you don't trust the system, in which case it will just broadcast the position whenever you enable the killswitch to everyone who could be even remotely interested. And again when you enable it is usually when you are most likely going to leak something interesting. There is here some usefulness in terms of having "another layer", but academically this is really debatable.
Switches are simple and predictable. Permission systems have shit UX, and are not granular enough anyway. Furthermore, suppose you need different things to be permitted at different times, e.g. you need the battery to last longer for a few days... good luck changing all your permissions manually.
Not to mention that whenever you finally enable the mic it is because you are probably going to say something interesting to it, which is exactly what whichever rootkit you're afraid of is going to be interested in. Not silence.
If you're this worried about leakage from signals, cameras, etc. what about the tradeoff of security where now you need to patch and monitor for any attacks on your device, now that you're off of any normal OEM's support?
What's the risk of that being done poorly by you, versus having better control over these physical switches?
What "normal OEM support" (like which company, for example?) has been good at regularly releasing security patches and keeping on top of various vulnerabilities? Especially past the 1-2 years after the release date of the device? Especially if you consider those companies that without any real consent from you install dozens of their own adware and spyware on each update that you can't even remove (like you can't remove system apps in android, only "disable" them, to make the phone nag you all the time to re-enable them).
Not having to rely on the joke of the "OEM support" from the big companies is the very reason to use these open phones.
Apple’s average full support for iPhone is trending to around 4-5 years since launch. Several times they’ve issued critical security updates years after ending official support.
For someone who needs to run Android apps (read everyone not bought into Apple's walled garden), that's as useful as a brick. Do they even have a browser other than Safari?
I would argue they are doing what I wish any normal OEM would do: upstream their patches to make it much easier to maintain. "normal OEM Support" for phones means you are stuck on whatever LTS kernel the OEM used, then good luck trying to upgrade past that.
For reference, I am typing this on a laptop from 2008. I am not worried about OEM support because all of the hardware support was upstreamed long ago.
Personally, I consider any code produced by Google to be hostile malware. Meanwhile, I'm quite competent with managing a Linux machine. For me personally, the choice is easy.
The current crop of Freedom Phones are targeted at people like myself who can break things and fix them ourselves. My hope is, in the future, you will be able to install vanilla Debian for example on your phone, which I think even the more paranoid of us would consider safe.
Too bad the battery "kill switch" seems to be turned on permanently. I don't blame them - it's a hard problem to solve. Todays higher end phones go as far as to turn off parts of the chips on the fly, dynamically, on demand. But until it is solved, the device is more or less a curiosity rather than something useful in practice.
