@rysiek What did I miss? Seems at least the server repo has been updated - about time!

@rysiek Hmm. Mixed feelings about this one... In your opinion, is this an all-bad thing or are there some uptakes to it?

@h3artbl33d look, I recognize that many places in this world have no reasonable banking services available, and that a lot of people have no access to digital payments that would otherwise make their lives better.

If you ever tried sending any money to Africa, or, you know, between EU and US, you know what I mean here.

At the same time, Signal Desktop remains crap ("optimizing database" ⏳, and then words appear seconds after I type them) and Signal mobile tends to fall minutes behind Desktop.

@h3artbl33d plus, there are no Signal clients for a number of privacy-friendly platforms (SailfishOS, postmarketOS, Librem5, PInePhone, or you know: any mobile OS that is not Android or iOS).

*And* moxie refuses to federate because "too much work to keep up".

Dunno, maybe instead of going full crypto Signal could fix Desktop (and drop Electron in the process), and write a client for at least one non-duopolistic mobile platform?

Follow

@rysiek @h3artbl33d when we were doing Ubuntu Phone, Signal was actively hostile to us making a client.

...reason we ended up with good Telegram support.

@ted @rysiek @h3artbl33d as I understand it any signal client not built by the signal team is against their terms of service.

So if you got a 3rd party signal client that works it only works because they didn't bother blocking it yet.

@rune @ted @rysiek Yeah, they [where?] hostile towards forks and third party clients. But it seems that they aren't as they once were. Nevertheless, it is a bad situation and attitude.

@rune @ted @rysiek @h3artbl33d show me where in the signal terms of service it says this please.

@sneak @ted @rysiek @h3artbl33d Well, as it turns out I can't find any terms of service on using the server directly 🤷

But Moxie has many times expressed not wanting 3rd party clients using their branding OR service. Even if they're unmodified builds made by f-droid...

whispersystems.discoursehostin

github.com/signalapp/Signal-An

github.com/LibreSignal/LibreSi

@sneak @rysiek @h3artbl33d The LibreSignal README also completely echoes @ted's experience of being willing to do all the work to support a new platform and being shut down devastatingly.

github.com/LibreSignal/LibreSi

@rune @sneak @h3artbl33d @ted yes, they will weaponize trademark laws and whatever else they can to push third party client developers away.

@rysiek @sneak @h3artbl33d @ted Which makes me wonder. What happens when they decide to do something terrible in the client?

That's right. Everyone has to move to a new messenger again because changing the client isn't possible.

Signal is effectively a "source available" project that sometimes accepts PR's.

Sure, it's technically open source, but nobody is going to use your fork after Moxie tells you to go host your own Signal Server.

@rune @sneak @h3artbl33d @ted any apparently-FLOSS server-client project that uses the Network Effect to wall users in is effectively a source-available project.

@rune @rysiek @sneak @h3artbl33d @ted I hosted my own signal server and sideloaded it into a custom apk. It is really hard to get others to use your apk.

Jami has the opendht and turn server available in the advanced UI. Still hard for a tech newbie, but at least it doesn't require sending someone a sketch unsigned appstore package.

Frustrating experience.

