LWN: Comments on "PureOS: freedom, privacy, and security"

PureOS: freedom, privacy, and security

marcH — Mon, 11 Jan 2021 10:18:07 +0000

> Hmmm ... yes. But how usual is that?

The original question is how do the various "no binary blob" policies handle real-world hence complex cases like this (not just this one). The naive ones may backfire.

(on Signal)

debacle — Mon, 11 Jan 2021 08:41:50 +0000

> I do think that your assumptions, inaccuracies, narrow perspectives and other misrepresentations

Feel free to correct me.

> Apologies for assuming you were trolling.

Accepted.

PS: This works for me: I try to not get angry, if people have dissenting opinions from my own, even if I'm sure, that they are misinformed. If I have time and energy for a discussion, I try to correct them, or learn, that they are correct. In most cases, there is no "correct", just different points of view and different priorities. I try to not become personal and refrain from any statements, that make too many assumptions about the person I'm talking to or their background and behaviour.

PureOS: freedom, privacy, and security

pabs — Mon, 11 Jan 2021 02:37:54 +0000

CPU microcode does that. Also things like WiFi and GSM firmware often have a lot of the code in ROM and then updates go into RAM and there is not enough RAM to be able to replace all of the ROM code.

(on Signal)

marcH — Mon, 11 Jan 2021 01:26:15 +0000

Don't thank me because to be very clear I do think that your assumptions, inaccuracies, narrow perspectives and other misrepresentations are indeed "reproachable"; even when not intentional.

Apologies for assuming you were trolling.

PureOS: freedom, privacy, and security

Wol — Mon, 11 Jan 2021 01:24:54 +0000

Yeah.

But to go back to the post that started this, it sounded like the ROM was supposed to be upgradeable ... which is not practical/possible.

Using the ROM to simply pull in the real code - can that code be modified by the user (which Respects Your Freedom), or is it code that is signed or otherwise unmodifiable by the user, in which case it doesn't Respect Your Freedom.

Cheers,
Wol

(on Signal)

debacle — Sun, 10 Jan 2021 22:29:13 +0000

No need to be aggressive or reproachful. Thank you.

Of course, they are free to spend their money as they like, but "very limited time and resources" is just not as realistic as "prioritizing only Android and iOS". Sure, they have their reasons for that, but as I'm myself not an Android (nor iOS) user, I can't use (or recommend) their software.

PureOS: freedom, privacy, and security

farnz — Sun, 10 Jan 2021 22:07:41 +0000

Note that in your example, the processor has a ROM embedded in it, whose job is to bring up external buses it needs to access the motherboard EEPROM (or Flash) and then load code from there. This is a ROM that RYF is fine with - it can't be changed after leaving the factory, because it is literally part of the processor's hard wiring, used to access the second-stage firmware from external memory.

This is very common in modern CPUs; now that memories tend to be complex protocols, not simple asynchronous busses like the ROM and DRAM of the 1980s, you need some form of programmable logic to bring up and sequence the bus in the right ways to get code to transfer across into the processor caches, and you might as well implement that logic as code for the processor that can be built into the CPU in a small and simple ROM.

PureOS: freedom, privacy, and security

mpr22 — Sun, 10 Jan 2021 21:01:12 +0000

The Amiga 1000's original boot ROM, as released in the hardware sold to the general public, had one job: load Kickstart.

Loading Workbench (or booter applications) was Kickstart's job.

PureOS: freedom, privacy, and security

Wol — Sun, 10 Jan 2021 20:50:57 +0000

Hmmm ... yes.

But how usual is that? Take a motherboard - the BIOS is usually in EEPROM, not ROM. Modern mobos often have a dual bios and the first one *could* be ROM ...

Or a video card - a ROM who's purpose it is to load the blob?

You're right, but I don't think it's *economically* feasible ... manufacturers wouldn't do it except in prototypes.

Cheers,
Wol

(on Signal)

marcH — Sun, 10 Jan 2021 20:20:44 +0000

> With their many millions of USD, Signal has "very limited time and resources"? I'm surprised.

This comment makes Signal looks like a rich, for-profit corporation. Either you're spending more time writing these comments than researching the corresponding information, or you're trolling.

Making money from the small and yet heavily fragmented "Linux Desktop" is very difficult and you must know at least that. So you're most likely trolling.

PureOS: freedom, privacy, and security

marcH — Sun, 10 Jan 2021 20:03:39 +0000

> > Having a ROM chip and not being upgradable are two different things. In fact it's common to require both because booting needs to start somewhere.

> And are mutually incompatible, unless the ROM is actually user-replaceable or an EPROM. The whole point of a ROM is it cannot be (re)written. It's like an old-fashioned write-once CD

