Hacker Newsnew | past | comments | ask | show | jobs | submit | jlund's commentslogin

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!


It's worked great for me so far! Thanks jlund.


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


This is correct, just set one of these up and it uses extra Nginx plugins.

Also the way they’ve done it makes it incredibly easy for anyone who isn’t a tech expert with a web server to still help out with a $5 domain and a $5 VPS. You literally run three commands and it’s done.

They want as many people as possible running these so blocking them all is as difficult as possible. It’s the smartest approach to have a low barrier to entry for something like this.



It seems to be about the clients rather than the server.

A level deeper than "how signal works" and more "how signal is made"

For example, I'd expect a "how signal works" article to explain why they even need when an account was registered and when it was last used.

"this phone number is using signal" is still a pretty large metadata leak.

Especially when state actors and probably a fair few non state actors can remotely compromise devices via the stuff in the baseband processor.


>"this phone number is using signal" is still a pretty large metadata leak.

>Especially when state actors and probably a fair few non state actors can remotely compromise devices via the stuff in the baseband processor.

A more accurate phrasing would be "this phone number was used to activate signal". If you only care about messaging other Signal users, you only need to have a baseband connection exactly once, when you receive the text message to confirm the number. After that you can toss the sim card and put in a different number, or run without a sim card at all and just use WiFi.

You don't even need to have the sim card in the same phone you will use with Signal when you receive the confirmation text.


wifi is still in the baseband processor.

There have been mutiple baseband RCE exploits published in the literature and demonstrated at blackhat - and they dont include any that were put there intentionally.

If you are not using a sim smartphones are pretty useless.

Im a long way from convinced that centralised servers have any role to play in reasonably secure e2ee, they certainly are not a requirement for other services such as firechat used to use before they got shutdown and bridgefy is making use of.


> wifi is still in the baseband processor.

> There have been mutiple baseband RCE exploits published in the literature and demonstrated at blackhat - and they dont include any that were put there intentionally.

You can't target a WiFi exploit against a phone number though, so that's irrelevant to the Signal situation.

>If you are not using a sim smartphones are pretty useless.

Maybe I spend too much time hanging around places with WiFi, but I almost never need to have a sim card. I don't even have data on my current plan.


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


Right, here’s another comment on the topic by Signal staff too: https://news.ycombinator.com/user?id=pthatcherg


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




GPL doesn't prevent you from using it on mobile devices, it prevents you from making changes to his code proprietary. You seem to just want to release proprietary software. You should say that out loud if so!


That's not what OP said at all.

Apple _forces_ you to make proprietary changes to your application (and doesn't allow you to publish the source code of that modification). There is no way to have both a GPL-compliant app and have it on the app store at the same time.


It sounds like he addressed the point you raised (App Stores) even though he'd prefer to keep it GPL so changes are required to be shared.

What's the objection?


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/


This seems like smoke and mirrors to me:

  Traditionally, in Signal that process has looked like:
  
    The client calculates the truncated SHA256 hash of each phone number in the device’s address book.
    The client transmits those truncated hashes to the service.
    The service does a lookup from a set of hashed registered users.
    The service returns the intersection of registered users.
The phone number space is really not this big.


They acknowledge that in literally the next paragraph, and the entire post is about how they improved on that old state of things. How is that "smoke and mirrors"?


Right, my bad. This does look like a sensible solution


Is this solution deployed in production? The source code says "beta".


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...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: