1. It's not stolen. It's used. It may not be used efficiently (or, if you're correct, used sensibly at all) but it's not stolen.

2. If deleted data not being purged from your iOS device is a "significant security flaw" then you shouldn't be using a device from Apple or Google; your threat model is way beyond the two big players.

3. Hyperbolic comments[1] don't help issues being re-opened. Helpful comments, preferably with steps to reproduce, and a polite note that the issue is still current, will get the issue re-opened in my experience. Getting on your high horse and making silly claims would get you put to the bottom of the pile if it were my job.

[1] https://github.com/signalapp/Signal-iOS/issues/4916#issuecom...

It's not a hyperbolic comment. The Signal stale bot is bad and frustrates anybody contributing.

* I've reported NullPointerExceptions with stack traces, stale bot comes to close.

* I've reported Signal fatally corrupting its DB and losing all its data [1], stale bot comes to close.

Few things are more frustrating than investing your free time, and then finding an automated system pitted against you.

[1]: https://news.ycombinator.com/item?id=26841134, https://github.com/signalapp/Signal-Android/issues/11160#iss...

The most prominent red flag about Signal is that, for all its purported commitment to "developing open source privacy technology", a real, working open-source app is not on F-Droid.

https://forum.f-droid.org/t/we-can-include-signal-in-f-droid...

I don't think availability via any particular distribution mechanism is a reasonable litmus test for "open sourcedness." Such a test would have excluded Linux for most of its development history, prior to migration to git.

This particular distribution (F-Droid) requires that the source be build-able from strictly source files, without bundling binaries.

You can download the APK directly from Signal: https://signal.org/android/apk/

When a new version is released, the Signal app notifies you.

Problem is, the APK is a closed-source binary. What they include there might be completely different from what is in the source.

Not with reproducible builds, no.

I agree it can be frustrating; the bot does seem to need tweaking.

The first issue was only closed two days ago and presumably it'll be reopened since it's effectively by design. The second issue you linked was not closed at all, and in fact looks to be been acknowledged. I don't like to nit pick but this just proves that the statement is indeed hyperbole: the Signal devs are paying attention, tickets aren't always closed and when they are closed I almost always see them re-opened.

> The second issue you linked was not closed at all

The only reason it's not closed is because I kept replying!

Had I not succumbed to the bot, it would have likely been closed before the acknowledgement, and never been looked at again.

> Getting on your high horse and making silly claims would get you put to the bottom of the pile if it were my job.

I disagree strongly. It’s not up to us — as designers and developers and maintainers of software — to decide how users engage with us. If they engage at all they are doing us a favor.

Tone-policing user bug reports is a nasty anti-pattern, a predictable way to make your software more user-hostile. Unless they degenerate into outright abuse, which is obviously unacceptable (and this does not), we should separate tone from content and see if the content is useful. A substantive response to the content, ignoring the tone, is usually the best practice.

I understand the issues you have with the claims, but I would argue that this is still a security flaw, given that Signal and other encrypted chat apps are often used by journalists and activists that may have openly hostile governments. If I were choosing an app to message about something sensitive like protests, etc., I would be pretty uncomfy with the idea that deletion doesn't actually mean deletion, even if it's only local. Especially given recent news about Russian police (reportedly) demanding to search random citizens' phones on the street[1].

[1]: https://www.independent.co.uk/news/world/europe/ukraine-mosc...

It's unfair to target individuals in this manner. If it were to me, I'd judge your comment as "borderline trolling". The OP has mentioned something specific and brought it to the notice of a larger audience.

Eh, sometimes going hyperbolic does the trick, but yeah, it’s not the most beneficial tactic, overall

>Eh, sometimes going hyperbolic does the trick

When has it ever worked?

Except that these full time engineers are getting in $110K per year to ‘fix’ these issues.

There isn’t any excuse left from that $60M in funding to fix these issues is there?

Maybe they were too busy integrating a scam private cryptocurrency over fixing these bugs.

I agree, and I am curious why your comment was downvoted. They have turned crypto shills :-)

It also eats up disk space on macOS (and I assume every other desktop considering the client is the same), I've had to reinstall it multiple times now just to save almost a dozen gigabytes of space...

I'm not even an active signal user, I only have a few friends on there, I can only imagine what it's like for someone who uses signal as their only chat app, it must get crazy.

Disappearing messages (4 weeks etc.) help mitigate the problem a little bit from what I've noticed but it's nowhere near a complete solution.

Are you guys sending HD movies around or something? How is a chat app using dozens of gigabytes for message logs?

I semi-frequently send audio files to one of the aforementioned friends of mine, and that’s about it. Everything else is just images (which signal compresses to oblivion btw) and stickers.

The fact that there’s no way to view individual files that have been sent to/from me (+ their sizes) and remove them—like there is for messages.app in macOS—makes troubleshooting even harder here.

