> Maybe, but the X60 is in China behind a closed border, and I am in
Aotearoa.
Damn, that sucks.
> How does Goggle get any info from an Android device that has never had a
Goggle account associated with it?
The OS.
> Yes, but the difference is that to use my SIM in the PP, I have to have its
cell modem turned on. If I don't, I can leave it turned off, and that's one
less piece of proprietary code in use on the device. The one bit that is
protected by law from being reverse engineered and run with free code.
Why did you buy the Pinephone then? The point of it is to be a phone. It
sounds like you should have bought a laptop. For $300 you could have a *way*
better computer than you'll get by plugging your PP into peripherals. And if
you're just using an Android device's modem instead of the Pinephone's modem
you are no more private or free, probably less so.
> It doesn't appear so, and since I have no experience with replacing the OS
on an Android device, I've been unwilling to risk a hack that *might* work
(and might brick the device). Once I have the PP, I expect I'll have two
Android devices I no longer depend on (I can put my NZ SIM in my Chinese Oppo
with my Chinese SIM if I have to), so I might try some experiments.
Don't let Technoethical's prices fool you. Installing a custom ROM on an
Android phone is very easy. You do need a compatible device though. Don't
try installing an incompatible ROM.
> I've heard this claim a few times. I've never seen any reason to believe
it. ELI5
Linux and much of GNU are C. C is not a memory-safe programming language,
which means that things[1] can happen with memory that are not supposed to.
For example, a program might use a chunk of memory and then stop using it,
but those bytes are still there, and then a malicious program might access
that same chunk of memory and use those bytes to do things.
Ideally programs would not be able to access each other's resources so that
this would not happen, but Linux gives every process it runs the same
permissions as the user that asks it to start the process, with no sandboxing
in between them. This is why running things as root is very dangerous, but
even running things as normal user is somewhat dangerous.
For servers, this can be addressed by creating per-application users, where
each user only has permission to run its application. Security-critical
server applications are often packaged this way. Even on a desktop system,
if you look at "/etc/passwd" to see a list of users on your system, you will
probably see a bunch of usernames that are not yours and that you didn't
create. These are being used to run different processes in isolation.
However, users typically run desktop applications as themselves, so each
application has permission to do anything that the user has permission to do.
This is not secure, although since there are not very many people using
GNU/Linux as a desktop system it is not a very popular target to attack
(unlike GNU/Linux servers, which are very common and very popular to attack,
hence isolation between processes being taken more seriously for server
applications).
Android uses the same kernel as GNU/Linux, but is also used by many people
and is popular to attack, and it has something called an "app store", which
is kind of like a distro's repository, if your distro were a terrible
cesspool of proprietary malware, so it implements isolation of applications
be design. You know how you can go into Android's settings and give
different applications permission to do certain things, like access certain
files and or your camera or microphone? Have you ever wondered why Trisquel
doesn't have something like that in its settings? It's because all
applications run with the same permissions as the user that runs them, so
they only way to prevent them from accessing something is to remove your own
access (keep those files on another medium, put tape over your camera, etc).
There are some works in progress to implement sandboxing for desktop
GNU/Linux. Flatpak and Snap have some basic sandboxing. Whonix appears to
be working on something[2] that will make it easy to run desktop applications
as separate users the way server applications often are. Guix has a very
cool containers feature. But there isn't yet a user-friendly, secure, and
adopted sandboxing mechanism for GNU/Linux like there is for Android.
Does that mean the Pinephone is bad? No, it is what it purports to be: an
inexpensive, hackable phone capable of running GNU/Linux with the minimal
amount of proprietary crap needed to have a decent smartphone (the modem,
since modems have to be non-free, and WiFi, since the WiFi cards with free
firmware would quickly drain a phone's battery). Unlike Purism, Pine64 has
not claimed to be security-focused. Hopefully by the time mobile or desktop
GNU/Linux acheives enough adoption to become a popular target to attack,
sandboxing support will have improved. But if you yourself are a trying to
protect against a sophisticated attacker, you probably want to go with
GrapheneOS for mobile and something like Tails or Whonix for desktop. It all
comes down to your threat model.
> I was initially excited by this, but it seems that with the initial models
you have to take the back off the device to get at these switches, which
makes them almost useless.
Yeah, that was my biggest disappointment with the PinePhone. I wouldn't say
it's *useless*. The back comes off pretty easily, so say you needed to go do
something important didn't want to be tracked you could take 20 seconds to
disable the modem, but it would probably be too inconvenient to switch it on
and off frequently.
> I'm hanging out for future versions in which cameras will have a lense
cover that users can manually slide clear
That would be nice. I wonder how hard it would be to modify the back cover
that way.
[1] https://en.wikipedia.org/wiki/Memory_safety#Types_of_memory_errors
[2] https://github.com/madaidan/sandbox-app-launcher
