Linux PinePhone has physical kill switches for its cameras, mic, data, BT, Wi-Fi
androidpolice.com
androidpolice.com
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
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
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)
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.
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).
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.
Many people like Mobian. It has a very nice UI (Purism's Phosh) and the full GNU/Linux under the hood.
I personally would recommend to try Sxmo: https://forum.pine64.org/showthread.php?tid=9913. It is unbelievably fast, capable and has a cool geeky UI.
> 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.
It reminds me of working with text-based user interface in the terminal, with intuitive window manager. I love it!
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.
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.
Unless that's not what motivates them. Maybe they want to get them into as many hands as possible to bootstrap a working phone.
They can always raise the price when the software becomes more usable.
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.
And no, it's not (yet) illegal (but might be against some ToS) in many countries to change your IMEI including the US (see https://en.wikipedia.org/wiki/International_Mobile_Equipment...).
https://xnux.eu/devices/feature/modem-pp.html
https://xnux.eu/devices/feature/modem-pp-reveng.html
They were able to get root access within the modem. Depending on how the IMEI value is stored, it may actually be feasible here.
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.
Be fucking careful when you are traveling with a phone that has an IMEI in the software that does not match the one on the sticker.
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?
Regarding your UK example, the law in question (https://www.legislation.gov.uk/ukpga/2002/31/section/1) mentions circumstances and gives exceptions:
" 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 ...
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.
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.
Not exactly the same, but in Librem 5 you can at least replace the whole modem.
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.
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.
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.
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.
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 :)
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.
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.
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?
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.
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.
There's still some gains to be made here, so this may still improve.
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.
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.
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.
Why is that? Was it too young or is it generally impractical on a phone?
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.
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.
The only thing stopping me from using it as a daily driver is MMS:
https://sr.ht/~anteater/mms-stack/
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.
I have been doing some work with MMS on it recently: https://gitlab.freedesktop.org/mobile-broadband/ModemManager...
I don't think it's a far off as a lot of folks thought.
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.
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.
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.
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.
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?
https://wiki.pine64.org/index.php?title=PinePhone_v1.2
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.
The datasheets for the individual chips are here:
https://wiki.pine64.org/index.php/PinePhone
EDIT: This has it too: https://wiki.pine64.org/index.php/PinePhone_FAQ#What_are_the...
> 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.
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.
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.
With zero days appearing in hardware, software and standards, its very easy if you have the knowledge to get a persistent backdoor into a device beit a PinePhone, Librem 5 or Necunos to name just a couple. https://forums.puri.sm/t/comparing-specs-of-upcoming-linux-p... https://tuxphones.com/yet-another-librem-5-and-pinephone-lin... Its probably why people like Cobham, Thales and other openly public military manufacturers make their own kits for militaries around the world. https://www.cobham.com/ https://www.thalesgroup.com/en
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
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"
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!
Other than PureOS what other "pinephone distros" are using Purism Software? On top of that, how much of "Purism Software" is upstream linux?
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:
https://puri.sm/posts/librem-5-may-2020-software-development... Note the "Linux Kernel" section.
Here's another one: https://puri.sm/posts/librem-5-june-2020-software-developmen... Also note the "Linux Kernel" section.
https://amosbbatto.wordpress.com/2020/08/05/advantages-of-ph...
The list of those distros is in the link.
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.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?
PS: I love both companies, it's just sad about Purism :)
Anyone know if they just closed their US entity and now operate from another country or are they having financial difficulties?
[1] https://businesssearch.sos.ca.gov/Document/RetrievePDF?Id=03...
------
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
https://en.wikipedia.org/wiki/Pine64
So just an entity move to a more favourable country.
But yeah, my PinePhone's supposed to ship on the 25th and I expect I'll be missing that feature.
AFAICT, the LTE switch disables GPS.
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.
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.
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.
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.