Live data from Hacker News

Wrong signal

it-kollektiv.com

61–70 of 84 posts

Re: Wrong signal

#61

Earlier quoted context omitted.

> We've seen a continuation of invasive, Bush-era policies IRT the NSA under Obama...but now Trump is terrifying? Uh, yeah. The Bush/Obama surveillance policies have largely been seen as dangerous not because of actual concrete harms that have materialized, but because if continued they raise the prospect of a much worse (because of the increased scope possible with modern tools) version of the kind of political targ…

I'm not buying it. The house is already on fire, and people are wringing their hands because the new owner might have a can of lighter fluid in his pocket.

I would say that many people view the Bush/Obama surveillance policies more as unreasonably dangerous highly flammable fuel stored in the house than an actual fire, and Trump as more analogous to someone carrying an ignition source than additional fuel.

I don't think many serious observers think that, whatever the potential, the actual substantive harm has yet been even close to Nixon levels, though the potential scope of intercepted communication (and hence, potential for harm with simply a change of intent at the top) is much broader.

Re: Wrong signal

#62
post #42

Earlier quoted context omitted.

Exactly, which is why they should have required Facebook and WhatsApp to comply with the GPL. Alternatively, they should have created a more flexible license that could be used by Facebook, WhatsApp, or other companies to integrate their software. My point isn't about the GPL per se, but about the unfair playing field they are creating.

I think the GPL is actually a perfect license in this case. Anyone who wants to use their cipher in another GPL project is free to. Commercial entities who won't do this can pay OWS for their time, expertise and IP in order to get a different license.

That makes sense -- I guess what it boils down to is it would be nice if OWS were more open about their commercial licensing options, and make it easy for a company to license + integrate their work. As it stands right now it feels like you have to be a Facebook/WhatsApp level company to be able to be worth their time to work with.

Re: Wrong signal

#63
post #53
post #34

I'm repeating myself on many of these points, so I've cut and pasted some of my previous responses: > Signal uses servers controlled by OWS. Other organizations could conceivably operate their own servers because OWS open sources the software, but because OWS strictly opposes federation (meaning the interconnection of independently operated servers which the XMPP protocol (jabber) or e-mail allows), only the users co…

> I do not feel like the FOSS community is a "burden," however I do wish they recognized that many of their desires are unique to a very small minority of Signal users. I wish that they'd take more responsibility for manifesting those desires themselves. > This is the second time in two months that someone from the FOSS scene has written up a list of complaints, but as far as I know, in neither case have the authors…

I think that the interest in the FOSS community is relatively low given the centralized format in which Signal is offered.

How is Signal offered in a 'centralized' way? There is a free and open-source implementation that already (according to Moxie) supports federation. And a standing offer from the authors to help anyone doing further work on federation. What more could one reasonably expect, short of demanding OWS do the work.

Re: Wrong signal

#64
post #44
post #21

It sometimes feels like the security community is a bucket of crabs where any time something starts getting traction due to ease of use a lot of others try to pick at it due to it not being perfect even if many of those things are trade offs - phone numbers allow for signal to be a drop in replacement for other messaging apps with minimal to no registration required, I doubt I could have gotten my mother to use signa…

> It sometimes feels like the security community is a bucket of crabs where any time something starts getting traction due to ease of use a lot of others try to pick at it due to it not being perfect even if many of those things are trade offs That's because when it comes to security often theoretical vulnerabilities end up being protocol-destroying vulnerabilities in practice. Security folks are notorious for saying…

> That's because when it comes to security often theoretical vulnerabilities end up being protocol-destroying vulnerabilities in practice. Security folks are notorious for saying, 'that won't work,' being ignored — and then everyone being surprised when indeed it doesn't work.

we're not talking about protocol destroying bugs, were talking about things firmly in the realm of trade offs between marginal security gains and usability with security folks tending to be far too focused on marginal security gains while loosing sight of the big picture of less then perfect security that people use is better then perfect security that nobody uses.

I.E. ChaCha is better then AES because it is more resistant to side channel attacks among other things, but if you are creating a TLS server and can only choose one algo, you probably want to choose AES because more browsers support it compared to ChaCha and the marginal gains from ChaCha probably don't justify excluding those users that don't support it.

> If there is no central directory of identifiers to public keys, there's no way for a spammer to send spam

If there is no central directory of identifiers to public keys, there's no way my mom will use it to send me anything

Re: Wrong signal

#65
post #39
post #21

It sometimes feels like the security community is a bucket of crabs where any time something starts getting traction due to ease of use a lot of others try to pick at it due to it not being perfect even if many of those things are trade offs - phone numbers allow for signal to be a drop in replacement for other messaging apps with minimal to no registration required, I doubt I could have gotten my mother to use signa…

This isn't the security community. The security community is pretty much unanimous in supporting Signal over all other secure messengers. That's not to say that security people aren't critical of Signal, which isn't perfect for all the reasons this blog post points out --- Grugq is a pretty good source for these kinds of criticisms through the lens of an infosec person. But security people tend to deliver these criti…

Yeah good point, it's less the infosec community that has the knives out for signal as much as the other messenger app folks and the HN diehards that will never accept a protocol that isn't totally federated and maximally secure.

Re: Wrong signal

#66
post #3

There are always security trade-offs (especially when it comes to ease of use) but until you can show me a better app, which I can get my non-techy friends to use , Signal remains the best option for the mass market.

That's fine for the mass market, but their lives don't typically depend on the security of their communications. For people who are targeted by bad guys (extortionists, kidnappers, terrorists) a considerably higher bar is appropriate. It is important that people should be aware of the risks they are exposing themselves to, and the fine article is a good step in that direction. Hopefully it can also help stimulate improvements in the landscape which ultimately save lives.

Re: Wrong signal

#67

I do not see any comments to tackle the weakest link: exploits on the OS. Federated or not, the tunnel can be encrypted. On the servers static data can be encrypted. How can a regular user know his/her device's OS is not compromised? That is the problem to solve now and it seems that a formally verified OS code is the only long path.

That's not an argument for or against Signal, though, as it affects all messenger apps in the same way. While OS trustworthiness is an interesting topic, it's not really the one being discussed here.

It is however an argument for enabling Signal to work well on, e.g. CopperheadOS. The patches moxie requested for bypassing Play services would help in this regard.

Re: Wrong signal

#68
post #53
post #34

I'm repeating myself on many of these points, so I've cut and pasted some of my previous responses: > Signal uses servers controlled by OWS. Other organizations could conceivably operate their own servers because OWS open sources the software, but because OWS strictly opposes federation (meaning the interconnection of independently operated servers which the XMPP protocol (jabber) or e-mail allows), only the users co…

> I do not feel like the FOSS community is a "burden," however I do wish they recognized that many of their desires are unique to a very small minority of Signal users. I wish that they'd take more responsibility for manifesting those desires themselves. > This is the second time in two months that someone from the FOSS scene has written up a list of complaints, but as far as I know, in neither case have the authors…

> But "their own needs" are completely out of bounds for you, and it seems pretty clear that this isn't something that's going to be fixed in patches and code, so expecting them to come and fix it because you have an open code base is rather disingenuous.

Many of the things listed in these articles, such as making GCM optional, or supporting distribution outside of Play, are not "completely out of bounds." We've expressly indicated support for them and enumerated the work required, but nobody has committed to doing the work.

I don't expect anyone to do the work, but I do think it's strange when someone from the FOSS community complains that we haven't done it for them.

> If you started by promoting Signal as a generic protocol or backend to other projects, it would get much more traction in the FOSS community, as they are attracted to components on which other things can be built.

Signal is broken into three layers, two of which are designed to provide exactly that:

A crypto protocol that can be incorporated into other projects: https://github.com/whispersystems/libsignal-protocol-java

A service protocol that can be pointed at any back end: https://github.com/whispersystems/libsignal-service-java

The service protocol even includes support for federation. I don't think it's a good idea for the reasons I've enumerated, but anyone can use this code to start their own federated network and prove me wrong.

> For human and community reasons, the upside to federation is probably a lot higher than you appreciate. I hope you consider it. You have built a nice platform, but for your work to make a lasting impact you need to share it with others.

We've done more than consider it, we've done it. We started Signal as a federated service, and it was kind of a disaster.

I'd definitely reconsider if people have a plan for avoiding the problems that we encountered the first time, beyond "federation is good." In the mean time I'm happy to help anyone deploying Signal in their own federated environment.

Re: Wrong signal

#69
post #59

Earlier quoted context omitted.

Phone-number as identifier is pretty terrible user-experience choice. I am traveling and my phone-number has changed half-a-dozen times in the past year alone, my email has been the same for over a decade. I tend to use Whatsapp because other people already have it but I have absolutely no motivation to use encourage other people to use Signal. Edit: Whoever down-voted this, want to explain how this isn't a huge user…

Why does your phone number keep changing?

Because that's how things are, at least in some locations. When you move to another city or state, you either suffer extra roaming costs (and incur some on your peers, as they'll be calling "long-distance" numbers even if you're physically close), or get a new (local) SIM/phone number. At least, that's what my experience is.

This must be even more true when moving to another country.

(Surely, there also must be some exceptions as well, where maintaining old number is an option.)

Re: Wrong signal

#70

Earlier quoted context omitted.

> We've seen a continuation of invasive, Bush-era policies IRT the NSA under Obama...but now Trump is terrifying? Uh, yeah. The Bush/Obama surveillance policies have largely been seen as dangerous not because of actual concrete harms that have materialized, but because if continued they raise the prospect of a much worse (because of the increased scope possible with modern tools) version of the kind of political targ…

I'm not buying it. The house is already on fire, and people are wringing their hands because the new owner might have a can of lighter fluid in his pocket.

Yes, the house is on fire, but your friend's friend who is a narcissistic and thin skinned and promises to use the power of government to go after his enemies just showed up with 2 55 gallon barrels of jet fuel.

He is about to enter the house and does not believe jet fuel can catch fire.

Post reply on HN