I will admit though that I haven’t looked too far into the problem but it’s seems to be an issue that just about every signal user I know deals with.

This is a real pain on desktop. I've taken to try to remember to delete files I've sent/received straight away if I don't need them.

Signal seems increasingly like a Tesla in the chat space, where certain parts of the product are excellent (E2E encryption and battery/drivetrain, respectively) but everything else sits between mediocre and bad, and the bad parts are rarely acknowledged or improved upon. Disappointing.

The chief distinction being that Signal is a nonprofit foundation with a revenue measured in millions of dollars[1], while Tesla's market cap is over $1T. There are comparatively few excuses Tesla can make that can simultaneously justify that kind of speculative valuation.

[1]: https://en.wikipedia.org/wiki/Signal_Foundation

Tesla does not need to justify it's valuation. That's set by shareholders.

I think you misread my comment. I'm not asking for Tesla's justification; I'm expressing my own view that the market's valuation of Tesla is excessive. You're welcome to disagree, but the underlying point remains: Tesla is fundamentally not resource-constrained in the way Signal is.

This isn’t great in terms of storage waste, but I don’t think this is a “significant” security risk for the average user: most users should have both iOS FDE enabled and Signal’s own DB is encrypted (with a stored key, but accessing that key requires ACE, which is already a “game over” condition).

If you want guaranteed deletion (modulo screenshots), you should probably use timed/self-destructing messages. That’s what they’re there for.

Full access to be device isn’t a “game over” scenario if the content is no longer on the device at all. The lack of this deletion feature means that something like WhatsApp is much more secure against certain threat scenarios.

Signal is a nice entry into encrypted chat. The fast signup makes it easy for me to recommend it. I prefer to use Wire, Threema, or Element but concede that too few people really care about private chat. This issue of Signal gobbling up storage space is an issue, possibly enough to gift licenses for Threema to the people with whom I chat the most.

Threema's protocol doesn't even implement forward secrecy. From a security standpoint Threema is closer to iMessage than to Signal or other Signal-protocol-based messengers.

These bots that close issues automatically because of lack of activity are so frustrating. It doesn’t take much time for a human to do the same and you don’t lack respect to your users. What are the benefits? A virtually smaller list of issues? It’s not because they are closed that they don’t exist.

not sure if you already read this, but there was a discussion about these bots here a while ago

https://news.ycombinator.com/item?id=28998374

They should not have closed the bug, but you have an opportunity to put on your hacker hat and take control of your device storage! Do you know how to attach a debugger to an iOS process? If necessary, could you fork the client, modify and install it locally? Do you know how to find out which files are taking up all the space, and delete them, from inside the process? (It's actually one reason I prefer Android because although I'm not an Android dev, I want (need?) to be able to do all of these things on my own devices.)

I don’t see this behavior on either my iPad or iPhone. They both are using about 12 MB of document storage space. I’ve been using Signal for years. My chats all expire in 1 hour, perhaps that feature delete’s correctly. Note: Twitter, on the other hand, is using over a gigabyte of local storage for some strange reason.

Signal is open source, maybe somebody can go in and fix it if there is a problem. I suppose if someone’s extremely paranoid they could just simply delete the app and reinstall. Though Signal does do some strange replication of data I have never understood, because I’ve installed it on a laptop and saw it pull down a bunch of chat history that I thought I had deleted, but still couldn’t see in the app.

Wire, and Threema seem to be much better than Signal.

Telegram, too. I know its not the favourite of this community here, but it offers everything else that these clients can't even imagine.

That stale bot is quite the sight. It seems the Signal team has fully adopted the ostrich strategy for dealing with issues.

Nothing infuriates me more than googling for a problem I’m having and finding a relevant issue that’s been closed by a bot as “stale”.

I _get_ that I don’t have any right to free maintenance, but the stale bot paints some veneer of process around a maintainer thinking “issue looks hard, doesn’t affect me, so I don’t care”. I would just so much prefer them to be honest and just say that rather than passive-aggressively send me emails every 30 days warning that my issue is becoming stale or whatever.

I thought stalebot was supposed to back down if people were commenting. But this time it added a "wontfix" tag right away, ignored the humans and closed the issue anyway. The scourge is getting worse.

It's not even about expecting free development and fixes, it's about mutual respect.

I respect that a developer doesn't have to fix an issue I report, but it's only fair that the time I spent on gathering information and reporting the issue is respected. It should be triaged, valid reports should be marked as such and if it's never gonna be dealt with then it should be closed.

Not some kind of software development equivalent of stringing someone along as a side b***ch.

I'd prefer they just leave them alone and open.

This sort of "ADHD-driven development" that heavily biases towards novelty and ease over quality and stability is a real problem with a lot of software today.

