Live data from Hacker News

The coming war on end-to-end encryption

community.qbix.com

41–50 of 58 posts

Re: The coming war on end-to-end encryption

#41
post #21

Eight years ago I took a whack at building a fully open source end-to-end encryption system. This is what I came up with at the time: https://github.com/Spark-Innovations/SC4 It's a bit dated at this point. It doesn't have a ratchet. I did implement one, but never got around to integrating it: https://github.com/rongarret/ratchet-js I also had an MVP iOS app which was never launched. The reason I gave up on the proje…

I agree that people generally don't concern themselves too much with how their information is protected. Most people simply assume that it already is or that they can't really do much about it without giving up a lot of convenience. However, I have noticed in specific cases, people do pay attention. In my case, I'm protecting contact information while sharing with others and most people think it is a great use of e2ee.

Re: The coming war on end-to-end encryption

#42
post #21

Eight years ago I took a whack at building a fully open source end-to-end encryption system. This is what I came up with at the time: https://github.com/Spark-Innovations/SC4 It's a bit dated at this point. It doesn't have a ratchet. I did implement one, but never got around to integrating it: https://github.com/rongarret/ratchet-js I also had an MVP iOS app which was never launched. The reason I gave up on the proje…

> The conclusion I came to is that a lot of people complain about the impending end of E2EE but very few people are actually willing to do anything about it except whine.

The connection between E2EE and privacy is to ephemeral to make that kind of judgment. If you live in the united states or similar country with a strong rule of law, the idea of paying for or using a specific E2EE app is functionally like asking somone to pay for free speech.

And even if it was more clear, privacy is like free speech in that you cant really measure enthusiasm for it in that way. Free speech and privacy are fundimental values that people dont want to pay for (for good reason!). But that does not mean they dont care.

People really do care about these things. And many many people will change how they vote and how they engage in civic action based on these principals. But asking someone to change how they live/communicate with others requires more then an intelectual "which party / candidate should I vote for?" kind of thing. For most people you need emotional investment for someone to overcome switching costs based on nothing but ethical / political principal.

As long as the harm to losing these core rights remains abstract you wont be to measure how much they care with metrics like that. Its a value that is too ephemeral and disconnected from day-to-day life to measure with a stick like "who will use this app".

But people can and do donate to groups like the EFF, and vote with their actual votes on this stuff. People really do care. Just like how people really do care about honesty, free speech, candor, trust, and other values of that sort. its just, you know, hard to measure.

Re: The coming war on end-to-end encryption

#43

The coming war? It's been a protracted war since the 1980's. The NSA and the FBI have been hazing, threatening, infiltrating, and backdooring end-to-end encryption since the early days of PGP.

> backdooring

Name one attempt besides Dual_EC_DRBG. Also could you explain why that one took NIST 8 years to say "don't use it".

Re: The coming war on end-to-end encryption

#44

Nice! I worked on something that seems similar to this ( https://redact.ws ). Unfortunately there are a lot of challenges with adoption that seem difficult to overcome. One of the big challenges is that most people do not understand the nuances of privacy and encryption, and they aren't willing to jump through hoops to protect their data.

I like the intent of this! My main question is, how do we know redact.ws won't suddenly serve different Javascript one day, to certain clients, which send unencrypted payloads somewhere?

Re: The coming war on end-to-end encryption

#45
post #44

Nice! I worked on something that seems similar to this ( https://redact.ws ). Unfortunately there are a lot of challenges with adoption that seem difficult to overcome. One of the big challenges is that most people do not understand the nuances of privacy and encryption, and they aren't willing to jump through hoops to protect their data.

I like the intent of this! My main question is, how do we know redact.ws won't suddenly serve different Javascript one day, to certain clients, which send unencrypted payloads somewhere?

The redact server is an open source application that runs locally on the client.

Re: The coming war on end-to-end encryption

#46
post #21

Eight years ago I took a whack at building a fully open source end-to-end encryption system. This is what I came up with at the time: https://github.com/Spark-Innovations/SC4 It's a bit dated at this point. It doesn't have a ratchet. I did implement one, but never got around to integrating it: https://github.com/rongarret/ratchet-js I also had an MVP iOS app which was never launched. The reason I gave up on the proje…

What is it? Seams like it's an implementation of ecc,but does what? A p2p chat? ::Shrugs:: I'm not sure the failure to adopt your one elusive product speaks for the entire pop.

Re: The coming war on end-to-end encryption

#47
post #44

Earlier quoted context omitted.

I like the intent of this! My main question is, how do we know redact.ws won't suddenly serve different Javascript one day, to certain clients, which send unencrypted payloads somewhere?

The redact server is an open source application that runs locally on the client.

How does a server run on the client? It runs on localhost! Right?

It can show the user their own info back to them in iframes?

Re: The coming war on end-to-end encryption

#48
post #32

Earlier quoted context omitted.

If I buy crypto and posess it in my own wallet afterwards I can usw it however. Atleast with monero.

How will you anonymously collect the groceries you anonymously bought?

Obviously you can't pick up a grocery delivery and remain anonymous.

But in theory if you could pay for groceries with monero (you can't afaik), you could pay from the same wallet you conducted a hack from or purchased a darknet server to host leaked data with. The grocery store wouldn't know the originating wallet or any of its other activity.

Anyone who thinks grocery stores are going to allow monero payments is pretty naive, but Monero at least makes these flows possible.

For example, if Walmart decided to let people pick up orders with monero payments, you'd log in with your walmart account (linked with real name), place your order, pay to the generated wallet address with Monero, and then show ID on pickup. Walmart would have no way of knowing where the money came from.

I don't have any Monero or particularly like it (but mainly because I consider proof of work unsustainable and wasteful). But you have to admit the privacy implications are interesting, and the technology is impressive.

Re: The coming war on end-to-end encryption

#49
post #47

Earlier quoted context omitted.

The redact server is an open source application that runs locally on the client.

How does a server run on the client? It runs on localhost! Right? It can show the user their own info back to them in iframes?

I'm not the creator of redact, but it sounds like you're under the impression that the iframe src is redact.ws in which case I'd understand your concern.

My assumption is that the iframe src would be the local redact server, which would keep things as secure as the package the user installed (though there could be compromises at the network level I suppose)

Re: The coming war on end-to-end encryption

#50

The coming war? It's been a protracted war since the 1980's. The NSA and the FBI have been hazing, threatening, infiltrating, and backdooring end-to-end encryption since the early days of PGP.

> backdooring Name one attempt besides Dual_EC_DRBG. Also could you explain why that one took NIST 8 years to say "don't use it".

There are already legal backdoors not actually referred to as that legally and they are used by corporations to meet their regulatory requirements for things like DLP. Google for example supports this. HTTPS doesn't even matter, their site supports DLP appliances logging in and intercepting all corporate interactions on the platform. The same capabilities exist for non corporate but that is used by law enforcement. This exists on all major platforms. This would play into E2EE if the servers create and manage the client E2EE keys which I believe is the case currently on all platforms that support E2EE. I am told that implementing client side libraries like OTR is too hard or too much friction. So what I am saying is that encryption need not be compromised when all corporations willingly create lawful intercept and DLP API's.

To get more information on this have your company reach out to each platform for DLP integrations.

Post reply on HN