maxidorius

In their Privacy Policy [1], Section 8:

Office.EU is a service offered and operated by EUfforic Europe BV, registered with the Dutch chamber of commerce under registration number 98746243 and having its address at Dr. Kuyperstraat 10-A at (2514 BB) The Hague, the Netherlands.

[1]: Link to PDF, no HTML version: https://hel1.your-objectstorage.com/officeeuaa001/officeeu-p...

I was merely making the distinction for those non-english natives people like me who tilted their head not getting it at first :D

"fuite" is french which means to escape, to flee. Flight is only in context of planes or flying transportation. As for the sense of it, you're right, it's either do something, go away, or do nothing.

I recently bought a Tuxedo InfinityBook Pro 15 [1] which has 2 USB-C ports with one being USB 4 (equivalent to Thunderbolt4), 3 USB-A, 1 Ethernet, 1 HDMI, 1 audio jack and 1 SD card reader.

I'm very much happy with the laptop and its build quality. But most of all, I love the flexibility to not be stuck with just 2 USB-C and needing dongles/docks. I can have them if I want to, but I don't need to rely on them.

I think you don't need to compromise: laptops do exist that can have everything.

[1] https://www.tuxedocomputers.com/en/TUXEDO-InfinityBook-Pro-1... - Laptop is fully configurable, you can choose to have Windows as the primary OS and can choose between AMD or Intel CPU (my link is for the AMD one)

No rudeness taken, don't worry! TIL, I didn't know! Thanks!

And then the customers will open support requests for code generated by an AI that misuse that very SDK. It doesn't look like OP's issue is with the code per say, only with the lack of skills of its customers, regardless of the code they write...

And yet Thib, mentioned in the article, does say in an another comment that they are employed by Element but working for The Foundation, making it quite hard to know the difference between the two: https://news.ycombinator.com/item?id=39369239

If you dig a bit, I'm sure you'll find this is true for quite a bit of the people either in Element or in The Foundation.

I can only be happy to see that the research we made and the documents [1] we produced some months back have lead to changes that improve privacy in Matrix. It is a huge win for our nonprofit Libre Monde [2].

We are especially happy to see you will now be lawfully processing GDPR Access requests by keeping the scope tight, and no longer include the full account history, confirming our statements in the Part 2 of the research that it was indeed unlawful to do so, and will inform the ICO accordingly.

Hopefully the remaining points in terms of privacy will be addressed!

[1] https://github.com/libremonde-org/paper-research-privacy-mat... [2] https://www.libremonde.org/

"It's so commonly used exactly because it's a very simple one-size-fits-all approach".

ICO says this [1] about choosing a lawful basis: "You must not adopt a one-size-fits-all approach. No one basis should be seen as always better, safer or more important than the others, and there is no hierarchy in the order of the list in the GDPR."

I think I'll stay clear of your lawyer advise.

[1] https://ico.org.uk/for-organisations/guide-to-data-protectio...

Thank you for your input. I am not worried about any traction we are getting. People do care even if you think nobody does. Per example: https://github.com/privacytoolsIO/privacytools.io/pull/1047

I'll let you do your own homework and research what else it triggered.

Feel free to post the same with your real account instead of a puppet one, then I'll be happy to reply to all your points.

I'm serious enough to put my name out there and own up to what I write - Are you also? Or are you ashamed?

I guess then New Vector is actually our best sponsor: they always give us those very important things to write about, like a personal data breach that has a federation-wide scope.

They certainly are generous! I'll ask them to renew our contract!

Because our document could be collected and processed illegally under GDPR. That the operator makes the conscious choice to have their name listed on their own organisation's website they are from is their own choice. Their organisation is processing their data, not us. They have the right to object to that, and the right to erasure of their personal data if having their name is listed.

