[HN Gopher] Snap Store administrators removed signal-desktop fro...
___________________________________________________________________
Snap Store administrators removed signal-desktop from Ubuntu Snap
Author : hagen2022
Score : 391 points
Date : 2022-11-03 13:42 UTC (9 hours ago)
(HTM) web link (forum.snapcraft.io)
(TXT) w3m dump (forum.snapcraft.io)
| lxe wrote:
| 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.
| jeroenhd wrote:
| 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.
| bbarnett wrote:
| 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.
|
| Good grief.
| einpoklum wrote:
| 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.
| bbarnett wrote:
| Systemd was a child of Redhat.
|
| Debian had to support it, mostly because at the time Gnome,
| another Redhat controlled project, decided to depend upon
| systemd.
| johnisgood wrote:
| My thoughts exactly. Thankfully there are other distros out
| there and you do not have to use Ubuntu.
| fazfq wrote:
| Did it manage to embed itself into anything beyond Ubuntu,
| which is a distro that is waning in popularity?
| luckylion wrote:
| You want a revolt against snap for ... Signal sending DMCA
| takedowns?
| johnisgood wrote:
| 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.
| a-dub wrote:
| 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.
| ryukafalz wrote:
| 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.
| jeroenhd wrote:
| 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.
| ryukafalz wrote:
| 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.
| cyberphobe wrote:
| Signal never gave canonical permission to distribute a binary
| called Signal. Canonical just went ahead and did it anyway.
| How is this Signal's fault?
| monocasa wrote:
| DMCA isn't a mechanism for trademark disputes.
| cyberphobe wrote:
| Then complain about that. Honestly given the existing set
| of miscommunications about what happened, I'm not sure it
| is an actual DMCA request
| jeroenhd wrote:
| 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.
| cyberphobe wrote:
| 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)
| jdiff wrote:
| Signal is not saying this, as evidenced by the cofounder
| saying that this is all a misunderstanding and that
| they're working to undo what's been done.
| loloquwowndueo wrote:
| 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.
| SlackingOff123 wrote:
| 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).
| j33zusjuice wrote:
| 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.
|
| I'm a big fan of Fedora. I primarily work on RHEL systems,
| though, so I'm biased because it's what I'm used to using.
| floren wrote:
| > 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.
| freedomben wrote:
| 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.
| ridgered4 wrote:
| I use linux mint which is still ubuntu based and doesn't use
| snaps.
| bitcharmer wrote:
| 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.
| freedomben wrote:
| > _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.
| CogitoCogito wrote:
| 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.
| jrumbut wrote:
| 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.
| mort96 wrote:
| 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.
| emj wrote:
| 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.
| mort96 wrote:
| 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.
| xp84 wrote:
| 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.
| sarnowski wrote:
| 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.
| public_defender wrote:
| 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.
| easrng wrote:
| iirc fdroid allows apps to be signed by the developer if
| the builds are reproducible.
| mort96 wrote:
| 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.
|
| [1]: https://www.yoctoproject.org/
|
| [2]: https://rauc.io/
| voakbasda wrote:
| 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.
| voakbasda wrote:
| 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.
| hamburglar wrote:
| What gives you any assurance that your inner sig check
| isn't tampered?
| runlevel1 wrote:
| How does that work? I would have expected Canonical to just
| be the CA.
| sarnowski wrote:
| 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.
| smallerfish wrote:
| 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.
| bbarnett wrote:
| Same as docker.io stuff, most stuff is just done by
| volunteers. Debian, php, etc.
| asdajksah2123 wrote:
| The problem here is that JetBrains and Zoom have chosen not
| to package their apps as Flatpaks.
|
| There is nothing stopping Canonical from offering a Flatpak
| based App Store that only contains approved and vetted apps.
| smallerfish wrote:
| > 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.
| boudin wrote:
| Most of what runs on any computer is built by volunteers.
| Most open source softwares relies on volunteers.
| smallerfish wrote:
| 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.
| mort96 wrote:
| 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.
| jcastro wrote:
| Publisher verification for flathub is in beta, you can
| track progress here:
| https://discourse.flathub.org/t/situation-report-new-
| flathub...
| freedomben wrote:
| Is the third party maintainer relationship a policy choice by
| flatpak? or is that just the case because the maintainer
| built the flatpak first?
| smallerfish wrote:
| 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.
| smoldesu wrote:
| 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.
| krageon wrote:
| Being able to autonomously do things as a community is
| healthy. All this corporate pandering is not.
| SSLy wrote:
| This is no worse than distro contributors or say, AUR or
| Nixpkgs folks packaging 3rd non-free party software.
| asveikau wrote:
| Zoom isn't required to "step up" and use your favorite
| packager or distribution mechanism.
| Spivak wrote:
| 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.
| galgalesh wrote:
| Snap maintainer here.
|
| 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.
| [deleted]
| cercatrova wrote:
| 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.
| inetknght wrote:
| > _I always `apt uninstall snap` and never worry about it
| again._
|
| Might want to double-check if/when there's some automatic
| update that decides to reinstall Snap
| foolswisdom wrote:
| 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".
|
| https://forum.snapcraft.io/t/what-happened-to-signal-desktop...
| he_is_legend wrote:
| "This is due to a DMCA takedown request coming from people
| representing Signal. Canonical is currently working with Signal
| to resolve this issue."
| TheRealPomax wrote:
| 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.
| turblety wrote:
| 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.
|
| 1. https://github.com/snapcrafters/signal-
| desktop/issues/70#iss...
|
| 2. https://forum.snapcraft.io/t/what-happened-to-signal-
| desktop...
| Y_Y wrote:
| That's funny, because in accordance with my policy I delete
| snap immediately after install.
| PetitSasquatch wrote:
| I'm actually kind of thankful for Ubuntu's move towards
| Snaps.
|
| Once I realised they were not for me I started distro
| hopping and ended learning far more day to day system
| administration skills than ever.
|
| To this day, I've never once found myself remotely tempted
| to use anything like a Snap or Flatpak.
| jacob019 wrote:
| My new policy is to just install Debian instead.
| Iolaum wrote:
| Snap is the reason I moved from Ubuntu to Fedora years
| ago. I couldn't have known how happy I would be with this
| decision :)
| xtracto wrote:
| 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.
| DiabloD3 wrote:
| This has been my policy since Debian Potato.
|
| Why fix what ain't broke?
| einpoklum wrote:
| Consider tweaking your policy to install Devuan instead.
|
| Basically the same thing, but not only does it not have
| snap, it's also systemd-free :-)
| jacob019 wrote:
| Thanks, but I've come to like systemd.
| cuteboy19 wrote:
| It's standard policy for me to uninstall snapd after every
| Ubuntu install
| bravetraveler wrote:
| My standard policy is to avoid Canonical
| Spivak wrote:
| 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.
| bravetraveler wrote:
| Fair enough, Linux at the end of the day is Linux --
| can't fault anyone for making it fit their needs
|
| Good to hear you enjoy Fedora, I do as well! I use the
| server variant for my stuff, unless you compile kernel
| modules you might find it a decent fit
| Spivak wrote:
| 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.
| jrumbut wrote:
| I haven't used Ubuntu recently, hadn't heard of snaps,
| and this entire thread has been a horrifying
| introduction.
| yamtaddle wrote:
| 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.
| jrumbut wrote:
| 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.
| HeckFeck wrote:
| APT: the only packager strong enough to tell the other
| packager where to go.
|
| Don't forget a --purge for extra wantonness.
| _jal wrote:
| 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...
| Avamander wrote:
| It also has the benefit of being able to get rid of that
| hideous ~/snap folder. With what were they thinking making
| that choice.
| bee_rider wrote:
| 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).
| wasmitnetzen wrote:
| You can still use a PPA:
| https://www.omgubuntu.co.uk/2022/04/how-to-install-
| firefox-d...
| bee_rider wrote:
| Thanks for the suggestion.
|
| 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).
| wiml wrote:
| 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.
| bee_rider wrote:
| 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.
| HeckFeck wrote:
| 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.
| jrootabega wrote:
| Maybe they're under a gag order? Or there's a critical
| vulnerability they don't want to disclose yet?
| bbarnett wrote:
| I am thinking of a "friendly bet" app, because I'd like to
| bet you 2 bucks it's just them being obtuse asses.
| 369548684892826 wrote:
| The thread's just been updated to say that Signal themselves
| issued a DMCA takedown notice against the Snap Store.
| JonathanBeuys wrote:
| Is there any reason to have snapd installed on your system?
|
| I am currently setting up a new laptop and so far my plan is to
| not install it.
|
| Anybody here who uses it? Care to tell why?
| timbit42 wrote:
| If you remove Snaps from Ubuntu, how do you install apps that
| are not in their regular repo, for example, Firefox? Do you
| sideload them?
| squarefoot wrote:
| 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.
| ifeeltriedboss wrote:
| 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].
|
| 1. https://github.com/signalapp/Signal-Desktop/issues/1639
|
| 2.
| https://www.reddit.com/r/signal/comments/tiidh8/comment/i1em...
| cmeacham98 wrote:
| There is a Signal flatpak
| (https://github.com/flathub/org.signal.Signal), I'm unsure if
| the Signal devs are involved in it or not.
| akvadrako wrote:
| I've been using it for about a year - seems fine.
| hackerbrother wrote:
| Me too. Would appreciate it being first-party though.
| _-david-_ wrote:
| It is not official.
|
| https://github.com/signalapp/Signal-Desktop/issues/1639
|
| https://community.signalusers.org/t/signal-desktop-for-
| non-a...
| FullyFunctional wrote:
| 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.
| ikiris wrote:
| It's also basically dead after the acquisition.
|
| Look at the github history.
| JTbane wrote:
| boycott Snap!
| rubyist5eva wrote:
| boycott Signal actually, they are the ones that sent a silly
| takedown notice
| numeromancer wrote:
| > > 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."
| bobmaxup wrote:
| It is interesting how quickly this discussion moved from, "Never
| use Ubuntu or Snap" to "Never use Signal"
| jethro_tell wrote:
| 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.
| cyberphobe wrote:
| miniBill wrote:
| ... Oh Snap
| ilaksh wrote:
| 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?
| commoner wrote:
| 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.
| b5n wrote:
| > you might prefer to go downstream from Ubuntu to get newer
| features sooner. sudo apt update sudo
| apt upgrade sudo sed -i 's/bullseye/sid/g'
| /etc/apt/sources.list sudo apt dist-upgrade
| 2pEXgD0fZ5cF wrote:
| 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.
| zach_garwood wrote:
| I recently switched to Pop_OS and I'm enjoying it so far. But
| yeah, you can't go wrong with just plain Debian.
| aftbit wrote:
| 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.
| bioemerl wrote:
| I don't see anyone mentioning fedora. Is that a decent
| alternative?
| teach wrote:
| Yes. In fact I'd personally recommend Fedora as a better
| alternative to Ubuntu than Debian.
| CoastalCoder wrote:
| Discussed recently in another story, but many including me like
| Pop!_OS as a better version of Ubuntu.
| ilaksh wrote:
| I tried Pop before, eventually ran into a compatibility
| issue. Also it's based on Ubuntu.
| CoastalCoder wrote:
| 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.
| mikepurvis wrote:
| If you basically-Ubuntu-but-more-free then yes, Debian.
|
| If you want a paradigm shift, try NixOS + home-manager.
| Schroedingersat wrote:
| Pop is nice for plug and play.
|
| Manjaro or mint too.
| biasedestimate wrote:
| Just switch to Mint, it is as stable / easy as Ubuntu and 100%
| snap free.
| siwatanejo wrote:
| As for me, I'll keep ubuntu but I'll start using flatpak
| instead of snap.
| commoner wrote:
| 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:
|
| https://flatpak.org/setup/
| kristjank wrote:
| It sure looks like Signal is trying to actively sabotage itself,
| and Canonical is happy to help.
| daitangio wrote:
| 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."
|
| see https://cialu.net/how-to-disable-and-remove-completely-
| snaps...
|
| 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/
| undoware wrote:
| "I can't believe they gatekept MY package," says user who
| enthusiastically downloaded WalledGarden Distro.
|
| cf
| https://twitter.com/cavalorn/status/654934442549620736?lang=...
| sschueller wrote:
| To any app dev. If your app is only available via snap I will not
| be using it.
|
| Also certbot, shame on you for removing the Debian repository in
| favor of snap.
| fanatic2pope wrote:
| 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.
| runlevel1 wrote:
| I was wondering why they'd stop shipping a deb package for
| certbot. This has some info:
| https://github.com/certbot/certbot/issues/6770#issuecomment-...
| jacob019 wrote:
| 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.
| fluidcruft wrote:
| It is officially distributed to linux as debs (see
| https://signal.org/download/).
|
| 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).
| pooper wrote:
| > Also certbot, shame on you for removing the Debian repository
| in favor of snap.
|
| Yes, this deserves shaming.
|
| > https://certbot.eff.org/instructions
|
| > 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.
| goodpoint wrote:
| certbot won't be missed. The code quality is pretty poor.
|
| https://github.com/certbot/certbot/issues 5000 bugs and it
| most of it can be replaced by much smaller tools
| mikepurvis wrote:
| Debian has it too: https://packages.debian.org/sid/certbot
|
| And even Ubuntu: https://packages.ubuntu.com/kinetic/certbot
|
| 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.
| jaapz wrote:
| versions in debian and ubuntu repo's have a tendency to lag
| behind, current version seems to be 1.30.x while in debian
| and ubuntu repos it's on 1.29.x
| dundarious wrote:
| bullseye/stable is on 1.12.0
| warent wrote:
| 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.
| [deleted]
| timbit42 wrote:
| Many Ubuntu users have moved to either Linux Mint, which is
| still based on Ubuntu, or Debian, neither of which have Snaps
| by default.
| jeroenhd wrote:
| 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.
| politelemon wrote:
| This issue was also raised on their GitHub
|
| https://github.com/snapcrafters/signal-desktop/issues/70
| dekhn wrote:
| 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.
| galgalesh wrote:
| 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.
| sschueller wrote:
| 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...
| award_ wrote:
| What are your others? I use signal alot personally and
| haven't had too many issues.
| defraxi wrote:
| Although I use Signal, I actually prefer Threema which you
| can also use without a phone number.
|
| https://threema.ch/en/home
| sschueller wrote:
| - 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.
| gort19 wrote:
| What do you recommend as an alternative?
| chpatrick wrote:
| matrix/element.
| freedomben wrote:
| 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.
| seized wrote:
| A lot of people moved to Signal because of WhatsApps
| changes so that advice can thought of as misleading at
| best.
|
| Your suggested alternatives are owned by Zoom and
| Facebook. I'll stick with Signal.
| L3viathan wrote:
| > keybase.io has been great
|
| > Crypto thing they attempted
|
| well...
| happymellon wrote:
| As a Facebook owned app, I don't trust WhatsApp.
|
| All of them being tied to a phone number is bad form.
| calgoo wrote:
| 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 :)
| gort19 wrote:
| friend_and_foe wrote:
| XMPP with OMEMO e2ee. Fallback to jitsi meet for video
| calling, although several xmpp clients support video
| calling to each other.
| alias_neo wrote:
| 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.
|
| [0]https://github.com/jitsi/docker-jitsi-meet
| [deleted]
| ixwt wrote:
| Moxie stepped down from the CEO of Signal in January of
| this year [0]. Other than that, yeah. Valid criticisms
| that their reasons are flimsy at best.
|
| [0]:https://www.theverge.com/2022/1/10/22876891/signal-
| ceo-steps...
| krageon wrote:
| Stepped down maybe, but the fostered culture remains.
| nells wrote:
| windexh8er wrote:
| I see you're new, you might want to review the
| guidelines:
|
| https://news.ycombinator.com/newsguidelines.html
| junon wrote:
| Agreed on all counts, especially the last one.
| artificialLimbs wrote:
| - Backups? lol...
| aeturnum wrote:
| 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).
| krageon wrote:
| There is no reason to believe it is secure, as it doesn't
| have reproducible builds. What you download has binary
| blobs embedded.
| aeturnum wrote:
| 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).
|
| [1] https://community.signalusers.org/t/overview-of-
| third-party-...
| dheera wrote:
| Yeah the phone number thing is a bad move since it's
| traceable to your identity one way or another, even if
| you use a virtual number like I do.
| ChuckNorris89 wrote:
| 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.
| londons_explore wrote:
| > takes horrible pictures on Android
|
| 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.
| gort19 wrote:
| The only one of these that is a 'bug' is the failure to
| ring on android.
|
| 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.
| thrtythreeforty wrote:
| 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.
| happymellon wrote:
| Taking poor pictures, if it is due to using the wrong API
| is also a bug.
| baq wrote:
| The camera thing is definitely a bug, on iOS there are
| issues, too (eg doesn't rotate pictures from landscape to
| portrait correctly).
| ChuckNorris89 wrote:
| _> The rest are all feature requests._
|
| 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
| gort19 wrote:
| Ok, but that means your criteria for a basic messenger
| app is something that does _everything that all the other
| messaging apps do_.
| ChuckNorris89 wrote:
| 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.
| gort19 wrote:
| 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.
| seized wrote:
| 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.
| thot_experiment wrote:
| 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.
| ChuckNorris89 wrote:
| _> 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.
| Zak wrote:
| 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.
| cyberphobe wrote:
| Signal offers an official deb. The correct behavior would
| have been for third parties to not distribute trademark-
| infringing binaries and call them Signal
| forgotpwd16 wrote:
| 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
| cyberphobe wrote:
| 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
| kybernetyk wrote:
| Binaries are just condensed source code. So when the source
| code is AGPL I sure as hell can distribute binaries if I
| like.
| cyberphobe wrote:
| What is GNU IceCat (formerly IceWeasel) then?
| jdiff wrote:
| Firefox's license did not permit use of trademark.
| Eventually an exception was made, and now GNU IceCat is
| mostly a relic.
|
| 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.
| MrsPeaches wrote:
| I think the point is that you can't call it Signal. Is
| that correct?
| cyberphobe wrote:
| Yup, also can't really prove it came from the same source
| code.
| bheadmaster wrote:
| > I sure as hell can distribute binaries if I like
|
| 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 (?).
| bubblethink wrote:
| You can't modify it and still call it Signal (i.e.,
| misrepresent the trademark). You should be able to
| redistribute unmodified binaries.
| bee_rider wrote:
| 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.
| bubblethink wrote:
| 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.
| [deleted]
| kevin_b_er wrote:
| What this is is also another reason not to use Snap.
|
| 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.
| cyberphobe wrote:
| 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
| kevin_b_er wrote:
| And the DMCA is about copyright. Where's trademark
| mentioned?
| tingletech wrote:
| Violating trademark triggers AGPLv3 license to be
| invalid, thus the copyright claim.
| Murrawhip wrote:
| No, AGPLv3 allows for adding an additional term regarding
| trademark. Signal-desktop is using the default APGLv3
| without such a term.
| Zak wrote:
| 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.
| tadfisher wrote:
| Because the AGPLv3 allows for trademark restrictions,
| violating the trademark revokes the copyright license.
| monocasa wrote:
| AGPLv3 allows for adding trademark terms, which signal
| has not done.
| nicce wrote:
| And snap store backend is walled garden, you can't really
| even make official snaps as external packages. Everything
| depends on Canonical.
| CoastalCoder wrote:
| > The correct behavior would have been for signal to offer an
| official snap or to contact the maintainer.
|
| Are we sure that Signal _didn 't_ contact the maintainer? I
| haven't seen any statements either way about that.
| freedomben wrote:
| Good thinking, but based on what GP said I don't think so:
|
| > _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.
| nvrspyx wrote:
| 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.
| CoastalCoder wrote:
| > 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.
| nimbius wrote:
| 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.
| 411111111111111 wrote:
| I thought moxie moved on from Signal? Is he still in the
| loop?
| cyberphobe wrote:
| The anti-signal crowd loves to blame moxie for
| everything. Just part of their overall commitment to
| being fact-free
| berkes wrote:
| Moxie was fairly controversial in his stance on several
| issues. That's not "fact-free".
| cyberphobe wrote:
| Moxie is no longer involved in Signal. Blaming him for
| things Signal does now is pretty free of fact
| dijit wrote:
| Other than that he set things up to be that way.
|
| He's not blameless for the fact it's not federated, for
| example. Even if he's not involved anymore.
| dheera wrote:
| > no third party clients
|
| 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?
| alias_neo wrote:
| 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.
| RektBoy wrote:
| Also HQ in US, rofl.
| kybernetyk wrote:
| 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.
| bogota wrote:
| This doesn't change the fact that signal is the best option
| for my grandma to use still.
|
| Moxie is no longer active in signal afaik. This is the new
| leadership.
| jeroenhd wrote:
| 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.
|
| Looks to me like Signal is the interior app here.
| croes wrote:
| Meta wants your data, of course they wouldn't do anything
| that could stop that.
| bogota wrote:
| If you look at anything through a narrow enough lens you
| can make it look good.
| jeroenhd wrote:
| 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.
| croes wrote:
| There is another feature of Signal.
|
| It isn't owned by a data leech.
| snovv_crash wrote:
| Ignoring UX for non-technical users is a narrow lens.
| krzyk wrote:
| Why not use sms? No need to install apps.
|
| My parents use that. I use that.
| munk-a wrote:
| 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.
| krzyk wrote:
| 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.
| bogota wrote:
| Missing the point. Sure pen and paper works great still.
| krzyk wrote:
| It is more like comparing pen and pencil.
| johnisgood wrote:
| What about Element?
| the_mitsuhiko wrote:
| > This doesn't change the fact that signal is the best
| option for my grandma to use still.
|
| Is it? How do you measure that? It seems like WhatsApp is
| a better default choice for most people probably.
| spdl wrote:
| Except it's owned by Meta, who I really wouldn't trust
| even if they say it's E2EE.
| 29083011397778 wrote:
| 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.
| dijit wrote:
| To be honest I don't see a strong reason to trust signal
| either except better marketing.
|
| 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.
| yummypaint wrote:
| 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.
| dijit wrote:
| 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.
| ohbtvz wrote:
| Your grandma cares about E2EE?
| krzyk wrote:
| Default should be sms, it is on every phone.
|
| As for web/desktop one can use also Telegram.
| bogota wrote:
| I agree but the person i am replying to is talking about
| using matrix
| kodah wrote:
| 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.
| rch wrote:
| Yeah, I regret ever mentioning the project to people.
| hammycheesy wrote:
| Reading this thread is what convinced me to switch away
| from Signal and investigate Matrix:
|
| https://github.com/LibreSignal/LibreSignal/issues/37#issu
| eco...
| kodah wrote:
| Thanks, this was illuminating.
|
| 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.
| capitalsigma wrote:
| 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.
| Zak wrote:
| 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.
| gkbrk wrote:
| 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.
| esaym wrote:
| Curious what all you had to do to switch from Signal to
| Matrix.
| googlryas wrote:
| 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?
| aero-glide2 wrote:
| This snap is unofficial.
| SSLy wrote:
| > _are you saying you are the maintainer of the signal snap
| package_
|
| They are, yes. Well, former maintainer.
| galgalesh wrote:
| I'm the maintainer of this unofficial snap package.
| cyberphobe wrote:
| Wasn't their own program. They have a binary they distribute,
| this was some other binary calling itself Signal without
| their approval.
| frontiersummit wrote:
| 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?
| cyberphobe wrote:
| Yes, this is a supply chain attack. That's how Snap
| works. As far as I know, no one is alleging they actually
| changed anything, just that they could.
| mananaysiempre wrote:
| 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.
|
| [1] https://drewdevault.com/2021/09/27/Let-distros-do-
| their-job....
| galgalesh wrote:
| This is simply incorrect, we were distributing the exact
| binaries signal produces.
| teraflop wrote:
| 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.
| crumpled wrote:
| A trademark violation is a copyright violation, because a
| trademark is copyrighted at first inception, before
| anyone adds the '(tm)'. A company is also compelled to
| take actions like this to maintain the rights to thier
| own trademarks. That's my understanding; IANAL.
| scott_w wrote:
| No, it's not. Copyright and trademarks are two completely
| different things with different rules that apply to them.
| crumpled wrote:
| 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.
| kube-system wrote:
| 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.
| monocasa wrote:
| That's not the case.
|
| 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.
| tingletech wrote:
| AGPLv3 allows one to add trademark terms that, when
| violated, revoke the copyright license.
| galgalesh wrote:
| 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
| cmeacham98 wrote:
| 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.
| tssva wrote:
| 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.
| tingletech wrote:
| Copyright license is revoked under AGPL v3 if you violate
| the AGPL v3 terms.
|
| 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.
| monocasa wrote:
| Signal doesn't appear to have actually added those
| restrictions to the license though.
|
| https://github.com/signalapp/Signal-
| Desktop/blob/main/LICENS...
| [deleted]
| fweimer wrote:
| 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.
| [deleted]
| ElijahLynn wrote:
| Thanks for the explanation Galgalesh!
|
| 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!
| SSLy wrote:
| They just did comment on that discourse thread.
| brianacton wrote:
| 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.
| fazfq wrote:
| Why is Signal, a company that prides itself in being tech-
| centric, allowing lawyers to send DMCA requests without
| consulting anybody?
| [deleted]
| lcnPylGDnU4H9OF wrote:
| I don't get why Signal being tech-centric (whatever that
| means) should disallow their lawyers from sending DMCA
| takedown requests.
| [deleted]
| Waterluvian wrote:
| If possible and reasonable, it would be great to get a short
| post-mortem on this (because they shouldn't always be for
| technical issues!)
|
| Trying to prevent legal from being overzealous while not
| chilling their ability to do their job seems like a very
| challenging problem.
| cyberphobe wrote:
| 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?
| nottorp wrote:
| This deserves a lot of publicity. Why send a DMCA takedown
| instead of contact the people involved?
|
| Will they do the same if some vulnerability is found in Signal?
| Lawyer up instead of fix the problem?
| [deleted]
| hyperhopper wrote:
| Exactly, using lawyers first is a very bad sign. I don't know
| why often people say "oh it was just the lawyers" like that
| makes it okay.
|
| No, those lawyers are paid for by and directed by signal.
| Signal is responsible.
| dheera wrote:
| Hey signal, maybe fix this $ 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
| nsxwolf wrote:
| Oh, snap!
| tssva wrote:
| The name for the Signal Desktop package is signal-desktop
| and Signal provides instructions on their website on how
| to add their deb repository.
| dheera wrote:
| Too difficult. Their install instructions are also too
| complicated and involve reading about 5 lines of comments
| and 4 shell commands.
|
| 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".
| cyberphobe wrote:
| 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.
| politelemon wrote:
| > 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.
| tssva wrote:
| 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?
| turminal wrote:
| You're already trusting debian/ubuntu maintainers with
| _your entire system_. Why would trusting them with one
| particular app make any difference?
| drran wrote:
| > If Ubuntu had spent resources to develop a convenient
| way for developers to directly provide binaries to the
| users of their OS
|
| No way. I will never trust your binary.
| mechanical_bear wrote:
| Lol, like you audit the thousands of lines of code when
| you compile from source.
| iakov wrote:
| All that time you've gained on the installation will be
| lost during the lethargic start of snapped application :P
| irthomasthomas wrote:
| It's 5 lines. Took me 30 seconds. Well worth it for the
| performance gains.
|
| 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
| marginalia_nu wrote:
| Yeah, let's teach users to paste sudo commands into the
| terminal. That's great.
| rosnd wrote:
| What alternative do you propose?
| marginalia_nu wrote:
| What if there was some sort of a store of snaps where you
| could download vetted packages with a graphical
| interface. A snap store, if you will.
| cyberphobe wrote:
| 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
| hsbauauvhabzb wrote:
| Unless you audit every line of code the one liner
| executed, reviewing that one line doesn't add much value.
| ChuckNorris89 wrote:
| _> 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.
| marginalia_nu wrote:
| I've seen this extremely sketchy variant a few times
| curl -sfL www.marginalia.nu/install.sh | sudo sh -
|
| Even without sudo, this is extremely sketchy.
| rosnd wrote:
| Is it meaningfully sketchier than downloading a .deb and
| calling dpkg -i on it?
|
| Or cloning a git repo and building it?
| jdiff wrote:
| 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.
| marginalia_nu wrote:
| 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.
| codedokode wrote:
| 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.
| turminal wrote:
| Why doesn't signal have a package in the official debian
| repo?
|
| I don't want to add random deb repositories for software
| like that.
| hiq wrote:
| 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.
| michaelmrose wrote:
| 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.
| turminal wrote:
| I'm already trusting debian to provide the rest of the
| system without backdoors. Why would getting signal from
| somewhere else help in any way?
| woodruffw wrote:
| 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?
| progval wrote:
| Trusting Signal to provide the _source_ and host the
| servers.
| woodruffw wrote:
| 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.
| codedokode wrote:
| 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.
| woodruffw wrote:
| 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.)
| bostik wrote:
| 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.
| woodruffw wrote:
| 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.
|
| [1]: https://news.ycombinator.com/item?id=33455836
| rlpb wrote:
| Snaps run sandboxed. It's not perfect, but it's a whole
| lot better than debs.
| galgalesh wrote:
| 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".
| tssva wrote:
| 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.
| jcastro wrote:
| There's also just as many reasons to not give Signal root
| on my PC by installing their .deb package.
| cyberphobe wrote:
| No one is forcing you to use their deb
| michaelmrose wrote:
| 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.
| jcastro wrote:
| 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.
| irthomasthomas wrote:
| 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.
| charcircuit wrote:
| That is what a DMCA takedown is. You contacting the people
| involved to get something taken down.
| kekkidy wrote:
| mort96 wrote:
| 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?
| bpicolo wrote:
| 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.
| Karunamon wrote:
| I think a great many people would disagree that taking
| legal action first is anything but rude.
| forgotpwd16 wrote:
| >this is because of a DMCA takedown request from lawyers
| representing Signal
|
| Whoa. That's unexpected.
| ddevault wrote:
| 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.
| [deleted]
| tapoxi wrote:
| 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.
| luckylion wrote:
| Telegram is super easy, but there's the whole "not e2ee by
| default" thing that some people care about.
|
| Threema is liked for security. I haven't used it, but my
| mother's tennis group is using it, and they're all 65+.
| Barrin92 wrote:
| 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.
| enriquto wrote:
| 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?
| goodpoint wrote:
| Support a new, well managed fork of Signal
| ddevault wrote:
| 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.
| forgotpwd16 wrote:
| >try Matrix earlier this year and so far I've regret it
|
| Why is that?
| ddevault wrote:
| Very bloated and unreliable.
| zaik wrote:
| Have you tried XMPP? The server and client implentations
| are both a lot more resource efficient.
| ddevault wrote:
| I have tried XMPP. It's not much better, but has
| different problems.
| A4ET8a8uTh0 wrote:
| 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 ).
| zaik wrote:
| 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.
| A4ET8a8uTh0 wrote:
| I agree in general, but can you offer a current project
| that is reasonably secure, relatively easy to install and
| use and built on actual standards?
|
| 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.
| zaik wrote:
| https://snikket.org/ could be the thing you're looking
| for.
| A4ET8a8uTh0 wrote:
| Thank you. I will test it out. It actually may hit the
| spot.
| spullara wrote:
| You didn't realize what you were doing was against the license?
| jdiff wrote:
| It wasn't against the license. It's AGPL v3, about as open as
| it gets.
| ohbtvz wrote:
| How terrible of them, packaging open source software for
| their distribution like so many package managers do.
| lxe wrote:
| 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?
| yuuu wrote:
| 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.
| jeroenhd wrote:
| 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.
| yuuu wrote:
| Just read this since you aren't familiar with the context:
| https://github.com/signalapp/Signal-Desktop/issues/1758
| jeroenhd wrote:
| 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.
| yuuu wrote:
| It being up to them and them being stupid and lazy are
| not mutually exclusive. Your points stand, and my points
| stand.
| noasaservice wrote:
| Reminder for you Ubuntu people:
|
| Snap is closed source garbage ware, with MS Windows forced
| updating and the terribleness of being 10x slower....
|
| So here's how to "Snap-Off" your system
| https://haydenjames.io/remove-snap-ubuntu-22-04-lts/
| turblety wrote:
| 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.
|
| 1. https://github.com/snapcrafters/signal-
| desktop/issues/70#iss...
| edent wrote:
| Because that doesn't solve the discovery problem. People want
| an easy way to find new things. Whether that's `apt search` or
| Google Play.
| vaidhy wrote:
| 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.
| danuker wrote:
| For discovery, there's also GitHub, GitLab, Hacker News and
| so on.
| seabird wrote:
| 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.
| freedomben wrote:
| 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.
| timtom39 wrote:
| 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.
| Asooka wrote:
| 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.
| martinmunk wrote:
| 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.
| Tsiklon wrote:
| 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
| tapoxi wrote:
| Flatpak solves this problem, unlike Snap (but like APT)
| anyone can run a repository. There is Flathub as a nice
| default but it isn't official.
| Octabrain wrote:
| 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.
| johnisgood wrote:
| 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.
| ajsnigrutin wrote:
| 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.
| syntaxing wrote:
| 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.
| ajsnigrutin wrote:
| Read the comment above mine:
|
| > 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?
| treis wrote:
| 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.
| _-david-_ wrote:
| 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.
| chriswarbo wrote:
| 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
| ifeeltriedboss wrote:
| And if you wanted to install 10 apps, then you'd have to visit
| 10 web pages, search for the file and then install? No, leave
| this for Windows.
| philliphaydon wrote:
| > No, leave this for Windows.
|
| This hasn't been the case on Windows for years now.
| forgotpwd16 wrote:
| 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.
| timtom39 wrote:
| 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.
| ajsnigrutin wrote:
| Don't most distribution repos already have all those
| already included with the "main" package management system?
| chpatrick wrote:
| Depends on the distro, I can just install all of those
| directly with Nix.
| ifeeltriedboss wrote:
| I just write flatpak install chrome and the machine is like
| OK /s
| johnisgood wrote:
| Oh God... I am not going to repeat myself. To put it briefly:
| Snap Store is Canonical's Play Store.
| simion314 wrote:
| It is not clear to me if the maintainers are the developers or a
| third party person not affiliated with the devs.
___________________________________________________________________
(page generated 2022-11-03 23:02 UTC)