LJ Archive

Letters

Kyle Rankin's RV TV and Disc Encryption

To Kyle Rankin: great article on your RVTV setup in the June issue! Encrypting the hard drive sounds like a good idea to protect against the real chance of burglary, but I somehow missed the decrypting part. It seems like you're setting up a keyfile (on the Raspberry Pi's SD card I guess) for that, but isn't that just hiding the key under the doormat, revealing the drive's content to a committed thief stealing the entire system?

—Mike Schilli

Kyle Rankin replies: Great question, and I'm glad you caught the risk with using a key file!

Yes, using a keyfile is not my standard practice—I prefer requiring a passphrase at boot—but in this case, I wasn't going to sit (or worse, make my family sit) in front of a keyboard to type in a passphrase each time we turned on the TV. I needed to balance security with how this system was intended to be used and who was going to use it.

My threat model in this case is more car thief than hacker or spy. With that in mind, I figured this was a fair compromise so that the media center is available for my family to use just by turning it on, but if someone takes the standalone hard drive and tries to plug it in to a computer, all of the files aren't immediately available. In that case, the thief is more likely just to format the drive. What's even more likely though is that because the hard drive is hidden away in a cabinet to keep it out of the way, the thief would unmount the TV, unplug all the wires, and take that. Or just take the whole RV—it is pretty sweet after all.

What the GDPR Will Do and What It Won't Do

Glyn Moody's article about the GDPR has a small but significant error when it says that ChromeOS is a free operating system. In fact, it is proprietary, and it contains known malicious functionalities (see "Google's Software Is Malware"). Users can't correct them because the code is nonfree.

That detail doesn't affect the overall point of the article. However, it is necessary to distinguish two different ways a service can mistreat users:

Both of these issues are important, but they are completely different.

A service can misuse users' data if it has their data. That problem is easy to understand. I don't give websites data about me—normally not even my name or email address. If they require an account, I usually don't use them, with the exception of posting comments on articles.

The other problem requires some thought to recognize at all. It is the problem of SaaSS (Service as a Software Substitute): if someone else's server does a computing job for you, you don't control how it does that job, or what job it does. It follows that entrusting your computing job to someone else's server is roughly equivalent to running a nonfree program. For your freedom, you should reject both. For more explanation, see "Who does that server really serve?".

The EU's GDPR tries to reduce the misuse of people's data. I think it does some good, but not enough to make people in the EU safe from misuse. See "A radical proposal to keep your personal data safe".

In particular, when governments (such as the US or France) seize databases of commercial surveillance data, the GDPR does not apply to the governments' copies. It does no good about this danger except in those cases (and I suppose there are some) when it convinces companies not to collect certain data. But the limit it places on data collection is not very strict, so it isn't likely to do that often.

However, the GDPR makes no effort to tackle the problem of SaaSS. That was not one of its goals.

—Dr Richard Stallman

Glyn Moody replies: Richard Stallman writes: "when governments (such as the US or France) seize databases of commercial surveillance data, the GDPR does not apply to the governments' copies."

It is true that the GDPR offers no protection against the French government seizing databases, because that is not its job. It is designed to regulate how businesses and organizations handle personal data in the course of everyday transactions—not to limit government actions.

However, an earlier Data Protection Directive does provide some protection against any government outside the EU, including the US. The personal data of EU citizens can only flow outside the EU to countries deemed to offer an "adequate level of data protection".

The US has already lost its adequacy status once after a ruling by the EU's highest court against the "Safe Harbour" framework that covered transatlantic data transfers.

Adequacy was regained with the replacement scheme, "Privacy Shield". However, that, too, is being challenged in the EU courts, and may also be struck down.

Seizures of databases containing EU citizens' personal data would make it much more likely that adequacy was withdrawn again. EU personal data cannot be legally transferred to any country without adequacy, and so this threat provides something of a deterrent to this kind of action, at least to rational governments.

In Response to the Letter from Gnat in the June 2018 Issue

I was reading the Letter to the Editor from Gnat in the June issue regarding Doc Searls' "How Wizards and Muggles Break Free from the Matrix", and I just so happened to have recently read (and bookmarked) a reddit megathread on breaking away from Google: "Can we get a megathread on breaking away from Google?.

—Doyle Young

I Like Your Daily News Briefs

That's it. They're short and clear, with good links if I want to know more, and cover spaces of the Linux ecosystem I usually don't follow that closely. So, great job.

—Ronan

That's great to hear!

LJ readers, in case you haven't seen them, we post News Briefs each weekday on LinuxJournal.com.—Ed.

From Social Media

In response to the Linux Journal news story:

Court orders Open Source Security, Inc, and Bradley Spengler to pay $259,900.50 to Bruce Perens' attorneys. See Bruce Perens' blog post for more details on the lawsuit against him, which sought $3 million "because they disagreed with my blog posts and Slashdot comments which expressed my opinions that their policies regarding distribution of their Grsecurity product could violate the GPL and lead to liability for breach of contract and copyright infringement."

Taran Rampersad @knowprose: At what point do we consider these lawsuits to be what they really are - attempts at being a #cyberbully

After attending Texas LinuxFest

Texas LinuxFest @texaslinuxfest: And it's a wrap! #TXLF 2018 is now over. Thank you to all our sponsors for their support of this year's event. @linuxacademyCOM @cpanel @linode @kernelcare @redhat @linuxjournal @lwnnet @nostarch

In response to the news that Microsoft's GitHub acquisition is celebrated by the Linux Foundation

Freyr Olafsson @gnarlin2: Replying to @linuxjournal I'm sure that Microsoft's 500.000 dollars for their platinum membership every month has absolutely nothing to do with it.

Simon Gramstrup: It's hard to boycott GitHub if projects stay, but if more knew of similar projects from open sites, these projects (and sites) would get a little more exposure and grow.

Does anyone know of an "open source project" search engine, that searches all the smaller alternatives? I looked at Searx (from GitHub: https://github.com/asciimoo/searx). They have a nice pluggable architecture, but only cover GitLab from Linux Journal's compilation (and I don't know how to make my own).

Alexander Dinesen: Having Microsoft in charge of GitHub is like having Jimmy Saville in charge of Save the Children.

In response to @linuxjournal Little known fact: Phil Hughes & Bob Young co-founded Linux Journal. Bob went on to start a little company you may know as... @RedHat. @texaslinuxfest

Bob Young: Replying to @linuxjournal @RedHat @texaslinuxfest

Without the experience of working with Phil on @linuxjournal not sure any of the rest of the adventure would have happened.

LJ BANNER

Send LJ a Letter

We'd love to hear your feedback on the magazine and specific articles. Please write us here or send email to ljeditor@linuxjournal.com.

Photos

Send your Linux-related photos to ljeditor@linuxjournal.com, and we'll publish the best ones here.

LJ Archive