Hacker News new | past | comments | ask | show | jobs | submit login
Tightening up Privacy in Matrix (matrix.org)
101 points by blendergeek on June 30, 2019 | hide | past | favorite | 39 comments



The addressbook, contact matching and public email are pretty low value from my perspective.

I'd much rather personally validate and match my contacts on my own and I really think this should be the default with huge WARNING to people that want to share their email globally and addressbook with the server etc.

"Users don't care" is largely because developers submarine the issues with "UX flow" reasoning.

Excusing this toxic data exfiltration with "UX" really doesn't hold water.

Edit -

Specifically looking at

https://github.com/vector-im/riot-web/issues/10167

This looks like industry standard bury the issue in unreadable TOS boilerplate.

How about "Hey YOU PROBABLY DON'T NEED to share your email globally unless you expect to meet your long lost cousin via the matrix.org social graph"

This is a place where ADDING friction makes the world better.


(Matrix lead here) The core problem is: empirically most users want an app which works like Signal, WhatsApp, Telegram etc and tells you which other users are contactable. If you’re some random installing a comms app, you want to know if any of your contacts are on it already. It’s nothing to do with whether your long lost cousin is on it.

However, there are then folks hyperfocused on privacy who declare this ‘toxic data exfiltration’ and vociferously object.

We’re trying to get the balance right, and it’s worth noting that the bug you linked is still up in the air. We don’t have the final UX yet, but the idea is to even more explicitly warn the user that their contacts are being uploaded to a identity lookup service if they want to discover people on the network. An alternative/complementary approach is https://github.com/vector-im/riot-web/issues/10093.

(edited due to accidentally hitting submit...)


> you want to know if any of your contacts are on it already.

For me that is an anti-feature and something which I have so far never wanted to do. I hate when apps ask me to add users based on my other contact lists. I want to curate my contact list and only add the people I communicate with over this platform. I do not want to add a bunch of old contact's which I have forgot who they are when moving to a new messenger and I do not want to add people's accounts which they may have only used once years ago.

And this is entirely ignoring the privacy aspect of it which I do not care that much about.


Yup, while many people do like this feature (the billions of people who use WhatsApp and breathe a sigh of relief that they can find their friends & family on the app without having to manually create a whole new contact list), obviously there are others who do not (irrespectively of privacy concerns). The point of the blog post is to show we're trying to cater for both, rather than assuming that everyone falls into the WhatsApp bracket.


If you are trying to cater to people that will use your app like the other services, then why would they just not choose Discord or Telegram in the first place?


The goal is to make it easier for those people to use Matrix too. Otherwise you won't ever expand past a fraction of the tech community and won't overcome the network effect of larger messaging systems.

This is the same reason why (for instance) E2E isn't the default right now -- there were massive usability issues that most normal users would have trouble with (until very recently you could lose all your historical session keys unless you were very careful and backed them up religiously). Speaking anecdotally, several people I've switched to Matrix really wanted to switch away because they lost all of our old chat messages when they logged out of their account.

I hope you agree that people without very strong privacy concerns should be able to use Matrix as well.


>> you want to know if any of your contacts are on it already.

> For me that is an anti-feature and something which I have so far never wanted to do.

This is also true of me. I have no reason to want to know if any of my contacts are available through the messaging app I just downloaded. I downloaded the app because I want to communicate with a particular person or set of people. I already know about them.

These people who would like to know if anyone in their contacts list is available on their new chat app -- why did they download it in the first place?


I really want to cheer for matrix/riot and this blog post moves me in that direction, but then seeing your comment as lead-dev throws me back into reality. The post is all about _tightening_ privacy! So why is the suggestion to solve addressbook feature more elegantly than a a TOS not addressed and instead GP is dismissed as being hyperfocused on privacy.

The reason I cheer about Matrix is exactly because of its P2P nature, which neither of the other privacy focused solutions like Wire/Signal address (though these give better privacy right now). Isn't it exactly the privacy conscious crowd that matrix is pitching to? Those of us who don't trust a signal or wire server because that server code is proprietary? Matrix has been promising better privacy (and e2e encryption) for some time but maybe this isn't actually where matrix is heading? I sure would like to know because there is no point for many of us to continue cheering for what otherwise looks really promising. And it's not like a better technical solution for the address book doesn't exist!!


