prism-break / prism-break

Privacy/security-oriented software recommendations (mirrored from GitLab)
https://gitlab.com/prism-break/prism-break
GNU General Public License v3.0
1.27k stars 288 forks source link

Delete Riot (Instant Messaging and Video & Voice) #1936

Closed RiQuY closed 6 years ago

RiQuY commented 6 years ago

The open source idea and decentraliced network was a good idea, but just take a look at the Privacy Policy. Riot will store everything you send and that's pretty bad and intrusive.

https://riot.im/privacy Read the part "What kinds of information do we collect?": Also check "When might we disclose your information?"

Zegnat commented 6 years ago

Not sure how to handle this. First of all it looks like a pretty standard boilerplate privacy policy for any sort of online service. And service is the key word there.

The Riot Service is what you use when you do not run the server software yourself. Of course this service will have access to the data you are sending by using it. Of course this data may contain “personally identifiable data”, and of course you explicitly give it PID when you tell the service that you want to to authenticate to Slack (and others) on your behalf.

Note that they also make it clear that the communication content “may be encrypted by your client”. That’s how you make sure the service cannot know what you are sending, by using encryption on your end. According to the security note Riot themselves are working on putting end-to-end encryption in their web client, actively working to make sure they will not accidentally end up owning your data.

I am split on this issue. There are enough other IM options listed, and I wouldn’t see removing Riot as the biggest loss. On the other hand, the argument made here is to throw out everything that offers a hosted version.

What about Diaspora? We haven’t checked the privacy policies on all the recommended Pods. It should be implied that PRISM Break doesn’t recommend all Pods and encourages you to self host. The same applies to Riot.

RiQuY commented 6 years ago

I think that the worst part is that he can sell our data to search engines or others, as seen in "When might we disclose your information?". I know that the server maybe needs to maintain the data, but they should not share it in any circunstance.

Zegnat commented 6 years ago

You mean this line?

We may share personal information with analytics and search engine providers that assist us in the improvement and optimisation of our Website and Service.

This is why I expect this to be some sort of boilerplate privacy policy. Things like your IP address and browser information are PID depending on jurisdiction. And obviously those sort of statistics are being recorded. Rather than trying to specify what info they collect for analytics and what they do not, they rather just put a blanket statement on there.

It might be worth contacting them to clear that up: do they even use external analytics services? What exactly do they hand over?

I’ll be interested in seeing what other people think.

anthologist commented 6 years ago

That's just the privacy policy of the Riot service, you can use the Riot client with a server of your choice and every server can have a different policy. So isn't prims-break recommending just the client?

Hillside502 commented 6 years ago

Riot the service hides behind Cloudflare https://iplookup.flagfox.net/?ip=104.27.178.139&host=riot.im https://www.shodan.io/host/104.27.178.139

So, there's a data sharing interested party!

r3k2 commented 6 years ago

Also in any case they should add matrix not riot, riot is just one client for matrix, but there are other clients even weechat that do not have to act the same way as riot.

anthologist commented 6 years ago

Maybe Prism Break should explicitly suggest "Riot client" and add a note to say not using the official server?

ara4n commented 6 years ago

I'm the project lead for Matrix (and Riot). Quick feedback:

Riot will store everything you send and that's pretty bad and intrusive.

Yes, the whole point of the Matrix protocol is to synchronise conversations between different clients and servers. That means that you have to store the conversations in order to synchronise them :(

Other comments:

I think that the worst part is that he can sell our data to search engines or others, as seen in "When might we disclose your information?".

Huh? We categorically are not selling anyone's data or metadata to anyone. I assume this is a misreading of the current policy.

Matrix is the only decentralised communication system with multidevice history-sharing E2E encryption that I know of. I would strongly recommend keeping it in the prism-break DB, for that reason alone - although feel free to recommend people to use their own servers rather than the default matrix.org if needed.

lukateras commented 6 years ago

We no longer use any external analytics in Riot (we originally used Google Analytics for expedience but phased it out last year). Nowadays all analytics is opt-in and even then only goes to our own hosted Matomo (Piwik).

In that case, this issue doesn't really hold up. Thanks for the detailed response!

(Also, Riot will become end-to-end encrypted eventually, see: https://github.com/nylira/prism-break/pull/1953#issuecomment-384660933, https://github.com/nylira/prism-break/issues/1963)

maxidorius commented 6 years ago

We no longer use any external analytics in Riot [...]. Nowadays all analytics is opt-in and even then only goes to our own hosted Matomo (Piwik).

@yegortimoshenko @ara4n At the time of this comment:

maxidorius commented 6 years ago

Also, several default features rely on the matrix.org server which doesn't improve self-hosting privacy by that much since Cloudfare can see all the traffic decrypted AFAIK, like:

maxidorius commented 6 years ago

Finally, as a Voice/Video client:

maxidorius commented 6 years ago

My personal believe is that Riot doesn't help evade PRISM since it relies on a whole set of services and practices that are playbook PRISM interception targets.

Hillside502 commented 6 years ago

Riot.im Android app embeds:-

RiQuY commented 6 years ago

@ara4n Maybe I'm understanding bad the Privacy Policy because english is not my native language, but I think this text from the Privacy Policy seems weird to me about handling privacy.

Quote: https://riot.im/privacy ################################# When might we disclose your information?

· To improve the Website and our Services We may share personal information with analytics and search engine providers that assist us in the improvement and optimisation of our Website and Service.

· Within our group. We may share your personal information with any member of our group, which means our subsidiaries, our ultimate holding company and its subsidiaries, as defined in section 1159 of the UK Companies Act 2006.

· With our third party suppliers. We may need to share your personal information with our business partners, suppliers and sub-contractors for the performance of any contract we enter into with them or you. We will only disclose information to third parties who are under obligations of confidentiality in respect of the personal data they receive.

· If NEW VECTOR LIMITED is sold. In the event that we sell or buy any business or assets, we may disclose your personal data to the prospective seller or buyer of such business or assets.

If we or substantially all of our assets are acquired by a third party, personal data held by us about our users will be one of the transferred assets. #################################

Hillside502 commented 6 years ago

We may share personal information with analytics and search engine providers We may share your personal information with any member of our group We may need to share your personal information

Your understanding of English is perfect!

Bunch of arse holes!!!

RiQuY commented 6 years ago

@Hillside502 We should keep this debate serious and friendly.

Hillside502 commented 6 years ago

Yeah. Bunch of friendly arse holes!

ara4n commented 6 years ago

@RiQuY:

@ara4n Maybe I'm understanding bad the Privacy Policy because english is not my native language, but I think this text from the Privacy Policy seems weird to me about handling privacy.

agreed that it's overzealous (which is why we're rewriting it currently), but this wording is typical legal ass-covering which we unwillingly inherited from our previous employers.

We may share personal information with analytics and search engine providers that assist us in the improvement and optimisation of our Website and Service.

This covers us for using Google Analytics or similar. In practice, we don't any more - we use a self-hosted Piwik, but we haven't updated the privacy policy since we stopped using GA.

· Within our group. We may share your personal information with any member of our group, which means our subsidiaries, our ultimate holding company and its subsidiaries, as defined in section 1159 of the UK Companies Act 2006.

This is a no-brainer, i hope. The matrix.org homeserver is run by New Vector Ltd (a UK private limited company). We also have a French wholly-owned subsidiary (New Vector SARL) which employs folks in France working on Riot. Therefore we need to be able to share data with them in the process of the working on the platform.

· If NEW VECTOR LIMITED is sold. In the event that we sell or buy any business or assets, we may disclose your personal data to the prospective seller or buyer of such business or assets.

If the company was sold, then ownership of the servers which run the matrix.org homeserver would pass to the company who bought us, so they would automatically get access to the data on it. We'd obviously inform everyone if this happened though so they could nuke their accounts if they wanted.

In short: I agree that the wording sounds scary, but hopefully it's clear that the reality is innocent. This is why we're currently rewriting the wretched privacy policy.

@Hillside502: wow, whatever did we do to you? :(

Riot.im Android app embeds:- Google Cloud Messaging (GCM) Firebase Google gson

Yup, the play store version of the app uses google for push notifications (GCM and Firebase (FCM)), and we use Google's gson JSON library. If you don't like GCM, use the Fdroid version or turn it off (Riot/Android 0.8.7 has a whole new compsulory UI to steer you through the process of disabling push and switching to a fallback mechanism if you don't trust Google, even on the playstore version). The gson library is just a JSON library which happens to be written by Google. If you don't trust it, you probably need your tinfoil hat checked.

@maxidor: for someone who spends time selling solutions based on Matrix, you sure spend a lot of time trying to make us out to be the bad guys.

The intention is for Piwik to be opt-in by default on all platforms these days. From memory iOS and Android (on Fdroid) gets this right. Looks like I need to check what the Web (and Android playstore) apps do currently.

matrix.org acts as the one and only server key proxy for Perspective by default in every synapse install (Source) which allows to collect meta-data about which servers are potentially talking together

We do not do this to gather metadata, and even if we did, the metadata would be negligible - just showing which servers are requesting keys. Instead, we do this to seed the perspectives system, and admins are welcome to choose other perspectives roots if they don't trust matrix.org. Meanwhile, we're looking at removing perspectives entirely going forwards.

Riot uses the matrix.org push server for smartphone notifications, without a (clear?) way to change it, potentially seeing the content of messages in rooms where matrix.org is normally not involved

Message contents only get sent to the push server if the client requests it for convenience, and Riot doesn't. Meanwhile, it's (unfortunately) just the way that APNS and GCM work that each app requires a centralised push server. This is why we're spending time in GSoC this year to develop a decentralised alternative to APNS & GCM: https://summerofcode.withgoogle.com/organizations/6091058287476736/#5936132521459712

Riot ships by default with the vector.im Identity server, which provides no clear, forthcoming way to manage and control emails and phone numbers that are shared with it, all under New Vector's control.

The IS API lets you manage 3rd party ID mappings: https://matrix.org/docs/spec/identity_service/unstable.html#establishing-associations - you're right that removing mappings is missing though; perhaps you could provide a patch rather than throwing us under the bus.

By default, Riot Android (and maybe iOS) will share your entire contact list with your Identity server (vector.im by default) when adding/inviting someone to a room (in the search screen of the contact list)

If you explicitly opt-in and give the app permission, it will search your contacts for Matrix users when you try to invite someone to a room. This means finding out which of your contacts are on Matrix by querying an identity server. Obviously this is not appealing to some users, which is why it is behind a permission prompt.

Riot-web (at least) uses the Google STUN servers as hardcoded fallback for WebRTC, which also affects self-hosted homeservers and Riot installs - Source.

By default we provide matrix.org-hosted STUN (TURN) servers for users on matrix.org. If people run their own server, then they need to run their own TURN servers. We provide the Google ones as a fallback, however we could equally provide the matrix.org ones instead; thanks for suggesting it in such a constructive manner; i've filed it at https://github.com/vector-im/riot-meta/issues/150.

By default in Riot, conferencing is to use the Jitsi Widget (an iframe view) which is hosted by matrix.org. Therefore, all voice & video traffic (+ some signaling) potentially goes through Cloudfare and New Vector (legal entity behind Matrix.org) servers even if you self-host Riot and your homeserver.

We've been forced to use Cloudflare (unwillingly) as DDoS mitigation after a catastrophic DDoS in March. Voice & Video traffic however goes via TURN and RTP and happens not to go through Cloudflare currently. Self-hosting Jitsi is something we'd love to do and will do as soon as we re-hire someone to work on it (as the guy working on self-hosted Jitsi quit mid-project due to funding problems last year).

@maxidor: congratulations on spraying an impressive amount of FUD. I ask you to consider whether you are actually helping Matrix succeed by trying to make those working on it out to be evil :| You might also want to consider whether you really want to be going down on record as behaving like this, given I suspect it would be a major turn-off to folks looking to Kamax.io for Matrix services. At least, I wouldn't want to do business with someone who stabs their chosen platform in the back.

maxidorius commented 6 years ago

@ara4n: Let's keep this about facts. You seem to make this very feeling-based and not given straight answers to those facts. I am only concerned about issues that can be used by PRISM from known attack methods and inform people who are not aware of them.

for someone who spends time selling solutions based on Matrix, you sure spend a lot of time trying to make us out to be the bad guys.

Only stating facts and letting people decide what should be made of those. Giving me personal opinion sometimes and doing my best to label it as such. If you believe I've made a factual mistake, I'll gladly correct it.

If you explicitly opt-in and give the app permission, it will search your contacts for Matrix users when you try to invite someone to a room. This means finding out which of your contacts are on Matrix by querying an identity server.

Only in the most recent version. Also, the prompt doesn't inform it will be shared by to a third-party service, only that Riot needs to access the contact list, but not to send all the emails and phone numbers.
But you're right, not by default per-se. I stand corrected on that word. Let's say it's missleading. I have edited my comment accordingly.

Voice & Video traffic however goes via TURN and RTP and happens not to go through Cloudflare currently.

The Jitsi widget and the Matrix endpoint to get the TURN credentials both go through Cloudfare at time of writing, which means that if Cloudfare was used by PRISM, you could potentially do man-in-the-middle since you control the TURN provider, the exchange of candidates and the SFU. I don't see an issue with my original wording which included potentially.


General feedback for all the other points:

The whole point of this repo is to avoid leaking data in the first place, and listing solutions that ensure it doesn't happen. We only have your word on how those are used. At this point, people running matrix.org/vector.im over the years seem to have a bad habit of not protecting users meta-data which are one of the targets of PRISM, but also people who do not want to use matrix.org but still do unless they spend extensive time researching the protocol. Myself and others have voiced and reported those issues many times (latest in date was the opt-out phone-home in synapse debian package) but little is done pro-actively towards privacy.

Informing those users IS the purpose of this repository (@yegortimoshenko correct me if I'm wrong), which I attempt to do to the best of my ability and knowledge. Again, if I am wrong about something, please let me know.

But in this instance, I'm referring to anyone who has potential access to the data: Cloudfare, potentially your ISP, yourself, any of the share holders of New Vector, your employees, or anyone that could be given access following the very broad Privacy terms. So unless you are the sole owner of those legal entities, I don't see how you can ever claim data sent your way is safe from PRISM. If you can, please let us know.

Other products listed in this repo manage to do it in a simple way: Don't collect any data. Don't share any data. Don't make your servers part of default opt-out services. There would nothing to listen to via PRISM using New Vector's infrastructure.

congratulations on spraying an impressive amount of FUD. I ask you to consider whether you are actually helping Matrix succeed by trying to make those working on it out to be evil :| You might also want to consider whether you really want to be going down on record as behaving like this, given I suspect it would be a major turn-off to folks looking to Kamax.io for Matrix services. At least, I wouldn't want to do business with someone who stabs their chosen platform in the back.

We are supporters of the Matrix protocol, which exists solely in the spec, to which we contribute regularly in various forms. We are eagerly waiting for the promised non-profit Matrix Foundation with healthy articles which we could potentially support.

We have spent a long time analyzing the protocol, the community, New Vector. We also had the chance to see which decisions were made and why, and how some were beneficial to the protocol and some were harmful to it. We very much do love our ability to be critical about all the good sides and all the bad sides. We thrive to be an independent entity that keep you and anyone else in a position of power honest. Thank you for letting people know about it.

Feel free to explain how we are stabbing our chosen protocol (and not platform) in the back by informing users and customers alike about privacy risks of using Riot (and the other New Vector services), since Privacy is one of our core business values?

lukateras commented 6 years ago

@Hillside502: Upstream clearly doesn't have any malicious intent, please don't call them words. We all want the same thing, and they are being reasonable and are doing more for decentralized/secure comms than most of us.

@maxidor: Yes, informing users is the purpose of this repository. And also thanks for all the input!


  • Riot-web via https://riot.im/app -> Analytics is opt-out by default
  • Riot-web self-hosted -> Analytics is opt-out by default
  • Riot Android on Playstore -> Analytics is opt-out by default
  • Riot iOS -> I don't have an iOS device, can't test

Analytics are disabled by default in the F-Droid version: https://f-droid.org/packages/im.vector.alpha/

And seemingly on iOS version.

@ara4n voiced that the intention is to make analytics opt-in across all Riot apps.

Riot uses the matrix.org push server for smartphone notifications, without a (clear?) way to change it, potentially seeing the content of messages in rooms where matrix.org is normally not involved

True, that said Riot on Android does implement polling which resolves this issue (by draining phone battery :-). Again, Riot seems to be interested in solving this issue.

Riot-web (at least) uses the Google STUN servers as hardcoded fallback for WebRTC, which also affects self-hosted homeservers and Riot installs - Source.

As I understand, this can't be used for MITM. While I agree that it's undesirable to leak data to Google, the only piece of data that gets leaked in this case is IP address (seemingly). This is comparable with Firefox that uses several Google services.

Riot ships by default with the vector.im Identity server, which provides no clear, forthcoming way to manage and control emails and phone numbers that are shared with it, all under New Vector's control.

While I would also like communication software to not leak social graph, we currently list Kontalk, GPG, and Tox that also have this property. As far as I understand, it's possible to use Riot without leaking contacts list.

On ToS issues: upstream is working on a new ToS for the home server. It is important to account for the fact that Matrix is decentralized, so one doesn't have to follow that ToS.

The Jitsi widget and the Matrix endpoint to get the TURN credentials both go through Cloudfare at time of writing, which means that if Cloudfare was used by PRISM, you could potentially do man-in-the-middle since you control the TURN provider, the exchange of candidates and the SFU.

Can calls initiated in end-to-end encrypted chats be MITM'd?


In general, it seems that Matrix is willing to tackle all of substantial privacy issues raised here, so I would prefer to see Riot listed. The most important issue seems to be end-to-end encryption by default, which renders control of most of this data useless (see #1963).

Hillside502 commented 6 years ago

@ara4n

We've been forced to use Cloudflare (unwillingly) as DDoS mitigation...

Would the single entry here be of assistance? Open Source Cloudflare Alternatives - AlternativeTo.net https://alternativeto.net/software/cloudflare/?license=opensource

ara4n commented 6 years ago

Heads up that the new privacy policies & terms of use for Riot (as hosted at riot.im/app and using the matrix.org homeserver) landed today, spurred on by GDPR; c.f. https://medium.com/@RiotChat/riot-web-0-15-4-ios-0-6-16-and-android-0-8-9-gdpr-on-matrix-org-c48f66afdae3 etc. You can also see the overall GDPR-related privacy picture over at https://matrix.org/blog/2018/05/08/gdpr-compliance-in-matrix/.

This means analytics are now explicitly opt-in on all platforms.

Can calls initiated in end-to-end encrypted chats be MITM'd?

1:1 calls cannot be MITMed. Conference calls could be MITMed in theory on the conferencing server; encrypted group calling is a Hard Problem but on the medium/long term roadmap (or sooner depending on how fast Jitsi get there).

Would the single entry here be of assistance?, Open Source Cloudflare Alternatives - AlternativeTo.net

No, unfortunately. The only way to avoid a DDoS is either to decentralise more aggressively to dilute attacks over more nodes (rather than having overcrowded servers like matrix.org which are attractive targets to attack) - or to hide high-value targets behind a network service provider of some kind who has a big enough pipe to swallow DDoS-level traffic levels (like Cloudflare). ModSecurity is just a firewall, but doesn't help decentralise Matrix or provide us with an ISP who has enough bandwidth & filtering to withstand a serious DDoS.

ara4n commented 6 years ago

Feedback would be very welcome on the new policies - PRs are also welcome over at https://github.com/matrix-org/matrix.org/blob/master/jekyll/_posts/guides/2018-05-24-privacy_notice.md and similar.

Assuming folks agree that this solves the concerns of the OP, I'm hoping this bug can be closed off.

maxidorius commented 5 years ago

It seems like we've come back full circle on this: https://gist.github.com/maxidorius/5736fd09c9194b7a6dc03b6b8d7220d0 @yegortimoshenko Worth reconsidering?

Edit: opened https://gitlab.com/prism-break/prism-break/issues/2176