Signal 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.
Correct. We spoke to our attorneys and found the breakdown in communication. We are working to rectify and reinstate signal-desktop ASAP. Sorry for the confusion.
Will a similar line of communication be established with other open source distribution platforms (such as F-Droid) that would also like to distribute binaries and call them Signal?
Because it means their lawyers are firing off in random, uninformed directions. There's no copyright issue, as the maintainers of the Snap have a copyright license (the AGPLv3) to do what they are doing.
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?
I'm not sure I understand your confusion entirely, would appreciate some clarification.
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.
I think a lawyer that's completely green on FOSS and working for any company I've heard of should never have been hired. Maybe I'm naive but that sounds insane to me.
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 never 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!)
So you're saying signal requested their own program be removed from the snap store? Sorry, I'm a little confused on terms. When you say snap maintainer, are you saying you are the maintainer of the signal snap package, or that you're a maintainer of snap itself?
If that's the issue, it's (at most) a trademark violation instead of a copyright violation, which means the DMCA complaint was filed under false premises.
I don't see where the source was being offered by the distributors of this package which would mean they were in violation of the AGPL and it was therefore a copyright violation.
The AGPLv3 only requires that you make the source available, that can even be on request, that can be on a CD. You can even, to quote the AGPLv3 itself, charge for that CD "for a price no more than your reasonable cost of physically performing this conveying of source."
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.
A trademark violation is a copyright violation, because a trademark is copyrighted at first inception, before anyone adds the '™'.
A company is also compelled to take actions like this to maintain the rights to thier own trademarks.
That's my understanding; IANAL.
There's no need to downvote me, as I'm only engaging in polite conversation, just explain it. And if you can support your argument with qualifications, that would be nice.
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.
You can't (legally) do a DMCA takedown for a trademark violation. You can use a copyright license that requires a user of a copyrighted work to respect your trademark (or whatever, basically). Then if someone doesn't meet those terms, the copyright license is revoked, and they are in violation of copyright law. However, this is legally just a DMCA takedown for a copyright violation.
Link to where Signal added these terms? You've posted a variant of this claim several times on this post but as far as I can see Signal-Desktop is licensed under a pure AGPLv3 which definitely does not have such terms.
This is not correct. The trademark doesn't affect the copyright but you need both in order to publish binaries with the original name and logo in a store.
You need a copyright license to use the binary. You need a trademark license to use the trademark. See the firefox -> iceweasel kerfuffle
At a naive level, this sounds like the sort of supply chain attack we've all been taught to fear. Asking seriously: has this build been replicated? is the source different from mainline? if so, what changed and who changed it?
That’s also how free software distros work, and have always worked, in general: their job is[1] to prioritize the interests of the users as they see them over the vision of the developers, so that the users can choose the distro that reflects their interests most and still be able to use the software.
What are the terms that Signal attaches to the binaries?
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.
I'm the last person to defend lawyers, DMCA takedowns, etc. But Signal has very strict build processes in place to ensure (to the best of their ability, anyway) that the official binaries are devoid of side-channel attack vulnerabilities.
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.
Read the full context of that rule. The entire section allows those provisions to be applied, it does not make those provisions. The APGLv3 disallows any further restrictions beyond the license to be applied, except for a handful of exceptions. That's one of them. And if such an exception is made, further instructions are provided to inform downstream users of them. Signal did not follow those instructions and didn't make any of the permitted exceptions.
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.
They own it, sure, but they license it out freely. They've released their work under a license that allows anyone use of their trademark, as long as they stick by the AGPLv3. The AGPLv3 is written permission.
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.
$ sudo apt-get install signal
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package signal
and we don't need to resort to unofficial snap packages
It's not a "random" repository, it's their official repository. They seem to be doing everything right (or as right as possible), including providing a signing key (which you can independently verify) and using an HTTPS host.
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?
This threat model was at the heart of Maemo's and later Meego's app store criteria. Both APT and RPM repository trust model is flat: all repositories have the same privileges to make packages available for upload, and can declare any dependencies they choose in their packages. This allows a third party to override any package in the system.
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.
I think I addressed this in the adjacent reply[1].
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.
The threat model here isn't about trusting one third-party repo and distrusting another. It's about trusting any third-party repository without exceptionally good reasons.
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.
Adding third-party repositories is actually dangerous because they can replace packages on your system (for example, bash) and run scripts with root privileges during installation.
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.
Yes, I suppose Signal could replace other packages on your system by updating their package lists with versions newer than those on the official index.
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.
Okay, but that's not what any of the parties in this current case are doing: the Snap in question is a third-party build, not a source distribution.
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.
I already trust Debian's repositories with my system; so getting Signal from Debian's repositories would not make my system or Signal more vulnerable. By adding Signal's deb repositories, I need to also trust Signal not to mess with the rest of my system.
Presumably for the same reason they don't want someone else packaging snap for them its another party to attack in order to attack their users in a way that would destroy trust in their product given its sensitive nature.
One potential reason is that their release cycle is too fast for the official Debian repositories, and they don't want to slow it down. Supporting old versions is a cost they don't want to bear.
All of their builds have shelf lives of 90 days. You must update at least that often or your app will stop working, so it's a non-starter for inclusion in the official Debian repos.
I don't think there is any reason for publishers to force users to download their software from the internet now that the Snap Store and Flathub exists.
I've had so many bad experiences with broken third party packages or worse, "installers".
I just expunged the snap system entirely from my ubuntu. It feels much snapier without it. I've never tried flatpacks, my preference is to AppImages, they seem to perform much better than other systems I've tried.
I can think of a lot of reasons why publishers of privacy and security related software would want to direct distribute their software rather than relying on 3rd parties if it is avoidable.
Signal is secure communications used not only by nerds but in situations in which privacy is a requirement for safety. In this singular case do you think its a greater security risk that someone may compromise signal and ergo your computer or that one or more of 97 different stores/repos with a multitude of different maintainers get attacked and used to first compromise your communications and then probably your computer as well?
Remember you are expecting the maintainer to not only be honest you are expecting them to secure his own machine as well.
I agree that policing a bunch of third party rebundling of apps is problematic but the entire idea of just giving up and letting user applications splat all over my system because that's how linux always has been doesn't work.
Unfortunately, this is the world Signal lives in. For binary debian packages to be installed securely directly from a vendor requires the installation of gpg keys which is what 2 of the 3 commands are regarding. If Ubuntu had spent resources to develop a convenient way for developers to directly provide binaries to the users of their OS instead of developing a system where they are gatekeepers and distribute all packages Signal would now be able to provide an easier secure method of installation. If you were providing a privacy focused product which in some uses that privacy can be the difference between life and death, would you want to turn over supply chain protection of that product to a 3rd party?
What made you think they'd be willing to compile from untrusted sources?
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
I’m a developer too. Currently job title “senior enterprise systems engineer”. It would take me much longer than that to ensure the code is ok. Additionally without modelling the code (and proving it correct) in something like COQ, you will never understand the calculus of inductive constructions behind the code and have no guarantees as to its correctness.
This is not secure at all because you just gave Signal root access to your system. By adding their keys you also have granted a permission for Signal to replace any packages on your system.
I would instead manually download and unpack the app, create separate user for it, and run it in chroot. Much safer than your method.
Respectfully, I don't think that's correct, or possibly I am misreading your comment. IIUC, placing a key in /usr/share/keyrings does not allow those keys to sign any package, only the packages designated with "signed-by" in the apt list.
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.
Yes, I made a mistake about the key. Adding a key is safe by itself. However by adding third-party repository you are granting Signal a permission to replace packages on your system (unless you manually whitelist package names in apt preferences), and by installing a package from Signal repository you grant it root access to your system.
Sadly debian-based distributions do not respect the principle of least privileges and grant unnecessary permissions to installation scripts.
>Yeah, let's teach users to paste sudo commands into the terminal. That's great.
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.
The difference is that the stream coming out of curl and entering sh is ephemeral. With this device, there is no checksum or signature (as with apt). If you pipe curl into sh, you also leave no trail of what you've run. A malicious actor can also hinder analysis by serving different payloads per user-agent, per time of day, per subnet; or only serving the malicious payload intermittently.
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.
>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.
Yeah, it's possible for a web server to detect and change the returned data maliciously. Even with user agent and all other factors changed to match, it's possible to detect even the difference between being piped into another command vs being redirected to a file.
It helps that Signal uses an HTTPS apt repo and includes "signed-by=/usr/share/keyrings/signal-desktop-keyring.gpg" in the apt list entry. If their download server were compromised, (and assuming the hacker didn't also get the private gpg key) the attacker would have to provide malicious archives selectively to avoid detection. Anyone who installed the old key (e.g., me) would notice the key validation errors.
So what? I can inspect downloaded code and find the backdoor, or a trojan, or an error. I did it few times already in last 30 years. If you cannot do that doesn't mean that nobody can. But I cannot do that with `curl | bash`.
I cam do that on MY machine. I cannot do that on your. I can download code, inspect it, install, and then create a RPM package, which can be installed in a safe way by DNF package manager, but I cannot do that with `curl | bash` method of installation.
>I can download code, inspect it, install, and then create a RPM package, which can be installed in a safe way by DNF package manager, but I cannot do that with `curl | bash` method of installation.
Sounds great as long as they get proper permission to distribute the software they’re distributing. Otherwise it’s just another untrusted party in the supply chain
> It should NEVER be more than 1 line of shell or 2 mouse clicks to install anything.
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.
It’s true, they should distribute a .deb that ensures the repo and key are installed so it gets updates. However, your suggestion that they should just capitulate and allow 3rd parties to violate trademark seems like a pretty bad take.
No. A DCMA takedown is your lawyers contacting their lawyers and saying that you're invoking a law which forces them to immediately take something down or risk severe legal ramifications. Isn't it better to reach out without invoking a DCMA and see if the other party is willing to cooperate first?
>Isn't it better to reach out without invoking a DCMA and see if the other party is willing to cooperate first?
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.
Those channels are illegal to use outside of the copyright issues they're intended for. It's not just a free "hey take this down for me, will ya?" button.
If there was an icon, that could have be what was copyrighted. Perhaps it's from the usage of the deb package. The creator of a project that uses the GPL can actually have a download link to that software which is under a different license that is not freely distributable.
The icon is in the repo covered by the AGPLv3. Signal-Desktop does not have a CLA that would enable them to license the built binary anything but AGPLv3, as they do not have sole copyright over the code. They themselves are also bound by the AGPLv3.
If their explicit goal is having it taken down, and the law gives them explicit ability to do so, why would they waste the time? A DMCA isn't rude, it's just a strictly outlined process.
The law doesn't give them the ability, as the DMCA is for copyright and with an unrestricted free software license, there is no copyright issue. The takedown itself was illegal.
Yet another reason not to use Signal. The correct behavior would have been for signal to offer an official snap or to contact the maintainer. Instead they send their legal team...
Moxies always been fairly dictatorial about Signal. no third party clients, no decentralization. im not surprised to see a DMCA at all.
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.
My grandma uses WhatsApp Web and Facebook hasn't taken down the WhatsApp Web snap yet. Both are end to end encrypted and based on the same transport but one of them used copyright law to take down a redistribution of their application.
If "a messenger that works" is a narrow lens, then sure. WhatsApp is still as secure as it ever was and everyone is already on it.
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.
You mix up concepts. The client app is responsible for e2ee, you don't have to care about the server.
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.
> 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).
> 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.
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.
Look at how signal vs meta make their money. Meta's entire business model is built around directly violating people's privacy, and conspiring with other businesses to violate people's privacy.
Meta is a publicly traded company. Signal is a 501c3, it's a completely different kind of organization.
I already said that meta has an incentive to snarf up your data.
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.
Beyond that, metadata can be every bit as interesting as the actual conversation. Alice only talks to Bob on the weekend. Charlie sending a message to Dave cascades to Dave talking to Eric, Francis, and Gavin. Herald is only online from this business' IP address during opening hours.
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.
It's extremely expensive outside the US and can't be sent over wifi - so if you're communicating with someone abroad it's not a very convenient option. You're also missing out on E2EE and, lastly, Apple has corrupted the utility of it as a communication method for half of the devices out there.
I'm not in US, and unlimited sms is included in monthly subscription.
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.
Federating is hard, and Signal is trying hard to solve the metadata problem in a fundamentally different way (which I happen to believe is better).
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.
You can build their client and use it yourself, but they don't want you to distribute it and they don't want you using their infra and API from a third party client.
Honestly not what I expected to hear about Moxie. Any more tales that back this up? If this line of behavior is true then I think it's time to move on.
I was ready to grab my pitchfork after that first comment, but farther down:
>>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.
Ah yes, velocity. I want my secure and encrypted messaging app to have development velocity so they can add sketchy cryptocurrencies, stories and giphy integrations instead of making a stable and polished app that can send messages and pictures.
There's a time for high velocity, and a time for stability. Federation, at least officially-supported federation is difficult when it's time for high velocity. Having used Signal in 2016 when that thread was written, it makes sense to me that Moxie felt it was a time for high velocity.
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.
> 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.
Wait? Really? I've been out of the loop regarding Signal. But "crypto punk/anarchist" Moxie Marlinspike is using DMCA takedowns and doesn't like decentralization and 3rd party clients? I'm flabbergasted.
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.
AGPLv3 does not somehow permit trademark violations. Signal has taken issue with third parties building binaries and calling them Signal, and I can’t really blame them. This is the same reason Signal isn’t in F-Droid
DMCA takedowns are for copyright only, not trademark. Requesting or demanding removal for trademark reasons is legitimate, but using the DMCA takedown process when there is not a copyright violation is fraudulent.
From galgalesh, the snap package maintainer, in the linked forum post:
> 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.
> 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.
Signal offers an official deb. The correct behavior would have been for third parties to not distribute trademark-infringing binaries and call them Signal
Yeah, checking on IA the snapcraft page, before Sep there was no notice (one was added early Sep) this was an unofficial package and the link just below the package name was/is link to Signal homepage with tooltip saying developer. Think the issue was the lack of such notice before. Because on Flathub the equivalent package exists fine: https://flathub.org/apps/details/org.signal.Signal
Signal has historically taken issue with 3rd parties distributing binaries and calling them Signal (understandably so). Most prominently with another serial trademark violator, F-Droid
Regardless of whether you actually should* be able to, "should" and "can" don't always match.
* 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.
Modification of binaries of open source projects is a common and perhaps the only issue from a trademark standpoint. Firefox and debian used to have this too until they resolved it at some point.
- 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.
Jitsi Meet is pretty good for video, and relatively easy to self-host, though you'll need some decent resources for it. The docker-jitsi-meet project[0] can get you started quickly
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.
keybase.io has been great, although it's not without its risks either since it was acquired by Zoom. It's still up and seemingly maintained but AFAIK there's no new feature work.
I've heard WhatsApp recommended from people I trust, but I have never personally used it so can't speak from experience.
The legal team at the company I work for are suggesting to remove keybase and treat it as compromised as there is no way of knowing of keys and other data has not been shared with the Chinese government. No proof at all of course, just the world we live in I guess :)
None of these suggest you shouldn't use signal - or that it's not meeting its goal of secure communication (except the last one I suppose).
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).
Signal has repeatedly been audited[1] so there's more reason to believe the protocol has the capacity to be secure than other options. Obviously if you believe the company is actively subverting their goal, you should use your own fork.
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).
Not GP but I'm a Signal user and here are my gripes:
- 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.
Backups work fine on my Android phone. They consistently go to a folder and Syncthing backs them up from there.
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 thought it was something I did that causes it to not ring. Glad it's not just me that has the issue.
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.
>Backups work fine on my Android phone. They consistently go to a folder and Syncthing backs them up from there.
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. No average user knows what Syncthing is and how to set it up. People expect the messaging app to have its own backup-restore system compatible with the cloud storage provider setup in the phone's OS.
>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 were 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's end-to-end encrypted, but so does WhatsApp, and until we have an independent security audit of all of Signal's code and infrastructure, 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 or owned by Russian/CCP tech magnates, 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 for the bytes going down the internet pipe and not have an impact on any other features.
It takes a few clicks and entering a password to enable backups. Restore also worked fine the one time I needed it. They can go to Google Drive just fine, Syncthing is only so I have the backups going to my NAS instead.
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.
Looking at the source code, they're using the newer Camera2 API. I have no expertise in implementing said API, and a quick comparison between Signal's code and that of Open Camera suggests the Signal developers don't have a whole lot more.
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.
If you want to be reductionist, everything is a feature. But if an app is missing something so basic as to impact usability, I might consider it a bug. It's a matter of opinion where the line is, of course.
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
No, that's not just my criteria, but Signal's own, when they entered the market as an alternatives to WhatsApp.
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, quirks, and lack of basic features for a modern messaging app.
Just being able to send encrypted ASCII characters to someone is not enough to make a good messaging app these days.
No, they are your personal criteria. Your “gripes” as you said.
> 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.
Typical behavior from Signal. They have a track record of hostility that we as a community should really not be tolerating. I do not use Signal and I tell my friends not to, either. Play nice or don't play at all.
Problem is, I already moved my friends and family to Signal and removed Whatsapp from my phone. It was an uphill battle that I don't want to fight again. What do I do, now? As much as there's a lot of questionable stuff on Signal, that's nothing compared to whatsapp. Do you suggest a Signal alternative that is significantly better?
I don't have an answer which is likely to satisfy you. I'm still a grumpy old IRC user. I communicate with non-technical friends and family via email, SMS, and Jitsi Meet. I allowed myself to be persuaded to try Matrix earlier this year and so far I've regret it.
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.
This. It was hard enough to migrate people from Whatsapp ( as in, for all my privacy gripes, it is hard to argue that it just works very well in most instances ).
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 ).
Sounds like sunk cost. What are your chances to influence Signal leadership in any way?
A better idea would be to use internet standands for messaging to avoid vendor lock-in.
I personally do not think this is user hostile because users have an interest in being able to distinguish between official and unofficial distribution of software, in particular in a security relevant case like this.
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.
What's the alternative? My mom onboarded my entire extended family to Signal, and she's not technical. I'm not sure of anything else, outside of Meta-owned WhatsApp, with that kind of simplicity.
This is not a good look. The snap has been gone for almost a month, with seemingly no information given to the maintainer or users about why, except a belated "we removed it for policy reasons" 21 days ago. And if this happens to maintainers associated with Snapcrafters, imagine how you're treated if you're just some random person or company who maintains your own snap.
This is the sort of reason why people are concerned about an ecosystem where Canonical has 100% of the control of the only distribution mechanism. I suppose this is just a confirmation of the legitimacy of those fears.
Another perspective: Canonical's IoT offering, Ubuntu Core, is based around the idea that Canonical provides the base operating system, and you provide your software as a snap, uploaded to Canonical's snap store, and you push updates to your IoT product by pushing an updated snap to the store. That has always rubbed me the wrong way, but "Canonical will just delete the snap and not respond to questions about why" wasn't even something I had considered as a possibility before.
And last time I checked, they refused to let you use your own signing keys. Means you do not get end to end trust for your own bits but need to rely on Canonical that they don’t screw up - with the obvious effect of strong vendor lock-in as I cannot sign and run my own bits.
Yeah, that's the kind of stuff which has made Ubuntu Core rub me the wrong way before this. I'm a much bigger fan of Yocto[1], with something like Rauc[2] for the software upgrade system. It's more work to get going, but in the end, you're in control of your product, not Canonical.
I have spent years developing systems using Yocto, and it's a steep learning curve for the average developer. Maintaining a proper distribution is not trivial. However, communities exist that want to band together and create distributions that meet their common set of focused needs, and Yocto would be perfect for many of those use cases.
Of course, take my opinion with a grain of salt. I am currently developing a tool at my day job to significantly lower the developer time required to produce and regularly release our Yocto-based distributions. I hope to be able to release that package as open source at some point.
In any case, Yocto is infinitely better than Ubuntu's Snap Crap.
This is the reason that Signal has given for not providing/allowing their client on f-droid (since all f-droid apks are signed by f-droid rather than the maintainer). I wouldn't be surprised if it were the issue here.
Couldn't you just double sign your bits? Sign your payload with your key, then wrap that in a snap with their key; snap verifies the outer sig, then an "inner" installer verifies the sig of the payload.
That said, I would run screaming from an ecosystem with such insanity.
In fact, I am poised at the starting line of that sprint, but I'm still trying to decide what my next distribution will be that provides similar quality and cadence. It's a somewhat sad day, as my servers have been running Ubuntu for almost two decades. A switch will be immensely painful, but the state of their snap crap is pushing me to switch all of my systems once and for all. Worse for Canonical, I then will be taking all of the systems in my engineering division to those greener pastures.
You get your private snap store and upload your snaps to it. Signing and delivery is only assured between the IoT device and the snap store. Not between you (the developer) and the device.
To be fair, as long as you don’t issue a DMCA takedown for your own software, this particular case is not a good example of something to be worried about in that situation. There may be plenty of other concerns, of course.
Due to how the Snapcrafters publisher works, Canonical was communicating with the "wrong" person about this takedown. They've since amended their process to make sure this doesn't happen anymore. (Snapcrafters is a team of community volunteers maintaining unofficial packages)
Due to how lawyers and legal threats work, Canonical is very hesitant to publicly talk about what is going on. You can expect a thorough post-mortem after the legal issues are cleared up.
While this incident isn't good, I still think the setup is a ton better than Flathub, where you have flatpaks being maintained by third parties with no relationship to the software vendors. For example, all of the Jetbrains snaps are managed by a volunteer, as is Zoom (!)
Compromise one of those devs' personal computers, and you've now got a path to getting a backdoor out to everybody using those. I trust Canonical's security team over random volunteers.
I agree, FlatHub isn't ideal either. They also fail to make it clear that the flatpak isn't made by the developers of the software, the "developers" on the Zoom snap lists zoom.us, and the only potential indication that it might not be official is the "See details" link under "Publisher" which takes you to a github contributors list.
How is a user supposed to decide whether they want to trust a flatpak published mainly by "flathubbot" (according to the page linked by FlatHub) and a bit by various other contributors with names like "TheEvilSkeleton" and "barthalion"? I have no idea.
Yes, but distributions provide a security layer, as well as source repositories. With flathub, binaries with no source code are being packaged up (albeit with scripts), and the process of pushing updates is quite easy.
Not really, distributions do not check every piece of code that is packaged and distributed.
I just meant that centralising distribution does not make thing specifically safe neither. Some form of audit over flathub would be nice though, but I personally much prefer projects open to community contributions.
It looks a lot like they are auditing what gets included very tightly. On the other hand, Flathub is all about convenience, and while I get where they're coming from, they've already shot themselves in the foot when it comes to credibility by allowing third parties to package binaries. If the sandboxes that flatpaks run in were really impenetrable, that'd matter much less, but they're not.
Flatpak is more like Docker than Snap. Flathub, an unaffiliated 3rd party that uses the Flatpak format and provides a Flatpak repo -- Flathub, allows people to publish packages to their repo that aren't the official developers.
It's because Zoom / Jetbrains haven't stepped up to package their software as flatpak, so volunteers got in there. There's a flathub policy that a flatpak project will be handed over to the vendor to maintain if they make that request - which is definitely good, but the fact of those volunteers being able to do this (however well intentioned) is not.
Yep. On top of that, some people just straight-up don't intend to port their software to Flatpak. There are a lot of unofficially supported packages (or incomplete ports) that will remain that way forever, which really makes Flatpak no better than the AUR in many respects.
The biggest problem IMO is that Flatpak coupled itself too closely with Bubblewrap. Flatpak is missing many key features because of this (support for running services???), and it makes zero sense in the context of a modern desktop. Apps like Flatseal should focus on sandboxing regular applications with Bubblewrap rather than trying to manage all of the software on it's own. As-is, Flatpak is the last resort of packaging methods for all of my systems, even behind Snap.
> There is nothing stopping Canonical from offering a Flatpak based App Store that only contains approved and vetted apps.
I agree consolidation on a single format would be great. They have no incentive to make this switch though - most of the flak they're taking is about them being in control of their app store, rather than snap as a technology.
There apparently was communication with someone related Snapcraft so there was effort to communicate, since the account used for upload was a generic one I think they be forgiven for not doing anything more than that. Regarding the reason for removal that is another issue.
After reading the thread, I still have no idea why it got removed, so: why did it get removed? What part(s) of the snap policies did they violate, and how is it possible that even something doesn't charge $100 a year before you can even publish a snap doesn't even notify the maintainers that their app got removed? Just because you run an app store doesn't mean Apple and Google's opaque refusal system is the part you should take inspiration from, too.
No one knows [1], except Snap. Not even the maintainers :(
Snaps response [2] seems to be:
> I understand the sudden move of signal-desktop can be disruptive for people wishing to install this package. Just to confirm the reason for the absence - Snap Store administrators had to remove the snap in accordance with our policies. We hope to have it back shortly.
I've been a happy Linux Mint users for a long time. The day they decide to "downgrade" to Snap, is the day I'm going to Debian o whatever is in vogue and user friendly at that time.
I do the same personally, and used to with my fleet at work. But Ubuntu Advantage is unfortunately a snap, so if you need any of those features, you're stuck. And we do.
And then engineers started installing snaps on their dev instances, I think mostly by accident...
Unfortunately Firefox is a snap on Ubuntu (eventually I'll get around to switching to a better distro -- "it's a laptop," I said, "it'll be nice to have Ubuntu deal with everything for me," big mistake).
It's fairly straightforward to add a PPA containing a normally-packaged Firefox. But it's always a bad sign when you start having to fight against the distro maintainer's choices.
Yeah, I'm used to starting with a base install and building up, I just tried out Ubuntu because I'd switched from desktop to laptop, remembered the bad-old-days of getting laptops working, and figured it would be nice to have Ubuntu handle all that stuff. But now I spend as much time bumping up against their design as I used to spend hunting down wifi drivers 10 years ago or whatever.
This is why I abandoned Ubuntu. I no longer wish to fight the system and I want to have something I can easily recommend to others. I don't want "snap" getting installed surreptitiously, that's far too much like Microsoft.
I went back to Debian in the end. Absolutely nothing wrong with good old apt. Nice to have a clean and predictable system that respects my choices.
I think the long term solution will be to just hop distros anyway (Ubuntu is doing their thing and it works for lots of people, they don't have to be everything for everybody, there are various other little pain-points for me that make it not really worthwhile).
The whole snap thing is clearly doomed anyway. It's got no chance of "winning" the new wave of app distribution on Linux, being easily the most-hated of the three taking any kind of similar approach (AppImage, Flatpack). Canonical just hasn't thrown in the towel yet, for whatever reason.
In my brief introduction to it, there seems to be an impedance mismatch between snaps and the entire philosophy of Linux (and Unix more generally).
When a program tries to build it's own little world without consideration for the conventions of the operating system it creates all sorts of problems and doesn't allow the user to leverage its functions as part of a complete system like they can with programs that follow the decades old Unix patterns.
What I'm saying is if Canonical wants to be in the Snaps business, perhaps they should make SnapOS.
Ubuntu minus snap is to me is still worth the headache honestly. Once you write the build script that cleans up the crap you forget it was ever even there.
Would I use Ubuntu as a desktop, oh hell no -- nothing is ever going to beat Fedora.
I would because hot damn does Redhat have their shit together when it comes to creating a stable cohesive system but I use Lightsail so my options are limited and I'm not touching Centos 8 since it's already EOL.
> The Certbot snap supports the x86_64, ARMv7, and ARMv8 architectures. While we strongly recommend that most users install Certbot through the snap, you can find alternate installation instructions here.
Shame on you, certbot and EFF.
Of all people, I expected better from you.
For my Fedora people, looks like we can directly install with `dnf`.
Debian aptitude people should prefer the same.
Available Packages
Name : certbot
Version : 1.30.0
Release : 1.fc36
Architecture : noarch
Size : 44 k
Source : certbot-1.30.0-1.fc36.src.rpm
Repository : updates
Summary : A free, automated certificate authority client
URL : https://pypi.python.org/pypi/certbot
License : Apache-2.0
Description : certbot is a free, automated certificate authority that aims
: to lower the barriers to entry for encrypting all HTTP traffic on the internet.
Though I guess there's a risk that eventually the Ubuntu package becomes a facade package like Chrome is, that has no content but uses a postinstall script to grab you the snap instead.
On the bright side, their move to snap finally provided me with the impetus to switch to acme.sh (https://github.com/acmesh-official/acme.sh) and it's been a much nicer experience.
I understand the appeal as the developer, Linux package management is heavily fragmented. The snap is build once deploy everywhere. But there are a lot of drawbacks for the user. I don't want my applications to be huge bundles that use twice the ram and have an alternate update system. As a primarily Debian user, I would much rather have a deb repo. If they insist on bundling it like this, flatpak would be a better choice than snap.
The snap identifies itself as an unofficial snap package of signal-desktop so my assumption is this is third-party volunteers repackaging it for snap users (and possibly non-deb systems).
This kind of thing is vindicating for those of us who stayed away from snaps precisely because the server side is proprietary and the snap tooling only supports Canonical's centralized store.
A centralized service being the only option for software distribution is too large of a failure point, no matter who's running it.
The application went down because of a DMCA request. The same would've happened with APT repositories and other distribution systems in that the "official" source would disappear. You could've installed it from an alternative source were that to happen to a simple repository but you still can now.
I have plenty of gripes with Snap but this time the Signal team is to blame.
Were that to happen to an official apt repository, you could install from an alternative apt repository. In this case, you can't install from an alternative snap repository. Sure, you can go build a binary yourself and keep it up to date yourself, but that's not really a user-friendly solution in the long term.
Your saving grace here is that Ubuntu as a Debian derivative still supports apt repos, but if snaps were to really gain traction that might not always be the case. A desktop version of Ubuntu Core (akin to Fedora Silverblue for flatpak) would not have this luxury.
It's Signal's fault for getting lawyers involved before communicating with the people that put the alternative up. If it's that much of a problem, asking nicely would probably have worked. They could even set up a mechanism to transfer users to the official distribution if they wanted to put in the effort to help their users.
As a side note, "Signal" is a generic English word. The logo is a generic speech bubble. Copyright and trademark law should not be piecing up language and handing it out to tech companies that decided that all app names should be no longer than two syllables. I'm sure legally speaking there's a trademark case to be made here, but ethically speaking I think it's wrong.
Signal isn’t saying no one can use the word signal. The problem arises when you use all of their branding together in such a way that could plausibly fool someone into thinking it’s their software, which very much appears to have happened here (see this entire thread full of people who installed this trademark violating build thinking it was legit)
yeah I noticed that. Quite a reversal from their previous position, which was incredibly clear. I wonder if they'll extend this policy to other groups that have previously been shut down for doing the same thing (F-Droid being the obvious one here).
Canonical distributes the snap in the sense of “owns the store and infrastructure” but the publisher is not canonical - it’s snapcrafters which is a group of community volunteers.
I'm being slightly offtopic here but I really dislike how slow Firefox is to launch since it became a snap package as a default on Ubuntu 22.04. I know I can uninstall the Firefox snap and install it through APT, but I imagine more and more packages will become snaps by default on Ubuntu.
And finding out now that it's possible that snaps are part of a walled garden, just like app/play stores are is really bumming me out.
I'm rather new to linux and Ubuntu is the distro I'm most familiar with and I also really like using KDE. So I'm wondering if it's feasible to continue using a Ubuntu based distribution while completely avoiding Snaps or should I just switch distros (maybe to another one that runs KDE).
Switching distros is pretty easy. Debian is a classic that will support KDE and will be familiar in some other ways.
If you're writing software, the switch will be a great way to see that your code is robust and not too closely coupled to the peculiarities of Ubuntu. Portability may not be an explicit goal but it turns out to have some benefits.
For a typical Ubuntu desktop user this is such a PITA. A small app like Spotify client takes around 15 seconds to start up on my beefed up workstation. Canonical pretends this issue doesn't exist but I've had enough and I'm switching to Fedora.
> They are openly hostile towards their own users.
Yes, and it's deeply ingrained in their culture so unlikely (IMHO) to change. My eyes first opened to this in April of 2011 when I was (horribly) surprised by Gnome being removed in favor of Unity, when I saw how they treated their users and community on forums and such. It was the same condescending attitude we see today where the user are complete idiots who want to do things the "wrong" way and the canonical employees (especially the "community managers") know the "right" way to do everything.
This is basically my feeling with PopOS as well. I bought a System76 laptop and decided to stick with PopOS (which came pre-installed) to try it out instead debian (which I usually run), but it's felt very much like a "our way or the highway experience". I'm moving off it and back to debian once I have the chance.
I'm also a big fan of Fedora and can recommend. Fedora does things a little differently that will take a bit of getting used to, but all in all it's mostly the same. You'll need to learn to use dnf instead of apt, and system files (like config files) will sometimes be in a different place (as Fedora follows FHS more closely, similar to Arch), but it's really not too bad.
I've never run the KDE spin of Fedora, but from what I understand it's popular and well maintained so shouldn't be an issue.
> They all run KDE, even when they don’t provide it out of the box. You can just install it and use KDE instead of Gnome.
Ubuntu has a lot to answer for, and planting the idea that you have to completely reinstall your OS to switch to a different window manager is right up there at the top. Kubuntu, Xubuntu, god those were terrible ideas.
Well, I have been using Ubuntu for many years. This kind of thing, centralizing packages and removing one without explanation etc makes me think I should move on. I suppose the alternative is to switch to Debian?
Or maybe there is something totally different that is becoming popular that I don't know about yet?
I switched from Ubuntu to Debian on the server side when Canonical started pushing Snaps on Ubuntu Server. Having a server dependency on a proprietary app store is unacceptable to me when open alternatives are available. Debian makes sense because it's upstream from Ubuntu and known for stability.
On the desktop side, Debian is also a stable choice, but you might prefer to go downstream from Ubuntu to get newer features sooner. Snap-free distros based on Ubuntu include Pop!_OS, Linux Mint, and elementary OS. There are also popular distros not based on Debian or Ubuntu, including Arch Linux (and its derivatives) and Fedora.
I also fled from Ubuntu recently due to Snaps, they are just plain terrible in every regard. I'm now much happier with Debian and Fedora when it comes to "plug and play" Distros.
Debian is probably the move if you want to keep stability, security, and minimize disruption. Most Ubuntu PPAs work on Debian too, in case that matters to you. I personally run Arch Linux on my dev machine, which has its own share of issues (mostly breaking changes due to being a continuous release distro with a focus on being up to date), but the Arch User Repository (AUR) is really good. IMO stay away from the redhat distros like Fedora.
I can't speak to the compatibility issues you hit, since that's obviously hardware specific.
Sorry I wasn't clear enough about the Ubuntu connection. Pop!_OS is based on Ubuntu, but Pop!_OS provides non-snap packages for (AFAIK) everything. So for me, Pop!_OS is like Ubuntu, minus the user-hostility.
It's easy to install Flatpak on your current Linux distro. Flatpak officially supports 36 distros. Some of them already have Flatpak built in, while others (including Ubuntu) require just a few minutes to set up Flatpak and Flathub:
DMCA takedowns need to go away forever. What an idiotic implementation of the law. If someone is claiming theft, they have to at least provide proof.
Imagine if I asked police to give me my neighbor's car, as I'm claiming it as mine, and they would have to immediately comply before investigating if my claim has merit?
How in the world did a walled garden ecosystem like Snap manage to embed itself so deeply into Linux culture? There needs to be a user and industry revolt against Snap for this sort of shenanigans.
No... there are many reasons to revolt against snap. That, and software that gets released on Snap Store only is definitely not worth using. Sorry for not having elaborated as to why snap sucks, but I have written so many comments on it already. I may look them up and bookmark them for future reference.
The snap distribution is unofficial. The Signal team only provides .deb files for Linux (seemingly built for Ubuntu Xenial) and any other distribution method on Linux is strictly done by volunteers.
If Signal is willing to leverage the DMCA to take down the Snap package, they could just as easily take down any other unofficial repository.
If you wish to solve this problem, write a letter to your favourite American legislator to protest the stupid way the DMCA is set up or contact Signal legal and tell them their use of the DMCA is bad for the open ecosystem that they operate in.
Someone freely choosing to grab an unofficial version of Signal from the store of their preference isn't the problem here.
The same was systemd did? The force of a multi-billion dollar company, where profit is far more important than doing it right?
Linux and OSS software became what it is, became the stable, secure powerhouse it is, literally dominating every aspect of computing, because profit was originally less important.
Look at Debian, which only ships when ready, and never ever to a fixed deadline.
Yet today, almost all private corps take and take and take, without every contributiong code and workers back.
Look at Ubuntu, a distro which literally could not even remotely exist without Debian, from which most of it is derived, and rebased to constantly.
To Ubuntu, a great leech of the OSS world, it is more important to give a crappy experience(snaps), than use Firefox LTS, for example.
So, do you think the adoption of systemd was motivated to a great extent by the influence of commercial companies' interest? Would you say that's true for distributions like Debian, which you gave as an example?
I'm not being facetious, it's just that this aspect has not been described to me so far, IIRC.
I wonder why Signal opposes flatpak so much. As far as I remember, they insist on sticking to .deb package only [1]. Seems like switching to Flatpak would benefit a lot of people now because of Steam Deck-induced Flatpak popularity [2].
I really despise the idea/existence of app stores.
Why can't a publishers website be their store front, then from that site, you can run (or "download"/"install" if you must) the app?
Technically it looks like that would actually work [1]. They could host the `.snap` file. Although I'm sure snap will add friction to this (as in, not simple let you open and click "Install") from a downloaded snap file, as they probably want you to use their app store.
For me, it's updates... I don't want popups telling me to update software every few days, and then opening a webpage, downloading a snap/deb/whatever, installing it again, with sudo passwords and all that,... and then open another app, another popup, another site, another .deb... It feels like windows.
I want a centralized "update" feature, that will do all that for me.
This can be done by signal adding its own repo, but it's a pain to add a per-app repo, if the app can be on the central (distribution-managed) one, especially if it's a popular app.
Not sure if your post was satire, but isn’t everything you mentioned doable with apt already? Signal already has an official apt repo so all you need to do is the standard apt upgrade and everything including signal would be updated.
The problem with that is now you've given a 3rd party power to update your system in any way that they want. Which is fine when it's just signal but less ideal when it's 20-30 randomish companies of varying degrees of trustworthiness. The point behind flatpaks et. al. is sandboxing applications so that they can be safely updated automatically.
I don't use apt but I think you can use the pinning feature in apt and only allow the Signal application from Signal's repo. It doesn't solve all problems since they could add dependencies from other repos, but at least it is partly stops them from adding their own dependencies in their repo.
Are they, technically, any different than APT repositories?
Don't get me wrong. I hate Snap much more than the next guy, but the idea of keeping a repository so you can go look for, and discover, stuff that is supposedly also vetted by someone is nice.
The issue is, when an app store is a monopoly and not standardized.
APT repositories is, in my eyes, an example of "the good" type of app store.
Technically not really, instead of packaging the software into a .deb it’s shipping a container and metadata to get it working.
I think the rub here is that the maintainers of the signal snap can't reuse the work they’ve already put in to this and offer it elsewhere in another snap repository as there’s no other snap repository possible
I always say that one of the problems in the Canonical's strategy with Snap is not to provide the backend allowing everyone to set their own "store". Then, Canonical would focus in the added value of their one, with things such as a payment processor, malware scanning, ci/cd integration, stats, etc making it appealing.
Flatpak allows this, but, in the other hand, despite I exclusively use Flatpak these days, I dislike the fact that is not focused in CLI apps but desktop ones instead.
There is a proprietary piece of software that is released on Snap Store only. They used to release a .deb file. When they did that, it was as easy as extracting the files from the .deb file and run the executable. With Snap, however, it is much more of a hassle to do the same thing. It is possible (at least for the one I have in mind), but yeah, no.
Do Linux users installing software actually have a "discovery problem"? The usual solution is to go to google.com and find in-depth information on the options available for a given class of software, with user reviews, notes on strengths and shortcomings, etc. I have never visited a store first on a desktop OS, and even average users of mobile OS' that I know will fire up Google first if they're actually trying to find the best implementation of X app. I don't know a single person that has anything good to say about the Windows app store.
The Year of the Linux Desktop isn't now, and it may never happen. Even if it does, I don't think any of the hypothetical "normie" Linux users would really care for it all that much. Trying to be the devil's advocate for things like the Snap store benefits a group of users that doesn't exist in any timeline at the expense of current users in this timeline.
Absolutely, when I want to find something, the first thing I will do is DNF search. It's amazing how much you can find and so quickly. It sorts in a smart way as well, where exact matches will appear first, then partial matches on the package name, and then metadata. This makes it quick and easy to see if what I want is there.
When searching on Google, I have to look through a bunch of crappy results from SEO optimized crap. Then when I find something that looks interesting, I have to see if it's packaged for Fedora or not. If not, then I have to hunt down either a GitHub page or look for a RPM file or a flat pack or app image. I won't use a snap even if it's the only distribution method.
There's also a very convenient way of checking for popularity, which doesn't necessarily mean it's a bad pic, but if the package is popular enough that somebody has packaged it for Fedora and maintains the package, there's a very high chance that it will work as needed.
If you don't currently check the apt or DNF repos first, I would definitely recommend doing so.
I do need t think discovery is the same problem any more. You can search for self hosted snaps about as well as you can within the snap store. However, trust can be an issue which has solutions that come at the cost of speed and storage.
Yea, don't bucket Linux users in with typical Google and Apple store users. I need no help "discovering" software through some companies arbitrary filter. I can use google, github, hacker news, etc.
That's a different problem to where the packages are hosted. You can host your own packages and get added to an official aggregator. Said aggregator can function as an automatic verification system to assure people that your software is not compromised, has been updated recently, etc.
Ideally it would be handled like BitTorrent/Magnet/IPFS:
- Links resolve, and data can be fetched, as long as anyone is hosting it (regardless of who)
- Anyone (including big orgs/corps) can provide a curated lists/search for links they vouch for
- Removing something from a list doesn't affect anyone's ability to fetch and use it; only whether they see the link in that particular search/list UI
You don't already do this for Linux? :( A new Linux setup already requires me to visit a bunch of sites and find .debs. Chrome, Signal, Edge, Visual Studio Code, Slack, etc. I don't really trust random unofficial maintainers in snap store and all of the above is required for my work.
It isn't impossible to have both. An app store that is a registry pointing to packages/files hosted by the developer. And since you mentioned Windows, that's exactly how choco and winget work.
On any fresh Ubuntu install including on WSL, I always `apt uninstall snap` and never worry about it again. I will never use snap and will continue to use apt for packages, thank you very much.
> > Snap Store administrators had to remove the snap in accordance with our policies.
>
> Thank you for providing an official answer.
An officious answer is more like it. Note the deliberate evasiveness (which policy? Mind your own business.). This is to be expected from an organization one of whose "policies" is "we are going to update apps on 'your' desktop whether you like it or not, luzer."
snap is garbage. For a while when it first came out, it had newer packages than Ubuntu. But then, over time, most of the packages went stale. Every snap I install requires --classic (which overrides the sandbox). I wish they would just kill it.
Quite something for an open source project to use DMCA of all mechanisms to remove an unofficial distribution, but alright, maybe there's a trademark issue.
Sounds like someone should change the icons and change the name to make the unofficial Signal snap look properly unofficial. Should protect the application from Signal's controlling tendencies as well as their open source code can and should be redistributed freely.
What is this response? Still no indication anyone has been contacted with the reason why it was removed, only that "in the future we will let you know if we remove something, sorry".
IDK, Signal has been getting more hostile to users over time. In the coming months, when they drop the sms functionality I will drop signal forever. That's pretty crazy because I've been using it since it was red-phone in the early 2010's with my samsung galaxy2.
This is my semi-regular message where I decry that Keybase Chat (https://keybase.io) isn't more popular. It's cross-platform, fully E2EE, has the best identity solution of all, open source, doesn't depend on phone numbers, etc etc, isn't mar In my experience, it beat all the alternatives I have used (incl. Signal, Telegram, WhatsApp, and especially Apple's Messenger). The only caveat is that Keybase.io got acquired by Zoom (thus, it's Zoom now) and the service is at the continued mercy of Zoom. However it's been a year (years?) and it's still working great.
This is really sad because I've become a huge Ubuntu fanboy in the last year, but this behavior is unacceptable. They need to fix their processes and be more dev friendly or they're going to lose allies.
I'm not a Signal user, however given what is the target audience of Signal, i can totally understand the maintainers not wanting unofficial packages around, even more so if surrounded by a snap environment they have no way to check for security.
Now, unleashing lawyers as first move is debatable for sure, and I won't be the one who defends that move, so probably some more insight from Signal should be expected.
The Signal developers don't even provide RPM- or AppImage-based installers, despite being able to create the latter in their build pipeline. I'm never donating anything to them because I'm convinced they're lazy and stupid.
The Signal developers have the freedom to distribute their application in any way they see fit. If they don't want to support your machine then that's their choice. You're free to set up a fork if you want to see change in this regard, as long as you don't violate their trademark and terms of service.
I don't use gnome-calculator on Windows because there's no official Windows distribution available for that platform. That doesn't make the Gnome devs lazy, that's just my preferences conflicting with theirs.
You're not entitled to support for your preferred distribution unless you sign some kind of (probably expensive) support contract and other people not working for you for free doesn't make them lazy or stupid.
I'm well aware of Signal's history with non-official distribution and alternative clients. How they distribute their official binaries is still up to them, though. They clearly don't care enough about AppImages (and other means of distribution) to put any effort into them.
of course they are going after unofficial distribution channels, it's signal, their whole schtick is owning everything end to end so that people can trust their brand.
My two cents: ubuntu snap daemon is not a good idea at all.
"Snap is a magnificent idea with a still immature realization.[...]
The overall user experience with Snaps on Ubuntu is frustrating: several apps won’t start when installed as snaps, others run weird, others take really long time to start. As an example: Telegram as snap takes around 51 sec to be operative, Telegram installed as binary starts in 1,5 sec."
Also I was never happy with snap because unable to full control when software will be upgraded (and why).
It was the main reason I stopped to use it, after Ubuntu20 make snap a default install complex to remove:
https://gioorgi.com/2021/ubuntu-20-failed-me/
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.