Can you post this update on the Snapcraft (https://forum.snapcraft.io/t/what-happened-to-signal-desktop...) and GitHub threads (https://github.com/snapcrafters/signal-desktop/issues/70) too?
I was going to just now and cross link back here to your comment and figured it would be better coming from you directly!
They are, yes. Well, former maintainer.
And if it were, it still wouldn't matter because the AGPLv3 source would have granted you a license to that too being a copyright license.
You need a copyright license to use the binary. You need a trademark license to use the trademark. See the firefox -> iceweasel kerfuffle
It sounds like people are saying that a company can have their trademarks used by downstream distributors of AGPLv3 software, if the license doesn't explicitly prevent that, which just seems wrong. The codebase license is not a license to other company IP
I also don't understand why an entity couldn't do a DCMA takedown based on a trademark violation.
But that's not what's going on here. If the source is unchanged, it's perfectly valid (and often done) to just point people upstream. That is providing the source. And the code used to build their snap is available*, and you can see all it does is repackage upstream's official package.
* https://github.com/snapcrafters/signal-desktop/blob/master/s...
AGPL v3 specifically allows authors to add trademark restrictions that become violating.
Don't follow the trademark clauses, lose your copyright license, that becomes a copyright violation, actionable under DMCA.
https://github.com/signalapp/Signal-Desktop/blob/main/LICENS...
[1] https://drewdevault.com/2021/09/27/Let-distros-do-their-job....
If unmodified binaries are redistributed, there is no trademark violation. It's nominative use, and simply not misleading the public because it's the genuine article. Any obstacle to redistribution must therefore come from the copyright licensing terms (if the binaries are available to the general public), or from an individual agreement with the original recipient of the binaries (so no direct free, public downloads even if the binaries are technically under an open-source license, and export compliance is a bit more difficult). Not sure which applies here, but it's not a trademark issue.
Are we sure that Signal didn't contact the maintainer? I haven't seen any statements either way about that.
> I was just linked to this thread from our issue tracker
> As a maintainer for this snap package, it’s mind-boggling to me that, even after almost two weeks, the store team did not contact me at all. I had to find this out myself from users reporting it on our bug tracker.
> After almost two weeks, the maintainer of the snap has not received any official communication about this, but @roadmr was able to provide this tiny sliver of info in a thread on this forum.
From the original comment of this particular thread, also from galgalesh:
> Snap Maintainer here, this is because of a DMCA takedown request from lawyers representing Signal. Canonical is currently working with them to clear things up.
> Canonical's communication to me was initially lacking due to issues in their process, the process has been amended and I'm back in the loop again.
Seems pretty clear that he was neither aware of it being taken down nor the reason, so I think it's safe to assume that Signal didn't contact the maintainer directly.
You could be right, but I think another possibility is that the maintainer did get contacted earlier by Signal, and just didn't mentally connect the dots between that and his Snap package being pulled.
Note that I don't know how realistic this is, I'm just trying to be fair in my assumptions.
> Canonical's communication to me was initially lacking due to issues in their process, the process has been amended and I'm back in the loop again.
Had they contacted the maintainer, then the maintainer would not have been wondering what the deal was.
- Still need a phone number
- They refuse to post the app on f-droid (directly)
- No 3rd party clients allowed on their servers.
- Crypto thing they attempted
- I don't trust Moxie, he rubs me the wrong way.Signal is not without flaws as you say, but if you have a phone number and can access a binary, there's every reason to believe it will securely and privately transmit your messages. You are also, ofc, free to fork their client and run your own service (as others have done).
Edit: to be clearer - signal both publishes a protocol (that is thought to be secure) and provides a public service (that claims to use the signal protocol). Signal has claimed that the binary blobs they add to their public client (and the other restrictions) are required to run a public service (anti-abuse, etc). You are free to believe them or not - I do.
At the protocol level, which you are free to use, none of the problems you or the ancestors have pointed to apply. All of the alternatives people are pointing to here are at the "protocol" level - accessible only if you or someone you trust has setup a node. There's nothing wrong with that - it's a good idea - but it's no reason to attack signal's service for not being a protocol (which they also provide).
[1] https://community.signalusers.org/t/overview-of-third-party-...
I've heard WhatsApp recommended from people I trust, but I have never personally used it so can't speak from experience.
Your suggested alternatives are owned by Zoom and Facebook. I'll stick with Signal.
All of them being tied to a phone number is bad form.
> Crypto thing they attempted
well...
Signal's "source available" infra can be self-hosted but it's huge effort and relies on a bunch of cloud-specific services which need to be replaced with self-hostslable alternatives. It's also extremely poorly documented and the code quality is fairly mediocre. I wouldn't recommend trying to host Signal infra yourself; it can be done; I've done it at work and it took some months of effort, and maintaining it is a nightmare (or was, then at least) because they'd only push one huge update to GitHub quarterly or less often.
[0]:https://www.theverge.com/2022/1/10/22876891/signal-ceo-steps...
- No easy way to do and restore backups on Android and impossible to do backups on their PC client
- Does not support Android tablets at all (my mom loves hers)
- Fails to ring on Android when you call someone or someone calls you, later serving you a missed call notification (disabled Doze/battery optimization feature on Android and tested on 3 different phones with no cigar)
- No way to share your live location to friends
- Using its built in photo snapping and sharing function takes horrible pictures on Android (I suspect they're using the wrong API). If I want to send someone I'm currently texting a good looking picture I need to switch to my phone's camera APP, then back to the chat and use the photo upload function, instead of the in-app photo snapping and sharing function
Some of these bugs have been reported 3+ years ago, while these things work flawlessly on WhatsApp since nearly forever, meanwhile Signal is busy implementing crypto payment features.
I don't know about iOS, but at least for Android and PC, it still feels like an app in alpha that's not yet released to the public compared to how polished and feature rich WhatsApp and Telegram are.
Also no problems with it not ringing, Signal is actually the primary way that my family calls each other now and no one has experienced it not ringing when expected.
The rest I admittedly dont use or arent impacted by.
While its not perfect in all ways, I disagree with the "alpha" quality sentiment. Especially when you are comparing it to apps that dont have the same security goals or standards.
I generally agree with gp, it's not a bad app but certainly not one id ever use if I could contact someone another way. I find the lack of interpretability with my computer especially annoying. I'm constantly left feeling like a second class citizen.
Especially when it comes to seeing my history, I linked the accounts ages ago, I barely use my phone yet I'm consistently losing messages on my pc
As for the "security" I'm pretty sure it doesn't have reproducible builds, so it's basically just "trust me bro". rather trust moxie than zuck but still don't really trust either.
I never said backups don't work, I said they're not easy to do and restore compared to other apps where it's much more seamless and hands-off.
>Also no problems with it not ringing, Signal is actually the primary way that my family calls each other now and no one has experienced it not ringing when expected.
Can't concur, I've personally seen this issue across 3 different android phones form 3 different brands and there are countless people online complaining about the same issue. You just got lucky.
>Especially when you are comparing it to apps that dont have the same security goals or standards.
Which security goals and standards exactly? Signal's sales pitch is that it claims to be end-to-end encrypted, but so does WhatsApp, and until we have an independent security audit of Signal and its code, the claim for "better" security goals is as valid as "trust me bro". The only thing going for it is that it's not owned by Zuck's advertising empire and not owned by Russians, and that's it, but that's a very low bar to clear.
And also, how does having "better" security goals impact the issues with picture quality the app takes or the app failing to ring when someone calls you? "Security" is not an excuse for major bugs and lack of basic features. If security is done right then it should work transparently and not have an impact on any other features.
As to ringing, it seems that the six people with six different phones (mostly Pixels, one iPhone) in my circle mean that it isn't good luck on my part...
It's end to end by default vs Telegram which is well known to be end to end maybeish if it's explicitly setup, for private chats only. WhatsApp is WhatsApp. Maybe it's a low bar, but Signal beats those others pretty easily. And refusing to use Signal over those two due to lack of a security audit is a bit absurd... All you're getting from Telegram and WhatsApp is "trust us bro" as well.
It's not an excuse. But considering it IS transparent for many users, me included.... Not everyone is having the issues you are.
This is mostly Androids fault... For me, even Whatsapp's built in camera is terrible. When you press the button to take a photo, it starts focussing, then takes a photo before the focussing is done. So every photo taken is reliably blurry. There isn't any way to take a non-blurry photo with the main (back) camera.
The main OS camera app works fine.
I think they have per-device logic for this sort of thing, and mine is an uncommon chinaphone, so presumably they haven't tuned the logic for it.
The rest are all feature requests.
That said, it’s interesting to see what people think are basic requirement for a messaging app these days.
Uncontroversial example: a calculator app that doesn't have a divide key. Technically, yes, it's a separate feature from the multiply key, but it's so basic, so expected, that its absence is a bug.
From the above list, I consider "No easy way to do and restore backups on Android and impossible to do backups on their PC client" a bug, or at least a frustrating omission by design.
More like missing basic features. I never said all are bugs, I said some are bugs and that all these things exist and work on the other alternatives like WhatsApp or Telegram
If you climb in the ring with Ali, then you'd better be able to box.
And it's also the criteria of millions of other users who have not switched to Signal because of the bugs and lack of basic features for a modern messaging app.
> And it's also the criteria of millions of other users who have not switched to Signal because of the bugs, quirks, and lack of basic features for a modern messaging app.
You have absolutely no knowledge that this is why people haven’t switched, indeed it’s highly unlikely that it would have been as successful as it has if this were the case. People move to Signal because they distrust Facebook and telegram.
The more logical explanation is simply network effects and inertia. Occam’s razor.
It also has some questionable decisions in it like cropping to close to the screen's aspect ratio rather than using the native aspect ratio of the sensor. I never want that behavior.
So far Signal is a centralized encrypted messaging app that includes its own cryptocurrency and wallet no one asked for, shills me for donations every other release, and begs me to invite new users despite deprecating regular SMS message support.
if youre a threat-actor the most malevolent thing you could do at this point is just watch Moxie and the team drive this project into the ground.
Moxie is no longer active in signal afaik. This is the new leadership.
Looks to me like Signal is the interior app here.
Signal had one feature it did better than its competitors and that's allowing integration of SMS. That feature is now getting killed because of RCS issues. With all my contacts on similar chat apps, I don't see why I should keep Signal installed once they remove the SMS feature, let alone why I should convince my grandma to make the switch.
"But Facebook is evil and wants to control you and wants to suck your blood" yes and so do the companies that made our phones and mobile operating systems. What's the point of Signal's openness (well, "open", they did stop uploading the source code for a while when they were adding in their crypto scheme) if you still use it on a proprietary phone.
And no, Linux on neither mobile devices nor the desktop is grandma-ready.
It isn't owned by a data leech.
Is it? How do you measure that? It seems like WhatsApp is a better default choice for most people probably.
There are so many scandals that come to mind, like not updating the FOSS code for years.
I’m no fan of Meta, and they have incentive to hoover up data.
But I don’t have a good reason to trust signal other than that everyone on hackernews seems to love them.
Meta is a publicly traded company. Signal is a 501c3, it's a completely different kind of organization.
There is credibility to the notion that signal is designed to ensure that people who are paranoid would prefer it.
The fact that it exists and is convenient prevents more secure messengers from existing as the lions share simply goes to signal, and this is what I mean by marketing. It is conventional wisdom that signal is the bees knees and looking further or scrutinising it is folly.
A lot of funding comes from the government to signal too; and since it’s an American company it must comply to the best of its ability with US law. They tell us that they can only comply in small ways, but given that there is no independent verification of the server (that it even runs the FOSS code) and the hostility in having unofficial clients on the network I am left pondering.
So you can actually audit the client code and make sure it is e2ee, which you cannot do with WhatsApp. In other words, for e2ee you must trust WhatsApp, not Signal.
I presume that for the outdated code, you think about the server code. That's different and would imply metadata, not message content.
Signal is e2ee, and you don't have to trust them for that.
Only if both sides are using clients that are self-compiled, independently-compiled (and audited), deterministic/reproducible or third-party.
The problem is that the network and the app are the same people, and worse than that; they send binaries and expect you to trust them.
I know lip service is paid to reproducibility but afaik the instructions for doing that are 404ing.
I just get a greasy feeling from the lock-in, the heavy marketing, the fact that everyone refuses to speak critically of them unless it’s about anonymous usernames.
A truly good secure client would have worked on any network, it wouldn’t rely on transporting your data over their servers, it would be a protocol that was open to third parties to implement, it would also be reproducible or independently compiled by trusted third parties (like OS maintainers, who already audit a lot of the code that gets built and signed).
There are two things: First, say the Android apk they distribute has a backdoor, and someone realizes that (it's distributed to millions of people, could be that someone checks). Then that's the end of Signal, right? So that's a big risk for them. That's for the "mass surveillance" scenario. Not perfect, but that's something. Second, if you fear a targeted attack, then self-compile Signal. It's not that difficult if you care about it.
The list goes on (and on), but the point is that Facebook gets to be the good guy and claim E2EE, while gathering all that metadata.
As for web/desktop one can use also Telegram.
My parents use that. I use that.
And years before that sms was cheaper than data.
Also sms is cheaper when roaming in Europe (in my case it has zero cost besides the monthly subscription price).
Sure IM are etter if you need group chat or communication abroad. But that is not the case for majority of population where 1 to 1 communication is used inside a single country.
https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
Ironically, from his website:
> In general, I hope to contribute to a world where we value skills and relationships over careers and money, where we know better than to trust cops or politicians, and where we're passionate about building and creating things in a self-motivated and self-directed way.
>>Some time ago you federated with CyanogenMod. What has changed since then?
>What changed was going through that experience. It seriously degraded the UX for our users and held us back in the development process at many times. I'd estimate that all told, we lost about 6 months to a year of progress. It's something we'll probably never do again, and has fully convinced me that federated protocols are a thing of the past in this world of ours.
That's a pretty reasonable take: we tried it and it hurt velocity too much.
I'm not convinced that's still the case in 2022. There are a couple issues I'd like to see polished in the Android client, but I have not noticed bugs or missing features that seem likely to require breaking changes.
He’s not blameless for the fact it’s not federated, for example. Even if he’s not involved anymore.
I see you want federation, that's fine. I want private metadata. Don't use Signal if it doesn't do what you want, but maybe try to accept that not every project should do what you want. They have their preferences too.
Isn't their client open source? If I compiled it myself, is that a third party client?
If they don't let me compile it myself, how can I trust their official version is using the source they published?
This is a multi-level failure.
1. Signal-Desktop is AGPLv3: https://github.com/signalapp/Signal-Desktop
2. The snap package metadata is AGPLv3: https://github.com/snapcrafters/signal-desktop
So, this looks like a fraudulent DMCA claim by Signal, as the snap package maintainers and Canonicial have an open source license! This shows malice by Signal.
3. No-one from Canonical contacted the package maintainer(s) about the DMCA, so they have no opportunity to counterclaim or defend.
This is an open sign Snap should not be used. Because utterly unjustified DMCA claims will result in the removal of a package without any way to contest. This is compounded by Canoncial's controlling methodology with Snap where it is ostensibly open-source but Canonical controls what is permitted with snap through a closed-source server.
As far as I understood the argument, you're free to distribute binaries, you just can't call them "Signal", since it's a trademarked name (?).
* I'm sure Signal would object to you redistributing binaries under their name, even if you claim they are unmodified, but they can't verify that fact. And honestly such an objection seem pretty reasonable.
Signal's license on the other hand, does permit use of trademark. If nothing else this means that using the DMCA for this is wildly inappropriate.
Will they do the same if some vulnerability is found in Signal? Lawyer up instead of fix the problem?
No, those lawyers are paid for by and directed by signal. Signal is responsible.
$ sudo apt-get install signal
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package signal
It should NEVER be more than 1 line of shell or 2 mouse clicks to install anything. This is 2022, not 1995.
It's faster to just search for "signal" in the snap store and hit "Install".
No way. I will never trust your binary.
There are a lot of users that prefer the established trust model of a Linux distribution. They're willing to trust the mostly unpaid debian maintainers for example... but not John Doe, the temporarily set back billionaire who's just about to make it big
wget -O- https://updates.signal.org/desktop/apt/keys.asc | gpg --dearmor > signal-desktop-keyring.gpg && cat signal-desktop-keyring.gpg | sudo tee -a /usr/share/keyrings/signal-desktop-keyring.gpg > /dev/null && echo 'deb [arch=amd64 signed-by=/usr/share/keyrings/signal-desktop-keyring.gpg] https://updates.signal.org/desktop/apt xenial main' |\ sudo tee -a /etc/apt/sources.list.d/signal-xenial.list && sudo apt update && sudo apt install signal-desktop
This is also one of my fears with pushing non tech savvy people away from Apple/Windows and onto Linux without the Snap, Flathub, or other such curated stores that ship with the distro, without which they would need to touch the terminal and run commands found on the internet.
GNU/Geeks will keep shouting religiously how insecure Windows is because "grandma can download a dodgy .exe pretending to be a game and get viruses", but on Linux it's the same shit or worse, all you have to do is to convince a user new to Linux to paste and run a sudo command in the terminal as instructed by some scammy tutorial he found on Youtube when searching for "how to install Fortnite on Linux" and it's game over for him, since Youtube removed the downvote counter and the user had no idea he was running into a trap.
After all, for most Average Joes, copying some text feels far less dangerous than downloading and opening a strange file.
At least Windows Defender will most likely catch that malware you downloaded and warn you about it being harmful, but on Linux you have no such guardian nanny to save you. With sudo, it will do whatever self-destructive thing you tell it to do and not complain.
curl -sfL www.marginalia.nu/install.sh | sudo sh -
Or cloning a git repo and building it?
But you can?
With .deb-files you're expected to verify the checksum. Maybe you don't, and even if you don't, you can theoretically go back and verify after as part of a forensic process. This checksum is also typically distributed across different mirrors, making bait-and-switch attacks difficult. It means that if you're going to do a supply chain attack, you must do it in the open.
Compiling from sources is a bit sketchy, but it is also the vector that is easiest to analyze, so I think they cancel out.
Is it really meaningfully easier to analyse? I get that it feels better, but I'd bet that the people saying this would fail to catch the backdoor every time.
I would instead manually download and unpack the app, create separate user for it, and run it in chroot. Much safer than your method.
Sadly, plenty of applications still take the old "apt-key" approach of adding the keys globally (e.g., installing keys to /etc/apt/trusted.gpg.d), but I think Signal's installation process is the correct/recommended approach for distributing apt packages securely.
Sadly debian-based distributions do not respect the principle of least privileges and grant unnecessary permissions to installation scripts.
If it is critical or has the potential to compromise security, it should take however many lines that are required to ensure a safe installation. The landscape today is far too complex to expect simple deployments (one liners) to be safe. A few extra lines is a small tradeoff in that case. I shudder when I see curl|bash type installations being normalized.
I've had so many bad experiences with broken third party packages or worse, "installers".
Remember you are expecting the maintainer to not only be honest you are expecting them to secure his own machine as well.
I don't want to add random deb repositories for software like that.
What's your threat model here? Trusting Signal to provide the binary and host the servers, but not distribute the binary that connects to the servers?
Doesn't matter who provides the repository, because ownership can change. Even if you trust the current owner to be diligent and fair you have no control over what a future owner does. (Incidentally, buying widely used but badly maintained browser extensions and using them to distribute malware is a real thing.)
For example: the software everyone cares about is in a repo. The company uploads a version of a core library, such as glibc or libstdc++ in their repo and set it up with a very specific version number. Then they wait a bit, and upload a version of the much-cared software that declares a dependency against the specific library version. When the end users upgrade their packages, they also get a compromised core system library and all of a sudden ALL the software on their system is affected. The software you added the repo for has not been tampered with. But a backdoor from the core library is now present everywhere.
I worked with Nokia and Intel before and during the Maemo/Meego fusion. Back in 2010/2011 I had an early draft patch against libzypper that would have allowed to set certain package priority levels behind a fixed signing key, and made the above attack impossible. (Others were looking at how to confine the install scripts.) I went to a holiday in January 2011 and during that time, Elopcalypse happened. When I came back, the project no longer existed and my RFC patch never saw the light of the day.
Yes, there's a legitimate risk (and accompanying threat model) when trusting package repositories. But I don't understand the specific threat model that involves not trusting Signal's package repository while (1) trusting a random third-party package that (2) just redistributes (in the best case) the official binary.
I trust Signal, the company, as an author of specific type of communications software. I hesitate to trust them with root on my systems. The company and their intentions are, for the best of my knowledge, benign - but I have seen far too many well-meaning packaging snafus over the past 25 years to add even them to my sources.list.d; and in fact, I believe that with the actions of the company over the past ~three years they have squandered lot of the goodwill they had built up. I'm sorry to say, but the theme to me has felt like one of miscommunication combined with a lack of foresight.
I do trust they have had good reasons for everything. But optics are important, and for stewards of such a critical piece of software Signal have come up with questionably announced surprises. In a domain where boring is the characteristic everyone looks for.[ß]
A bit more context. As of now, there are only two third-party APT repositories that I can stomach. The official Postgres repo, and the Deadsnakes PPA. Both are maintained by the actual package maintainers, so they benefit from the assumed baseline and robustness.
ß: btw, I understand the SMS stuff. From an engineering effort perspective it makes sense, given what shitshow the SMS/MMS protocol stacks are. And with RCS, future integration would not be guaranteed at all. But it still came as a surprise.
Sadly many Linux distributions do not have user-friendly ways to install third-party applications and as a result we see instructions on running curl via sudo bash.
But again: what's the threat model here? If you're worried about someone stealing your messages, then they don't need root access -- they just need to give you a malicious build of Signal. That's way easier in an unofficial ecosystem like Snap than it is with a third-party package repository that Signal's developers are signing for.
(My understanding is that you can also configure apt to limit packages on a per-source basis, but I won't recommend that since I don't think anybody bothers to do that.)
By installing signal-desktop you give Signal not only access to your messages (which is fine), but root access to the whole system which allows reading and modifying any file. Even if Signal doesn't have malicious intents, they might have vulnerabilities in their installation or configuration scripts.
My understanding (as an outsider) is that Signal doesn't object to you building yourself a copy of Signal Desktop for source, but they do object to anybody building it for others, especially when they brand it as "Signal." That doesn't seem especially unreasonable to me: E2EE is a domain where trust is established exactingly; a proliferation of unreviewed third-party builds compromises environmental trust.
That would still be your lawyers talking to their lawyers. The channels for handling DMCA takedowns are much more efficient than channels for handling something custom.
goodpoint's answer is probably the best longer term answer: someone needs to fork Signal and manage it properly. But it's not as simple as just rebranding the software, it needs lots of difficult technical work to fix its many problems.
Why is that?
It is not like most of my social groups are me-centric, which forces me to pick battles carefully. Now that I moved people to signal, I need to do what I can to try moving signal to my ideal space ( no phone requirement being one of them, 3rd party clients and so on ).
That list is still short. I would love to be able to return to pidgin days, where all I had to connect my various accounts >.>
I do not know if the issue is that some the features are just incompatible with standards?
Sadly, the biggest problem is inertia.
Threema is liked for security. I haven't used it, but my mother's tennis group is using it, and they're all 65+.
I used this snap package thinking it was an official one, if I had known that it isn't I wouldn't have installed it.
Whoa. That's unexpected.
You could argue that it's a trademark issue, except that if it was, this makes a DMCA request illegal as it's not a tool to enforce trademark issues. And in addition, while the AGPLv3 has allowances for trademark carve-outs, Signal makes none.
It's not a good look for the lawyers to be completely in the dark on an issue so core to their company's business.
> ... a company that prides itself on being tech-centric ...
I can't see why this matters. Wouldn't it also be a worthy question for $NOT_TECH_COMPANY if their lawyers send a DMCA takedown request in such a manner?
It's bad in any case, it's worse when you're uninformed on an issue core to your entire mission. This is an area their lawyers should be exceptionally experienced and informed in, where it'd be potentially easier to forgive a lawyer completely green on FOSS making a mistake on something they thought was straightforward.
To clarify, any lawyer working for any company with a publicly available physical (read: non-software or computer hardware) product or service that I've heard of should ever make this mistake. That's why I wouldn't think it's especially weird that the company in question is one who offers a software product.
Anyway, you do otherwise make a good point. I can understand that someone sees it that way. (And thanks for explaining your perspective!)
Trying to prevent legal from being overzealous while not chilling their ability to do their job seems like a very challenging problem.
Putting my tinfoil hat on, all it takes is one unofficial Snap maintainer to be approached by one Glow-In-The-Dark with an offer they can't refuse to infect a hundred thousand users with key material compromise.
I hate to say it, but Signal is doing the right thing, here.
e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or
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 [email protected].
https://github.com/signalapp/Signal-Desktop/blob/main/LICENS...
I think what Signal is objecting to is that the snap looked like it was packaged and distributed by Signal when the files included could have been modified with a backdoor or whatever.
Canonical's communication to me was initially lacking due to issues in their process, the process has been amended and I'm back in the loop again.