7 ms·

While I suppose the protocol is not at fault and it's a UI and client bug it's still a huge problem. Just today I was thinking ”it's been weeks since they move

While I suppose the protocol is not at fault and it's a UI and client bug it's still a huge problem. Just today I was thinking ”it's been weeks since they moved the GIF button to a different place but there's still the old button at the old place and when you click on it there's a pop-up "wrong, the button is somewhere else now"”. Why even keep the old button in the old place ? And it led me to thinking "what else could be wrong/buggy in the UI and the UX that is not obvious to them ?". edit: according to this comment https://news.ycombinator.com/item?id=27951648 https://news.ycombinator.com/item?id=27951648 there is only one dev working on the Android client ? Hats off to that person, it's incredible. So I should have written: And it led me to thinking "what else could be wrong/buggy in the UI and the UX that they haven't had time to catch and fix yet ?".

kitsunesoba 5y ago
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.
  - 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.
mdoms 5y ago
This is the same app that only 6 months ago had an outage lasting more than a full day[0] - an outage that to my knowledge remains unexplained. The protocol is one thing but these clowns are obviously not careful or reliable engineers. [0] https://www.theverge.com/2021/1/17/22235707/signal-back-app-privacy-encrypted-outage https://www.theverge.com/2021/1/17/22235707/signal-back-app-...
- NateEag 5y ago
  Have you ever experienced millions of new users starting on your service in the space of a few days? Predicting the future is hard. Calling a team "clowns" because they didn't make the right guesses when they did capacity planning and had a day with downtime as a result of meteoric growth seems unfair to me.
deanCommie 5y ago
> Just today I was thinking ”it's been weeks since they moved the GIF button to a different place but there's still the old button at the old place and when you click on it there's a pop-up "wrong, the button is somewhere else now"”. That's actually a UX FEATURE. Google Maps did exactly the same thing when they reorganized and move the toggle between maps/satelite/traffic layers. The answer is pretty straightforward: Users get used to a certain UX. If you do a reorganization (to introduce new features, to improve performance, whatever), and move a button, a meaningful percentage of your users won't read the blog post, the release notes, or hunt for a new "Intuitive" location for the feature. They'll just assume you removed the feature and either panic or get mad. Leaving the old button in the old place is actually kind of a clever way to "Deprecate" a UX feature.
- johnchristopher 5y ago
  It has certainly not trained me to reach for the new way since it was introduced considering I strangely still reach for the usual and visible old way every time despite being treated with "lol, no". But I may be the exception.
- lostlogin 5y ago
  > Leaving the old button in the old place is actually kind of a clever way to "Deprecate" a UX feature. That would drive me demented in 5 minutes.
  - deanCommie 5y ago
    Which would force you to learn the location of the new feature, and in the next version the button would be gone.
- carstenhag 5y ago
  I agree. Am an app dev myself and the weird maps relayout of gestures got me dozens of times... Can't imagine how condused my mum or some not phone-savy person is.
- greysonp 5y ago
  Yep, this was the intent. It's a relatively common pattern. We kept it that way for a few releases so people could see it, and we removed the button in the latest release.

kitsunesoba 5y ago

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.
- 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.

mdoms 5y ago

This is the same app that only 6 months ago had an outage lasting more than a full day[0] - an outage that to my knowledge remains unexplained. The protocol is one thing but these clowns are obviously not careful or reliable engineers. [0] https://www.theverge.com/2021/1/17/22235707/signal-back-app-privacy-encrypted-outage https://www.theverge.com/2021/1/17/22235707/signal-back-app-...

NateEag 5y ago
Have you ever experienced millions of new users starting on your service in the space of a few days? Predicting the future is hard. Calling a team "clowns" because they didn't make the right guesses when they did capacity planning and had a day with downtime as a result of meteoric growth seems unfair to me.

deanCommie 5y ago

> Just today I was thinking ”it's been weeks since they moved the GIF button to a different place but there's still the old button at the old place and when you click on it there's a pop-up "wrong, the button is somewhere else now"”. That's actually a UX FEATURE. Google Maps did exactly the same thing when they reorganized and move the toggle between maps/satelite/traffic layers. The answer is pretty straightforward: Users get used to a certain UX. If you do a reorganization (to introduce new features, to improve performance, whatever), and move a button, a meaningful percentage of your users won't read the blog post, the release notes, or hunt for a new "Intuitive" location for the feature. They'll just assume you removed the feature and either panic or get mad. Leaving the old button in the old place is actually kind of a clever way to "Deprecate" a UX feature.

johnchristopher 5y ago
It has certainly not trained me to reach for the new way since it was introduced considering I strangely still reach for the usual and visible old way every time despite being treated with "lol, no". But I may be the exception.
lostlogin 5y ago
> Leaving the old button in the old place is actually kind of a clever way to "Deprecate" a UX feature. That would drive me demented in 5 minutes.
- deanCommie 5y ago
  Which would force you to learn the location of the new feature, and in the next version the button would be gone.
carstenhag 5y ago
I agree. Am an app dev myself and the weird maps relayout of gestures got me dozens of times... Can't imagine how condused my mum or some not phone-savy person is.
greysonp 5y ago
Yep, this was the intent. It's a relatively common pattern. We kept it that way for a few releases so people could see it, and we removed the button in the latest release.