3 ms·

The first commit that they omitted in April 2020 is related to the payment feature they just announced. So the two events coinciding (server code being publishe

by est31 6y ago

The first commit that they omitted in April 2020 is related to the payment feature they just announced. So the two events coinciding (server code being published and payment feature being announced) might not have been a coincidence. They apparently didn't want to bother creating a private test server running a private fork of the server code and just pushed their experiments to production, just not releasing the source code to prevent people from seeing the feature before an official announcement. They neccessarily built test client apps because I couldn't find any old commit mentioning payments in the client app git log. https://news.ycombinator.com/item?id=26718134 https://news.ycombinator.com/item?id=26718134

theptip 6y ago
This leaves a very bad taste in my mouth. Unclear how much practical damage this caused (how many security analysts are using the Signal server source to look for vulns?) but this is damaging to the project's claims of transparency and trustworthiness. It’s quite clear that this crypto integration provides a perverse incentive for the project that points in the opposite direction of security.
- ignoramous 6y ago
  It was called out as recently as 4 weeks ago [0] and was voted to the front-page but then weighted-out possibly incorrectly by mods (may be because the top comment is dismissive of concerns raised [1]?) before a discussion could flourish. cc: @dang [0] https://news.ycombinator.com/item?id=26345937 https://news.ycombinator.com/item?id=26345937 [1] The title is the only thing worth reading in this pile of speculation and hand waving.
- _dibly 6y ago
  Forgive me if this is a stupid question, but how exactly is that the case? It's been damaging to their claims of transparency for almost a year now, if anything this should be the first step in repairing that slight. How is dumping a year's worth of private work into your public repo somehow doing damage to their trustworthiness?
  - theptip 6y ago
    You're right that the damage to trustworthiness was always there. (I.e. they did the damage when they stopped publishing their source code, and they compounded that damage the longer they declined to publish their code). My point was more that the damage now seems to be directly attributable to the new payments integration. Prior to seeing this post, I was already concerned that adding a crypto/payments integration would damage the Signal project, and this appears to be an immediate example of the kind of harms/perverse incentives I was concerned about. (A counterargument to my theory here would perhaps be "Signal was always doing stuff like declining to publish their server code even prior to the payments integration", I'm not familiar enough with the history of the project to know the details there.)
    - _dibly 6y ago
      Reading the other article on HN definitely helped me understand more. I think really it comes down to me not understanding why they had so much trustworthiness to begin with. They've been obscuring their code for about a year and even then, it's not like Signal has always come out and said "we love the passion our fellow developers have for our commitment to privacy and security". They just let people sell their relatives on that promise and waited until they had a massive userbase to start monetizing their platform. Thanks for your reply, I just wonder where all this trustworthiness has been coming from for the last 12 months while they've been quietly working on the platform without publishing any changes. It feels like a beta tester for a game being mad that there were lootboxes in the full release of the game when they weren't in the beta. Even if you didn't know they were coming, you had to assume something like it was inevitable given enough traction.
      - mindslight 6y ago
        Signal's choices never really felt right, as their justifications tended towards authoritarian paternalism - eg willfull reliance on Play services, keeping it out of F-Droid (which while flawed as Signal pointed out, seems to be the best we currently have), bottleneck centralized servers, and phone numbers as primary identifiers (?!). But the standard Free Software development/distribution model does lack in some areas. And so Signal got a bunch of community leeway for going against the grain, in the hopes that a fresh approach would somehow bear fruit. We're now apparently seeing some of the fruit from that approach.
- kelnos 6y ago
  The server being or not being secure is only important to the people who operate it. You can examine the client code and see that your messages are encrypted end to end. Signal's entire security model revolves around the idea that you don't need to trust the server.
  - theptip 6y ago
    There's no concern about metadata leakage?
    - outime 6y ago
      Even if you have access to an up-to-date source code it doesn't guarantee at all they'd be running a completely different version if so they wish. I mean this have just happened yet this question kind of implies you'd still trust such entity to run the server from the source code you have access to. I hope this collective illusion dies already.
      - theptip 6y ago
        True, neither the absence of an identified vuln in published source code, nor the absence of published source code can guarantee that you don't have vulns. And sure, a bad-faith operator can always back-door the server and run different code. But, a good-faith operator can find and fix bugs faster if they operate in the open and in collaboration with the community. "Given enough eyeballs, all bugs are shallow" etc.

