Live data from Hacker News

On Privacy versus Freedom

matrix.org

111–120 of 209 posts

Re: On Privacy versus Freedom

#111

Earlier quoted context omitted.

> I can even send encrypted emails with GnuPG without any problem, and it's as secure as Signal, if not better. Alas this requires a fairly contorted definition of "secure" to be true. The cryptography in GnuPG has plenty of problems even if you insist on manually doing everything from your own CLI tools which maybe don't suffer the problems from EFail. Mostly it's just kinda old, AEAD hadn't been conceived when Phil…

>...if you insist on manually doing everything from your own CLI tools which maybe don't suffer the problems from EFail. The only surprising thing that EFail revealed is that there are email clients out there that will silently allow html emails to communicate with the outside world. Encryption isn't the only thing that leaks from such clients. >...PGP had to kind of fudge a separate MAC into the design and hope that…

> Well isn't it? What attack is possible here? What attack was ever possible?

No. Unsurprisingly the result is exactly what you'd expect. Idiots build software that throws away the error result and returns the unauthenticated text. This has always happened, which is why AEAD modes exist now. EFail documents what it names "CFB gadgets" to abuse this in typical HTML-based OpenPGP clients but you could attempt the same fun attacking a human subject directly, in some ways it might be easier because humans tend to just sort of "read past" nonsense in the search for meaning.

Phil Zimmerman didn't have a better option. You do.

> You use the best ones supported by the receiver as listed in their public key

So, you never use anything in the least bit new unless you're communicating with somebody who just minted new keys. For older users, you're stuck with whatever was current in the software version they ran five, ten, twenty years ago.

Re: On Privacy versus Freedom

#112
post #109
post #95

Earlier quoted context omitted.

That's not the representative experience for most consumers/users. Most people do have a phone number, though, so it's easy enough to bootstrap with. I might not agree with the phone number thing, but I recognize the tradeoff being made and am willing to begrudgingly accept that for right now, Signal/Moxie are probably making the right call. It's not like they're not moving to fix it anyway. Also, unless I misunderst…

> That's not the representative experience for most consumers/users. Most people do have a phone number, though, so it's easy enough to bootstrap with. It's a trap most don't realize they are falling in. It's easy to set up things without one time registration step (instead of making a user id and password, just download some client and boom - you are set). But think about it. One time(!) convenience is paid with con…

The second isn't better by default - no matter what, you're trusting some organization/entity somewhere in the chain.

Furthermore, your comment just eschews what Signal has said elsewhere - if you have a social app, you need a social graph to operate. They have to piggyback somewhere or else store a bunch of data themselves, and it's clear that they take their time to make sure they're doing something as best as possible before committing to it.

It's also not developers proliferating the approach. This is what the market developed into, and if you want your product/service/whatever to be successful, you have to win with that constraint. What you're describing is idealist, but not realistic at time of writing this. Hopefully it changes, but place the blame where it's appropriate.

Re: On Privacy versus Freedom

#113
post #109

Earlier quoted context omitted.

> That's not the representative experience for most consumers/users. Most people do have a phone number, though, so it's easy enough to bootstrap with. It's a trap most don't realize they are falling in. It's easy to set up things without one time registration step (instead of making a user id and password, just download some client and boom - you are set). But think about it. One time(!) convenience is paid with con…

The second isn't better by default - no matter what, you're trusting some organization/entity somewhere in the chain. Furthermore, your comment just eschews what Signal has said elsewhere - if you have a social app, you need a social graph to operate. They have to piggyback somewhere or else store a bunch of data themselves, and it's clear that they take their time to make sure they're doing something as best as poss…

> it's clear that they take their time to make sure they're doing something as best as possible before committing to it.

If you mean developers of such tools, they are surely not doing it "as best as possible", because they by design chose the worse approach. Decentralized approach is more difficult, but it is as best as possible.

> This is what the market developed into

Yeah, right, and developers just follow the "invisible hand of the market". It's not an excuse in the slightest, for fooling their users into trading off their privacy for convenience. Those who create such tools bear responsibility for what they created and for proliferation of such approach.

