Follow

The developers of Signal are currently doing a user survey:

surveys.signalusers.org/s3

I told them that I really like the app but also that I would like:
a) Signal on @fdroidorg
b) a proper desktop client
c) no data stored in "secure enclaves"

Maybe you'd like to tell them, too?



@fdroidorg Wow, this tweet really took off. I hope I managed to reply to most people!

Show thread

@__h2__ @fdroidorg Filled out.

Asked for a version that runs on pure linux phones, an fdroid version, said the desktop client is useless because it doesn't also work with SMS and suggested "opt-in federation" can work.

@__h2__ @fdroidorg The availabilty on #Fdroid is really important ! At least they could have their own repo. But that would be cumbersome for new fdroid users :/

@__h2__ @fdroidorg they funny. "want to chat more?" then don't ask for contact data. 😛

I think that one of the biggest issues with #SecureEnclave|s is being forced to use them, @waterbear.
If they were optional, I would feel less uncomfortable using them. However, the current situation creates a compliance issue when using #Signal in a business environment in the EU, as the highest EU court has ruled that US servers cannot be considered #SafeHabour|s anymore
@__h2__
@fdroidorg

@tetrapyloctomist

Think their use isnt as secure as signal suggests either. SGX isnt a secure enclave. Its using root-of-trust signing. If I'm not getting confused all Intel CPUs have keys that can do SGX attestations. If you keep one from getting updated, while watching for and examining any updates they get, may find a way in.
Alternatively just try hard to attack one, maybe an older, less secure design. Or an employee leaks the keys.

1/2
@waterbear @__h2__ @fdroidorg

@tetrapyloctomist
Signal is relying on this to increase security of the encryption on this metadata. Its running on servers they don't control

They pretty much forced people into setting this up (couldnt use the app otherwise)without explaining properly what was going on

The app offered a keypad - where users were highly likely to set up a weak pin

Could of easily included all this data in existing backups, which use a secure passphrase that the app assigns @waterbear @__h2__ @fdroidorg

@waterbear @fdroidorg The core problem is not whether we think SGX will work or not; the core problem is that SGX reverses the entire trust model of Signal.

Before it was "We have no data, so you don't need to trust us".

Now it is "We have your data, but we are smart nerds and will manage to protect it."

@__h2__ @fdroidorg
Just completed the survey. Thank you much for sharing the link to it!

@__h2__ @fdroidorg I told them about not enjoying having to disclose my phone number to everyone, I'd like federation, and that being suddenly forced to use a PIN which still hasn't been explained was a very jarring user experience.

@adam @__h2__ @fdroidorg yep they're world class at security but maybe 10th or worse when it comes to usability

@adam @fdroidorg I have mixed feelings about this. You can get Signal-like encryption on XMPP, but people are not buying it. They want contact-discovery via phone-numbers / address book.

I think that it is not ideal, but changing it means that Signal would need to store the entire contact-graph of the network, which is much worse from my POV. I think they want to go there which is why they are doing the SGX-thing.

@__h2__ @fdroidorg I'm not sure I follow. Why would using usernames for unique identifiers instead of phone numbers require server side storage of people's contact lists?

The only motivation I can think of for moving contact lists server side would be to make moving from one phone to another easier, but that's not required to implement easy migration.

@adam @fdroidorg You are right, this is not required, it is just how XMPP is implemented right now.

But not having this decreases usability even further. You wouldn't only need to discover all of your contact's usernames, but also need to rediscover them when you lose your phone. All these things are solvable, but I just don't see it happening.

The things I asked for are very straightforward and don't require coimplicated changes of the status quo.

@__h2__ @fdroidorg Signal protocol over XMPP sounds great to me. When people lose their phone, they can recover the XMPP usernames of the people they talk to the same way they would recover their address book (which for me is backups)

I do hear you about discoverability though. Usernames require two parts so it's clear which server should get the traffic. People accepted that paradigm for email though.

Do you know of any mobile apps that make e2ee XMPP easy?

@adam @fdroidorg Conversations has Signal-grade encryption (called OMEMO). It's fairly easy to use, but it relies on separate identifiers (regular XMPP).

I wrote a proposal some years ago to add phone-number bases client-side discovery, but the authors were not interested ;-)

github.com/iNPUTmice/Conversat

@__h2__ @fdroidorg I read through your proposal and my concern is that it would allow a guess-and-check way to obtain a person's contact list. Just query a user with all possible phone numbers. This is bad in that I can't control if anyone ever puts my JID and phone/email in their contact list and this feature is the link that allows randos to query this info.