by est31 6y ago

theptip 6y ago

This leaves a very bad taste in my mouth. Unclear how much practical damage this caused (how many security analysts are using the Signal server source to look for vulns?) but this is damaging to the project's claims of transparency and trustworthiness. It’s quite clear that this crypto integration provides a perverse incentive for the project that points in the opposite direction of security.

ignoramous 6y ago
It was called out as recently as 4 weeks ago [0] and was voted to the front-page but then weighted-out possibly incorrectly by mods (may be because the top comment is dismissive of concerns raised [1]?) before a discussion could flourish. cc: @dang [0] https://news.ycombinator.com/item?id=26345937 https://news.ycombinator.com/item?id=26345937 [1] The title is the only thing worth reading in this pile of speculation and hand waving.
_dibly 6y ago
Forgive me if this is a stupid question, but how exactly is that the case? It's been damaging to their claims of transparency for almost a year now, if anything this should be the first step in repairing that slight. How is dumping a year's worth of private work into your public repo somehow doing damage to their trustworthiness?
- theptip 6y ago
  You're right that the damage to trustworthiness was always there. (I.e. they did the damage when they stopped publishing their source code, and they compounded that damage the longer they declined to publish their code). My point was more that the damage now seems to be directly attributable to the new payments integration. Prior to seeing this post, I was already concerned that adding a crypto/payments integration would damage the Signal project, and this appears to be an immediate example of the kind of harms/perverse incentives I was concerned about. (A counterargument to my theory here would perhaps be "Signal was always doing stuff like declining to publish their server code even prior to the payments integration", I'm not familiar enough with the history of the project to know the details there.)
  - _dibly 6y ago
    Reading the other article on HN definitely helped me understand more. I think really it comes down to me not understanding why they had so much trustworthiness to begin with. They've been obscuring their code for about a year and even then, it's not like Signal has always come out and said "we love the passion our fellow developers have for our commitment to privacy and security". They just let people sell their relatives on that promise and waited until they had a massive userbase to start monetizing their platform. Thanks for your reply, I just wonder where all this trustworthiness has been coming from for the last 12 months while they've been quietly working on the platform without publishing any changes. It feels like a beta tester for a game being mad that there were lootboxes in the full release of the game when they weren't in the beta. Even if you didn't know they were coming, you had to assume something like it was inevitable given enough traction.
    - mindslight 6y ago
      Signal's choices never really felt right, as their justifications tended towards authoritarian paternalism - eg willfull reliance on Play services, keeping it out of F-Droid (which while flawed as Signal pointed out, seems to be the best we currently have), bottleneck centralized servers, and phone numbers as primary identifiers (?!). But the standard Free Software development/distribution model does lack in some areas. And so Signal got a bunch of community leeway for going against the grain, in the hopes that a fresh approach would somehow bear fruit. We're now apparently seeing some of the fruit from that approach.
kelnos 6y ago
The server being or not being secure is only important to the people who operate it. You can examine the client code and see that your messages are encrypted end to end. Signal's entire security model revolves around the idea that you don't need to trust the server.
- theptip 6y ago
  There's no concern about metadata leakage?
  - outime 6y ago
    Even if you have access to an up-to-date source code it doesn't guarantee at all they'd be running a completely different version if so they wish. I mean this have just happened yet this question kind of implies you'd still trust such entity to run the server from the source code you have access to. I hope this collective illusion dies already.
    - theptip 6y ago
      True, neither the absence of an identified vuln in published source code, nor the absence of published source code can guarantee that you don't have vulns. And sure, a bad-faith operator can always back-door the server and run different code. But, a good-faith operator can find and fix bugs faster if they operate in the open and in collaboration with the community. "Given enough eyeballs, all bugs are shallow" etc.