HN user

topdancing

114 karma
Posts1
Comments59
View on HN

Signal does not know numbers or how these contatcs interact.

It is described here [2]. Number is only needed for creating the unique hash. Server knows only the recipient, not the sender.

Signal does know everyone's numbers as everybody is logged into a Signal account on the server end (this is how your client fetches messages for your number). That same account and IP are also used when you send a message.

On top of that fact, sealed sender has been known to be broken for some time now: https://www.ndss-symposium.org/ndss-paper/improving-signals-...

Yes, and security has a large performance impact.

Not necessarily. The linked blog talks about SPARK which is about running your code through theorem provers to mathematically formally verify that your code does the correct thing _in all instances_.

Once you have passed this level of verification - you can disable assertions and checks in the release version of the application (whilst of course - having the option of keeping them enabled in development releases).

SPARK itself can handle and prove some ownership properties but to the best of my knowledge isn't at the level of rust in memory safety on dynamically allocated memory.

It actually is: https://www.adacore.com/uploads/techPapers/Safe-Dynamic-Memo...

And using https://www.adacore.com/sparkpro as a reference (ignore the 'Pro' bit as it's also available in the GPL edition) - anything certified to SPARK Silver level is far safer than any Rust code out there.

Funny how before Alire was a thing, people complained that there was no easy way to take other people's Ada code and add it to one's own software projects.

Now Alire exists and people complain that it's easy to add people's code into their own projects.

You don't even have to use Alire in the first place - every modern Linux distro ships with an Ada compiler - on Fedora just install gcc-gnat and off you go.

What are people using VPNs for mostly, if they're living in a country without internet censorship?

I find it's a convenient way to prevent services beyond my ISP from knowing where am I based on IP address.

All of those apps you have on your devices presumably have permanent connections back to their servers and they can very easily tell if you're at home, out on mobile data, in an office, or in a cafe/public library or even in a different country.

With a VPN, they currently think I'm in Dallas; which I'm nowhere near right now.

Conversations, draugr.de, can't really say much on steps to reproduce - it worked reliably and then it didn't just yesterday

So it worked fine for some time, glitched one day, you presumably have done zero debugging as you have no logs or error messages to show us and somehow that means that clients "just lose messages".

This isn't how it works. If you actually pull down one of their multihop configurations - you'll see:

- the WireGuard public key for server 2

- the IP address for server 1

- a unique port for server2 on server 1

So all they're doing is a standard iptables redirect to the second host (which may or may not itself be under a WireGuard tunnel).

then try to find your contacts again (which may be cached by your client or not)

You can save XMPP account IDs in any mobile address book.

Finally, you have to convince "someone" that this is just you with another account on another server. There is also no verified E2EE anymore.

I'd pretty much just do a video call at that point.

How is this different from "when Signal goes down one uses a completely different instant messaging system", apart from using another client?

You don't have to use another client software.

Which means: If one of these hosting companies blocks XMPP traffic (e.g., if a rogue state starts censoring) or one of these XMPP servers goes down, a huge part of XMPP users is affected.

Equally applies to most messaging apps out there. Some XMPP apps have the benefit of also supporting using Tor and hidden services - Signal/WhatsApp/etc, don't.

Don't want to use the Internet at all and your friends live close by? You can even go wild and do something like:

- https://github.com/ddamianus/Lora-Chat-Device

- https://github.com/jgoerzen/ax25xmpp

I realize this is something most people would not do, but XMPP's _flexibility_ allows this to be an option if it was something people wanted. Can't do Signal over LoRa.

Once again, "I, as a tech-savvy person, can operate my highly-customized XMPP setup everywhere", while ignoring that most people do not run their own servers.

I said "my server", but the exact same code could be pointed at a different server by simply changing the username/password. Compare this to having to port a codebase from Signal to WhatsApp/Slack/whatever.

I'm also just using a standard ejabberd-based deployment, nothing highly-customized about it. Have you tried a Signal server deployment? I have, and THAT is the definition of highly-customized.

This was discussed numerous times various platforms and proven wrong.

Alternative clients exist, but they are heavily frowned upon by the community - as a lot of the functionality they add (disappearing messages, view once media) depend on people using the official clients and not custom ones that could simply ignore this functionality.

