4 ms·

I run Signal on GrapheneOS and find this comment incorrect and borderline offensive.

lmm 6y ago
I see that Signal no longer depends on Google Play Services specifically. However it's still the case that it depends on proprietary Google code (it just includes that code in its own APK now) and still can't practically be installed without auto-update (again, it just includes that in its APK).
- tga_d 6y ago
  The "proprietary Google code" is a library with a well defined API, you can see what it has access to. I agree that Signal should take it out, but it's not an especially big deal from a security perspective. The auto update functionality just tells you that an update is available, you can choose not to install it. You can also independently verify that the sha256 sum matches the one given on the website, and that the binary that sha256 sum corresponds to is produced via the reproducible build instructions. There are occasional bugs (I'd estimate a couple times a year, though it's less and less frequent) that causes the reproducible build to not match the provided build, and it's quickly noticed by someone and an issue opened in the issue tracker. If there were no explanation or no quick resolution, people would publicly raise a stink about it.
  - xorcist 6y ago
    > you can choose not to install it There is a time bomb in there and servers will kick you out regularly unless you have updated. If you get a patched client running you could probably change whatever string is required but some sort of action is required on the client side.
    - tga_d 6y ago
      Sure, but that's an unrelated phenomenon to the security implications being discussed. The argument against auto-updates is "it's running code without my permission or ability to audit first"; putting a recency requirement for client-server communication doesn't impact that concern, and I don't see any reason why it would be considered a bad thing.
      - lmm 6y ago
        > The argument against auto-updates is "it's running code without my permission or ability to audit first"; putting a recency requirement for client-server communication doesn't impact that concern It makes it impractical to actually audit the code you're running, because you're forced to re-audit on Signal's schedule. And it makes those audits mostly meaningless: what are you going to do if you decide a given code change is suspicious? You can't keep using the version of the code you were happy with, so you'd better have a plan in place for moving off Signal quickly - but in that case how much can you gain from using it at all?

lmm 6y ago

I see that Signal no longer depends on Google Play Services specifically. However it's still the case that it depends on proprietary Google code (it just includes that code in its own APK now) and still can't practically be installed without auto-update (again, it just includes that in its APK).

tga_d 6y ago
The "proprietary Google code" is a library with a well defined API, you can see what it has access to. I agree that Signal should take it out, but it's not an especially big deal from a security perspective. The auto update functionality just tells you that an update is available, you can choose not to install it. You can also independently verify that the sha256 sum matches the one given on the website, and that the binary that sha256 sum corresponds to is produced via the reproducible build instructions. There are occasional bugs (I'd estimate a couple times a year, though it's less and less frequent) that causes the reproducible build to not match the provided build, and it's quickly noticed by someone and an issue opened in the issue tracker. If there were no explanation or no quick resolution, people would publicly raise a stink about it.
- xorcist 6y ago
  > you can choose not to install it There is a time bomb in there and servers will kick you out regularly unless you have updated. If you get a patched client running you could probably change whatever string is required but some sort of action is required on the client side.
  - tga_d 6y ago
    Sure, but that's an unrelated phenomenon to the security implications being discussed. The argument against auto-updates is "it's running code without my permission or ability to audit first"; putting a recency requirement for client-server communication doesn't impact that concern, and I don't see any reason why it would be considered a bad thing.
    - lmm 6y ago
      > The argument against auto-updates is "it's running code without my permission or ability to audit first"; putting a recency requirement for client-server communication doesn't impact that concern It makes it impractical to actually audit the code you're running, because you're forced to re-audit on Signal's schedule. And it makes those audits mostly meaningless: what are you going to do if you decide a given code change is suspicious? You can't keep using the version of the code you were happy with, so you'd better have a plan in place for moving off Signal quickly - but in that case how much can you gain from using it at all?