Hacker News Reader

Comment by squarefoot | Hacker News Reader

Slightly off topic but related to the product: how can a device using Android be considered safe and trustworthy privacy wise? The maker can surely choose FOSS only Android and encrypt communications, but the moment they add a binary only device driver it can do whatever it wants since it runs with kernel privileges (ie, sniff virtual keyboard, listen to conversations, access messages, contacts, photos, documents etc). If I'm not mistaken (please correct me in case I am) there's still no phone out there with open device drivers, which IMO translates into giving only a false sense of security to the user. Moreover, if I buy a security oriented device and it has a remote kill switch, I would expect at least to be the one and only entity in control of it.

View on HN

Safe and trustworthy aren't binary values. They're probabilities that the system won't release private information to undesired actors. To calculate those, you have to do your own risk assessment. Remember that a risk assessment for privacy has to put the value of the privacy against the cost of security -- on your side. On the attacker's side, it's the value of whatever they can learn about you vs their costs in getting past whatever defenses you have. Generally that results in going one of two ways: you trust a 3rd party vendor for some of it, or you build the damn thing yourself from small parts. And unless you've got a silicon fab at home, or are buying a shitload of transistors off of digikey, you're going to be trusting some 3rd parties.

In my book, a remote kill switch is OK if you can also trigger it. For privacy, DOS is pretty harmless -- you don't lose privacy, you just lose access to some data/service. If, in exchange of a risk of DOS, I can get better privacy some other way, I'll take it. As for SC fighting counterfeiters, I don't blame them. They're not making much $$ these days, and this is a way to keep alive without hurting their actual customers.

You're right in that a binary blob may just contain a backdoor and analyzing it is very hard.