Re: On Privacy versus Freedom

#114
post #95
post #86

Earlier quoted context omitted.

In his "The Ecosystem is Moving" talk at CCC, he had many presumptuous and dubious "arguments" but one regarding privacy of phone numbers was that a user's APN would be used to determine their phone number, so there was no point in trying to keep phone numbers private. This fails to account for the possibility of not using the cellular network. With unlocked smartphones, it is possible to remove the SIM card, clear a…

That's not the representative experience for most consumers/users. Most people do have a phone number, though, so it's easy enough to bootstrap with. I might not agree with the phone number thing, but I recognize the tradeoff being made and am willing to begrudgingly accept that for right now, Signal/Moxie are probably making the right call. It's not like they're not moving to fix it anyway. Also, unless I misunderst…

> You realistically can't use Signal without an Apple ID

I do, because I got it and signed up for an account on my Android phone...

Okay, I realize what you're getting at here, but it seriously irks me when people talk as if Apple was the only ecosystem, or even the most popular ecosystem, when it is neither.

I probably don't even need a Google Play Store account if I can find an unmodified APK that's signed by OWS.

Re: On Privacy versus Freedom

#115

Earlier quoted context omitted.

>...if you insist on manually doing everything from your own CLI tools which maybe don't suffer the problems from EFail. The only surprising thing that EFail revealed is that there are email clients out there that will silently allow html emails to communicate with the outside world. Encryption isn't the only thing that leaks from such clients. >...PGP had to kind of fudge a separate MAC into the design and hope that…

> Well isn't it? What attack is possible here? What attack was ever possible? No. Unsurprisingly the result is exactly what you'd expect. Idiots build software that throws away the error result and returns the unauthenticated text. This has always happened, which is why AEAD modes exist now. EFail documents what it names "CFB gadgets" to abuse this in typical HTML-based OpenPGP clients but you could attempt the same…

>For older users, you're stuck with whatever was current in the software version they ran five, ten, twenty years ago.

GPG2 doesn't support V3 keys anymore so old keys just won't work. That point is fairly moot in that pretty much all the ancient encryption is still unbroken.

Re: On Privacy versus Freedom

#116
post #97
post #57

Earlier quoted context omitted.

> In this case however, the code is under the GPLv3, which is far more problematic. It contains a "anti-tivoization" clause, which says you cannot require any "methods, procedures, authorization keys, or other information required to install and execute modified versions". That doesn't actually apply to the Apple app store. The "anti-tivoization" clause is narrowly written to only cover what Tivo did. Namely, providi…

>anything designed or sold for incorporation into a dwelling. I'd be willing to make the argument that a program integrated into a previously owned computing device is a totally valid case for this clause to trigger under. Your computer is part of, and is increasingly integrated into your dwelling. The program being pulled down is just another module for it.

It wouldn't matter. Two things are required to trigger the clause.

1. The GPLv3 object code has to be conveyed "in, or with, or specifically for use in, a User Product", and

2. This must occur "as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient".

The "User Product" in your argument is still the computer, and so unless you are buying the computer itself from the App Store at the same time as the app you are buying, the second condition is not met.

The definition of "User Product" in GPLv3 might seem a little puzzling at first. There are two kinds of things that count:

1. "any tangible personal property which is normally used for personal, family, or household purposes", or

2. "anything designed or sold for incorporation into a dwelling".

There is no definition of "dwelling" in GPLv3, so it is going to be given its ordinary meaning which according to Oxford is "a house, apartment, or other place of residence".

#1 already covers any tangible personal property used for personal, family, or household purposes, and since dwellings are places of residence it might seem that anything incorporated into a dwelling would also be covered by #1.

So what is #2 actually getting at?

The answer, I'm sure, is fixtures. A fixture is physical property that is permanently attached to real property. Crucially, if something is a fixture then it is not considered to be personal property and so does not fall under #1 of the "User Product" definition.

Unless the sales contract specifically says otherwise, fixtures go with the house, and personal property goes with the seller.