If I were an advertiser, or Facebook or whomever, I'd absolutely use this to suck up contact lists.

@__h2__ @fdroidorg The fact that the developer was so against the idea of phone numbers as a discovery mechanism and then later went on to implement phone numbers as a discovery mechanism is pretty disappointing, and in a centralized way at that. :-(

@__h2__ @fdroidorg I am going to give it a try though, just to see how it compares to Signal and Briar. If the UX is nice, then I'll dig into the crypto.

@__h2__ @fdroidorg Signal is neat and probably the most private way to go without sacrificing convenience, but I ended up going back to XMPP. It offers a lot more freedom while still being capable of being very private, especially with OMEMO and clients like Conversations/Quicksy and Gajim.

@__h2__
I won't install Signal solely because of the eye-popping list of permissions it wants on my phone. Beyond absurd.
@fdroidorg

@kot @__h2__ @fdroidorg

All permissions are explained here:

support.signal.org/hc/en-us/ar

Apart from localization and calendar, they are all used by major features of the app (camera for quickly snapping and sending pictures, contacts for contacts, microphone and camera for calls, storage for saving media sent and phone/sms to use signal to send standard sms, not just using data).

It works perfectly fine when most of them are deactivated, nothing forces you to activate them.

@__h2__
There exist issues for each of these points on github, look for it. Signal declined them.
@fdroidorg

@sadmin @fdroidorg I am aware of all these things, but I still end up using it, so I thought creating more publicity for the survey can't hurt.

@__h2__ well that was a quick one. But I think it's probably a lost cause anyway.

@sir @fdroidorg Federation is important, but hard to do if servers don't store the contact graph (which is a feature IMHO).

@io @sir @fdroidorg Yeah, I am not asking for federation. We have good federated networks already.

@__h2__ Second all of that. But i get a security warning on the survey site and my browser won't open it?

@__h2__ @fdroidorg
I did a) and wished they made more responsive app. :)

@__h2__ @fdroidorg

* Federation with #XMPP.
* Being free/libre as required by #GNU #FSDG, in order to use it in #Replicant and other free/libre distributions.

@__h2__ @fdroidorg

I dont find any connection between this survey and Signal on Signal website. May you share more detail about it?

@fossasap @__h2__ @fdroidorg

If you click on the survey, the starting page offers you another link to "Signal research", which brings you here: signal.org/blog/signal-researc
On this site - which looks official to me - you find a link back to the survey.

@fossasap @fdroidorg I was asked directly by the App on my phone, so I am fairly certain it is legit.

@__h2__ @fdroidorg

Thanks for your response. @bene has shared the releavnt link.

@__h2__ I completed that one, too! Didn't think of #3, but I asked for 1 and 2 as well. Especially when it comes to the accessibility of the desktop app. Currently, it's pretty horrible.

@mimi89999 @fdroidorg I love XMPP and I still have Conversations on my phone, but it is like PGPed e-mail: literally none of my contacts use it any longer.

I have hundreds of contacts on Telegram, maybe around 90 on Signal.
On Conversations I have maybe 10 and all of those prefer Signal.

@newt @fdroidorg It's a non-issue for me. We have networks that are federated and use separate IDs. I am not asking for Signal to become one of them.

I am merely asking for them to not change their threat model by storing my data and to support fully free platforms better.

In fact, not using phone numbers is what they are currently planning, I think, and which has led them to store data in the SGX.

@__h2__ @fdroidorg how is not using phone number for identification is in any way related to encrypted memory?

And how is using encrypted memory in any way bad here?

@newt @fdroidorg
Right now the contact list in Signal is stored client side, because the identifier is the phone number and that is stored in your address book. Signal servers don't know who I know or who I am in groups with.

If identifiers are separate, they are not stored in the address book and for any type of usability will be stored server-side. This reverses the trust model.

Whether this data is stored in SGX or not is another matter. Nation-scale adversaries will have access to SGX.

@__h2__ @fdroidorg understood.

Although if your threat model includes nation adversaries who might gain physical access to your hardware, I'd say Signal probably isn't gonna help either. Just saying.

@newt @fdroidorg Sure, if I am actively being targetted, this all won't help. But I think that for general centralised infrastructure a "know-nothing" approach is the best.

I would prefer decentral, but apparently "like WhatsApp" is the main criterium right now. So I would at least like this service to store as little data as possible.

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!