Of the issues I've replied to, closed by the stale bot, they've been reopened.

And still you shouldn't have had to reply to those issues to keep them open.

A small team with nearly 1000 open tickets needs a way to manage those issues which are genuinely stale.

It's called triaging your tickets, not letting a bot roam free hoping to catch someone that didn't press a button at the right time.

It's disrespectful to the reporters' time and effort to keep pestering them with an inane bot. It doesn't fix the issues reported. It just makes the bot owner feel good that they have fewer tickets open.

I agree on most of your points but triaging requires resources - setting up a bot to quickly close stale issues is a poor stopgap but it seems they felt they had to do something.

Why not? It seems like a reasonable way to prioritize fixing issues that people actually care about.

Signal's insistence on doing the wrong thing for 99% of users (storing media blobs in SQLite) drives me crazy. Protect our metadata over the wire, fine, but there is almost no additional protective benefit whatsoever by storing the files inside SQLCipher when the user's fingers can be broken one-by-one until they unlock their phone.

Meanwhile it causes issues just like this, not to mention broken integration with every audio/gallery/video app on the device.

Accusing them of doing the "wrong thing for 99% of their users" is pretty hyperbolic. They've managed the feat of offering simple, easy E2EE for messages, audio and video calls for one-to-one and groups, without charging anyone a penny for it. Their protocol is so successful it's been adopted by others and is often considered a gold standard.

Having used SQLCipher myself for an app I created, I've often thought about the tradeoffs between security and convenience. I struggle to see how the only benefit to using SQLCipher to encrypt the stored data is to try to protect against someone breaking someone's fingers and forcing someone to give up their password.

Do you not think there are other, much less violent, ways for someone to read an unencrypted database on a phone?

The files on disk are already encrypted (or at least are encryptable: there is a flag the developer can technically turn off), remember, by iOS itself; this is an additional layer of what I'd think really amounts to nothing more than "obfuscation" added by the application (unless the app itself has to be separately unlocked each time you use it--to prevent this key from being stored on disk--which I don't think is true of Signal? or, if it is, is not how that user is clearly using it). The concept of SQLCipher makes the most sense as part of some (evil) defense-in-depth DRM scheme, with the goal of preventing the owner of the phone from getting access to data that is "for developer eyes only", which is how I swear I most often had seen it used. (It is also fine for encrypting data files in transit, or putting passwords on specific files; which, of course, fits perfectly with sqlite being used as an app-specific file format, but that definitely isn't the case for here.)

> The files on disk are already encrypted (or at least are encryptable: there is a flag the developer can technically turn off), remember, by iOS itself;

Just to clarify on this, I had been thinking that the user had to opt into full disk encryption on iOS, does it come enabled by default?

> (unless the app itself has to be separately unlocked each time you use it--to prevent this key from being stored on disk--which I don't think is true of Signal? or, if it is, is not how that user is clearly using it)

At least for the way I use Signal on iOS, the screen can lock and be unlocked by Face ID, but yes, no separate key I have to enter to unlock the SQLCipher database.

So yeah, maybe it doesn't add too much to the current implementation, especially if files are encrypted by default by iOS. If not, then I can see the benefit in adding the "well the device isn't encrypted but at least the Signal files are."

For my case, it was more like this:

> or putting passwords on specific files; which, of course, fits perfectly with sqlite being used as an app-specific file format, but that definitely isn't the case for here.

I built an app for micro-journaling about how I was feeling and I wanted it to be super private, so, at the time, it was local-only and stored the data in a SQLCipher database. The user had to enter a password each time to enter the app and unlock the database, AFAIK, I coded it so the password wasn't stored anywhere.

Yes, the idea was defense in depth, maybe too intense at the time and maybe even less necessary now that more phones seem to have full encryption than they did in 2012-14 when I was making this.

Anyway, I'm grateful for your insight—thank you!

> I had been thinking that the user had to opt into full disk encryption on iOS, does it come enabled by default?

Full disk encryption (called Data Protection on iOS) is enabled as long as a passcode is set. This has been the case since what, iOS 4?

AFAIK the storage is encrypted using (a key derived from) a unique device key in the secure enclave and thus the storage is tied to the physical device. Further keys are generated using the Passphrase and the unique device key, so they are tied to the user and the device.

The application can chose per file:

* Encrypted when locked: NSFileProtectionComplete

* Encrypted until first unlock: NSFileProtectionCompleteUntilFirstUserAuthentication

* Encrypted unless used by the applications background tasks: NSFileProtectionCompleteUnlessOpen

I think the keys used for file encryption are unique per application and then again per file, but I didn’t find information on this.

I appreciate you both providing more info on this. It seems iOS is much more encrypted than I had thought it was. Still, if I resurrect the micro-journaling app, I'll probably keep an app-specific password and SQLCipher to add that extra layer of protection.