As discussed before on this page, most XMPP users don't run their own XMPP server but use a public XMPP server on the internet. Nobody can check whether this public XMPP server tracks its users without accessing the server itself.

That's fine, same thing applies to Matrix/Signal/WhatsApp/pretty much any messaging service out there.

So, do you assume the Signal network infrastructure consists of a single server?

Functionally - although it is clustered - it is a single server, run by a single team - and it has gone down multiple times in the past few years.

And when it does go down: good luck using that Signal client to talk to anyone over it (SMS doesn't count as it has zero security on Signal and isn't even available on the iOS client). At least with XMPP, I can point the same client to some other server and potentially continue a conversation with someone somewhere else, with the exact same OMEMO/PGP encryption.

That is why decentralized/federated is better than "all your eggs in one basket" centralized. Centralization provides one with convenience, right up until it stops working and then it becomes a massive inconvenience.

At least Quicksy (from the Conversations developer who bragged in a public video about copying WhatsApp/Signal) and Kontalk require a phone number.

The whole point of Quicksy is to allow people to try XMPP and find contacts easily with their number before they then move on to using actual JID-based accounts.

And he's more than free to brag about what he does - he's the one that spent the time; writing code and extensions and then released the thing to the public as free and open-source code.

Signal does. You wrote, you use Signal. Did you ever join a Signal group? There is a dialog when entering a group the first time.

This is your Signal PROFILE name, not a username. You can quite clearly see this described in Settings -> tap the top bit with your number and read the text at the bottom.

People can still see your phone number by simply clicking on your user in the group member list. Signal, at the current time[0], has zero username functionality.

[0] https://twitter.com/moxie/status/1480643863970816001

XMPP is about choice.

I use OMEMO everywhere. However, I do know of people out there who simply do not see the point of OMEMO as, when they are the server admin, OMEMO adds no value over TLS. OMEMO also doesn't make sense in large public groups, cause you're not going to go and verify 100+ people's encryption keys one by one.

OMEMO and end-to-end encryption are also incompatible with keeping a reliable server-side archive of your messages - which will be accessible to all future XMPP clients that you add to your account - which apparently some people want. You can see this at the table at https://conversations.im/omemo/

Meanwhile, you occasionally find people on the Signal subreddit bemoaning that they lost their entire message history with a loved one because some backup file got corrupted and failed to restore or; they lost some device. Here's an example: https://www.reddit.com/r/signal/comments/rbtdtb/

As I said: XMPP is about choice.

XMPP is an open standard -> Doesn't this apply to Signal, too?

Signal is the opposite of an open-standard, there's a single server implementation and basically three clients (Android, iOS, desktop) and they discourage people from using other clients. Best way to think about Signal is that it's just WhatsApp with some marketing on top.

Meanwhile, I can link a raspberry pi anywhere in the world to my XMPP server with a few lines of Python and some libraries.

Some developers claim not to track users -> Same applies to Signal.

Both cannot be verified by the users, but as an admin, I can verify that my server isn't tracking users.

Decentralized -> The first difference, and here we can write another article on why decentralization doesn't magically add any security or privacy.

It does certainly help not to have all of your eggs in a centralized basket, both in terms of privacy and reliability.

Users can choose a username, doesn't need phone number -> Second difference, which doesn't apply to all XMPP clients as some may require your phone number

Do not know of a single XMPP client that requires a phone number - some random server out there, maybe.

and if we assume people can choose a non-identifiable username, then we can also assume people can choose a non-identifiable phone number. User may not be identifiable -> Another vague statement without any explanation that we can just assume the same way for Signal.

You'll find most people will tell you that you need ID these days to get a SIM card. Creating a new XMPP account takes less than 5 seconds.

Presence status shared with others (without mentioning that server admins can see this, too) -> Signal comes without this feature.

The user can disable these, personally I find them useful on my server and miss it sometimes when I use Signal.

Only nicknames exposed in MUCs (again without mentioning what MUC admins and server admins see) -> Signal lets users decide if they want to share their phone number and username with groups.

Signal doesn't, all phone numbers of group members are visible to people within the group.

Your Signal client is at this moment logged into a Signal account on the Signal server. Sealed sender does nothing to protect against this - Signal knows that tialaramex is at that IP address.