Nowadays a lot of things that include software might be fixtures. Some things that might be considered fixtures and might also have software in them:

1. Thermostats.

2. Smoke alarms.

3. Security cameras.

4. Appliances.

5. Lighting fixtures.

(I'm not saying that they are fixtures. In some houses they might be fixtures and in others they might not be, depending on how they were installed).

Without #2 in the "User Product" definition, manufactures of those things might be able to include locked down GPLv3 firmware without trigger the "anti-tivoization" clause.

I say "might be able to" because those things aren't fixtures until they get attached to the house. A thermostat sitting in a box on the shelf at Home Depot is not a fixture at that point. It only becomes a fixture when someone installs it.

This would probably cover it under #1, closing the loophole.

But what if the thermostat is not sold through stores like Home Depot? What if instead you have to buy it through the manufacturer, which sends an installer to install it, and only conveys ownership to you after it has become a fixture? This could probably be done in a way that evades #1.

#2 shuts down such shenanigans.

What I'm puzzled by is what about things that are neither personal property used "for personal, family, or household purposes" nor for incorporation into dwelling?

Would it be OK for Boeing or Airbus to Tivoize the software in their planes and still use GPLv3 code in it? Can John Deere use GPLv3 code in its combines and Tivoize it?

Re: On Privacy versus Freedom

#117
post #86

Earlier quoted context omitted.

In his "The Ecosystem is Moving" talk at CCC, he had many presumptuous and dubious "arguments" but one regarding privacy of phone numbers was that a user's APN would be used to determine their phone number, so there was no point in trying to keep phone numbers private. This fails to account for the possibility of not using the cellular network. With unlocked smartphones, it is possible to remove the SIM card, clear a…

In the context of this talk, APN means "Apple Push Network", I think. The concern is that even if the service doesn't ask for a phone number directly, it does still have an APN or GCM/FCM push token. Through the push provider, that token can probably be linked to the user's phone number. > With unlocked smartphones, it is possible to remove the SIM card, clear any APN settings and access WiFi. If you're willing to do…

So you pull a Telegram and create a good alternative to APN/Firebase.

Re: On Privacy versus Freedom

#118
post #31

One frustrating thing about Moxie's original post is that Signal derives huge amounts of value by piggybacking on an existing distributed federated network: the phone system. If phone numbers weren't an existing working identifiers that people had regardless of what OS, carrier, or messaging app, Signal as designed wouldn't work. People should think harder about how to replicate that experience, instead of how to app…

>One frustrating thing about Moxie's original post is that Signal derives huge amounts of value by piggybacking on an existing distributed federated network: the phone system. If phone numbers weren't an existing working identifiers that people had regardless of what OS

oh my sweet summer child.

I hop countries and switch phones every few years. This entire assumption that my identity is tied to a phone number which I will have forever is patently false. Phone numbers are an anachronism.

I sure as hell don't trust an alleged privacy focused messenger that insists on a hard identifier (even if I know how to subvert said identifier for now). When privacy truly matters, signal runs on an emulated phone and a burner number.

Re: On Privacy versus Freedom

#119
Signal really tries hard to not be trustworthy.

The way they defend WhatsApp is heart-breaking. It's cute to see them saying there is no backdoor when it can't be proven to be the case, since it's all proprietary. They can't show the server side wasn't tampered with. Same with Skype.

Re: On Privacy versus Freedom

#120
post #69

Earlier quoted context omitted.

To be fair, since there is no remote attestation possible for the Signal servers, and you realistically can't run one yourself, you only have their word that they don't store any of that information. This is similar guarantees that a lot of other chat and VPN companies offer. Personally I would consider any information given out to a company non-secret, especially to those operating outside my jurisdiction.

Maybe I'm misunderstanding what you're trying to say, but remote attestation is in fact exactly what they're doing with their contact discovery: https://signal.org/blog/private-contact-discovery/

SGX is crypto that is already exploited and broken, it offers no real use in this context.

Oh, and I forgot, you do need to essentially blindly trust Intel.

Post reply on HN