Hacker News Reader

Comment by sneak | Hacker News Reader

I am on board with this stack 100% and have been recommending Mattermost myself. Imagine my disappointment when I found out that Mattermost, even the self-hosted one, is spyware.

They call it "Diagnostics" to hide its true purpose, but really it's phone-home. Silently and with no notification, on f/oss self-hosted software; it's really a letdown.

To disable it, you must use the following entirely undocumented environment variables:

    MM_LOGSETTINGS_ENABLEDIAGNOSTICS=false
    MM_SERVICESETTINGS_ENABLESECURITYFIXALERT=false

I go the further step of using a small Dockerfile that contains the following to patch the binary itself:

    FROM mattermost/mattermost-team-edition:latest
    RUN sed -i 's#api.segment.io#xx.example.com#gI' /mattermost/bin/mattermost
    RUN sed -i 's#securityupdatecheck.mattermost.com#xxxxxxxxxxxxxxxxxxxxxx.example.com#gI' /mattermost/bin/mattermost

View on HN

You might want to consider Matrix, where admittedly we do have phone-home stats, but you have to explicitly opt in to them during installation if you want to participate. (https://youtu.be/dDddKmdLEdg?t=605 in the video in the original post here)

Yeah, opt-in is fine. It’s when it happens silently and automatically that software becomes unethical.

I am always surprised to find that kind of spying in self-hosted apps. People self-host specifically to keep their data private!

I'd like to see this idea implemented at compile time. Don't opt-in and the code that does it doesn't even exist in the binary. That way there's no worry a logical error in the code could accidentally ignore the choice.

If you use the Matrix identity server, which is required to have federation, the 3rd party identity server operated by the Matrix organization retains a list of your usernames. They don't tell you up front about this, either, and I think silently leaking a username list is pretty bad. You have to really pay attention during setup to realize that the federation technology relies on a bastion operated by matrix.org.

The identity server is optional and you can use your own, but you will lose the federation that Matrix is so proud of, and the instructions to set up the reference home server don't make it clear that this is necessary in order to avoid a leak of your users' identities.

https://vector.im/identity-server-privacy-notice

That seems like a huge oversight.

The clients also attempt to connect to this hostname.

Fwiw, this is pretty much entirely untrue.

> Matrix identity server, which is required to have federation,

The identity server is not required to have federation to work. All it does is let you optionally discover users on Matrix by their email address or phone number.

> 3rd party identity server operated by the Matrix organization retains a list of your usernames.

Not sure what this means, but the identity service does not retain a "list of your usernames". All it does is keep track of email->matrix ID mappings for users who have published them. When you look up an email address (or phone number), a hashed representation is sent to the service, and even then, they're not retained.

> They don't tell you up front about this

We do; to use the identity service you have to click through a very explicit GDPR terms of use which explains precisely how it works. You only get prompted with this when you actually use the identity service though (i.e. when inviting someone by email address) which might be why you've never seen it, however.

> You have to really pay attention during setup to realize that the federation technology relies on a bastion operated by matrix.org.

Again, Matrix federation does not depend on identity servers (and I kinda wish we'd never even implemented the feature, given how confused and upset people get about them).

https://matrix.org/blog/2019/09/27/privacy-improvements-in-s... goes into this all in much more detail.

I'm sorry if I was unclear, but

> All it does is keep track of email->matrix ID mappings for users who have published them

This is what I mean by "it leaks the userlist." Matrix (the organization) stores the email addresses of my users, along with some mapping that could allow Matrix the organization to correlate email addresses with my server. To me, as a server operator, this is a deal-breaker, even if it was just email addresses with no mapping. I see this as a privacy violation against my users who trust me to hold their information privately and securely. My understanding is that you cannot join another Matrix homeserver server with an identity established on a homeserver disconnected from the vector.im identity server, which effectively forces the homeserver operator to use the vector.im centralized identity server if you want, as an end user, to actually take advantage of federation. I do not know how a user is supposed to take their login from one homeserver to log into another one if the first homeserver is not connected to vector.im.

Please correct me if the above is wrong.

Additionally, when I set up Synapse I was not presented with any kind of GDPR info, and it wouldn't make sense that I would be, because the GPDR is for end users, not site operators. Maybe this is presented to new users who connect to the public reference Synapse instance using Riot.im or something, but I'm not talking about this issue from the perspective of an end user, I'm talking about it from the perspective of a homeserver operator. I got about halfway through the homeserver setup before I realized that vector.im was necessary for identity lookup and I realized it only by carefully following the docs. This was long before the 9/27/2019 blog post was published, so I guess maybe this has been addressed somewhat. I have been following Matrix now for the better part of a decade.

If federation is possible without identity mapping done on a central server, then I too wish that identity mapping was never implemented.

> Please correct me if the above is wrong.

Yup, this is still wrong, sorry.

> My understanding is that you cannot join another Matrix homeserver server with an identity established on a homeserver disconnected from the vector.im identity server

This is not true. The identity server is an optional feature, which users can use if they want to try to discover a user's matrix ID based on their email address. Matrix itself operates using matrix IDs to federate and establish conversations.

A good analogy is using LDAP as an address book in an email client. LDAP addressbook lookups are very clearly optional, not relevant to all people, and don't stop email itself working.

> Additionally, when I set up Synapse I was not presented with any kind of GDPR info, and it wouldn't make sense that I would be, because the GPDR is for end users, not site operators.

Because the identity server is an optional feature for users (just like a user, not a sysadmin, would configure LDAP lookups in Thunderbird), the GDPR terms of use are shown to users if they try to use an identity server to make sure they understand what they're doing.

Well then I'm glad that the blog post linked above was written, because obviously this situation was confusing when I set up Synapse a couple years back. I might not be a genius but I'm not stupid, either, and I'm obsessed with chat systems (I trialed every available self-hostable chat server at the time), so I guarantee if this confused me, it confused plenty of perfectly intelligent individuals.

I hope the team has clarified this in the documentation.

Uh, this is quite verbose :-/

"The following information [a boolean, not the event details] is sent when the specified event occurs: - Sign-in Error - Account creation - Login succeeded - reset password - updated password - Joined a channel - Created, edited or deleted a message - searched for a term" … and the list goes on: https://docs.mattermost.com/administration/telemetry.html

Thanks for letting us know…

I have qualms on Mattermost too, particularly their licensing. Does it even qualify as open source?

I strongly would recommend Zulip - https://zulipchat.com/

```

You are licensed to use compiled versions of the Mattermost platform produced by Mattermost, Inc. under an MIT LICENSE

- See MIT-COMPILED-LICENSE.md included in compiled versions for details

You may be licensed to use source code to create compiled versions not produced by Mattermost, Inc. in one of two ways:

1. Under the Free Software Foundation’s GNU AGPL v.3.0, subject to the exceptions outlined in this policy; or 2. Under a commercial license available from Mattermost, Inc. by contacting commercial@mattermost.com

You are licensed to use the source code in Admin Tools and Configuration Files (templates/, config/default.json, model/, plugin/ and all subdirectories thereof) under the Apache License v2.0.

We promise that we will not enforce the copyleft provisions in AGPL v3.0 against you if your application (a) does not link to the Mattermost Platform directly, but exclusively uses the Mattermost Admin Tools and Configuration Files, and (b) you have not modified, added to or adapted the source code of Mattermost in a way that results in the creation of a “modified version” or “work based on” Mattermost as these terms are defined in the AGPL v3.0 license.

```

[1] https://github.com/mattermost/mattermost-server/blob/master/...

It is absolutely open source. AGPL for source, MIT for the binaries. Both of those are free software.

Their enterprise version has a different license; the source for that one is not available and the binaries are released under a much more restrictive license, but that's nothing to do with the normal one.

Disclosure: I run Zulip, a Mattermost competitor that has intentionally avoided taking venture funding in part because we don't want to be forced by investors to be Open Core.

Venture-funded Open Core software like Mattermost is an awkward place for the terminology. The free version is distributed under an open source license, as so there is a thing that is "open source", but the clear intent of Open Core licensing policies is primarily to achieve the goals of: (1) Being able to market the software as open source. (2) Maximizing the portion of users who buy the paid/proprietary version.

While in theory open core can be run responsibly, the incentive structure is to intentionally not include features important for typical use cases in the "open source" version of the software that any similar community-driven open source project would have considered an essential, early feature.

FOSS means different things to different people, but my personal perspective is that venture-funded open core software like Mattermost feels like FOSS to me about as much as proprietary software with a free plan like Slack or GitHub does.

For Mattermost in particular, this thread is a good reference: https://news.ycombinator.com/item?id=21820583. They made changes to the specific items mentioned there in response to the community pressure, but that doesn't change their fundamental business strategy.

They do seem to document what they send:

https://docs.mattermost.com/administration/telemetry.html

I think this telemetry should be opt-in for self-hosted, but the data they send doesn't seem to push it to the level of spyware (i.e., no message contents or PII as far as I can tell). It's still much more private than Slack.

I'm glad folks like you are looking out for things like this and saying "not ok" (and posting fixes)

Reply on news.ycombinator.com