Hacker News Reader

Comment by Vinnl | Hacker News Reader

Their shtick is that they won't have to fight much, because they can't turnover someone's messages. Here are some examples of where they were legally compelled to turn over everything they had, and they did - but it was roughly nothing: https://signal.org/bigbrother/

View on HN

We can expect that every military action has a principals committee (if not a principles committee).

Most actions that are on the record, with classified data properly conveyed through their "high side" inboxes and properly archived, will have those records accessible to special counsel or historical analysts. If, as I suspect, most of the current cabinet's principals committees are meeting over Signal, the records of those communications will be conspicuously absent.

It's not like these guys are masterminds meticulously generating compelling and consistent alternate records in the SCIF, then also pulling out their phones and telling most of the same people most of the same things in group chat messages. They're just not having the discussions in the SCIF at all, and that will be evident to anyone who cares to investigate.

Sorry, to clarify: when I said "they", I meant Signal.

This schtick is just that, a schtick thats only as strong as whoever is fighting against it...

https://www.devever.net/~hl/webcrypto

Signal is distributed as an app. Furthermore, the client is open source, you can see the repositories here:

https://github.com/signalapp

I don't know the latest details about Android/iOS app signing, but presumably reproducible builds + sufficiently strong signing would make it secure enough for most users. For those who are truly paranoid, then can build it themselves (subject to their own device OS's requirements, which are hardly a unique problem to Signal).

In short, Signal's security should be as good as any mobile app can be, and can be even better if you're willing to put in legwork.

When was the last time you verified that the update being pushed to the app store by signal matches the git repo?

When was the last time you checked what updates have been made to the git repo?

Of course what you're saying is "technically" possible to avoid signal changing code and circumventing encryption, but show me one person who does a check of all the changes to signal source(and verified the binary matches) before they let their app store update it and they launch it...

Everyone I know has signal auto-update through the app store and don't even know it updated until after they launch it.

Well, the security should be good enough for most people's threat models. But government officials will probably want to have some restrictions on who can be added to a group, for example.

The government could definitely compel Google to give a list of users a malicious Signal update

The government could compel signal to do this, no?

They haven't, but if they decide they want to what's technologically stopping signal from:

1. Making an update that doesn't exist in git which pushes decrypted messages to their server when you launch the app

2. Push this update to the app store

If a government ever compelled them to?

I don't believe Signal has a web app. Am I wrong?

I understand the point about the app being distributed by the same people who run the service, but it's much harder to hide shenanigans with a local app versus a web app, especially when the app is open source.

When was the last time you verified an update to signal against the source code? The threat model is circumvented for people that do that before every update, but unless you're doing that they can push whatever code they want to your app.

What's your point/goal with this and your cousin comments? Yes, of course at some point you need to trust a binary or verify yourself. I'm technically correct and you're technically correct. What are you getting at? Do you suggest people not use Signal? What do you suggest as an alternative? What should Signal do to change things? Splitting management of the app and service doesn't help much; a compromised browser, not co-owned with the services it accesses, is enough to eavesdrop on someone despite HTTPS.

My point is to make a comment on social media and get responses to see what other people think.

All I'm getting at is that any company that distributes code to you and tells you they can't see your data is lying. They just don't want to access your data right now.

I would suggest people understand this and position themselves accordingly security-wise.

If that means not using signal because its not secure enough then ok.

If that means continuing to use signal with the understanding that it's only secure until signal decides they want your data(or a gov forces them to), then ok

Splitting management of an app and service is the exact solution. If signal can't control when to push updates to your phone then they can't control when they want to break encryption.

In your compromised browser example we understand that browsers have an interest in imementing HTTPS correctly and treat them accordingly. That's part of the reason the market is dominated by 2 engines that do their development as much in the public as possible

What does that article have to do with Signal?

Signal is an app whose distribution is controlled by the same people that say they don't have access to your data.

They could at any point push an update that decrypts your messages locally and pushes them decrypted to a server. The only way to prevent this would be to verify each binary update to signal matches the source code, and no modifications have been made to the source to do this.

Is that part of your "signal update" routine?

Reply on news.ycombinator.com