[HN Gopher] Tell HN: iOS Signal eats your disk space
___________________________________________________________________
Tell HN: iOS Signal eats your disk space
Signal on iOS will not free up any disk space when you delete chats
or media. You cannot see or clear usage in the app or in iOS
settings. There's a potential security problem where your data is
not actually being deleted when you delete chats. We are having no
luck getting the Signal team to acknowledge the issue. The ticket
was automatically closed despite activity.
https://github.com/signalapp/Signal-iOS/issues/4916 1. Be aware
that a large portion of your storage space might be stolen by
Signal. 2. Be aware that this might be a significant security
flaw. 3. If anyone can get Signal to pay attention rather than
closing repeated tickets as stale, that would be great.
Author : Waterluvian
Score : 53 points
Date : 2022-04-09 22:01 UTC (58 minutes ago)
| proactivesvcs wrote:
| 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...
| Strom wrote:
| That stale bot is quite the sight. It seems the Signal team has
| fully adopted the ostrich strategy for dealing with issues.
| xerxes901 wrote:
| 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.
| ______-_-______ wrote:
| 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.
| proactivesvcs wrote:
| Of the issues I've replied to, closed by the stale bot, they've
| been reopened.
| naoqj wrote:
| And still you shouldn't have had to reply to those issues to
| keep them open.
| proactivesvcs wrote:
| A small team with nearly 1000 open tickets needs a way to
| manage those issues which are genuinely stale.
| woodruffw wrote:
| 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.
| outsb wrote:
| 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.
| proactivesvcs wrote:
| 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.
| javajosh wrote:
| 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.)
| kitsunesoba wrote:
| 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.
| mikece wrote:
| 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.
| Silhouette wrote:
| I really wish there were better secure communications apps.
| Signal is good for encrypting messages/calls, which is the main
| feature I happen to care about personally. It's awful for keeping
| important communications safe, though, because it's deliberately
| tied to a single device that is highly likely to be broken or
| lost. There is still no sensible way for users to even export
| their Signal message history to another safe place as a backup,
| for whatever their personal definition of "safe" happens to be.
___________________________________________________________________
(page generated 2022-04-09 23:00 UTC)