3 ms·

> The messages are mine, not theirs, and yet they refuse to allow me to handle them how I deem fit. "They refuse to allow me" meaning "they don't add the featu

by palata 1y ago

> The messages are mine, not theirs, and yet they refuse to allow me to handle them how I deem fit. "They refuse to allow me" meaning "they don't add the features I want for free to the app they provide for free, so I complain". The messages are yours, of course. But don't forget that you use their work for free. If you're not happy, go use the free work of someone else, I guess?

Y-bar 1y ago
They are somewhat correct though, Signal has written code explicitly to prevent iOS users from including Signal data in Apple’s encrypted local and/or cloud backups. Allowing encrypted backups was free for Signal, but they spent time and money to prevent it for iOS users. Part of the code the wrote to prevent backups in question: https://github.com/signalapp/Signal-iOS/blob/5590f09c3643f12cb1b774821051e965bb34e99b/SignalServiceKit/Util/OWSFileSystem.swift#L115-L138 https://github.com/signalapp/Signal-iOS/blob/5590f09c3643f12...
- palata 1y ago
  It would be interesting to have Signal's justification for that, but I can totally imagine that it is a security feature. As in: they may not want their users to inadvertently share their Signal messages with Apple.
  - Y-bar 1y ago
    Lot's of people have requested justification in related Github issues there, but Signal has not given a clear answer. If there was a security problem with the encryption process I believe a CVE or similar would have been in order because it would affect millions of users.
    - palata 1y ago
      I was not talking about a security flaw. I was saying that maybe, Signal did not want to push their users to trust the Apple backup by default. Signal is a nonprofit foundation, it's not like they are trying to squeeze their users with their own secure backup.
      - Y-bar 1y ago
        We are unfortunately rehashing the same arguments from Github, nothing prevents Signal from distrusting Apple by default. But there is also nothing (except for some secret reason they refuse to elaborate) that prevents them from allowing users to actively chose to trust Apple. Except for their own internal reasons, that is. It's the user's data after all. The user should be able to control and access it. Sensible defaults makes sense, but the outright refusal to explain why they prevent it is very odd. I have a decent "IT hygiene", I keep my operating system updated with patches, I don't download pirated/cracked software, I have hardware-enabled encryption on my storage devices, I have a good password for my local account, I encrypt my local iPhone backups. Why should I not be allowed to include my Signal chats in those local backups? Signal has never answered that question, which is very strange.
        palata 1y ago
        > Why should I not be allowed to Same as I said above: you are asking for a new feature. Their default is those 20 lines that "protect" the files. If they want to offer you a way to still enable it, someone has to do it. Someone has to work on the UX of it, maybe there is a need to explain to the users why it is less secure when this feature is enabled, and then there is work to do with the criticisms that will come next time someone shoots themselves in the foot because of this feature (because "Signal shouldn't have allowed that in the first place"). I know, you will say "it's not much". But everybody asks for their "small feature", and projects generally can't do everything that everybody asks them to do (and usually for free). I find it totally valid if they choose that they won't offer features to lower their security, and instead they will work on features having sufficiently good security. Which in this case is the secure backup.
        Y-bar 1y ago
        > you are asking for a new feature I think we have vastly different definitions of what is a "new" feature. This is not about adding a new feature, but removing an old bug. > If they want to offer you a way to still enable it, someone has to do it. They can just use the iOS system settings to allow users to enable/disable backups. This would be zero code needed. Zero maintainability problems. Zero UX. Zero unexpected data loss for customers. The settings for this is for all sane apps at Manage Storage > Backups > [Device Name] > [App Name]. > I know, you will say "it's not much". But everybody asks for their "small feature" It's less than anything, it's removing a "feature", which should make things easier to maintain. Signal _added_ the "feature" to disable the default iOS behaviour that user data can be backed up securely. This caused, in many users life, a bug of unexpected data loss. Signal caused that bug and that data loss by introducing this "feature". Again, fixing this bug would not require a new feature to be added, but rather an unwanted bug to be removed by removing code needed to maintain it. > I find it totally valid if they choose that they won't offer features to lower their security, and instead they will work on features having sufficiently good security. Which in this case is the secure backup. Not a single argument has been given why this would be more secure than the locally encrypted backup you can do yourself in iOS. In fact, it would be sane to suggest that any newly introduced claimed secure system is insecure until tested. -- Edit: It's also worth noting that their disable-backups feature is a bit hack:y (see https://blog.eidinger.info/prevent-your-apps-files-from-being-included-in-icloud-backup#heading-important-facts-to-know-about-this-api https://blog.eidinger.info/prevent-your-apps-files-from-bein...)

by palata 1y ago

Y-bar 1y ago

They are somewhat correct though, Signal has written code explicitly to prevent iOS users from including Signal data in Apple’s encrypted local and/or cloud backups. Allowing encrypted backups was free for Signal, but they spent time and money to prevent it for iOS users. Part of the code the wrote to prevent backups in question: https://github.com/signalapp/Signal-iOS/blob/5590f09c3643f12cb1b774821051e965bb34e99b/SignalServiceKit/Util/OWSFileSystem.swift#L115-L138 https://github.com/signalapp/Signal-iOS/blob/5590f09c3643f12...

palata 1y ago
It would be interesting to have Signal's justification for that, but I can totally imagine that it is a security feature. As in: they may not want their users to inadvertently share their Signal messages with Apple.
- Y-bar 1y ago
  Lot's of people have requested justification in related Github issues there, but Signal has not given a clear answer. If there was a security problem with the encryption process I believe a CVE or similar would have been in order because it would affect millions of users.
  - palata 1y ago
    I was not talking about a security flaw. I was saying that maybe, Signal did not want to push their users to trust the Apple backup by default. Signal is a nonprofit foundation, it's not like they are trying to squeeze their users with their own secure backup.
    - Y-bar 1y ago
      We are unfortunately rehashing the same arguments from Github, nothing prevents Signal from distrusting Apple by default. But there is also nothing (except for some secret reason they refuse to elaborate) that prevents them from allowing users to actively chose to trust Apple. Except for their own internal reasons, that is. It's the user's data after all. The user should be able to control and access it. Sensible defaults makes sense, but the outright refusal to explain why they prevent it is very odd. I have a decent "IT hygiene", I keep my operating system updated with patches, I don't download pirated/cracked software, I have hardware-enabled encryption on my storage devices, I have a good password for my local account, I encrypt my local iPhone backups. Why should I not be allowed to include my Signal chats in those local backups? Signal has never answered that question, which is very strange.
      - palata 1y ago
        > Why should I not be allowed to Same as I said above: you are asking for a new feature. Their default is those 20 lines that "protect" the files. If they want to offer you a way to still enable it, someone has to do it. Someone has to work on the UX of it, maybe there is a need to explain to the users why it is less secure when this feature is enabled, and then there is work to do with the criticisms that will come next time someone shoots themselves in the foot because of this feature (because "Signal shouldn't have allowed that in the first place"). I know, you will say "it's not much". But everybody asks for their "small feature", and projects generally can't do everything that everybody asks them to do (and usually for free). I find it totally valid if they choose that they won't offer features to lower their security, and instead they will work on features having sufficiently good security. Which in this case is the secure backup.
        Y-bar 1y ago
        > you are asking for a new feature I think we have vastly different definitions of what is a "new" feature. This is not about adding a new feature, but removing an old bug. > If they want to offer you a way to still enable it, someone has to do it. They can just use the iOS system settings to allow users to enable/disable backups. This would be zero code needed. Zero maintainability problems. Zero UX. Zero unexpected data loss for customers. The settings for this is for all sane apps at Manage Storage > Backups > [Device Name] > [App Name]. > I know, you will say "it's not much". But everybody asks for their "small feature" It's less than anything, it's removing a "feature", which should make things easier to maintain. Signal _added_ the "feature" to disable the default iOS behaviour that user data can be backed up securely. This caused, in many users life, a bug of unexpected data loss. Signal caused that bug and that data loss by introducing this "feature". Again, fixing this bug would not require a new feature to be added, but rather an unwanted bug to be removed by removing code needed to maintain it. > I find it totally valid if they choose that they won't offer features to lower their security, and instead they will work on features having sufficiently good security. Which in this case is the secure backup. Not a single argument has been given why this would be more secure than the locally encrypted backup you can do yourself in iOS. In fact, it would be sane to suggest that any newly introduced claimed secure system is insecure until tested. -- Edit: It's also worth noting that their disable-backups feature is a bit hack:y (see https://blog.eidinger.info/prevent-your-apps-files-from-being-included-in-icloud-backup#heading-important-facts-to-know-about-this-api https://blog.eidinger.info/prevent-your-apps-files-from-bein...)