Hacker News new | past | comments | ask | show | jobs | submit login

Yep, but Signal is still a potential adversary, and could roll out a backdoor.

A couple of things that are easier in a web-delivered tool is deliver a backdoor to a user or group of users (which Skiff can track), or deliver a backdoor over a particular window of time across many users to decrease the chance of detection.

I know Skiff uses IPFS in some of parts of their solutions, and there's something they could do with that for the first -- essentially making visiting a particular version of the code part of how it is accessed, but there's some real UI challenges, which maybe they're looking into (it's been a while since I checked them out: they have some great UX in other parts of their suite).

The other tactic I've seen is to bundle the page into a browser extension, which moves you closer to Signal's status.




Signal's servers can't backdoor the Signal Client. From what I understand of Skiff, Skiff's servers are the client.


Not directly. They would have to roll out an update with the backdoor to the App Store. But as a user I’d be none the wiser.

I wish there was some way on iOS to prove that some particular version of an app was built from a certain git hash. That way these sort of attacks would be easier to detect.


That would be ideal. F-Droid on android can do this: https://f-droid.org/en/docs/Reproducible_Builds/

However there is still one advantage of even appstor: They have to push the backdoored version to everyone (or large set of users). So that drastically increases risk of being caught. Website under their control can backdoor one specific user or even just one session, making detection harder.


> So that drastically increases risk of being caught.

Only if someone out there is extracting, decompiling and auditing each version of the Signal iOS app in the app store. But I doubt anyone is doing this. If a backdoor is ever snuck into the signal ios app for a few users for a few weeks, I highly doubt anybody would notice.


xkcd://386

Of course someone is doing this. I’m not sure they are the kind to tell it to the world, though.


Not just someONE, whole bunch of researchers and automated scans.


You can change remote configuration flags post-release (e.g. to enable diagnostics).

Even “secure” softwares like Google Chrome can capture your whole browsing history if they suddenly decide to enable a flag on your IP address. No need for conspiracy or update, though Chrome is considered perfectly secure.

In Android you can also distribute updates to specific e-mail addresses, which is very convenient.


> In Android you can also distribute updates to specific e-mail addresses, which is very convenient.

Yes but this requires the user to opt-in, you can't do it silently:

> After clicking the opt-in link, your testers will get an explanation of what it means to be a tester and a link to opt in. Each tester needs to opt in using the link.

Source: https://support.google.com/googleplay/android-developer/answ...

As for the Chrome thing, I'm a Firefox user but I would be surprised if it shipped with the option to remotely upload whole history without user's knowledge or consent, do you have a source to back that up?


You can disable updates. As long as the servers (and the OS) don’t break compatibility, you can continue to use the same old likely-non-backdoored version.


At least when downloading from the Play store, Google requires the application be updated every 90 days or so. I've run into this multiple times where the application ceases to function after the 90 day window until I go update.


Not for Signal. I was periodically prompted to update with the warning that I would lose access to signal if I didn't. Then I upgraded and they robbed me of SMS features. I would have been happy to remain on a previous version.


Group invite links in Signal work similarly to Skiff: they reveal a key to the client side js so it can either present users with a Signal download link or open a URI, depending on whether they already have Signal or not. (Signal chooses not to use a URI in this case because it would break for anyone without Signal.)

So if a Signal group is using group invite links they have the same problem Skiff does.

What I would like to exist is something like Subresource Integrity [1] but for a URL itself, so that you could include a hash in a URL and let the browser warn you if the page source doesn't match the hash.

1. https://developer.mozilla.org/en-US/docs/Web/Security/Subres...




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

Search: