Delete Riot (Instant Messaging and Video & Voice) #1936
Comments
|
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. |
|
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?". |
|
You mean this line?
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. |
|
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. |
|
Riot the service hides behind Cloudflare So, there's a data sharing interested party! |
|
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. |
|
Maybe Prism Break should explicitly suggest "Riot client" and add a note to say not using the official server? |
|
I'm the project lead for Matrix (and Riot). Quick feedback:
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:
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. |
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: #1953 (comment), #1963) |
@yegortimoshenko @ara4n At the time of this comment:
|
|
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:
|
|
Finally, as a Voice/Video client:
|
|
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. |
|
Riot.im Android app embeds:-
|
|
@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 · To improve the Website and our Services · Within our group. · With our third party suppliers. · If NEW VECTOR LIMITED is sold. 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. |
Your understanding of English is perfect! Bunch of arse holes!!! |
|
@Hillside502 We should keep this debate serious and friendly. |
|
Yeah. Bunch of friendly arse holes! |
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.
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.
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 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? :(
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.
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.
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
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.
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.
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 element-hq/riot-meta#150.
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. |
|
@ara4n: Let's keep this about facts. You seem to make this very feeling-based and not given straight answers to those facts.
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.
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.
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. 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. 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. 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.
We are supporters of the Matrix protocol, which exists solely in the spec, to which we contribute regularly in various forms. 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? |
|
@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!
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.
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.
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.
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.
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). |
Would the single entry here be of assistance? |
|
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.
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).
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. |
|
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. |
|
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 |
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?"
The text was updated successfully, but these errors were encountered: