i would like to know if are you looking into this with matrix guys?
I share some of these concerns. While on the Matrix website and in presentations the words “End-to-End” and “Encrypted” are used frequently, the statistics draw a different picture (source):
Also I currently get the impression from the Matrix blog that fancy features, UX improvements and bridging between different messaging silos (WhatsApp, Telegram etc), have higher priorities at the moment than laying the foundations for a truly decentralised identity management (also see the “needs” here from less than a week ago).
Another interesting fact are the permissions the Riot.im Android app currently requires:
android.permission.INTERNET
android.permission.VIBRATE
android.permission.READ_EXTERNAL_STORAGE
android.permission.READ_CONTACTS
android.permission.WRITE_EXTERNAL_STORAGE
android.permission.ACCESS_NETWORK_STATE
android.permission.READ_LOGS
android.permission.REORDER_TASKS
android.permission.GET_TASKS
android.permission.CAMERA
android.permission.RECORD_AUDIO
android.permission.MODIFY_AUDIO_SETTINGS
android.permission.MANAGE_DOCUMENTS
android.permission.WAKE_LOCK
android.permission.RECEIVE_BOOT_COMPLETED
com.sec.android.provider.badge.permission.READ
com.sec.android.provider.badge.permission.WRITE
com.htc.launcher.permission.READ_SETTINGS
com.htc.launcher.permission.UPDATE_SHORTCUT
com.sonyericsson.home.permission.BROADCAST_BADGE
com.anddoes.launcher.permission.UPDATE_COUNT
com.majeur.launcher.permission.UPDATE_BADGE
android.permission.BLUETOOTH
I understand it is still very early days for the Matrix project, so I hope that these things will improve significantly until the completion of the Librem 5. I also think we need to keep watching this space and keep asking for privacy if the situation doesn’t improve by itself.
As for the term “collect” Riot.im is using in its privacy statement, I think this just means that they get access to the respective data and may store it. Considering that they have the ability to bridge between messaging protocols, that’ll probably also mean they have (need) access to a user’s other instant messaging accounts… so users intending to use this feature may care even less about their privacy/security; something I do not understand at all.
2 Likes
What I just said about “early days” seems to be confirmed by Riot’s security page:
As of May 2017 Riot’s end-to-end encryption is technically in beta, but this is due to some residual stability bugs and missing usability features. Once these are resolved we plan to get the full implementation security assessed and out of beta. End-to-end encryption will then be turned on by default for private conversations.
2 Likes
first problem is servers, because with this privacy policy they log too much things
second one is permission app, but let’s see how librem 5 handle it
i’d like to have an official reply from purism about it, because i feel it as a privacy problem
I just hope this matrix stuff will be optional and removable, not integrated into the core messaging system of the phone. so that i could just wipe it clean and install my preferred messaging app.
I do understand about vanilla os and blah but hate to remove some core components. I.e. removing telepathy stack with libcomhistoryd on jolla is possible but insane (telepathy is pluggable though hence not bound to any specific protocol).
2 Likes
Hi folks - I’m the project lead for Matrix.org; only just found this, so sorry for the delay. Quick answers on my side:
-
@eagle: The current plan is not to use Riot on the Librem5 but a dedicated native client (Riot has no native linux clients). In terms of the privacy policy for Riot:
- It only applies to users on the matrix-org (or hypothetical riot-im) homeserver. The whole point of Matrix is that you can run the client against whatever server you like, and be beholden to that server’s policy. For instance, for the Librem5 the plan is to for Purism to supply their own default homeserver for their users, with whatever privacy policy Purism desires.
- Agreed that the policy is too large and scary, although in practice all it does is to spell out (in gratuitious detail) the data which you share by using Matrix at all; forbid illegality and abuse; and give the right to optionally use analytics in the apps to help us see what features people are using and how much.
- The reason the policy is so large and doesn’t have a TL;DR is that it was provided by the corporate overlords who used to fund Matrix and Riot. As of July we no longer work for them, and the policy has yet to be updated to reflect the new setup (which is now an independent startup). When we do this in the near future we intend to make it much clearer and less scary, as well as make it clearer that, again, it only applies to people using the default matrix.org homeserver.
- With this all in mind, I’m not sure I agree that Matrix is “a privacy problem”.
-
@shagreen: Riot/Android should let you find users fine without giving access to your contacts; since July[1] it implements the ‘user search’ API which lets you query your server for all the users you have rooms in common with or who are in publicly visible rooms. Now, if you still can’t find the user, then you either enter their email address or phone number. Finally, you also have the option of searching your contacts, but only if you give permission. So we’re hardly mandating it
- cgelinek: It should be a no-brainer that improving the app’s UX (to avoid confusion like @shagreen’s above) is as important if not more so than working on deeper infrastructure work like decentralised identity/reputation. You’re right that E2E is still being polished, but we’re working on this as fast as we can and the support of the Librem5 project helps substantially with this. In terms of it being “early days” - it may still be beta right now but it’s still the most advanced decentralised end-to-end encryption solution out there, plus the first to have a public audit of its core crypto. In terms of permissions: I believe that all of the perms you’ve quoted for the Android app are these days prompted incrementally (in Android M and later) as you use the features which require them; we spent ages[2] getting this right.
- ruff I’m sure you’ll be able to delete the default dialler/messaging app if you so desire.
16 Likes
[1] https://github.com/matrix-org/matrix-android-sdk/commit/daa3d2a2148878097612e9e038d024d1098ff195
[2] https://github.com/vector-im/riot-android/pull/232
3 Likes
thank you @matthew for your reply, it’s very appreciated
is awesome to have the option to make your own server, the problem is for normal users who are not able to do it, so we have to trust the server admin/owner
because all surveillance we see from big corps and governments, company like purism and alternative messagging system like matrix are welcome, but even if your intentions are the best one, people like me will be ever scared from what should be happen to our data, because we need to trust you, but we know in the age of surveliance and big data economy we can trust no one, so the best thinks you (both matrix and purism) can do is to make products/service where the data you have is essential and well encrypted from user, so you can see nothing, and the privacy policy should be essential, as i already wrote in another topic
otherwise is just about a choice to trust android-whatsapp or purism-matrix, this is not bad, but the goal is to do not have the trusting problem, chosing a service who have no visible data but just encrypted with a good, short and well readable privacy policy, where if a malicius dev or an hacker see/sells the stored data, can just access to a useless encrypted file
same for the client, i’m scaried from android apps permission, and i really hope purism will make this issue a priority, giving to the user the full power to manage it with a good user interface and popups when needed, and of course i hope matrix client will just require the permission who really need and will access to the data when WE choose to use it
i know i’m paranoid, but as i wrote we live in a big data surveillance/economy era, and freedom is really important to me, i think company like matrix and purism have this user target, because normal user will just spend 100$ for and android phone with whatsapp used by almost everyone, less money needed and less problem, i have to convince people to use matrix to comunicate with me, and every time i’ll be watched like an alien “why you are not using whatsapp?” and so on, than i will explain why i really think different, and that’s why your policies and how the service/data storage work need to be made for paranoid like me, thanks to snowden and others heroes, we know we cannot really trust people or companies, that’s why technology architecture are important more than manifesto
2 Likes
i’m happy to see you like “my model” of privacy policy, i hope you, both purism and matrix server, will use it
opt-in is also awesome as i understand you need analytics for improve your product, and with opt-in you will respect the user privacy and will
about android permission i just don’t like how android work, but this is because usually apps will abuse of these permission
after your replies i’m satisfied about matrix or i’ll be when i’ll see the newer privacy policy from you and from purism server of course
let us update on this if you still have time to communicate with us, thanks again for your time and your work, is important to have a privacy wise comunication system to be used for freedom and free speech
1 Like
yes, i found that wondrous when i touched matrix the first time. for purism which states to use telepathy (which i consider the way to go while not really usable currently) i wonder if there would be a native “connection manager” for matrix (a libpurple one seems to exists and there is a bridge from telepathy).
@purism: will there be a telepathy connection manager for sms/mms? 
where are you seeing that Purism is going to use Telepathy?
i’ve read it somewhere but don’t remember where and can’t find it with their search. it may well be that it was mentioned as part of pureOS and they tell pureOS will be installed on librem5…
i like the telepathy idea as (in theory) you can freely choose the protocol and the gui. but i found a mailthread now about the topic which even mentions matrix and librem5 (and contains a post from a Matthew Hodgson - is that you? ) which tells alot about architectural problems of telepathy… so what 's your oppinion?
Yup, that mail-thread was me too. As you saw, there was debate on whether telepathy should be left to die, or whether Matrix could replace it (albeit with quite a different architecture, given the multi-headed approach would be done serverside rather than clientside), or whether there’s a “telepathy but done right” model which could work better, providing a local OS abstraction which could be backed by Matrix (or other connectors if preferred). To my knowledge there hasn’t been a conclusion yet, although on the Matrix side we’re syncing with Purism about it this week.
3 Likes
i’m quite new to matrix (old user of irc and jabber) but amazed. but from my view matrix cant be a replacement for telepathy (i wondered about the subject already) as it’s below: as you say: a huge change in architecture.
the telepathy design fits so well because you are forced to stay on the device with a mobile if you want to support sms/mms, a proxy is mentioned there but that sounds ugly.
i’m not that deep into the messanging topic (only seen that empathy is unusable) - can you enlighten me about the major problems of the telepathy architecture? is it fixable with affortable efforts?
Rob McQueen (who I think ran the telepathy project) wrote a huge rant on its problems here: https://mail.gnome.org/archives/desktop-devel-list/2017-September/msg00047.html. Meanwhile, some of the stuff that telepathy doesn’t implement (and can’t, without big reengineering effort) include:
- Infinite scrollback serverside history
- Synced history across multiple devices
- Server side search
- Server side notification settings
- Read receipts
- Read-up-to markers
- Multiway voip
- Promoting 1:1s to group chats and vice versa
- Native end-to-end encryption (verifying keys, devices, sharing keys, etc)
- Encrypted file transfers
- Redacted msgs
- Reactions / upvotes / downvotes
- Editable msgs
- Pinned messages
- Threading
You’re right that Matrix isn’t a direct replacement, as architecturally it differs. However, one approach being considered is to expose a Matrix-like API in the OS which maps easily to the Matrix client/server protocol, and is handled by a daemon process of some kind which handles some of the heavy lifting (e.g. E2E crypto; local chat history). This daemon could also implement other backends direct to IRC, XMPP, Slack or whatever if people wanted to take Matrix out of the loop entirely - at which point it starts feeling a bit like a modern version of telepathy (although in practice the only ‘connector’ which we’d be focusing on the Matrix side would of be the Matrix-backed one).
</thought experiment>
3 Likes
so you see matrix protocol as a blueprint for an api which can be used for others protocols or even local stuff like sms or voice-call - did i get that right?
still a background daemon handles the local stuff (i already thought of history, i’m often in areas without internet access and hate not to be able to use my phone), i like that idea…
what’s your oppinion about d-bus? the mailthread states it’s the cause for bad performance.
1 Like
Matrix already bridges through to many protocols (IRC, Slack, XMPP, Gitter, Telegram etc) but does so using bridges which run (conceptually) server-side. But yes, in the hypothetical daemon model, the same generic Matrix-like RPC API could also abstract other protocols directly (or local stuff like SMS & PSTN calls), similar to Telepathy.
I haven’t played with D-Bus much myself, so all I’ve seen is the Telepathy guys implying that it introduced too much complexity. An alternate solution could be to have the local daemon API just be the Matrix HTTP API (but immediately converting that to other protocols if/when it makes sense). An a final extreme would be to have the local daemon be a full Matrix homeserver (albeit one set up for p2p federation, in future).
4 Likes
Ugh oh by the sound of it it will be integrated into dialer - which is all about the insanity I’ve mentioned in my post.
As for telepathy…
I’ve attempted adding features to gabble but the only thing I’ve managed to add was roster versioning and csi. anything else (eg simple carbons) stumbles upon ambiguity of the client implementation.
In any case - new platform, new challenges. let see what exactly will be on the plate.
well, as per the previous posts in the thread, there’s discussion about abstracting it from the dialler. and one could always fork or swap the dialler for whatever tech floats your boat…
2 Likes
Hello all, I have found this very interesting thread about Matrix/Riot. I would like to share my “average man in the street” feedback and ask a request.
1. First, the feedback :
My wife and I are not expert in softwares. We like when we use and it works easily. I have installed Riot for Android for both of us… and I can say that it was not intuitive at all. The homeserver/identity server fields appeared strange for us.
Then we had to setup the E2E discussion, and the “room”. Same here, not easy.
However, when everything is setup, we can say that it works pretty well. We are really happy to see such an app allowing to communicate in a cross-platform way. And despite all the “bad points”, the overall is positive.
2. Request :
So seeing the above concerns, I would like to know :
- if a “easy setup/advanced setup” can be put in place (think about beginners, we like this app but we are so bad ^^ !).
- if the discussions can be the homescreen of the app (like common messenger apps) instead of rooms ?
In any case, thank you very much.
We understand that the project is at the beginning and we are very impressed about the progress. Also, my requests and feedback are our opinion, but maybe people have different opinion.
4 Likes