They were not given the choice to be part of our publication and therefore, we have no lawful basis to use their name since 1) they did not give us consent and 2) they would not have understood (we didn't say) nor expect (it was a private chat) that we will use their personal data - making Legitimate Interest not possible.

The only way we could be GDPR compliant for being Accountable and not break a lawful basis was to not use their name but the name of their role under their obligations towards us, and linking to the blog post instead (Accountability of what we claim).

Thank you for bringing our "failing out", which has an impact on the Personal Data leak itself, so I really hope people will look into it.

As for "with the general matrix community", I believe the amount of projects and people we talk to, and still are in rooms with (which are public) will be the proof of that.

I hope you'll enjoy the read, since we believe this is not the first data leak of this kind and that your personal data might very well have been leaked if you're a Matrix user.

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...

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?

(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?

We have answered to your claims of "being alarmist", "disproportionate FUD" and that we did not forget to disclose we are working on a fork which is not hostile.

https://gist.github.com/maxidorius/5736fd09c9194b7a6dc03b6b8...

The document has been updated from feedback received all over the community, including new identified leaks and possible data correlations.

We encourage anyone who already read the initial version to check out the revisions of it for new content or re-visit the document.

Or what about joining the room given on the research paper and actually participating in the discussion? We would love to have some proper interaction where we can exchange network output and screen recordings that simply show first hand what we are talking about...

Replying to a blog to a living research document intended to be used by another project/protocol feels silly. Whatever you write certainly is not all up to date anymore with the corrections we made thanks to the Matrix community that joined the room, and the Grid community that kept on discussion the doc.

Where is Matrix.org tho? This could also be a good occasion for the three new guardians to join the community.

After talking with the other contributors of the doc, we decided on not going into further details.

We acknowledge the need for reproducible investigation, but the document did not explain in a scientific manner how we reached such outcomes. We had to draw a line to keep the document on point with our message. Adding hashes wouldn't really make a significant difference.

We'll make sure to keep this in mind if we do write a follow-up with details on reproducible checks thought. Thank you for your insight!

I believe you are missing the point of the document. It is not so much where the leaks go, but that they happen when there is no consent or knowledge of the transfer.

Example: for Scalar, the issue says that Riot talks "too much" to it. The research is not about how many times Riot talks to it. It is that Riot talks to it before the user explicitly requested the service, and in a way that the user does not expect.

As we wrote in the paper: "Privacy protection is a mindset". It is not about fixing individual issues and then have new ones pop up because the underlying problem is not fixed. It is about having a process in place so it cannot happen again.

Totally fair point, thank you for bringing it up. Given the numerous build types (source, pip, debian packages, etc), what would you suggest to do in this case? Give the git commit hash maybe?

To clarify: the paper does not claim a list with email addresses is made public or anything of the sort. Only that they can be queried without restriction or authentication.

Once again, it's not about brute listing things. It's about knowing a 3PID from another source, like a dump of email/phone number on the darkweb which can then be used to query for a mapped Matrix ID. Or simply an email given for another purpose to the same server.

It is all fun and games until you start correlating data sets, like claudius points out correctly with other public lists.

Thank you for your feedback! It is great to know if it was understandable or not, especially given its length.

The document does not try to compare other chat applications with Riot. It does not try to say what is good or bad. We simply take how Riot is presented and understood by non-technical people, and see if its behaviour matches what they understood it does in terms of privacy. There was a mismatch, and people asked to know what was shared without their consent or understanding: we wrote it down.

We did the next best thing after improving sydent: we wrote our own implementation of an Identity server: mxisd. We linked it several times in the doc. You should give it a look. That's one example of how you can be better at privacy.

If the content of the document does not surprise you, and you were fully aware of all that was going on, it is also a win! Sadly, this is not our experience with the many users we came in contact with. They did not know, but wanted to know in details.

We do not mention End-to-End encryption would be cool indeed because it would not change what is happening here. In Matrix, the encryption would only cover the content of the event, but not its metadata (sender, source, timestamp, etc.). The document is clear that the vast majority of the leaks are around metadata (who sent what, who did what, when, from where) and not data itself (the message itself).

This document only scratches the surface of privacy in Matrix, by being specific to Matrix.org and its choice of recommended software. It gets worse as we start investigating the protocol itself. It is your choice to see this as FUD. It does not make it less true, and while you might not care, some do. We published the document for those who care and do not have the means, time or capacity to do such a research themselves.

I would appreciate if we could stick to the points brought up in the notes instead of trying to discredit the work of several people (writers, reviewers, sanity checkers) who equally contributed to it.

The document is clear that it puts the default behaviour and explanation next to what users understand out of it and expect, just like what the privacy policy of Matrix.org is based of in section 2.1.1. We have asked several technical and non-technical people alike, from our family members to our friends to people in our communities. And the feedback is unanimous: They did not understand nor expect what we described.

In terms of actually of handling the issues, the scalar issue is one we brought up with Ben months ago in private as per your disclosure policy, and yet nothing was done. This is just an example of a long list of issues brought up over the years.

The point of the document is not to find justification for what is happening, but to inform users that it is happening. An attacker got access to your systems which contained logs from which such data can be gathered. It is important that users who self-host and do not expect such data to get out realize that it does so they can take appropriate action.

The document might feel alarmist, certainly. It does not feel alarmist because we wrote it. It feels alarmist because the behaviour described is happening and nothing is done about it. It is not discussed anywhere. Attempts to do so are shut down. But it does not change anything: leaks are happening right now on thousands of servers and for millions of users (up to 9M, as per Matrix.org figure) and every person who we showed this to before publishing had the same reaction: "I never expected such data to go out like this. I am worried".

As for Grid, we made a specific effort out of respect for the Matrix.org people not to mention it or steer towards it. Yes we have forked Matrix. No it is not hostile, despite your continuous claims to label it as such.

We think it is time to stop talking about all the good reasons why, in the 5 years it took to get Matrix out of beta, there was just no time to deal with such leaks. We think it is time to start talking about how we can make sure it stops from happening and which decisions lead to it happening for so long unnoticed.

You wrote the software. Start respecting your users privacy.

One of the swift steps should be to address https://github.com/matrix-org/matrix-doc/issues/1194 and https://github.com/matrix-org/matrix-doc/pull/1915 and https://github.com/matrix-org/synapse/issues/4540 properly, so others servers cannot be impacted in any way.

... or is it? https://github.com/matrix-org/matrix-doc/issues/1194 and https://github.com/matrix-org/matrix-doc/pull/1915 and https://github.com/matrix-org/synapse/issues/4540 would tell a different story: Potentially deleting data on remote server just because being matrix.org (or anyone with an access)

It also has very questionable choices towards respect of Privacy: https://github.com/matrix-org/synapse/issues/4540