Comment by saurik | Hacker News Reader

Comment by saurik | Hacker News Reader

1) I would expect "signald" to be the server that clients connect to (as in, the thing provided by signal) and "signalcd" to be a client that is in the form of a daemon (akin to dhcpd vs. dhcpcd).

2) You can't use either of these names as Signal owns a trademark on their name (and even cares, as they should, particularly for a security product) and this looks like an official product in a way you can't disclaim away: come up with your own name for your daemon and then "support" signal or be "for" signal.

https://signal.org/legal/

> Signal’s Rights. We own all copyrights, trademarks, domains, logos, trade dress, trade secrets, patents, and other intellectual property rights associated with our Services. You may not use our copyrights, trademarks, domains, logos, trade dress, patents, and other intellectual property rights unless you have our written permission. To report copyright, trademark, or other intellectual property infringement, please contact abuse@signal.org.

Also Signal has a history of shutting down third party clients, e.g. there was an effort making Signal completely FOSS and publishing it on F-Droid and Moxie shut them down for using the official servers, as well as the name: https://github.com/LibreSignal/LibreSignal/issues/37#issueco...

For people longing for a phonenumber-based messenger with a good selection of officially-supported free/open-source clients, have a look at:

https://quicksy.im/

It would appear that encryption is optional in this tool. That's a 50 caliber footgun (on par with Telegram) if I ever saw one; I won't be using this software.

OMEMO is optional because not all of the 37283749 XMPP clients support it. But it is enabled by default if all involved parties are using Quicksy, Conversations or another reasonably new client.

I won't touch a messenger that ever lets me send a mix of encrypted or unencrypted communications. That's an accident waiting to happen.

For what it's worth, Signal on Android allows sending of unencrypted messages over SMS.

But that's a different protocol than the signal protocol. And Signal encrypts your SMS at rest should you choose to use their app to do so.

You're totally allowed to publish client software that has the URLs of the official servers in the code, including that forked from the official client. Believing otherwise is a common (and false) misconception that I wish people would stop repeating. (However, if you do fork the program, pick a new name! "Signal" is trademarked, don't use it in your name.)

The ToS for the signal service API applies to end users who connect to that API. The ToS of the API does not apply to software - the AGPL license applies to that, and the AGPL permits anyone to make forks (including ones that are configured to talk to the official servers).

EDIT: Disregard the following paragraph. See below.

There is a little bit of an issue, though, because contributions to Signal's upstream are not accepted unless the contributors sign the CLA, which allows Signal to relicense future versions more restrictively as they wish. They could relicense and then introduce intentional incompatibilities in the protocol if they really wanted to harm forks, but that would make them non-free, non-open-source software.

EDIT: Turns out I'm wrong in the above - the Signal CLA, to their immense credit, only permits relicensing under OSI-approved free software licenses. Fork away!

Moral of the story: don't listen to bluster, stick to what the license says (and the AGPL says you can fork), and never sign a CLA. You don't have to sign a CLA to contribute to the Linux kernel, and you shouldn't ever sign one to contribute to any other open source project.

I also wonder if it's even possible to enforce an "official clients only" restriction in the ToS for the service API. This would be a little bit like Google claiming that you aren't authorized to use Firefox to access google.com (i.e. insanity). Technologically if you tracked upstream closely enough, they probably wouldn't even be able to tell if a given 3p client user is running your fork or the official one.

(This whole comment is a paraphrase of a blog post[1] I published just a few hours ago that tries to dispel this whole "but you can't fork Signal and use the official servers" false meme.)

[1]: https://news.ycombinator.com/item?id=26940342

Thanks for letting us witness your research.

They probably do not have a leg to stand on legally but what should I do if they ban me? Sue them?

How or why would they ban you for publishing software?

If they ban end-user accounts that use your client software to connect to their API, that's obviously a bug in your software as it diverges from the behavior of the official client. This is why anyone making an alternative client should be doing so with a fork of upstream that is regularly updated. You'd need to keep it in sync pretty closely. Most official Signal clients autoupdate (a huge security vulnerability in and of itself[1], as SolarWinds demonstrated very nicely for everyone), but not all of them (you can't override the user's systemwide app autoupdate setting on iOS), so they have to maintain BC with out of date versions for at least a few weeks/months.

[1]: https://github.com/signalapp/Signal-Desktop/issues/4578

That thread is a bit ridiculous, the guy was already told that he can block updates.signal.org if he really wants to inspect the commits first, but he insists there no workaround.

My mitigation strategy for this issue has already been posted in that thread; I didn't file it because of my own computer.

I was referring to banning of users who use third party clients and I do not think it would be particularly hard to do if they really wanted to. You can for example use request patterns or the fact that the unofficial clients do not autoupdate. I doubt that they would go that far, but it would be trivial if they really wanted to.

Banning the set of users that are so passionate about your service that they jumped through hoops to work around your dogshit software is probably not the best decision a product company can make.

Yea but Moxie is trying to make money out of said dogshit software with his crypto editions

FWIW Moxie has claimed to own zero mobilecoin, and Signal/OWS is a nonprofit.

You're accusing him of lying.

Nothing GP said has to contradict either of these. I think you’re accusing them of accusing him of lying. Was Marlinspike paid for his services to mobilecoin, possibly even as CTO? Be more careful with your accusations. https://www.coindesk.com/signal-founder-may-have-been-more-t...

Is the link you provided right? I don't see how it relates to this. I generally agree with your statements, but I wouldn't want to run a project like LibreSignal with the lead of the original project not wanting my project to exist, although I find moxy's behaviour in this case very unsetteling.

My rant about the licensing confusion is at the bottom of the post, below the part about how it silently ruins the files you attach. It should probably be a different blog post, but I don't feel the rant alone is worthy of its own webpage. I like dispelling misinformation, but I don't like drawing specific attention to misinformation, if that makes sense?

Trademark for ‘Signal’ is still pending in the US https://uspto.report/company/Signal-Technology-Foundation

Even with a granted trademark, it would be up to the company to enforce it. Simply stating “you can’t use our name” is much different from perusing open source projects in court or sending them cease and desist letters.

But it's also a dick move to ignore their consent just because it's hard to enforce.

Say "for Signal" or "supports Signal" like the other person said, don't pretend to be part of the Signal org.

"Twitteriffic" and "Tweetbot" exist as accepted third-party Twitter-related apps, despite the fact that Twitter owns the "Twitter" and "Tweet" trademarks.

On appstore tweetbot does have a "for Twitter" suffix to its name though

Signald sounds much more official than twitteriffic (trademarks are all about confuseability). Besides, how twitter does or does not enforce its trademarks has no bearing on what signal does.

To be fair, it says “unofficial” as the first word of the description on the website.

That really doesn't affect the legality (or, frankly, morality) here for many reasons, but the most obvious is that the word "unofficial" is certainly not going to be used in all of the discussions about the software as it simply isn't actually in the name, which is clearly only "signald".

> or, frankly, morality

Sorry, are you saying it is immoral to name a daemon that interacts with Signal 'signald'?

First off, morals are subjective, but, also, yes: if you're going to have a different project, it should have a different name. Otherwise you run the very real risk of deceiving people into thinking that A is affiliated with B.

What's so surprising about the fact that someone would find that immoral due to the potential to mislead? I would find it immoral, as well.

Reply on news.ycombinator.com