[WIP] Utilize Riot Instead of Wire #562
Labels
No Label
🔍🤖 Search Engines
approved
dependencies
duplicate
feedback wanted
high priority
I2P
iOS
low priority
OS
Self-contained networks
Social media
stale
streaming
todo
Tor
WIP
wontfix
XMPP
[m]
₿ cryptocurrency
ℹ️ help wanted
↔️ file sharing
⚙️ web extensions
✨ enhancement
❌ software removal
💬 discussion
🤖 Android
🐛 bug
💢 conflicting
📝 correction
🆘 critical
📧 email
🔒 file encryption
📁 file storage
🦊 Firefox
💻 hardware
🌐 hosting
🏠 housekeeping
🔐 password managers
🧰 productivity tools
🔎 research required
🌐 Social News Aggregators
🆕 software suggestion
👥 team chat
🔒 VPN
🌐 website issue
🚫 Windows
👁️ browsers
🖊️ digital notebooks
🗄️ DNS
🗨️ instant messaging (im)
🇦🇶 translations
No Milestone
No Assignees
1 Participants
No due date set.
Dependencies
No dependencies set.
Reference: privacyguides/privacytools.io#562
Loading…
Reference in New Issue
No description provided.
Delete Branch "Riot"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Description
Some of the many advantages to Riot/Matrix
HTML Preview
Replace [GITHUB_USERNAME] with your GitHub username and [BRANCH] with the branch name.
https://htmlpreview.github.io/?https://github.com/asdfghjz/privacytools.io/blob/Riot/index.html
I definitely think this is a good idea for the above reasons. I think Matrix also has enough momentum behind it to make it.
https://matrix.org/blog/2018/04/26/matrix-and-riot-confirmed-as-the-basis-for-frances-secure-instant-messenger-app/
https://matrix.org/blog/2017/08/24/the-librem-5-from-purism-a-matrix-native-smartphone/
Additionally it has been audited https://matrix.org/blog/2016/11/21/matrixs-olm-end-to-end-encryption-security-assessment-released-and-implemented-cross-platform-on-riot-at-last/
Another reason I thought of why I think this is a good idea is because to be honest, I think there's way too many efforts to "create secure messengers". Most of them with very varying degrees functionality, openness and federation. A lot are centralized, a lot are closed source, some are open source but centralized. A lot don't have any interoperability.
Centralization creates singular targets to be spied on manipulated or exploited. Just because the server https://github.com/wireapp/wire-server sources is available doesn't mean that's what the server is actually running. Nobody can really know that for certain.
The fact is Wire keeps metadata https://github.com/wireapp/wire/issues/214 in the name of offering certain features but then doesn't go on to be federated. I don't think centralization is a proper solution against metadata. (An argument Signal makes). I think things should either be federated (Matrix, Email etc) or server less (Tox, Ricochet) and you should pick whichever you find acceptable to your usage needs. Serverless messengers can come at the cost of some features but then be more secure. It really is up to the user to decide whether they need those features.
As a user I refuse to have 20 messenger programs on my phone. Matrix is the only project making an effort to bridge the gap. https://matrix.org/docs/guides/types-of-bridging.html wire doesn't really have any intention of being decentralized. https://github.com/wireapp/wire/issues/160 just like Signal.
I'm fine with replacing Wire, but let's keep Signal for to it's ease of use.
Since there's so many (types of) messengers and I fully agree with
Maybe we could expand this section and recommend 6 instead of 3 messengers? (Because now there are 3 main messengers and some that are merely "Worth mentioning".)
It's best to let the users decide instead of making decisions for them.
Yep I agree with that. I wasn't suggesting on removing it or changing it's placement.
I was thinking maybe a table or some way to represent the pros/cons of each. See https://github.com/privacytoolsIO/privacytools.io/issues/596 as that is not related to this pull request.
I do however think it should be a requirement that the "top 3" have been externally audited (Signal, Matrix and Ricochet have been). So I wouldn't recommend Tox take the place of Ricochet for example.
I'll merge this and let's discuss the section layout change in the thread of the issue you just created.
Let's expand the description of Riot though.
XMPP"Unescaped
"err protocole should be protocol
something like this i think would sound better, copied mostly from their Wikipedia article https://en.wikipedia.org/wiki/Riot.im
You may say something about it's usage being very much like IRC and XMPP but I wouldn't say that it is a successor as that infers that New Vector Limited developed those other things and now has stopped developing those things.
I'm particularly comfortable with this change given their presentation at 35C3 Matrix, the current status and year to date 2018-12-29
I am not comfortable with Riot/Matrix storing removed messages indefinitely (https://github.com/matrix-org/synapse/issues/1287 (& related issues)) and E2EE being warned about by the mobile app so I don't think any changes should be done to the experimental label for now.
Riot.im supports video so there's no reason it couldn't change places with Wire for "Encrypted Video & Voice Messenger" section as well.
Specification wise the encryption is stable and has been audited, this beta warning I think relates more to the user experience (UX) which they say will be fixed soon rather than security. They aim to enable encryption on by default for private communication.
I think this is particularly the case as Matrix and Riot confirmed as the basis for France’s Secure Instant Messenger app. In the 35C3 presentation above they indicated that DINSIC were doing more auditing with ANSSI.
There was a question in the Q&A at the end about this apparently raised by HackInt Apparently customized message retention, per room, per message is being added to the specification.
Ultimately though it does depend on servers adhering to that. There's nothing stopping other users from making screenshots of said messages and then storing those.
There is only so much the software can do and this will always be an honesty based thing rather than a security one. If you tell a secret to many people you can't expect them all to keep a secret, ultimately you reduce your risk by telling less people. This is the same as it would be for any real-life communication.
It's a bit like complaining that Matrix has more metadata than something like Tox or Ricochet. Yes that's true but it also is capable of doing a lot more than those clients ever will be able to.
There's always a trade off in regards to security vs features. The ultimate goal is to strive to meet the best of both worlds and make the software as usable as possible to a wide range of people.
Also as a side note there is a re-implementation of Riot on Android using Kotlin which will be coming soon, seeing as you mentioned the mobile client.
I also observed during this presentation the addition of XMPP bridging.
Synapse also keeps log in the database of each time device connects to the server and this is stored forever as currently there is no mechanism to remove it. This data includes, IP address, device fingerprint, user-agent and precise time. With one db query someone can get entire connection history on a user when, from where and which device.
Retention of messages is something that I've heard already last year that it will be added in no time.
At this moment I dont see how this could be advice as privacy aware service alternative. It's quite possible synapse stores more metadata then whatsapp at this point.
To be honest I don't see how this is a successor of XMPP. XMPP is still heavily developed protocol with same level of encryption (endtoend on most clients), bigger number of server implementation which shows diversity and asures the protocol not being controlled by one entity and being implemented in different programming languages. It offers bigger number of clients and is more established protocol. It has larger number of public servers https://compliance.conversations.im/ not to mention the fact that unlike matrix, xmpp is privacy/security oriented protocol (data retention in place, no information on device stored on server forever, possibility to on per user basis to switch off history server side storage), and has very low server resource requirements to run on (similar to email).
Which features do you refer to?
Matrix (unless using google services) does not do push but rather pull. Its the clients asking server every given time (depending on your settings) so battery usage is also affected.
Server side logging in case of matrix since you cant remove anything and everything you say (even redacted messages) is stored forever without any way for users to change it is at this moment anti-feature privacy wise. And yeah of course someone can make a photo of the conversation but we are talking about the server logging and it is logging everything without a way to set retention. Even redacted messages are not removed from the server and users are unaware about it.
Yeah but when E2E is used you can't read the messages without the keys, but you're right the existence of them isn't deniable. If that's a requirement for the user then Ricochet or Tox would be a better option for those users.
This is why it's not a one size fits all situation. I have only ever considered "redaction" feature as a toy. Maybe that's because I grew up with IRC, Email and internet forums like this where there was always the opportunity for someone to screenshot, quote, archive it etc.
I'm more comparing matrix to xmpp actually since tox and ricochet are utilizing totally different technology so shouldn't be comparable. I think privacy wise xmpp is more suitable and deserves more exposure rather then being treated as an obsolete technology that noone uses.
As for redaction, avarage joe thinks redacted means gone. It nowhere states otherwise. Also as far as metadata goes on matrix, everything you do on all devices is carefully stored in the database forever. There are some api endpoints for purging history, but there are no official tools (in the only working server implementation) and when using those not all metadata is removed from the database anyway.
It's useful tool for group communication with shiny webapp to go with it, but on the website that scares people with prying eyes and how much data proprietary apps are collecting promoting open source application that does exactly the same in terms of metadata collection without any warning is a bit strange.
Agreed. I have had to point that out many times in a couple of different issues. 😉
I think this needs to be rectified on the site and I have opened an issue here https://github.com/privacytoolsIO/privacytools.io/issues/746 discussing this further, please leave comments.
I think the main problem is the fragmentation over supported XEPs. We saw this with the XEP-0166: Jingle briefly mentioned in the history part of the XMPP wikipedia entry. This is the reason file transfer didn't work correctly between Pidgin/Adium (libpurple clients) and GoogleTalk.
End-to-end encryption was a downright mess:
You had Off-the-Record Messaging but this only covered the text of conversations and not file transfer or voice/video. Of course GoogleTalk and Facebook's XMPP gateway never implemented this.
Then OMEMO only some clients implement it, this solves some problems as it gives us many-to-many encrypted chat, offline messages queuing, forward secrecy, file transfer. However it does not encrypt voice or video communications.
Now we have Off-the-Record-Messaging (OTRv4) which offers some of the functionality too see presentation at 35C3. It is going to suffer from the same problems.
There were also two standards for OpenPGP encryption XEP-0027 and XEP-0374 (OX). There's a nice table Feature Comparison at the bottom.
In contrast to matrix's megaolm which is used for everything,
I think with the fragmentation surrounding XMPP it's unlikely to provide today's users with the features they expect from instant messaging. It never really managed to steal enough users from competitors like AIM, ICQ, MSN and Yahoo. All of these protocols since discontinued with the exception of ICQ. Microsoft saw Skype as a "successor" built on new technology.
Things were looking hopeful for XMPP around the time that Google announced GoogleTalk, and Facebook came on the scene with their XMPP gateway. As both companies have now discontinued their adoption and support for XMPP it is unlikely to gain any traction. Google had the marketing and Facebook had the user base.
You may appreciate this article and the comments on HN to summarize it points out a couple of issues:
A lot of effort has gone into the Matrix specification, and in turn this is clearly generating a lot more interest from developers who are likely to make good Matrix clients, but couldn't give two shits about making another XMPP client.
I think that as Matrix essentially uses HTTP with JSON it will scale a lot better. There's a lot more research here (on HTTP) and possible benefits from things like HTTP/3 which XMPP won't ever benefit from. The fact that Matrix also connects over a standard https port is a good thing in regard to getting around overly restrictive outgoing firewalls.
From that article I linked above:
I can kind of relate to this one although it's not what you'd expect from someone who is interested in privacy software. Most of my private conversations happen on a private IRC server which I use ZNC to connect to with either Weechat or Revolution IRC. It's reliable, low bandwidth, multi device and doesn't get in the way. If I need to send a file I usually just email it or stick it up on my server and the other person can then get at it by just clicking the https link. The server only supports TLS connections. For all other public communications, Freenode, OFTC etc I rely on transport encryption, (no E2E) but it's no matter because those are public channels anyway. Anyone can join or run a public logger.
I think E2E has become a bit of a buzzword rather than something users apply when they need improved confidentiality. The majority of conversations believe it or not I still have over email. If I need confidentiality I use PGP, unfortunately though most of the time I have to rely on opportunistic TLS which there has been some recent developments on. Email is ubiquitous, so I don't really have a choice.
For the occasional time I need voice/video I'll use qTox or TRIfA. They aren't perfect. I did try Ring (now Jami and had issues initiating a video conference. I tested it between a Linux desktop and a Windows desktop (because I knew the other person would be on Windows) and found that the uninstaller didn't remove the application correctly. I hope they've fixed this. Despite the flashy polished website the actual application was anything but that.
Matrix is still very experimental which is why I am yet to rely on it. It is making huge amounts of progress. I'm really curious about their plans for key distribution in Riot. There were some preliminary screenshots of how that might look when end-to-end encryption is on by default.
I think XMPP has had it's time. It's not so much the protocol but rather the clients. Conversations I don't think is going to be enough. I used Pidgin and Adium for XMPP from around 2004 till about 2014 and ran my own server. I ended up shutting the server down and discontinuing use because my friends had moved away to other things. I don't think I would be able to convince my friends to come back and there wouldn't exactly be shiny awesome features to help me do so.
I've heard this one before, apparently there is going to be additions to the Matrix specification that allow for customizable message retention, either per room or per message, however the speaker does note that this does rely on you trusting what happens on "the next server".
My personal view on this is if you're too worried that, you're you're using it wrong. This comes back to an age old problem in a time long before computers. If you're not comfortable sharing that data, you simply shouldn't. There's a couple of reasons for this, firstly no software is able to stop someone taking photos of the screen with a camera. Notice I didn't say "prevent someone from taking screenshots", because yes I know that is possible on Android, but there are ways around it.
Secondly it is entirely possible in the future the encryption might be broken. Maybe something like Logjam could exist and be used in conjunction with a large quantum computer? We know despite not being able to crack OTR and PGP communications the NSA collects up all that encrypted data anyway.
I actually think these redaction features should not be relied on for security purposes. Just take a look at Twitter, when someone of importance posts something embarrassing and then deletes it, there's usually been countless screenshots of it that get reposted. It is something software cannot fix. Perhaps I feel this way because I grew up in an age where there wasn't a lot of encryption and the services I used didn't allow you to "take something back".
I think this has a more humanistic side too. There are non-technical solutions to this problem. One of them could be simply saying "oh I meant ...." or "I'm very sorry that I offended you." I think it would make us all better human beings if we were able to vet ourselves before posting something that might need to be deleted.
The thing about the proprietary options is you have absolutely no control and have to trust that the E2E and key distribution actually works.
Even with PGP and Email, there's a certain amount of metadata of where something came from and where it needs to go to. You can only avoid this with server-less things like Tox and Ricochet, but then you'd have to agree upon communicating with someone on those in some other way beforehand. If you're not doing that in person, you're probably going to be leaving some metadata with some other protocol, somewhere else.
I think what we need is some sort of decentralized data store for messages on a system similar to the way FreeNet or IPFS works. Of course in regard to message retention, nothing is going to stop the recipient from distributing those messages on other networks. Software can't fix that issue and this area is going to need a lot more research.
Ouch thats a long one. I will answer just few things that poped up. Hopefully I will go through the whole post in time and address more things:
As you can see in xmpp complience table the number of server supporting all / most features is quite large, now with the https://github.com/openspace42/aenigma deploying fully compliant server things are looking even better and easier. Also the point of delivering more then instant messeging. XMPP is widely used for IoT and in contrary VOIP used in matrix is only supported in riot as its basically jitsi (ironically needs working xmpp server to run) slapped on top of the webapp.
Things are not looking that bad lately. You have conversation (android), Dino.im (linux and soon windows), monal (macOS, iOS), beagle.im (macOS), conversejs and jsxc (web), movim, salut (chat+social network), skeekxmpp (python framework supporting omemo) and number of others. The list of clients supporting OMEMO is also not that bad at this moment and there is more clients joining in in quite rapid pase. Of course some of the clients are far from perfect still but they are actively developed.
Contrary on matrix land, only Riot supports all the features including encryption.
Yes piding and adium are clients of the past and its about time to forget about them and focus on new stuff which is what developers of above clients are doing and are very active in pushing for better user experience.
Heard that one on number of occasions also :p
My matrix server at the moment hosts about active 50 matrix users online and uses about 8GB RAM, 250GB db, and 24GB RAM (db)
My XMPP server hosts about 247active users eats 253MB RAM and about 2DB database.
Not to mention general lag of sometimes even up to 15-30 minutes between servers on matrix network (ask any person hosting public synapse) which renders communication somewhat impossible.
As far as I know the specification is broken to the point synapse (the only server implementation) is not compatible with and this is the reason matrix was/is facing a fork from community members that were trying to create independent matrix implementation but were unable to do so because of the need to reverse engineer synapse rather then implement the spec.
I think its rather a feature to be able to choose your own encryption method. Being able to use GPG or OMEMO is great. The mere the better, isn't it? It's all about choice and having one proves always to be better then no choice. Esepcially where one solution (OMEMO) is the default one, and you can force it server wide if you like (again a choice).
Already implemented on conversations, dino, being implemented in monal too, and there is some key management (could be improved) in converse.
But why do I have to keep in on my server? For example, my server gets confiscated or stolen, all redacted possibly incriminating or embarrassing messages are still there. So you dont have to make a screenshot of something prior redaction, the info is there on the server and when subpoena'ed you need to give that info. This is the point I was making. I do not care if someone makes a screenshot . This messages should not live on the server because there is no reason for it to be there.
Of course matrix is new and shiny and of course a lot of marketing and buzz is created around it. Something that other protocols (xmpp) do not have or cant afford to have. But when you become part of the ecosystem outside of the main matrix.org server or better yet, run your own server, you realize things arent that great. If you start inspecting the database and amount of data stored it becomes even scary to some degree, especially when talking about privacy. Xmpp in my opinion suffers from the unfortunate google tripple E strategy and the fact that since its an old protocol people do not take it serious and want something new instead treating it as something dead and long forgotten. I think building on top of existing protocol like xmpp which proven to be scalable as fuck (gtalk, whatsapp, even online, origin and many more) with low resource footprint would have been more beneficial to all. In terms of performance matrix is miles behind xmpp and all the added features (like voip, widgets and all) are just a product of webapp not protocol itself.
Anyway. I know neither protocol is best and its mostly matter of preference (the market share of both combined is also close to zero when talking about federated instances in comparison to commercial alternatives). We could write here the entire year back and forth and would not convince neither side. I think the point I'm trying to make here is that xmpp is not dead and shouldn't be treated as forgotten protocol of the past. Would be nice if websites that contribute to the general exposure (marketing) of alternative free software tools would not burry xmpp underground.
This a good thing to see it improving. However there is a problem with having a dozen different clients with different user interfaces and differing levels of matureness.
It means if I use one client, and my friend is on another platform and I suggest they use X client. I can't be sure how "good" their experience will be. It also means if there is some problem I have to do a lot of testing to determine which client is at fault.
In terms of websites like privacytools.io we can't say "Use
x_flagship_client" and know they aren't going to royally fuck things up. There's a good reason that not all the other Matrix clients are recommended, mostly because they are missing core features.Even things like Matrix are still highly experimental and changing quite frequently. There are faults and there are regressions https://github.com/vector-im/riot-web/issues/8298
I have to say though I think Matrix is moving at a faster pace. Maybe that's because it's a more coordinated effort? Who knows exactly. I don't think the fragmentation in XMPP helps. At this point I wouldn't recommend any Matrix client but Riot. Considering the effort for Matrix began in 2014 and it has come this far I'd say things are looking good.
In contrast to XMPP where the effort started in 1998. I think a large part of the problem has been reactionary. A lot of proprietary protocols have implemented certain features and in turn XMPP has issued a XEP to react to that, rather than having it there to begin with. I also doubt it was helped by major implementations such as ejabberd using relatively obscure languages like Erlang. I am not criticizing their choice of that language, it may very well have been the best tool for the job at the time given it's focus on concurrency. It's not like we had Go at the time. It will be interesting to see how Dendrite stacks up.
I also think that Matrix provides a convergence of personal instant messaging and "chat rooms". From my experience XMPP's "chat rooms" were far less used than say IRC channels.
I also think MegaOlm will work a lot better in providing end-to-end encryption in this usage.
I do think there's a lot of refinements to still be made as the the server software stabilises. A lot of people have motivation to label something as "stable" long before it actually is.
It will be interesting to see what happens in the next 4 years.
As I said above, it's still early days. It will be interesting to see what happens after the spec stabilises. It's quite a monumental task what they have attempted. I have high hopes considering the progress they've made in such short time.
It is if users know which one to pick and why. Typically security is something users think about after the fact which is sometimes unfortunately too late.
This is why it's not a good idea to make this any more complicated than it needs to be. Unfortunately encryption is an area where users tend to "glaze over" if you try to explain too much about which one they should use for what.
I'm not denying the feature should exist, it just shouldn't be trusted from a user perspective.
Only time will tell. I'm hoping that Matrix improves some of it's performance. Apparently synapse switching to python 3 made a huge difference.
I do agree with that. I'm just not all that hopeful at this point.
Is there a proof that synapse/riot doesn't keep this kind of metadata? Because I'm pretty sure it does. There's literally no metadata removal in place.
@gerg5c42g542g2c54g52c yes it does store all that and more. like mentioned above it stores IP+agent+token+device_id+timestamp in the same table on every user for each time user's device connects (syncs) with matrix server.
Havent notice much improvement. It's the same resource hog as it used to be.
It's weird imo that it doesnt exist in the first place, and it does put a question mark as to why? It's a garbage data that user has no way of un-redacting anyway, then why do we keep it. I dont want to go too far in conspiracy/thin-foil hat theories as I think (hope) its not the case here, but this fact alone and the amount of meta stored without any retention is very strange. I can literally see when any user on my server logs in, from where and does what. Of course you can do that with any centralized system, but here its not logs, its db entries that live there forever. In terms of privacy it's horrible. (say police confiscates the server, because of investigation on political activists. Those people though that they are using privacy respecting tool so they should be safer then whasapp, the server stores all possible data on each of them forever. With the meta i can see in the database I really dont need the content of the message, there is enough info.
So unless things won't improve in that area, since performance, resource footprint might not be necessarily the problem in terms of what privacytools focusses on (though imo it is connected), I don't know how you can promote chat solution that does nothing in terms of less meta stored apart from implementing e2ee crypto which even whatsapp has.
@gerg5c42g542g2c54g52c to give you some more details.
Since Tuesday, December 6, 2016 12:58:36.296 AM I have been seen (and recorded in db)
14991times by matrix server. This entries consist of:user_id, access_token, device_id, ip, user_agent, last_seen - timestampAs for meta of the rooms most essntial and basic (all in one table) data stored is:
room_id, is_public, creator(user_id)And thats basics. Db stores all joins and leaves for each room to the point I can see which color people selected for the room.
@gerg5c42g542g2c54g52c, @muppeth
In regard to Matrix - in a federated universe you cannot expect the "deletion" of metadata to be enough. Anyone could set up a server which simply does not abide by those requests.
As mentioned in https://github.com/wireapp/wire/issues/214 that metadata could be incriminating on it's own.
This is the reasoning for me opening https://github.com/privacytoolsIO/privacytools.io/issues/746 and making the suggestions there that I have. I think users really do need to think about if metadata is dangerous to them and whether they really require the subset of features that makes use of that metadata.
I'm curious to know what you people think about that.
So how is it more privacy respecting and secure than Wire? You just said it's no more privacy respecting and you've been proven it's by default less respecting.
Your logic is distorted. Federation isn't mandatory in Matrix. The only sensible reason to use federation is self hosting and federating between small, trusted servers. Yes, I can obviously expect my own server to reliably abide removal requests. No, my own server isn't malicious and hence there's no way it will be set up in such a way that it doesn't abide these requests.
My recommendation is include Matrix on the website, but with self-hosted and experimental badges. If you use the default matrix.org server you'll much better off using one of the many centralized alternatives if you care about privacy. And its privacy, security, performance, encryption, documentation, governing and so on status is beta or alpha and therefore shouldn't be yet considered anything usable or serious unless you have extensive knowledge and you're willing to spend time on setting it up the right way (hint: it won't be easy).
of course i cant expect the metadata to be removed from remote servers. however with matrix you can be sure it isnt removed even from the originating server. its basically following in my opinion flaud logic that since its federated no data can be removed at all. like i mentioned before, for example diaspora gives possibility to remove local content (for example copyright) and it has a logic in place that will make the other servers remove it too (egsample, few months ago we had on our server a proper nazi account posting videos glorifying hitler. we removed the account with the option to purge content from remote servers. result? this accounts post dont exist in the network).
of course there can be bad actors in the network (just like the example of screenshot), but here we are talking about no option at all, and data (as much as possible) stored without any retention in place. so when using matrix you can be sure that every your move is monitored and saved by local server (a lot of data) and all servers participating in the rooms (less but still a lot of data) from the moment you logged in for the first time. the problem is that this is nowhere stated so great majority of people are un aware of it. i saw somewhere people advertising matrix as anonymous chat, and its in part because it is considered privacy friendly where in fact its far from it.
its open source - yes (though scalar as far as i know is closed source)
its decentralized - yes
its federated - yes
its privacy focused - no
On 5 February 2019 02:01:24 CET, tya99 notifications@github.com wrote:
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
It's a matter of perspective and whether or not you're using federation as you've said.
From the user side of things, a personal Matrix server (that isn't federated) is going to be be more trustworthy than the Wire server run by Wire Swiss GmbH. It is possible if you were the sysop at Wire Swiss GmbH your opinion on that might differ. Presumably this would be the way DINSIC runs their Matrix infrastructure, as in it's only for government employees and would not federate.
Wire do however say federation is on their long term roadmap. Wire may very well then have the same problems when joining a "Wire fediverse". Personally I think that's not a particularly good design decision to "tack federation on afterwards", as this may cause other design related issues that were not planned for, but that is a separate topic of conversation. To compare Matrix to Wire you'd really need to be comparing two private instances.
At the moment Riot isn't able to do multiple accounts I can see a scenario where you may have an account on the fediverse and an account on a private server. This is currently possible in more mature clients for things like XMPP. I used have a work account (only accessible via VPN) to a non-federated server and it used my authentication credentials from my work's LDAP server. I also had a public federated account on another server that I used to talk to everyone else.
That is assuming that said centralized servers do what they say. They still collect metadata, ie Wire and Signal and even XMPP. Federation isn't about privacy is just about who you trust. If you really want to minimise metadata you have to not have servers, or run your own in a confined manner that you trust.
So from a provider perspective there's going to be bad actors and you want to deal with them appropriately. When content is redacted you can then use cleanup scripts to remove the content from your server's database. In some cases this might be exactly what you want. As in if you want to do something with it before removing it.
This is different to retention and pruning. Pruning happens on your server whereas redactions are propagated.
Soon we should have MSC1763: Proposal for specifying configurable message retention periods which will be good as it will allow for the removal of old stuff on our servers.
None of the instant messenger programs are anonymous, with the exception of Ricochet and none of them claim to be either. This is why I suggested https://github.com/privacytoolsIO/privacytools.io/issues/746 to better educate people on this.
Trust is a different thing.
I confirmed with Whisper Systems that Signal stores message content and its metadata only until the message is delivered or, if the receiving end is inactive, until the message times out.
To be sure that the server does what you think it does, you have to host it in a DC you own (such as your house) and you have to host it yourself.
Will this delete metadata along with the message content? If not then it's still a huge step back in comparison to other messaging solutions.
Ricochet is merely obfuscating your identity, this is not true anonymity, not even in the cryptographic sense. It's important to understand this distinction.
I created two issues, contribute, if you know of anything I missed:
Metadata resistance in Matrix
Problems with self-hosting Matrix
@muppeth are you from disroot? Wanna keep in touch? I find it difficult to follow Matrix development in these areas, it's very time consuming and impossible to follow everything. Do you do this in any more organized way?
This is a legsislative control unfortunately at the moment. I don't how a NSL (like the one Lavabit got) couldn't be served at least for the metadata. They could easily add a section about not deleting the metadata for user "XYZ". In the case of LavaBit they demanded their TLS private key, which would have exposed all their customers. Even if the contents is protected knowing who is talking to whom would be of interest still to those organizations.
It will also be interesting to see if the other Five Eyes countries move towards doing something like what Australia did with their Assistance and Access Bill (summarized on ZDNet). I get this feeling governments would love to be able to push compromised versions of an app down the software distribution network to specific users.
Then there's also the key distribution network which it seems the GCHQ wants to exploit with their invisible participant idea.
In this video interview with Moxie from TechCrunch's 2017 event in San Francisco he states their main objective was to stop mass surveillance. He admits targeted surveillance is a much more difficult task. Moxie did mention there they are planning on developing a technology to require the user to "not trust anyone" whatever that means. I doubt it will be a distributed network as it's rather evident he isn't very fond of those. He has also indicated elsewhere he doesn't like federation either.
With a centralized service like Signal that would mean you'd only have yourself to talk to.
Well it does seem a bit unclear:
Yes you are right here. True anonymity is rather difficult to get in real-time communication protocols. If your Ricochet ID can be assosciated with your person then you're no longer anonymous.
Probably also too broad. As we've discussed previously nearly everythig has metadata somewhere, unless it's peer to peer and without servers.
I do however think those synapse scripts should be a part of the main project. I'd be reluctant to run them in case they broke something.
To be honest I think you got the correct reply there. You mentioned many different things in the one issue. I think you would have had more luck with opening individual issues with PRs with corrected documentation. This isn't unusual for an organisation that wants to review everything.
speaking as the project lead for matrix: we really do want it to be privacy-focused. from my perspective, the main issues are:
Meanwhile, everything we've been doing on Synapse recently has been around getting to a 1.0 which is stable and correct - but not fast. Yes, it's still a resource dog. But now 1.0 is (effectively) out the door, we are going to be blitzing the performance stuff at last. It's years overdue. You can see the roadmap details over at https://matrix.org/blog/2019/02/15/publishing-the-backend-roadmap/ if you're interested.
@ara4n
Hey Matthew - I have watched some of your talks and interviews online and I love what you're doing. However, after weeks of solid research (for a non tech like me, that's a lot of tech speak to handle in such a short time!) I am still none the wiser on whether Matrix is DEFINITELY secure and private (at least as much as competitors like Wire.
I get the point about decentralisation, and it's a commendable thing to do especially for the long term. However, I am more interested in privacy, forward secrecy, deniability and minimal metadata logging. How does Matrix stack up now? I have read tons of threads where Matrix gets criticised for various things (no point listing them, you will know better than me what they are!). But most of it is 4-12 months old, and I would love to know what, if anything, has changed since then?
For example, IS E2EE working? Can I have a chat with a friend on Riot and KNOW that the conversation CONTENTS are impossible to read by others?
Would love a general update on where things stand in June 2019, if you'd be kind enough. Thanks
Briefly:
Matrix 1.0 happened last week, so we're now focusing on performance and some residual privacy work.
E2EE works; I've been using it day-to-day for at least 2 years now.
yes.
It's still not turned on by default for private rooms. The main things blocking this are:
E2E search (which is almost done, as of last week)
Cross-signing to simplify verification (demoable as of last week)
Support for non-E2E clients via a shim (working as of a few weeks ago).
https://matrix.org/blog/2019/06/14/this-week-in-matrix-2019-06-14#crypto has more details on this. Once these have landed (and anything else at https://github.com/vector-im/riot-web/issues/6779) then we'll turn it on by default.
Metadata is stored on servers. Fixing this is a long term project.
We need to better at helping users understand where their contact data goes, and hash contact data during lookups (https://github.com/matrix-org/matrix-doc/issues/2130).
Forward secrecy is generally a contradiction in terms for Matrix, given that conversations are synced between devices - you need to be able to decrypt them on new devices, therefore they can't be forward secret. If you really want that, you can do so, but the resulting UX is bad.
Well that was fast! Thanks very much indeed.
"E2EE works; I've been using it day-to-day for at least 2 years now." - I had a feeling you'd say that. I have read several posts by people claiming it is not rolled out yet, but I was sure I had watched talks by you (old ones too) where you showed that E2EE was all working properly.
"It's still not turned on by default for private rooms." - I don't know if that will affect me or not, I have not used it yet but I am only looking to use it to replace Skype, one to one conversations only, no group love needed! I don't know if that means me and my friend still need to 'get a room', or whether Riot users can chat 1-1 without a room. Perhaps rather than explaining this (as I can of course learn this myself and will do), could you confirm what steps I should take if i want to chat with one person as securely/privately as possible on Riot? (I will be doing this later today)
So I think I am right in saying..... If I don't care about metadata (which I believe means 'who contacted who, when, on what devices') but want my conversation contents to be totally private, I could sign up and use Riot today and be perfectly confident in it fitting my needs. Can you confirm this please? (Sorry, after so many contradicting messages, having the main man here to ask, I would love to get this stated from the horse's mouth, no offence intended :D)
Oh and PS - Since you have dispelled much myth and misinformation I have ingested recently, maybe you could comment on another...... can Riot do screen shares? Some say yes its great, some say no its in beta and doesn't work!
Thanks again, keep up the great stuff you're all doing there.
Yes it is, and I have been using it for quite some time.
Yes you can private chat without a room and that is E2EE. However if you invite multiple people in on group video chat the server has to be able to mix the videos together, if I understand correctly to send them out. Other things like Tox don't do more than 1:1 video with others.
Yes.
@ara4n Have you got any idea when RiotX will be ready for F-Droid? I'm really looking forward to the Kotlin port getting exposure if it's 6x faster like you say.
I'd also see multi-account support an option, it's certainly been requested a few times https://github.com/vector-im/riot-android/issues/120 https://github.com/vector-im/riot-android/issues/1353 https://github.com/vector-im/riot-web/issues/2320 part of it is for a private (family) context and a public context (pseudonym). I guess I take that for granted being an longtime IRC user.
Thanks for chipping in. I also have a rooted android which I would like to use for chats, so I guess I would need something from FDroid too, as I wont use Google Paystore
I should have said really, regarding E2EE - Does that apply to all or just some of these:
Also, is there a screensharing function in Riot?
thanks
I do agree this could be set out a bit better on the website something like: as an example. My understanding is everything can be end-to-end encrypted, except 1:many voice/video calls, it's still encrypted but the server has to mix the feeds and send them back to the users participating.
Thanks. My riot app went haywire today. Failure connecting, long delays, all sorts of problems. I uninstalled and will reinstall tomorrow, maybe choosing another homeserver. I noticed the list, there's one in Russia which I quite fancy! But will probably go with chat.privacytools.io in the end.