You're missing the point. Code in the ROM can check for later version and run that instead of itself.

(on Signal)

debacle — Sun, 10 Jan 2021 19:58:23 +0000

That is good news, indeed, not only in the context of Signal. Thanks for the pointer!

(on Signal)

alex19EP — Sun, 10 Jan 2021 18:24:07 +0000

Btw., the issue reminds us, that Electron applications are not usable by visually impaired users: https://github.com/signalapp/Signal-Desktop/issues/2178#i...

this is no longer the case. https://wiki.gnome.org/Projects/Orca/Chromium https://bugs.chromium.org/p/chromium/issues/detail?id=24585

(on Signal)

debacle — Sun, 10 Jan 2021 11:35:11 +0000

> In case you haven't noticed, Signal is mainly aimed at smartphones.

I have noticed :-) However, because I don't have a smartphone, I can't use Signal. And wouldn't be rudo to recommend it to others with the remark "by the way, you can't reach me with the chat app I forced upon you, send email instead"?

> No, unless you have very limited time and resources

With their many millions of USD, Signal has "very limited time and resources"? I'm surprised.

Btw., the issue reminds us, that Electron applications are not usable by visually impaired users: https://github.com/signalapp/Signal-Desktop/issues/2178#i...

> After searching for 2 more minutes I found mention of some command line clients

I'm aware of such clients, but I'm not aware of anyone actually using them. Nor are they packaged in Debian or other Linux distributions. I assume, that they are not yet ready for consumption? Also, if I remember correctly, the Signal project was not very open for 3rd party clients ("LibreSignal"?), and I'm not sure, whether there is something like a stable protocol description.

> Considering what appears to be your profile I can't resist the infamous "Send patches".

I'm probably not as good a programmer as the Signal folks and they would reject my patches rightfully. And they have far more budget than I have.

> Maybe encrypted RCS

I migrated to CVS recently :-) But, yes, that might well be...

> What better messaging app do you use on your phone to communicate with non-technical friends and relatives?

Not "better", but "good enough" (YMMV, etc.): Some relatives and friends use quicksy.im, a Conversations (Android Jabber client) fork, that uses phone numbers as id, like Signal. Or they use Conversations. Others use SiskinIM or Monal (iOS Jabber clients). All are compatible to my XMPP client on Linux.

Some contacts don't have smartphones, but good ol' brick phones, therefore I maintain a personal gateway between SMS and XMPP in my storeroom. With that I can receive and send SMS without having to own a mobile phone.

Of course, those programs are all developed either by hobbyists in their spare time or by freelancers or very small teams without much funding. Technically, they cannot compare to a multi-million dollar project such as Signal.

Alternatively, I would look into DeltaChat (based on email) or Matrix (based on HTTP), or maybe something completely distributed such as Briar or Jami...

PureOS: freedom, privacy, and security

Wol — Sun, 10 Jan 2021 09:36:12 +0000

> > > Take exactly the same blob and stick it on a ROM chip - so it cannot be upgraded or replaced by a free alternative? That hardware now does Respect Your Freedom™.

> Having a ROM chip and not being upgradable are two different things. In fact it's common to require both because booting needs to start somewhere.

And are mutually incompatible, unless the ROM is actually user-replaceable or an EPROM. The whole point of a ROM is it cannot be (re)written. It's like an old-fashioned write-once CD ...

> > The RYF approach seems to be that as long as the user has the same ability to update as the vendor, that is OK.

> Could you elaborate? I don't get this sorry.

The vendor should not retain powers that the user does not have. If BOTH the vendor and user can update the device, that's okay. If NEITHER the vendor NOR the user can update the device, that's fine.

But if the vendor CAN update the device, and the user CANNOT update the device, then it's clearly not the user's device ...

Cheers,
Wol

PureOS: freedom, privacy, and security

marcH — Sun, 10 Jan 2021 02:13:00 +0000

> > I can see how they got there: without an exception for binary blobs on secondary processors there is no hardware that could get a RYF certification.

Very good point, thanks. Like it or not there are now dozens of "secondary" processors and micro-controllers in every computer and smartphone, all requiring some firmware which is almost never open source. Most pages ranting about "binary blobs" seem surprisingly naive about that.

BTW binary blobs do not automatically make all efforts on the main processor useless, the attack surface matters.

> > Take exactly the same blob and stick it on a ROM chip - so it cannot be upgraded or replaced by a free alternative? That hardware now does Respect Your Freedom™.

Having a ROM chip and not being upgradable are two different things. In fact it's common to require both because booting needs to start somewhere.

> The RYF approach seems to be that as long as the user has the same ability to update as the vendor, that is OK.

