5 ms·

This is an issue from 2016, it's 2022 now and Signal works perfectly fine without Google Play Services. The .apk is there if you don't want to use Google Play S

by hiq 5y ago

This is an issue from 2016, it's 2022 now and Signal works perfectly fine without Google Play Services. The .apk is there if you don't want to use Google Play Store: https://signal.org/android/apk/ https://signal.org/android/apk/ and it prompts for updates when they're available.

dane-pgp 5y ago
Thank you for adding that context, which I should have included in my comment. I still think the issue from 2016 is worth reading, as the issue was closed on the basis of being a duplicate, but as a commenter on the issue points out: > Because all the refernced duplicate discussion threads trying to solve this are locked (why?), I'm raising my voice for this here. This is indicative of a project which not only resisted supporting users without Google Play services, but also resisted people questioning their decision. Two days after that plea, without any further explanation: > @signalapp locked and limited conversation to collaborators Of course an issue tracker isn't a discussion forum, but a good project team would have taken an extra couple of seconds to point issue reporters and commenters to an FAQ answer (assuming they had an answer that would withstand scrutiny). Anyway, my point is that despite the supposed merits of centralisation, people had to beg (and be met with silence) before the project deigned to grant this reasonable request. This is not the sort of permissionless innovation that free software is supposed to enable. Similarly, although Signal may have relented and made an .apk file available (perhaps due to pressure from more innovative and user-respecting platforms like Matrix), their stubbornness is still apparently preventing F-Droid from distributing it. Here's a better link to support that claim: https://forum.f-droid.org/t/signal-on-f-droid/13742/4 https://forum.f-droid.org/t/signal-on-f-droid/13742/4
- hiq 5y ago
  > Of course an issue tracker isn't a discussion forum, but a good project team would have taken an extra couple of seconds to point issue reporters and commenters to an FAQ answer (assuming they had an answer that would withstand scrutiny). I don't know what your experience with FOSS development is. I still have fairly little and only with low-profile projects, and yet I've already been accused of many things and spent (wasted?) quite some time in pointless arguments. This issue is exacerbated in high-profile projects such as Signal, and it's impossible to deal with them as you're suggesting. https://github.com/signalapp/Signal-Android/issues https://github.com/signalapp/Signal-Android/issues currently has close to 10000 issues (most of them closed). Signal does not have that many people to deal with what is mostly noise. There are explanations about their stances regarding F-Droid etc. if you're willing to look for them. In any case these questions belong to the community forum. Most of the duplicates are opened in bad faith, and there are diminishing returns in answering all of them. I recommend you "watch all activity" on one of the Signal client repository and check your GitHub notifications to understand the problem. > Anyway, my point is that despite the supposed merits of centralisation, people had to beg (and be met with silence) before the project deigned to grant this reasonable request. This is not the sort of permissionless innovation that free software is supposed to enable. You're talking about their development model (which is rather closed, a very high bar has to be reached for them to accept community contributions) rather than the fact that they're using a centralized rather than federated network. The article is about the latter, not the former. These issues are orthogonal.
  - dane-pgp 5y ago
    > There are explanations about their stances regarding F-Droid etc. if you're willing to look for them. Source(s): Dude trust me. > These issues are orthogonal. They are distinct issues, but not orthogonal. It wouldn't matter how Signal decided to run their "rather closed" open source software project if they allowed other people's forks to connect to their centralised network. By not allowing that, they have "weaponised" the "rather closed" development model against their own users, and, as a result, invalidated these bold claims made about why centralised networks are better. The benefit of Free Software is that it allows everyone (rather than a self-selected few) to add and remove features as they choose, and let users choose which fork they support. That creates a selective pressure towards genuine (user-centric) innovation, rather than changes that are declared to be innovation by fiat (excuse the pun). It also prevents the sort of stagnation (and potentially security problems) we saw when Internet Explorer had a 90% browser market share. There are very clear links between centralisation of design/control and a culture of closed source software development (with a non-transparent "we know better" attitude).
    - tptacek 5y ago
      It would matter a great deal if Signal allowed other people's forks to connect to their network, because they would lose the ability to deploy new privacy features. The whole point of Signal is that it consistently makes tradeoffs in favor of privacy and against UX. An "open" Signal network would immediately be dominated by clients making the opposite tradeoff, because users value good UX far more than they value privacy. This is pretty obvious, so much so that I'm immediately suspicious of people who believe it's some nefarious plot. You don't have to agree with it, and many people don't, but if you say you don't trust their intentions (with respect to this one issue), you're saying more about yourself than about Signal.
      - dane-pgp 5y ago
        > they would lose the ability to deploy new privacy features I disagree, in the sense that they could still produce their own client which had those new features (and use feature-detection to remain compatible with forks that support them), but you seem to be making a more subtle argument about market forces and group dynamics, which I want to understand better. What sort of tradeoffs do you think competing clients would make? I can't think of any way that weakening the privacy could improve the UX enough to make people want to abandon the official client (although I could see people abandoning the official client for a fork which doesn't include the crypto-coin, and all of its attack surface). The only example I can think of (trying to steelman your position as much as possible) is that other clients would remove the requirement for providing a phone number, and this would make it harder to do key verification somehow (and thus it would happen less often). I can't quite make that argument work, and I still think that not providing Signal with a phone number is a choice that users should be allowed to make based on their own assessment of the risks. Ultimately, though, Signal closing their network cannot make users safer, since their network isn't the only way to communicate. Users who don't like the UX (or unwanted features) of their client are free to install WhatsApp instead, or just use SMS, so I really don't accept the argument that restricting free software development leads to better privacy over all.