There is Replicant ( http://www.replicant.us/ ), a version of Android that aims to get rid of all binary blobs. There is also CopperheadOS ( https://copperhead.co/android/ ).

Replicant got rid of all the binary blobs (for the main OS, that is), is not just aiming. The effects are of course that you can't use wifi, unless you're using a USB dongle. Not only that, but Replicant is only ported to devices where the GSM chip can be securely turned off (in other words, it's a separate chip, under the control of the main proccesor); Also, the GSM and GPS chips should be separate. The baseband OS if ofcourse still proprietary, but it can be considered an acceptable tradeof, given that it's only connected to the main processor via a USB-like connection (HSIC).

Shameless plug: we sell preinstalled Replicant phones at https://tehnoetic.com/

Having a FOSS phone would only be considered trustworthy if it had been reviewed by an entity you trust. I'm not aware of any mainstream OS that has been fully reviewed for security, so realistically the concept of a "trustworthy" device in that sense doesn't exist.

Even if such an audit was done perfectly (a very serious and difficult undertaking), it would be a point in time assessment, so would become less relevant as new code was committed.

Basically you have to trust some group of people to run a modern computing device/environment, it's just a question of who and how much...

Proprietary software starts off with a high level of trust - trusting just one company. But it can never progress past this.

The advantage of FOSS is that the set of who can audit the code is open. It starts small, but grows with popularity and remains agile - eg doesn't necessitate transitively trusting whatever nation-states a single company is vulnerable to.

Unfortunately can audit and do audit are very different things. I'd agree absolutely FOSS has a higher possible level of trust than a proprietary solution, however in practice I don't think it's necessarily the case.

To take one example with a propietary solution with code from a single company, it is possible for a level of background checking to be done on all contributors. With a FOSS solution, that's just not possible, so you get risks like what if one of the contributors is being paid by a nation state who would like to place a specific bug/vulnerability into a codebase.

Of course in practice the world is much muddier than that as pretty much all propietary software vendors make ample use of code they did not write, and in many cases on open source code that they don't really controle the provenance of.

Personally I'd say the idea of having a high level of trust in any larg'ish software stack is very dubious these days given the likely incentives of various groups to compromise them.

"Proprietary software starts off with a high level of trust - trusting just one company. But it can never progress past this."

The first systems that were trustworthy were done by proprietary companies with independent evaluation of the product, signatures on source/binaries, and/or optional generation from source on-site. This became standard practice in security- and safety-critical development. You can scale it to as many people available for review often under NDA for the source itself but not signatures or binaries.

Sure the company can improve their process, but you're trusting the company to do that and do it properly - a user's relationship is still effectively rooted with one company. It's generous to call this "high", but forgive me for trying to make the point palatable to people who believe an autocratic company makes for something trustable.

A company can do things that are similar to Free software (eg allow customers to build from source), but in the context of modern discussion I'd say that's just taking on aspects of Free software.

Im responding to this claim:

"Proprietary software starts off with a high level of trust - trusting just one company. But it can never progress past this."

It's totally false. The evaluation side has been done more times than I can count. It doesn't even have to start with a single source. Many products started as a collaboration of multiple organizations checking each others work that share the result. Another model is CompSci inventing something with details open at the start, patented, and then turned into closed source product. Finally, there's Shared Source models where you can have, fix, or extend the source so long as you're paying. Burroughs B5000 (1961), first system resilient to 0-days, was distributed in source form to customers.

You were oversimplifying proprietary systems then attacking that simplification.

I appreciate your historic perspectives, but it feels like we're merely quibbling over terms/framework on this one. I don't think I'm oversimplifying, more like it's current mass-oriented software that essentially falls into two basic camps, Free and proprietary, with various small tweaks to each model. For example, something like a mass-NDA for every user is going to fail for consumer-oriented software, whereas a company contracting a discrete number of external auditing decomposes into trust through branding.

I'd love to find a commercial model that could work for consumer-oriented Free software [0], and I think it could sound quite similar to something you describe. It's just that those type of multi-party collaborations have been pulled into the attractor of free-as-in-beer, at least as far as the code itself is concerned.

[0] I say Free instead of Open, because I can envision software lacking just FSF freedoms 1b and 3 could get stuck in a bad state as well. Like say everyone knows there is a bug and how to fix it, but is legally prevented from doing so.

"but it feels like we're merely quibbling over terms/framework on this one. I don't think I'm oversimplifying"

You were. You made a blanket statement about the whole, proprietary model. In recent comments, you've changed your statement to talk about how the model is applied in the general case. As in, popular implementations vs all implementations. I'll reply to the new comment anyway.

"For example, something like a mass-NDA for every user is going to fail for consumer-oriented software, whereas a company contracting a discrete number of external auditing decomposes into trust through branding."

That's basically what happened. It could go further where lots of users get the NDA with cross-checks but not mass on high-volume scale. It helps if the software is designed in such a way where it can be shown it doesn't manipulate the system. I once proposed memory safety, safe API use, and sandboxing as a start on that. Automated tools could assess those. One could go further with information-flow labels tracking confidentiality or integrity enforced by compiler, runtime, or hardware. A few CompSci projects do it but not mainstream.

"I'd love to find a commercial model that could work for consumer-oriented Free software"

They pay for it. Then they get it. The source is in a FTP server or something somewhere. Things like branding, enterprise features, and tie-ins keep them buying from original supplier. Been done in a few ways although always a risk of clones.

"[0] I say Free instead of Open, because I can envision software lacking just FSF freedoms 1b and 3 could get stuck in a bad state as well. Like say everyone knows there is a bug and how to fix it, but is legally prevented from doing s"

Dual-licensed (proprietary + GPL) covers this. A few, quick proposals follow on non-free trying to approximate free. One could do a shared-source license that allows bug fixes. One could allow redistribution of software to other paying customers. One could cap what's to be paid or for how long before what's purchased becomes perpetual. One can make it go FOSS if it's EOL'd or gets under certain amount of developer time/contributions (tricky measure). Recent proposal was time limit on how long a version or individual product would be paid with it going FOSS after that time limit.

So, quite a few options here. One thing that's important to remember is that FOSS will always have a disadvantage over benign, paid model. The disadvantage is you can contractually ensure those being paid are doing support, bug-fixes, enhancements, pen testing, etc. They can also cover the pro's to do it right. They have lawyer money for patent trolling that will come their way. Combined with shared source like above, they might also get most or all benefits of FOSS with benefits of paid. It's why I'm highly interested to see companies experiment with hybrid models. A few have showed up here but nowhere near enough.

> I'm not aware of any mainstream OS that has been fully reviewed for security

Windows NT

OpenBSD

Fully audited? all the code? you sure? If so, I'd be very interested to see links to the results.

Most practical security measures are about striking a (better) balance between practicality and security. You're probably right that there is no viable device without binary blobs, but if the (corporate security policy) conclusion from this is that you can't use smartphones at all, practical experience shows that people will be using their private (vastly less secure) phones. In that case, it's way better to provide a much more, if not perfectly, secure phone (and sensible policies for using it).

At least, this is the market I perceive the Blackphone to be addressing.

Your text messages, voice calls and browsing history are analyzed by Google using automated software so there is nothing to worry about... (it is used only for targeted ad purposes) /s

Unless you either live in a "five eyes" country, or live in a country that isn't one of the five eyes.

Reply on news.ycombinator.com