jlund

Hey, HN. While I was helping a friend set up their new iPhone, I noticed that they were prompted to upgrade to a newer version of iOS. When I checked my own phone, I saw that the update had been released more than two weeks earlier — but I was still stuck on the old version even though I had the iOS "Automatic Updates" feature enabled.

As a result, I started working on this project to make it easy to get notified whenever Apple releases a new iOS update. It can send notifications via Discord, Email, Signal, Slack, SMS, and Telegram.

It's free and open source. There are even a couple of no-setup options (just scan a QR code or text a toll-free number) for people who want to try it out first or who don't want to self-host it themselves.

Whether you care about security and want critical bug fixes fast; or you get excited about new features and want to try them first; or both — my hope is that this little tool can help.

Thanks for taking a look!

The Nginx configs use modules that are not compiled by default, so most preexisting Nginx binaries in mainstream distros won't work.

Does this help?

https://signal.org/docs/

Just to clarify, the bug you're talking about was in WebRTC. We submitted a patch upstream:

https://webrtc-review.googlesource.com/c/src/+/175960

Google Play Services aren't required to run Signal on Android either.

https://signal.org/blog/license-update/

Nice breakdown! Just to clarify, in step 2 of your "Recovery of the secret (by the client)" section, the client is retrieving `split2`, not `split1`.

You can read more about the Registration Lock feature here:

https://support.signal.org/hc/en-us/articles/360007059792-Re...

The Contacts permission is completely optional, and contact information is never stored: https://signal.org/blog/private-contact-discovery/

It does. Signal supports runtime permissions[1] and it requests them dynamically while you are using the app (e.g. the camera permission prompt appears the first time you try to take a picture).

1: https://developer.android.com/training/permissions/requestin...

Everything in Signal is end-to-end encrypted.

I was incorrect about this, and I apologize.

Just one additional note that might not be immediately clear from the advisory: Exploiting this requires the attacker to first manually place malware (a malicious JavaScript file) on your computer or on a Samba network share that your computer is already connected to.