@rysiek @rune @h3artbl33d @ted they're using trademark laws as intended. if you fork the signal-client codebase, you can't (and shouldn't!) use the word or name "signal" anywhere. you should name your fork something else entirely.

@rune @sneak @ted @rysiek @h3artbl33d On the other hand, they have given a 👍 to developing a native Linux client using the new Rust library: github.com/signalapp/libsignal

@rune @ted @rysiek @h3artbl33d it really doesn't matter if they discourage it or don't like it. the GPL says developers are free to fork the code. the service TOS says users are authorized to use the service. AFAIK there are no cases where an authorized user of a service is only authorized using certain software - they're authorized for the *service*. google.com can't say you're not allowed to use non-chrome browsers.

@ted @rysiek @h3artbl33d

He was asked at 36c3 after his talk was over if: with the existance of postmarketOS that boots in a ton of devices, and the Librem 5 and the Pinephone if they would finally consider making a fully featured native mainline linux app.

His reply at the time was that; making clients for different platforms is hard, adding a new platform is hard, and maybe these platforms should look for a way to run the android app.

@maryjane @ted @h3artbl33d yeah, everything is hard, and Signal is so strapped for cash that after that 50mln USD donation some years ago they're spending what scarce resources they have on adding cryptocurrency to Signal.

Give me a fscking break.

@rysiek @maryjane @ted @h3artbl33d know what else is not hard? not publishing code while claiming "open source", keeping control of the center while claiming to build a secure and private platform. going full cryptoscam. because you know, think of the people and the poor. the children!

@zeh @rysiek @maryjane @h3artbl33d today I looked and it seems they've started pushing the server code again.

@zeh @rysiek @ted @h3artbl33d

1/2

For the record I am not defending his position or his reply, was just repeating what he said.

I think his answer is stupid, and the examples he gave to justify why it is hard, like getting app windows for factor rigth for different screens, only shows that he does not know the work of GNOME/libhandy and Plasma Mobile in getting apps that work in tablets and mobile devices.

@zeh @rysiek @ted @h3artbl33d

2/2 and he is also one of the several persons that think that a good security model is a hardened android kernel.
And Linux mainline distros are "security nightmares".

@maryjane @zeh @rysiek @ted

There is a truth in there. For instance, see: grapheneos.org/features

I do like the Pinephone (and to a lesser extend Librem) - but while they are private and the hardware toggles are fantastic, they miss security features (full verified boot, a weakened or no selinux, firmware update problems, etc).

@h3artbl33d @zeh @rysiek @ted

The Librem 5 does have a smartcard reader so there is some hope and intention to work on a solution for verified boot using that. As for selinux it an be worked on, but I am not sure how to balance that.
As for Firmware updates, not sure about the pinephone, I am more familiar with the Librem 5. But with the Librem 5 the attitude seems to be some latitude for those updates. For the pinephone modem it seems there are also some avenues for updates.

@h3artbl33d @zeh @rysiek @ted Well I work for Purism (but not on the phone development team), but I keep track of it so I am aware of some of the stuff I stated ;)

@maryjane @zeh @rysiek @ted

Thank you :) Purism has stated before that the Librem 5 was going to have SELinux enforcing out of the box. Then, all of a sudden, that statement was removed and to the best of my knowledge, current models don't have SELinux. Is that correct?

@maryjane @zeh @rysiek @ted With all due respect - and this is not personal (more of a concern towards Purism): in my opinion, announcing security features a device is supposed to ship with, only remove it without a trace before public availability is raising red flags at best.

The Librem 5 is geared towards privacy enthousiasts (among others) which makes this more concerning IMHO.

no disrespect taken: I am going to take the cautionary approach and say that I need to lookup that statement, because I am unfamiliar with it, before my time I would say, in order to understand what we are talking about.
But as a general note about the Librem 5 OS, in it's defense, it is still under heavy development, a lot of features are only landing now.

@h3artbl33d
Also need to consider with SELinux that its not just a binary thing (has / has not) eg. the policies in android, implemented as part of a comprehensive security model ( arxiv.org/abs/1904.05572 ), provide so much more than what is gained by the SELinux implemented in Fedora.

Comprehensive policies are apparently a massive undertaking to implement and maintain. Obvs Google has the resources to do that.

A linux project which has been working on… 1/2 @maryjane @zeh @rysiek @ted

@h3artbl33d
…a full system Mandatory Access Control is #Whonix / #Kicksecure (the hardened Debian on which Whonix is based - basically whonix workstation with all the tor stuff stripped out — whonix.org/wiki/Kicksecure )

They are using #AppArmor rather than #SELinux as its easier to do and its taken a couple of years to get things to a stage where its apparently getting reasonably usable.

github.com/Whonix/apparmor-pro

forums.whonix.org/t/apparmor-f
@maryjane @zeh @rysiek @ted

@dazinism @maryjane @zeh @rysiek @ted

Yes. It certainly isn't a binary thing and it offers fime grained policies. AOSP and "stock Android" offer one of the most sane policies. GrapheneOS takes it even a bit further.

