5 ms·

This underscores why it’s important to allow third party clients to connect. When only the first-party client is allowed, the failings of its UI drag down the c

This underscores why it’s important to allow third party clients to connect. When only the first-party client is allowed, the failings of its UI drag down the core, too — it doesn’t matter how good the core is if it’s permanently mated to a half-baked UI.

rakoo 5y ago
And when third parties can connect, the protocol can't evolve because every change becomes "good to simplement" but it takes an enormous amount of time, resources And influence to change to "mandatory to implement". As always it's a delicate balance between security And ease of use, and Signal has always been up front in favoring the former.
- nmlt 5y ago
  That would be the case if they’d standardize the signal protocol. Letting third parties connect has nothing to do with that. Signal can still change their API any time they want.
  - retrac 5y ago
    And Microsoft could in principle choose to do a hard break with all backwards compatibility in the next version of Windows. But they won't. Eventually, the third-party base may be so large and varied, that it becomes quite painful to actually make such a change even if the letter of the law says you can.
    - lwhi 5y ago
      In which world does Microsoft conform to open standards or protocols? Your point simply doesn't make sense.
      - NateEag 5y ago
        Microsoft's Windows APIs are, in some sense, an "open platform". They don't accept third party contributions, but they are thoroughly documented and their whole purpose is to support third party developers. Because that's their goal, they won't ever break that backwards compatibility. That, I think, is what the GP was getting at - the Signal team does not want to wind up being constrained in the ways that MS is by supporting third-party developers. Making their protocol an open standard would have that effect, because they could no longer unilaterally change the protocol as they see fit. They would be constrained by the need to support and think about all the other stakeholders who rely on the standard. If you control the client, the server, and the internal-only standard, in really bad situations, you can just push out an update that fixes the apocalypse in a backwards-incompatible way and drop support for all previous clients. This is not hypothetical - see the KRACK attack from 2017 for an example where an open standard was found to have a security flaw (https://www.krackattacks.com/ https://www.krackattacks.com/). We all got very lucky that the flaw could be mitigated in a backwards-compatible way.
        retrac 5y ago
        Yes, this is about right. I was struggling to express the idea. Thank you. Win32 is an open API in a certain sense. Of course it's not open as in open source as in consensus and cooperative standards as in FLOSS, at all. But. It's well documented. Anyone can target it. It's stable. Textbooks on Windows Vista programming 15 years ago are almost completely applicable to Windows 10 development. Even software that was targeted at a reasonable subset of the Windows 95 API, whether binary or source, is still going to run on Windows 11 without change in many cases. You get notice of what parts of the API they're gonna break in the next version (usually) too. In the olden days this was an "open platform" meant, usually. It's what the open in OpenWindows, OpenUnix, OpenStep was about. An open API. As opposed to a possibly undocumented, unstable API you only used under special contract and arrangement with the supplier. Often there was no actual prohibition (legal or technical) but there'd be no support. And it'd break randomly without notice. As you say, it's a potentially enormous commitment, and organizational issue, to provide that sort of long-term API stability. And you can box yourself in regarding development and design choices.
  - rakoo 5y ago
    I replied in another comment, but letting third parties connect widens the surface area of the potential attacks. If that bug happened in a third party, from a security pov you must block them from accessing the service, at which point you need to decide if you want to police every single possible client or focus on one and make it widespread.
- deleted 5y ago
  [deleted]
- sschueller 5y ago
  This doesn't have to be the case. Look at how stripe does it with their API which would be a disaster if older versions just stopped working. Versioning is doable even with chat apps.
  - rakoo 5y ago
    But Signal isn't just a chat app, it's an app with a very strong focus on security, and you can't have backward compatibility with security. Otherwise you end up with some servers still implementing SSLv3 years after its due date, or GPG with settings that make it insecure by default. You must force everyone in the ecosystem to use the latest version of the API, but even that is not enough: if there's an issue with the client (the issue in the article could happen with a third party) you must find a way to force it to upgrade; if they dont want to it's better to block them, but at this point if you need to choose where to best spend your resources you might as well block everyone else. Opening the service to other clients widens the potential surface area of attacks. It must be considered with a lot of care.
    - dane-pgp 5y ago
      > You must force everyone in the ecosystem to use the latest version of the API Couldn't Signal just announce a "flag day"[0] in advance and say that their servers would block connections from clients that don't support a specific version of the API by that date? For non-essential upgrades, the API change should be announced well in advance, but client developers might be given just a few days notice before security patches become mandatory. (Given the circumstances of this bug, though, perhaps several months of leeway would be more fair). [0] https://en.wikipedia.org/wiki/Flag_day_%28computing%29 https://en.wikipedia.org/wiki/Flag_day_%28computing%29
      - rakoo 5y ago
        They could, but again it's not just about the API, the client itself must also be secue enough. That means enforcing security in some way to third parties, or just blocking them until they've solved all issues. And in practice if you let people migrate at their own pace they just won't migrate until clients complain.
lwhi 5y ago
I'd go further than this. It underscores why open standards and protocols are essential for a more secure world.
ViViDboarder 5y ago
With this party clients, you don’t avoid this. The failings of a third party client will still reflect on the whole of the core product as well. Articles would still talk about a bug like this breathing a Signal issue, even if limited to a third party app. Additionally, I find it quite a stretch to call the app “half-baked”. I think it’s pretty great.
- remirk 5y ago
  I don't see this happening. As long as the app that's buggy doesn't have more than 33% market share I doubt the media would write it down as the system as a whole having the bug. Thought I am disappointed by lazy tech articles by otherwise good media regularly.

rakoo 5y ago

And when third parties can connect, the protocol can't evolve because every change becomes "good to simplement" but it takes an enormous amount of time, resources And influence to change to "mandatory to implement". As always it's a delicate balance between security And ease of use, and Signal has always been up front in favoring the former.

nmlt 5y ago
That would be the case if they’d standardize the signal protocol. Letting third parties connect has nothing to do with that. Signal can still change their API any time they want.
- retrac 5y ago
  And Microsoft could in principle choose to do a hard break with all backwards compatibility in the next version of Windows. But they won't. Eventually, the third-party base may be so large and varied, that it becomes quite painful to actually make such a change even if the letter of the law says you can.
  - lwhi 5y ago
    In which world does Microsoft conform to open standards or protocols? Your point simply doesn't make sense.
    - NateEag 5y ago
      Microsoft's Windows APIs are, in some sense, an "open platform". They don't accept third party contributions, but they are thoroughly documented and their whole purpose is to support third party developers. Because that's their goal, they won't ever break that backwards compatibility. That, I think, is what the GP was getting at - the Signal team does not want to wind up being constrained in the ways that MS is by supporting third-party developers. Making their protocol an open standard would have that effect, because they could no longer unilaterally change the protocol as they see fit. They would be constrained by the need to support and think about all the other stakeholders who rely on the standard. If you control the client, the server, and the internal-only standard, in really bad situations, you can just push out an update that fixes the apocalypse in a backwards-incompatible way and drop support for all previous clients. This is not hypothetical - see the KRACK attack from 2017 for an example where an open standard was found to have a security flaw (https://www.krackattacks.com/ https://www.krackattacks.com/). We all got very lucky that the flaw could be mitigated in a backwards-compatible way.
      - retrac 5y ago
        Yes, this is about right. I was struggling to express the idea. Thank you. Win32 is an open API in a certain sense. Of course it's not open as in open source as in consensus and cooperative standards as in FLOSS, at all. But. It's well documented. Anyone can target it. It's stable. Textbooks on Windows Vista programming 15 years ago are almost completely applicable to Windows 10 development. Even software that was targeted at a reasonable subset of the Windows 95 API, whether binary or source, is still going to run on Windows 11 without change in many cases. You get notice of what parts of the API they're gonna break in the next version (usually) too. In the olden days this was an "open platform" meant, usually. It's what the open in OpenWindows, OpenUnix, OpenStep was about. An open API. As opposed to a possibly undocumented, unstable API you only used under special contract and arrangement with the supplier. Often there was no actual prohibition (legal or technical) but there'd be no support. And it'd break randomly without notice. As you say, it's a potentially enormous commitment, and organizational issue, to provide that sort of long-term API stability. And you can box yourself in regarding development and design choices.
- rakoo 5y ago
  I replied in another comment, but letting third parties connect widens the surface area of the potential attacks. If that bug happened in a third party, from a security pov you must block them from accessing the service, at which point you need to decide if you want to police every single possible client or focus on one and make it widespread.
deleted 5y ago
[deleted]
sschueller 5y ago
This doesn't have to be the case. Look at how stripe does it with their API which would be a disaster if older versions just stopped working. Versioning is doable even with chat apps.
- rakoo 5y ago
  But Signal isn't just a chat app, it's an app with a very strong focus on security, and you can't have backward compatibility with security. Otherwise you end up with some servers still implementing SSLv3 years after its due date, or GPG with settings that make it insecure by default. You must force everyone in the ecosystem to use the latest version of the API, but even that is not enough: if there's an issue with the client (the issue in the article could happen with a third party) you must find a way to force it to upgrade; if they dont want to it's better to block them, but at this point if you need to choose where to best spend your resources you might as well block everyone else. Opening the service to other clients widens the potential surface area of attacks. It must be considered with a lot of care.
  - dane-pgp 5y ago
    > You must force everyone in the ecosystem to use the latest version of the API Couldn't Signal just announce a "flag day"[0] in advance and say that their servers would block connections from clients that don't support a specific version of the API by that date? For non-essential upgrades, the API change should be announced well in advance, but client developers might be given just a few days notice before security patches become mandatory. (Given the circumstances of this bug, though, perhaps several months of leeway would be more fair). [0] https://en.wikipedia.org/wiki/Flag_day_%28computing%29 https://en.wikipedia.org/wiki/Flag_day_%28computing%29
    - rakoo 5y ago
      They could, but again it's not just about the API, the client itself must also be secue enough. That means enforcing security in some way to third parties, or just blocking them until they've solved all issues. And in practice if you let people migrate at their own pace they just won't migrate until clients complain.

lwhi 5y ago

I'd go further than this. It underscores why open standards and protocols are essential for a more secure world.

ViViDboarder 5y ago

With this party clients, you don’t avoid this. The failings of a third party client will still reflect on the whole of the core product as well. Articles would still talk about a bug like this breathing a Signal issue, even if limited to a third party app. Additionally, I find it quite a stretch to call the app “half-baked”. I think it’s pretty great.

remirk 5y ago
I don't see this happening. As long as the app that's buggy doesn't have more than 33% market share I doubt the media would write it down as the system as a whole having the bug. Thought I am disappointed by lazy tech articles by otherwise good media regularly.