Could you elaborate? I don't get this sorry.

> I prefer Raptor's approach where they look at which side of the IOMMU the hardware is on.

Very interesting, thanks. As a coincidence: https://lwn.net/Articles/841916/ "Restricted DMA"

(on Signal)

marcH — Sun, 10 Jan 2021 01:54:21 +0000

> First: The installation on my OS (Debian)...

In case you haven't noticed, Signal is mainly aimed at smartphones. Of course these are neither iOS nor Android are free nor open-source but they're the most popular and as far as messaging is concerned popularity obviously matters a lot. We can also be reasonably confident that these operating systems do not systematically spy the apps running on them; this would most likely have been noticed already.

"The perfect is the enemy of the good" and it is already today extremely easy to switch to Signal for anyone using WhatsApp or similar - except of course for convincing your friends that their privacy matters.

I haven't checked but I bet Signal runs on https://e.foundation/.

> but I had to download a huge file, euphemistically called "Electron". Having a complete web browser bundled in an executable... Is this a good idea?

No, unless you have very limited time and resources as explained at https://github.com/signalapp/Signal-Desktop/issues/2178 (2018)

After searching for 2 more minutes I found mention of some command line clients: https://github.com/AsamK/signal-cli/wiki (did not try any)

> The installation process asked for my phone number, which I was not willing to enter, which was the end of the game.

It's unfortunate that most messaging apps rely on a phone number as an ID but again phone numbers seem most popular than email addresses nowadays and Signal is at least (slowly) working on supporting other IDs. Considering what appears to be your profile I can't resist the infamous "Send patches".

> I also want to decide, where my chat is hosted

AFAIK Signal servers are only acting as a phonebook, something which is not impossible but notoriously difficult to fully decentralize, especially using power conscious smartphones. You can backup your _encrypted_ communications on Signal servers but it's not required.

I agree this seems to be a single point of failure though, now I'm curious whether this could be distributed across several providers and countries in the future.

Maybe encrypted RCS could bring us a more decentralized and secure messaging solution eventually? Dunno how closed are the specs and implementations.

What better messaging app do you use on your phone to communicate with non-technical friends and relatives?

(on Signal)

debacle — Sun, 10 Jan 2021 00:16:53 +0000

> I am a bit more optimistic on Signal.

I'm pretty pessimistic about Signal, but I only tried it once, long time ago, without success.

First: The installation on my OS (Debian) was not an easy "apt install signal", but I had to download a huge file, euphemistically called "Electron". Having a complete web browser bundled in an executable... Is this a good idea? Worse, it didn't even work, because at least at that time, an Android phone was required, which I don't have.

Second: The installation process asked for my phone number, which I was not willing to enter, which was the end of the game. Note, that in my country, it is difficult to get free and/or anonymous phone numbers, so I need to be careful with my only phone number I have, my landline. Anonymous SIMs are outlawed here.

Third: I do not feel comfortable with the Signal server in the AWS. I decide, where my email account is hosted, I decide where my web applications are hosted, I also want to decide, where my chat is hosted. Chatting is important nowadays, its power should not be concentrated in only one country, at only one cloud provider.

PureOS: freedom, privacy, and security

Jandar — Thu, 07 Jan 2021 20:57:34 +0000

>> your disk drives can't steal information from you nor get you to execute desired malware

>If it injects a malware on the fly in a binary it returns, then it can definitely get you to execute malware

The first quote was dependent upon "if you use software disk encryption". I you use encryption one can only inject random garbage.

PureOS: freedom, privacy, and security

cpitrat — Thu, 07 Jan 2021 20:19:24 +0000

> your disk drives can't steal information from you nor get you to execute desired malware

If it injects a malware on the fly in a binary it returns, then it can definitely get you to execute malware

PureOS: freedom, privacy, and security

brunowolff — Thu, 07 Jan 2021 15:13:01 +0000

The RYF approach seems to be that as long as the user has the same ability to update as the vendor, that is OK. I prefer Raptor's approach where they look at which side of the IOMMU the hardware is on. You can generally set things up so that devices with binary blobs can only do DOS attacks against you except for network chips that can directly communicate to others if the IOMMU restricts their access to memory. For example if you use software disk encryption, your disk drives can't steal information from you nor get you to execute desired malware. It can just break things by lying about storing data or returning effectively random garbage. They are encouraging work to replace to replace the firmware for bcm5719s to reduce the ease at which the network chip they use, can be used against you. A couple of people have done a lot of work to get the replacement firmware working, though it isn't considered ready for production yet.

PureOS: freedom, privacy, and security

raof — Thu, 07 Jan 2021 05:40:27 +0000