by hiq 5y ago

dane-pgp 5y ago

Thank you for adding that context, which I should have included in my comment. I still think the issue from 2016 is worth reading, as the issue was closed on the basis of being a duplicate, but as a commenter on the issue points out: > Because all the refernced duplicate discussion threads trying to solve this are locked (why?), I'm raising my voice for this here. This is indicative of a project which not only resisted supporting users without Google Play services, but also resisted people questioning their decision. Two days after that plea, without any further explanation: > @signalapp locked and limited conversation to collaborators Of course an issue tracker isn't a discussion forum, but a good project team would have taken an extra couple of seconds to point issue reporters and commenters to an FAQ answer (assuming they had an answer that would withstand scrutiny). Anyway, my point is that despite the supposed merits of centralisation, people had to beg (and be met with silence) before the project deigned to grant this reasonable request. This is not the sort of permissionless innovation that free software is supposed to enable. Similarly, although Signal may have relented and made an .apk file available (perhaps due to pressure from more innovative and user-respecting platforms like Matrix), their stubbornness is still apparently preventing F-Droid from distributing it. Here's a better link to support that claim: https://forum.f-droid.org/t/signal-on-f-droid/13742/4 https://forum.f-droid.org/t/signal-on-f-droid/13742/4

hiq 5y ago
> Of course an issue tracker isn't a discussion forum, but a good project team would have taken an extra couple of seconds to point issue reporters and commenters to an FAQ answer (assuming they had an answer that would withstand scrutiny). I don't know what your experience with FOSS development is. I still have fairly little and only with low-profile projects, and yet I've already been accused of many things and spent (wasted?) quite some time in pointless arguments. This issue is exacerbated in high-profile projects such as Signal, and it's impossible to deal with them as you're suggesting. https://github.com/signalapp/Signal-Android/issues https://github.com/signalapp/Signal-Android/issues currently has close to 10000 issues (most of them closed). Signal does not have that many people to deal with what is mostly noise. There are explanations about their stances regarding F-Droid etc. if you're willing to look for them. In any case these questions belong to the community forum. Most of the duplicates are opened in bad faith, and there are diminishing returns in answering all of them. I recommend you "watch all activity" on one of the Signal client repository and check your GitHub notifications to understand the problem. > Anyway, my point is that despite the supposed merits of centralisation, people had to beg (and be met with silence) before the project deigned to grant this reasonable request. This is not the sort of permissionless innovation that free software is supposed to enable. You're talking about their development model (which is rather closed, a very high bar has to be reached for them to accept community contributions) rather than the fact that they're using a centralized rather than federated network. The article is about the latter, not the former. These issues are orthogonal.
- dane-pgp 5y ago
  > There are explanations about their stances regarding F-Droid etc. if you're willing to look for them. Source(s): Dude trust me. > These issues are orthogonal. They are distinct issues, but not orthogonal. It wouldn't matter how Signal decided to run their "rather closed" open source software project if they allowed other people's forks to connect to their centralised network. By not allowing that, they have "weaponised" the "rather closed" development model against their own users, and, as a result, invalidated these bold claims made about why centralised networks are better. The benefit of Free Software is that it allows everyone (rather than a self-selected few) to add and remove features as they choose, and let users choose which fork they support. That creates a selective pressure towards genuine (user-centric) innovation, rather than changes that are declared to be innovation by fiat (excuse the pun). It also prevents the sort of stagnation (and potentially security problems) we saw when Internet Explorer had a 90% browser market share. There are very clear links between centralisation of design/control and a culture of closed source software development (with a non-transparent "we know better" attitude).
  - tptacek 5y ago
    It would matter a great deal if Signal allowed other people's forks to connect to their network, because they would lose the ability to deploy new privacy features. The whole point of Signal is that it consistently makes tradeoffs in favor of privacy and against UX. An "open" Signal network would immediately be dominated by clients making the opposite tradeoff, because users value good UX far more than they value privacy. This is pretty obvious, so much so that I'm immediately suspicious of people who believe it's some nefarious plot. You don't have to agree with it, and many people don't, but if you say you don't trust their intentions (with respect to this one issue), you're saying more about yourself than about Signal.
    - dane-pgp 5y ago
      > they would lose the ability to deploy new privacy features I disagree, in the sense that they could still produce their own client which had those new features (and use feature-detection to remain compatible with forks that support them), but you seem to be making a more subtle argument about market forces and group dynamics, which I want to understand better. What sort of tradeoffs do you think competing clients would make? I can't think of any way that weakening the privacy could improve the UX enough to make people want to abandon the official client (although I could see people abandoning the official client for a fork which doesn't include the crypto-coin, and all of its attack surface). The only example I can think of (trying to steelman your position as much as possible) is that other clients would remove the requirement for providing a phone number, and this would make it harder to do key verification somehow (and thus it would happen less often). I can't quite make that argument work, and I still think that not providing Signal with a phone number is a choice that users should be allowed to make based on their own assessment of the risks. Ultimately, though, Signal closing their network cannot make users safer, since their network isn't the only way to communicate. Users who don't like the UX (or unwanted features) of their client are free to install WhatsApp instead, or just use SMS, so I really don't accept the argument that restricting free software development leads to better privacy over all.