If the solution to censorship is to constantly switch to new hosts, it would be even easier to do this via a VPN (which wouldn't require you to rebuild your social graph at all, unlike a federated endpoint switch).

If the more straightforward solution (VPN) isn't a panacea for censorship, then federation isn't either.

Time to look for another option then

That's the plan. This is covered briefly in the second-to-last paragraph.

so it was never really viable

Signal remained running for more than a year and a half in several countries that were actively trying to censor the service.

Let's say I have an account on a federated server and a censor then blocks my ability to access that server from my home country.

While it's true that my friends on other servers might be able to send messages that will arrive on my chosen server, that distinction isn't very meaningful because I am unable to connect and retrieve those messages.

I wouldn't be communicating with my friends until I switched to a new server and rebuilt my social graph.

The loss of domain fronting as a viable strategy means that it will be possible to censor Signal in areas where the service was previously working.

An aspiring censor could also "easily connect to the broader network" and masquerade as a federated server in order to discover others. This process could even be automated.

Federated services also require an identifier, and this identifier usually indicates where the user's account is located and how to connect with them (e.g. user@domain.com). As people share these identifiers, the aspiring censor can just keep adding new entries to the blacklist.

The technique that Signal was using to circumvent censorship (domain fronting) will no longer be possible on Amazon:

https://aws.amazon.com/blogs/security/enhanced-domain-protec...

Unfortunately, federation is not an effective tactic against censorship: https://news.ycombinator.com/item?id=16871352

The relevant text is in the subject line of the email: "Notification of potential account suspension regarding AWS Service Terms"

It's trivial to block several distributed hosts simultaneously. An aspiring censor would simply find the most common federated endpoints for a given service and block all of them. Only the users of that software would be affected. There wouldn't be any collateral damage.

If the censors somehow didn't hit every single worthwhile federated endpoint, users would still be left wondering why they couldn't communicate with most of their friends. Moving between federated hosts would also necessitate an entirely new identifier, so users would need to rebuild their social graph again.

In addition to being ineffective against censorship, there are several other properties and trade-offs that make federation a difficult proposition for an application like Signal: https://signal.org/blog/the-ecosystem-is-moving/

Hey, everyone. We spent a decent amount of time at Signal trying to come up with alternatives when we first heard rumors that Google was disabling domain fronting on GAE.

We're using Souq because it is popular in the countries where we have Censorship Circumvention enabled (Egypt, Oman, Qatar, and UAE) but it would be nice to have other options on CloudFront as well. It's possible that we overlooked other highly ranked domains in these countries that use the CloudFront CDN.

If anyone has any suggestions, we would appreciate them.

Signal takes metadata protection very seriously: https://signal.org/bigbrother/

Nothing about Signal itself is changing. This is Microsoft adopting the Signal Protocol for a new feature in Skype.

I am in the perfect demographic for the Bolt: I am a previous Chevy owner (with a car that ran well for over fourteen years!), I want an electric car, and I'm not afraid of being an early adopter.

I can't buy one.

Chevy doesn't appear to be manufacturing them beyond a handful of review units for magazines like Motor Trend and a small number of end-user sales in states where they need the ZEV Credits. People are unenthusiastic about the Bolt because they're matching Chevy's apparent level of enthusiasm.

The rhetoric around the Bolt ("Chevy did it! They were first at scale with a $35k car!") is arguably even more disconnected from reality than anything people are saying about Tesla. The Model 3 isn't a compliance car that is masquerading as a serious effort. Tesla is planning on selling it nationwide. They didn't restrict pre-orders to California and Oregon. Setting aside the actual cars, these are big differences.

At Chevy's current roll-out pace, my Model 3 pre-order will arrive long before any local Chevy dealerships are willing to sell me a Bolt (while passive-aggressively pushing me towards an internal combustion vehicle the entire time).

When an adversary intercepts a Telegram SMS authentication code, this gives them pretty much complete access to a user's entire Telegram messaging history. This is true because messages are not end-to-end encrypted by default. The Telegram servers will happily return perennially stored transcripts to any client that is even temporarily considered valid.

This is _not_ true for messaging applications that are end-to-end encrypted by default and that do not store plaintext on their servers. This isn't a subtle difference. Lots of comparisons in this thread fall victim to a sort of implied false equivocation.

Using SMS as a form of authentication may be a quality that Telegram shares with other popular messaging applications, but it is uniquely susceptible to all of the associated pitfalls.

Yeah, I will probably make it possible to choose the list of services instead of singling out Tor specifically. I have heard from some users who only want to run Shadowsocks, for example. The diversity of services really helps keep things flowing in restrictive environments. Not everyone falls into that category though.

Good news! Your Ubuntu dreams are already a reality. The playbooks are currently designed for Ubuntu 14.04. I was using Debian 7 at launch (which might be what you saw previously) but I switched the base distribution late last year. Ubuntu 16.04 is the frontrunner for the next upgrade. The playbooks and roles are complicated enough that it's not terribly practical to target multiple distros, especially given the wide support that Ubuntu enjoys.

I'm planning on implementing IKEv2 support in Streisand soon. I wanted to get OpenConnect/AnyConnect implemented first. I had not heard of OpenIKED until your comment, and I got really excited, but it looks like the portable version for Linux has been deprecated? If that's the case, it is really unfortunate; I love OpenBSD and their security track record.

I will likely use Libreswan for both L2TP/IPsec and IKEv2, and give the user a choice between those options at installation. L2TP/IPsec support is still a little more ubiquitous, but IKEv2 will be set up by default. It's a much better protocol with significantly less legacy baggage.

Your comments on Tor are thought-provoking too. I can look into making that optional as well, either through a prompt or command-line flag.

Thanks for the feedback! Let me know if you have any other suggestions.

Helping people get around the Great Firewall was one of the main reasons I started working on Streisand[1]. OpenVPN (wrapped in stunnel), Shadowsocks, and Tor (with obfsproxy) are all still highly effective. The setup process is completely automated, and other connection options are available too.

1: https://github.com/jlund/streisand