Naturally, it does not need any binary blobs for its functionality either.

My understanding is that this is not true. It has binary blobs (for a number of components), they're just not easily user-replaceable, to comply with the RYF certification.

My feeling of RYF certification is that it's a compromise between pragmatism and purity, but that it's unfortunately ended up in a being a ridiculous label that actively impedes free hardware.

I can see how they got there: without an exception for binary blobs on secondary processors there is no hardware that could get a RYF certification. But the compromise they've chosen - that binary blobs on secondary processors are OK, as long as software installation is not intended after the user obtains the product is a bad compromise. This results in the perverse outcome that, in order to achieve RYF certification, a manufacturer must make it more difficult to replace any binary blobs with reverse-engineered free alternatives. Have a non-free blob that's loaded at runtime (and so could be easily replaced, should a free alternative become available)? That doesn't Respect Your Freedom™. Take exactly the same blob and stick it on a ROM chip - so it cannot be upgraded or replaced by a free alternative? That hardware now does Respect Your Freedom™.

(on Signal)

Herve5 — Tue, 05 Jan 2021 12:28:41 +0000

> Every time I recommend trying Signal and Firefox, explaining what differences they make and
> insisting on how they can be used next to their alternatives, how a quick try does not even
> require abandoning or converting anything. (...)

I am a bit more optimistic on Signal. My wife being a worker's elected admin in a very large company (150000 people, 15 countries), it was obvious to us from the start that her emails, SMS, phone calls, would automatically be tracked. So we switched to Signal with a good reason if unfrequent.

But actually our recent experience has been surprising, as more and more of our friends and correspondents do suddenly appear on Signal (even though we are less active than you!)
OK, that's still a minority, but not a rounding error anymore ;-)

Now, I share everyone's concern here : I'll dare saying I find Signal weak when compared to Jami, which doesn't require a central server (save the first connection). Signal allows 'spies' to know who you are talking to. Jami doesn't...
And then indeed Jami, not even mentioned here, is definitely confidential :-D

PureOS: freedom, privacy, and security

marcH — Mon, 04 Jan 2021 21:37:19 +0000

> There is no shortage of press articles and documentaries explaining the very sorry state of privacy. These prompt regular conversations with non-technical but educated friends and relatives.

Just had another such discussion. Eventually I got the famous: "I'm not too concerned because I don't think I have much to hide".

The End.

PureOS: freedom, privacy, and security

marcH — Mon, 04 Jan 2021 04:44:47 +0000

> Nowadays the top issue is the lack of demand.

You can tell when the only hope for privacy comes from... the most secretive tech company:

ttps://www.forbes.com/sites/zakdoffman/2021/01/03/whatsapp-beaten-by-apples-new-imessage-update-for-iphone-users

PureOS: freedom, privacy, and security

pebolle — Sun, 03 Jan 2021 20:33:34 +0000

> Most of them can afford advisers that make sure their schemes are legal.

Of course, this should be: "All of them can afford advisers that make sure their schemes are legal."

PureOS: freedom, privacy, and security

pebolle — Sun, 03 Jan 2021 20:06:48 +0000

> People pretend to be horrified but they really don't care about privacy,

About everything we do with current technology (mobile phones, smart appliances, browsing the web, e-payment, email, whatever) leaks a vast amount of information. The number of people worried about this seem to be a rounding error. Let's face it: the universe where one uses a mobile phone, watches Netflix, uses Spotify, logs in to Facebook, seldom uses cash, etc. is filled with happy citizens.

> at least not before some sex tape

Perhaps in a few years the common reaction will be: "That's me having fun. So what?"

> or offshore account of theirs actually ends up online.

Which is only relevant for the extremely rich people or multinational corporations dumb enough to do illegal stuff. Most of them can afford advisers that make sure their schemes are legal.

PureOS: freedom, privacy, and security

marcH — Sun, 03 Jan 2021 09:27:26 +0000

> In order for that to go anywhere, though, people are going to have to start changing their thinking and prioritize freedom, privacy, and security over convenience and price. In truth, that all seems rather unlikely, sadly.

There is no shortage of press articles and documentaries explaining the very sorry state of privacy. These prompt regular conversations with non-technical but educated friends and relatives. Every time I recommend trying Signal and Firefox, explaining what differences they make and insisting on how they can be used next to their alternatives, how a quick try does not even require abandoning or converting anything.

My impact has been close to zero. People pretend to be horrified but they really don't care about privacy, at least not before some sex tape or offshore account of theirs actually ends up online.

Decades ago, "religious" objections in many companies were seriously affecting free software "supply". Nowadays the top issue is the lack of demand.