...and your remark, about Google having enough resources, is kind of my point. With Linux, there are just too many stakeholders that each have their own agenda, work and projects. Getting it broadly adopted [1/2]

@dazinism @maryjane @zeh @rysiek @ted sane default policy is nearly impossible. The BSD deratives, like OpenBSD, can implement security features much swifter, due to the different development model and project setup.

I did give a talk about this on two occassions. In some aspects, Linux is f*cked by the 'organic' model. [2/2]

@maryjane @zeh @ted @h3artbl33d I know, sorry, I did not mean to sound like I'm debating you. We're in agreement!

@ted @rysiek @h3artbl33d Don't forget Telegram's server is proprietary and not to be trusted. Honestly I'm very concerned @PINE64 images ship with Telegram - that's my first thing to remove before going online.

@gytis @ted @rysiek @PINE64 The proprietary server is bad, really. But overall Telegram is a complete and utter shitshow-clusterfuck. The server is just a part of the overall nightmare.

@gytis @rysiek @h3artbl33d @PINE64

To be clear, I'm not advocating for Telegram just using it to show the results of Signal having a policy against externally developed clients.

@ted @gytis @rysiek @h3artbl33d @PINE64 signal's policy is irrelevant. the client is GPL. you can fork it and talk to signal servers just like you can fork chromium and talk to google servers.

@sneak @ted @gytis @h3artbl33d @PINE64 it is relevant, because if they wanted to, they could block your client. Signal is actively hostile to third-party client developers.

The right to fork is there, the right to use their servers is not.

@rysiek @ted @gytis @h3artbl33d @PINE64 they can't block it without making their official client nonfree, as a fork would be indistinguishable to the server.

@rysiek @ted @gytis @h3artbl33d @PINE64 you are conflating the developer releasing a fork with the end user using the server. there is nothing in the tos that says i can't use a modified client, and technically there is no way to prevent me.

@rysiek @ted @gytis @h3artbl33d @PINE64 example: bob forks signal-client, is not a signal user. permitted under GPL. alice, a signal user, downloads the fork and uses it. permitted under the service's TOS.

@sneak @ted @gytis @h3artbl33d @PINE64 can you please explain to me again how the GPL and client-server architecture works, as I am clearly unfamiliar with those concepts? :blobcatcoffee:

@rysiek @ted @gytis @h3artbl33d @PINE64

then you know both developers and end-users have the right to use their servers regardless of client software

@sneak @rysiek @gytis @h3artbl33d @PINE64

They have an API key that they put in their builds and can rotate with updates. You can steal the key from the binary, but your client is going to end up unreliable as you constantly play catchup.

This doesn't matter if it is a single user, but if you're trying to provide it as a feature to many it effectively shuts it down.

Nothing in the GPL limits this.

@ted @sneak @rysiek @gytis @PINE64

There was a certain timeframe once the build keys were rotated, right? Rotating those keys too quickly would break legitimate clients - so it _might_ be doable.

@rysiek @sneak @ted @gytis @h3artbl33d @PINE64 Signal was hostile to a fork of the Android client they developed. They are not hostile to independently developed clients. github.com/signalapp/libsignal

@be @rysiek @ted @gytis @h3artbl33d @PINE64

most upstreams that get forked in open source are hostile and/or unreasonable. that's why people fork them.

upstream being hostile to forks is not a signal thing. fork away.

@sneak @be @rysiek @ted @gytis @PINE64 Unfortunately, that is true. I can name dozens of examples where hostility and/or rogue behaviour against forks happened. It's sad.

@ted @gytis @rysiek @PINE64

My bad, apologies for interpreting it incorrectly.

I share your thoughts. Ideally, Signal should embrace the community, developers, etc. Develop a SDK, implement federation, ditch the cryptocurrenxy, etc.

Plz, Moxie. Stawp.

@ted @rysiek

Ugh. Telegram. As it stands right now, I'd rather use Whatsapp. Telegram is a nightmare.

@ted @rysiek @h3artbl33d ignore upstream hostility, fork the code. signal is GPL, the right to fork is explicitly permitted by them in the license.

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!