The server fully aware where Steve is logged in from, and sees a message come from there to tialaramex. On top of even that: you then reply back, server sees a message going to Steve, going straight back to the IP address where it already knows he's logged in from.

Another thing people don't consider is that Signal's core server infra is hosted at AWS... so Amazon can also peek into both this network traffic and also dump out that it's your Signal account (ie. phone number) tied to that IP from the EC2 instance's memory.

These folks showed that this sealed sender stuff is broken last year: https://www.ndss-symposium.org/ndss-paper/improving-signals-... (and there's an acknowledgment from the Signal team on page 3 of the PDF).

https://wiki.openstreetmap.org/wiki/Key:opening_hours

You go around, survey the opening hours posted on local restaurants (I usually take a photo, and don't copy and paste from other sources as this normally goes against their T&C) and then add these to openstreetmap.org.

Then next time apps like organicmaps.app update, you'll have all the local opening hours for restaurants and things directly on your device.

I have found that places usually change opening houes by an hour or two.

And if anyone reads this and thinks: "well, that sounds like a chore", this is the only solution I've found that:

1. Is under an open data license

2. Is easily editable as a normal user

3. Isn't backed by "Big Tech" that can wall it off

4. At least has apps that make the data searchable in an offline way

5. Fully exposes the data in open formats (just zoom in on the map, right click on an object and press "Query features" for a basic example or see https://wiki.openstreetmap.org/wiki/Databases_and_data_acces... )

But like anything else, you need people to contribute to it.

- They talk about evaluating extensions but extensions was one of the things I raised as being a turn off.

They can be daunting at the start (as it is with learning any new technology ecosystem), but once configured; it's not something one thinks about.

- They talk about clients, but there's no shortage of other chat solutions out there with decent clients these days. A list of platforms and links to clients doesn't tell me whether XMPP clients are buggy or well polished. Let alone why I should use XMPP over another solution with a well polished client.

My personal favourite is conversations.im, but these days, with the notable exception from Pidgin, they all tend to interoperate fine. iOS clients still has issues with push notifications (thanks to the OS level) that are being fixed: https://snikket.org/blog/snikket-ios-public-release/

- They talk about privacy but even on XMPP that's not a given and there are other solutions out there if you're interested in privacy.

Disagree on this point:

- Other solutions generally require a number or email address. On XMPP, you can simply create an account by pointing a client at a server and asking for an account (you can even create a completely random pseudonym).

- Other solutions do not generally allow you to self-host (Slack, WhatsApp, Signal, etc), so they're not private even to begin with.

- Other solutions don't generally have the flexibility of federation to let you talk to other servers (such as Mattermost).

- XMPP clients also have optional support for Tor, and servers can be hosted on hidden services and can talk to servers over Tor too - which is much better than Signal and others should you desire an elevated level of privacy (I do not bother with this point, but if I met someone who did - good to have as an option)

- Things like Briar that do P2P do exist, but their clients are lacking in other areas such as voice calls, multi-platform support, etc.

- They talk about voice and video calls, and that at least is new from when I last tried. So that's one thing in favour of your point. However I already have a half a dozen platforms that do that -- platforms that already have my friends and family on it. Why should I set up another? And moreover how am I going to convince my friends and family to install this other chat client if you can't even convince me, a fellow technology geek, to try it?

It's just chat at the end of the day, and as I said - I did not want to rely on a third-party for something as crucial as my personal, private comms.

Another thing that I enjoy about XMPP is that the clients support multiple accounts as a first-class feature (something you cannot do on Signal/WhatsApp). Theoretically; from the same app; I could have accounts for personal, work, a neighborhood chat, and an account over at sfconservancy[1], whilst being able to enable/disable as and when I want to.

This last point is more pertinent as people become fatigued and bored of having to have multiple apps for different contacts across multiple platforms (a pain point made worse as new chat apps come into life every other year and contacts decide to move over). In my case, I know that there will be open-source XMPP clients that I can use to log into my server and still have the same contact list.

Tools like https://quicksy.im/ also exist to make it easier for normal people to adjust to an XMPP client before moving them over to non-number based accounts.

[1] https://sfconservancy.org/blog/2021/jun/21/chat-options/