Hacker News Reader

Comment by johnchristopher | Hacker News Reader

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

View on HN

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

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.

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.

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

Which would force you to learn the location of the new feature, and in the next version the button would be gone.

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.

Yeah, I actually like this UI feature. I would have been very frustrated if they had just changed it over on Google Maps. I use Timeline all the time and it was important to me.

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.

I'd go further than this.

It underscores why open standards and protocols are essential for a more secure world.

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.

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.

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.

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.

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.

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.

In which world does Microsoft conform to open standards or protocols?

Your point simply doesn't make sense.

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

We all got very lucky that the flaw could be mitigated in a backwards-compatible way.

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.

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.

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.

> 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

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.

It's not at all clear that the messaging ecosystem would be better if Signal could say "We won't let you send this message to your friend because we think their client isn't as secure as ours."

I'm sure there are cases where a third party client would be less secure and Signal would be justified in refusing to relay messages to/from that client, but what about situations, like the current one, where it is Signal itself that is insecure? To be consistent, shouldn't Signal have to block their own client until they fixed the issue?

Even if you accept the idea of Signal having a (inconsistently applied) veto over which apps are allowed to use its infrastructure, how far do you take it? Should they deliberately brick official Signal clients running on versions of iOS or Android that are deemed insecure? Should they require that the phone manufacturer is "trustworthy" so that it doesn't risk containing Chinese government spyware?

Taken to extremes, Signal would need to come with its own antivirus scanner or support some sort of remote attestation of all the versions of all the software running on the phone, to prevent messages being leaked through side-channels. And what would that achieve, other than pushing people to use other, less secure apps?

I think it is a dangerous distraction for Signal's threat model to worry about anything other than making their own app secure, and making sure that the protocol supported by their servers is secure.

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

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.

Reply on news.ycombinator.com