Matrix aims to be for everyone, not just those with a (hyper)focus on privacy. From my perspective as project lead, the primary goal is more to open up communication so that users have control and that there is an open platform to build on, much like the Web, but for communication - rather than being locked into Facebook/Google/AT&T or whoever. A very desirable side-effect of that is that you get better privacy.

You can see this spelt out in our project manifesto at https://matrix.org/foundation, which says that we believe:

* People should have full control over their own communication.

* People should not be locked into centralised communication silos, but instead be free to pick who they choose to host their communication without limiting who they can reach.

* The ability to converse securely and privately is a basic human right.

* Communication should be available to everyone as a free and open, unencumbered, standard and global network.

You'll note that privacy is in there, but it's not the only thing that guides the project.

> Matrix has been promising better privacy (and e2e encryption) for some time but maybe this isn't actually where matrix is heading?

I assume this is ironic, when commenting on a blogpost talking about how we're improving privacy considerations. Meanwhile, E2E is going great guns, as per https://news.ycombinator.com/item?id=20315096.

> And it's not like a better technical solution for the address book doesn't exist!!

What do you have in mind? The only one I'm aware of is Signal's SGX stuff (https://signal.org/blog/private-contact-discovery/), but there you swap out trust in whoever runs your identity server for trust in Intel, which doesn't necessarily seem like an obvious win.


Theoretically, SGX allows you to assume that your data is in danger only if Intel and your service provider are cooperating in order to access it. SGX has had vulnerabilities before, and there are likely to be more, but it still seems like a sane way to secure your customer’s data.


It doesn't allow you to assume that at all, precisely because of the potential for vulnerabilities.

SGX is just yet another iteration of the 'trusted tamper-proof hardware' concept (which, for reasons that are unclear to me, is apparently magically fine when Intel does it but impossible and bound to be broken when somebody else does it), and it suffers from the exact same issues as every 'trusted hardware' scheme before it.


Like everyone else they want to become the next WhatsApp - with only "the privacy conscious crowd" they don't think they'll get there. They market to your mom.


We really don't want to become the next WhatsApp fwiw. The idea is more to be the new email, or the realtime version of the web. We should be able to support the use cases both for privacy enthusiasts as well as mums, dads, grandparents or whoever.


Do you imagine the new email is going to be anything like the old email, in allowing easy composition of substantial, letter-length messages which can be organized in their own right?

I would love to be able to point non-technical users to an email alternative with sane integrity properties, and I've tried to some extent to push correspondence to Riot, but as it is right now, many of those users seem to suffer from Riot's flat design and not adapting well to the room metaphor. And one trigger-happy composition line posted to infinity scroll chat is pretty far from the experience of even a rudmentary email client.

I'll admit I haven't done a thorough search of the clients but if you're aware of good implementations of a letter metaphor for Matrix I'd be very grateful to learn what I've been missing.


We don't have a good letter metaphor in Matrix yet, but it should be coming fairly soon - we have someone sponsoring development on threading, and so you should get that bit at least in the coming months.

However, the other aspect of mail style semantics is the incredible flexibility which email gives in terms of adding/removing people from threads on a message by message basis. This doesn't map very tidily into a Matrix room currently, and is a bit of an open question right now :)


Nice to know it's in progress!

I hope the Matrix equivalent will be able to fully match and outdo email eventually, but 1-on-1 is already enough to be valuable, and it seems to me the room metaphor should be possible to map fairly gracefully to mailing lists at least.

Thanks for the efforts, as always!

I will read up on more of the current capabilities soon, by the way, to see if we can put an society I'm in on Matrix for internal communications and event announcements.


Not sure I'm in the "hyperfocused on privacy" camp but I guess if people need to be typecast ok...

I use matrix to talk to a few friends and family largely trying to replace gtalk.

The irc or whatsapp usecase isn't really whats up for me.

Sharing the email globally suddenly puts its out there for 7billion other people... you KNOW this is going to get scraped and repurposed, so why do it?

Separate the flows.

1 - "Hey I'm a social butterfly and WANT to add my twitter etc I UNDERSTAND this is blasting my personal data to the world"

2 - "Hey I'd just like to get off gtalk and talk to my close friends and family/creepydarkprivacyspais"

The flows for addressbook alone... like how thought out is any of that? Oh sweet my coworkers from 17 years ago are going to matrix with me...(no thanks?).

You've done a lot of good INNOVATIVE work with matrix so far but this part seems half-baked and frankly like you are phoning it in.


Okay, so i guess it's not really a question of privacy hyperfocus but just different users having very disjoint use cases.

I'm not sure i'd characterise this as phoning it in: the point of the blog post and all the accompanying bugs is to spell out that we're trying to solve for once and for all the problem of how best to enable contact discovery for folks who want it (as opt-in rather than opt-out!)... while also keeping the private-messaging crew happy. Totally agreed that it's been half-baked historically though, which is why we're fixing it now that 1.0 is out the door and we have some bandwidth to address it.

> Separate the flows.

The idea here is absolutely to separate the flows. We don't have a final UI proposal yet (as is clear from the bugs) because we're still working it through. The closest is probably https://github.com/vector-im/riot-web/issues/10091 right now.


My big problem is the auto uploading of all contacts. Maybe providing a ui to select the ones you're most likely to want to contact would be beneficial? Some ppl would want to select All, and some None, but if given the choice between the two, I'd select None. However, with a list I could select the 10 or so important to me rather than actually None.


>most users want an app which works like Signal, WhatsApp, Telegram etc

Most users are already using Signal, WhatsApp, Telegram etc. I don't think it makes sense to sacrifice privacy to make Riot work similarly to them when the whole reason to use Riot is so that you don't have to make such sacrifices.

How does Discord works? It's pretty popular and I don't think they do that. Somehow it doesn't seem to be a problem for them.


But we're not sacrificing privacy. The idea is to give the user a checkbox to check that lets them opt in to making themselves discoverable on the network if they want, and similarly clarifies the wording if they want to see which of their contacts are also on the network.

Discord is just one specific use case of an app, while Matrix is trying to support all possible ones (e.g. WhatsApp style behaviour).


I'm fine with that as long as it's clearly explained. The issue was that the program would nudge the user to upload personal information without making it clear what was happening and that it was unnecessary for Riot to function.

However there's a broader point that it doesn't make sense to imitate the competition when the thing you're copying is precisely the reason why one would want to leave the competition to your solution.


Allowing a user to make themselves discoverable is fine. The real question is why was "vector.im" used and not "matrix.org", or the user simply prompted? And why is that data queryable without any kind of authentication?

Also, the Identity servers are part of a closed cluster where data is replicated. We are aware of vector.im and matrix.org but you did not answer the following question of the research document: is there other servers in that closed cluster? If yes, which?


vector.im is the default for Riot because branding for validation emails is done by the identity server, and Riot users expect to see Riot branded mails, whereas the matrix.org IS sends generic Matrix branded mails. The user will now get prompted explicitly to confirm their IS as part of the GDPR flow.

IS lookups are shortly going to require auth, as per the OP (even if just to check whether the API user has agreed to the server’s T&Cs)

There are no other servers in the cluster.


> (edited due to accidentally hitting submit...)

You can add a value to delay in your HN profile. E.g. delay 10 gives you 10 minutes till your comment appears.

See the FAQ, "In my profile, what is delay?" [1]

[1] https://news.ycombinator.com/newsfaq.html


I'm using Signal and I never want or wanted

"like Signal, WhatsApp, Telegram etc and tells you which other users are contactable."


okay, which is why we're making it very clearly opt-in, so that folks who don't want this don't end up accidentally using it.


[flagged]


I don't think your comment helps. An alternative to Slack exists: Zulip and Mattermost and both aren't annoying to use. You can use Signal instead of WhatsApp or if you don't trust that you can also use Ricochet. Being passionate about something doesn't make them a Nazi.


Dunno about Zulip, but IMO Mattermost is pretty clunky and uncomfortable.


Mattermost CEO here, thanks for your feedback, is there anything specific you feel we could improve?

We recently raised $50 million in funding from YC to accelerate the project.


The feature I miss most is expiring messages. Yes, it totally depends on correct end-user client implementations and honest participants, but it is crucial for many scenarios where a client is compromised after the fact (or, lets say, an over-ambitious border control...). https://github.com/vector-im/riot-web/issues/2497


Hopefully this will be coming relatively soon once https://github.com/matrix-org/matrix-doc/pull/1763 is implemented. It’s mainly been waiting for someone interested in sponsoring the feature (which hasn’t happened yet).


I host my own Synapse instance and for the most part it's very reliable. I don't bridge to anything. So far it's been like pulling teeth to get my friends to sign up but once they do it's been super reliable. I'm traveling through Japan right now and the server hosted in NYC has been fine.

There are a few problems. First the UI for approving new client connections in encrypted chat rooms is complete crap. It needs to be clear and concise what is happening and currently it starts a super complicated verification process which is frankly confusing.

It simply needs to say "$user has signed in on a new device $deviceName. Is it okay to send messages to this device? Yes/No"

That's it.

Also there needs to be a better way to integrate third party plugins. One thing I miss from Facebook messenger is being able to paste a Spotify link and have the song come up as an embed.

Finally the bot API could use work. I spent some time professionally maintaining a Slack bot for a major American cable company and currently it's much harder to make a Matrix bot and documentation is lacking.


> There are a few problems. First the UI for approving new client connections in encrypted chat rooms is complete crap. It needs to be clear and concise what is happening and currently it starts a super complicated verification process which is frankly confusing.

Device cross-signing has nearly landed and will solve this problem by creating a pseudo-WoT between users meaning that you need to do verifications very infrequently (ideally, only once when you first start talking to the user).

> It simply needs to say "$user has signed in on a new device $deviceName. Is it okay to send messages to this device? Yes/No"

Doing it this way would open the door to a malicious homesever (or a user's account being hacked into) being able to eavesdrop on you. Device names aren't cryptographically relevant. Device cross-signing (where a user's devices sign each other) solves the problem in a much safer way.

> Finally the bot API could use work. I spent some time professionally maintaining a Slack bot for a major American cable company and currently it's much harder to make a Matrix bot and documentation is lacking.

This boils down to the fact that bots are basically just normal Matrix clients (with a few extra features if you've set them up as an application service). You might be better served by using a library (like matrix-nio or the Matrix SDKs).


I'll take the chance to plug miniVector again. It doesn't solve the problems discussed in this thread, but it's a stripped-down Riot fork that requires fewer permissions than the full program: https://github.com/LiMium/mini-vector-android

I have no affiliation with the project.


Also RiotX (full rewrite of Riot Android) is hopefully landing soon, so that should improve the mobile experience a lot for people who want a full client.


Interesting that you tighten up privacy by adding more tracking to your main website with a cooking spanning sub-domains as well: https://github.com/matrix-org/matrix.org/commit/48545495afe1... and JS code from twitter directly: https://github.com/matrix-org/matrix.org/commit/30ece47f8930...


Seems like a well thought out response


(One of the author of the research doc that triggered this blog entry here)

It's good to finally see a reply, and it's good to see you are addressing some of the issues we have highlighted. It's a shame it took a whole research document posted on Hacker News and other websites to start getting your attention. I am personally surprised about this blog entry (and reply to some extend), given that the research doc was labeled as "FUD" by the lead dev.

Now that we have it, and that you answered in a blog post, there is one question we asked several times and that you still did not answer, even in our GDPR data request: Given that the research document clearly highlights that users are totally unaware of how their personal data was collected, how its going to be used, and that they did not given consent (e.g. storing their email addresses for a lookup query mechanism) under EU GDPR: 1. Under which lawful basis do you collect, process and allow others to use such data? 2. Are you going to keep storing/using all the data you have collected using all the methods highlighted in the research doc, or will you purge all that was collected without clear knowledge and consent of the users?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: