This text analyzes the level of privacy/security/anonymity provided by the numerous servers that comprise the XMPP network.
One day during 2023 I was bored and decided to rate a couple of XMPP servers off of their privacy policies, and other information I could glean from their servers, in order to determine how private/secure they were. Then I decided, why not just rate the whole network? That is what I have attempted to do with this article. I believe that it covers most servers on the XMPP network, although it does not cover the entire network (and I will never claim that it does). I completed the research for this article a year ago, and I've been sitting on my findings ever since.
To preface this entire article: I have conducted all of the activities mentioned in this article through Tor. I route my internet traffic through Tor exclusively.
My methodology for collecting servers to review was crudely simple. I pulled all of the servers listed here:
https://jabberworld.info/serversThen I subtracted the lists from each other to find the unique servers, added the unique servers to the list I had from jabbersworld and scraped it. Initially, I scraped entire websites, but this proved to be unnecessary, so I then only scraped deep enough to get privacy policies as to minimize the junk I collected. Out of the approximate 2400 servers that were targeted, only around 1720 were scraped. The rest rejected me or timed out. Once the scrape was finished, I scanned all of the HTML, and php for keywords relating to privacy policies in several languages such as English, Spanish, Portuguese, French, German, Russian, Italian, Chinese, Japanese, Arabic, Farsi, etc, in order to determine which servers I would review. I discovered 380 servers to potentially review. My keyword searches were quite broad, so I got a lot of false positives. The bulk of the 380 were miscellaneous web pages, that had no relevance to this project. If I had done a more refined scan I would have risked accidentally filtering out websites containing privacy policies, and this was not acceptable to me, hence the broader searches.
I did take the care of checking some of the websites that were excluded by my keyword search, but from what I saw — granted there were over 1000 websites and I proportionally checked very few — they did not have any privacy policies, and tended to be miscellaneous.
I manually analyzed servers to determine ratings for them, because automating the process of rating servers could produce false ratings. Out of the 380 keyword-selected servers I analyzed, I could only rate 89. In my analysis, I came upon around 24 private (members only) servers, which I chose not to rate because of their private statuses. Those 24 weren't counted toward the total of 89. I later found two more servers, making the total 91.
In the process of writing this article I had to review all of my work, since all of the work was done a year ago, and a lot can change in a year.
After reviewing my final list of servers, I found that only 60 remained online. 31 of those 91 servers had vanished.
At this time there are about 2049 XMPP servers. Overall, the number of XMPP servers has decreased since 2023.
I also discovered another list of servers I hadn't yet seen:
https://list.jabber.atI found 19 more servers from it.
Out of pure curiosity, I decided I would recreate my combined list of servers from jabberworld.info and xmpp.love, and randomly select 200 online servers that I did not recognize as having previously viewed — because that's all I had patience for, and analyze them, in order to see if there was a significant change in the state of the XMPP network. I appended the servers I found to the end of the article.
My process for coming up with a rating for a server was as follows.
Servers' ratings were denoted with tags. Here are the tags and their definitions:
L stands for Logs. This represents the duration of time that logs are retained for. Server logs should generally consist of metadata like IP addresses, connection timestamps, bytes sent to/received from the server, message senders and recipients, and so forth. XMPP servers do not store actual message contents, unless they support message archiving, which is called MAM (message archive management), and the client has MAM enabled. If you have MAM disabled, message contents won't be stored. If you use OMEMO, then they will be stored encrypted.
B stands for Backups. This represents the duration of time that "data" is backed up for. The types of data backed up can vary from server to server. Sometimes it is just the essentials like account data e.g usernames, passwords, rosters, avatars. But sometimes server logs are stored in backups.
Both of these tags will be followed by a number ranging from 1-5
This color coding may seem dramatic. In my opinion, you shouldn't let it concern you if a server keeps logs for 15 days as opposed to 14, however, in reality, this will not happen. The servers listed in this article will store logs in weekly brackets.
R stands for registration. This represents the process of registration.
Server logs are retained for one week; Registration conducted via email; Backups retained for 3 weeks
Server logs retained indefinitely; Supports in-band registration
These tags are tacked on to the end of other tags or a whole rating:
p = Potential, meaning there's a potential for something to exist. For example,
onion = Server runs a hidden service.
trep = Server has a transparency report (a chart of law enforcement requests for information from the server)
? = A question mark next to a number means that a value has been assumed. If there is a question mark in the place of a number, the value is unknown.
If I put a dash (-) between two numbers it means the time may range across those two values.
L?,
Cannot determine how long logs are retained for; Must register via website with javascript dependency; Runs hidden service; Has transparency report
Privacy Policy seems to say logs are retained for 3 weeks; Must register via website with reCAPTCHA; Backups retained for four weeks; Runs hidden service
Logs retained for 1-3 weeks; Potential for data to be backed up indefinitely. I think you get the rest by now.
If this all seems too convoluted for you, and you just want to find a "good" XMPP server quickly, that's fine. I created a table charting most of the servers in this article. The table is more utilitarian, so I excluded some XMPP servers nobody would realistically use from it, namely, servers that are most likely not intended to be used by the public, but have registration opened to the public anyway, probably due to oversight.
It is a given that every XMPP server will store your JID, password, avatar, roster (contact list), vCard, and presence information. Most will also record the date of your account's creation and the last time you logged in to your account, in order to detect inactive accounts. If a server says they will purge inactive accounts, that is how. I will try to note the storage of account creation and login times, or lack thereof, whenever possible.
Most servers will also cache messages sent to you that you were not online to receive. These will be wiped after you log in to receive them. Even if a server does not specify that they will wipe cached messages, they almost certainly will, and their failure to specify this is simply a mistake.
This article will be subject to updates over the passage of time. Servers will be added to it here. Additional segments will be added in the future to expand upon some of the various subjects of this article.
Rating:
They state that they do not keep logs on their server. Considering this, they probably don't make backups.
Server: ejabberd 22.5.0
SASL mechanism(s): PLAIN, SCRAM-SHA-1-PLUS, SCRAM-SHA-1, X-OAUTH2
Gajim chose SCRAM-SHA-1
Website connects to: google.com, googletagmanager.com, gstatic.com, fonts.gstatic.com
Quoting from their privacy policy:
Our jabber servers are completely free and maintained with strict privacy for our users. We protect the privacy of our conversations by controlling our own secure means of communications.
Our servers our secured in Germany
Law enforcement requests will be posted to a tranparency page.
We do not keep logs of any kind.
Archived messaged are auto-deleted after 7 days
Rules:
- The service is used for illegal purposes
- The server operation is disrupted, e.g. by excessive traffic or to many connection attempts per second etc, disturbed
If someone violates these rules, their account and/or IP address will be blocked. In the case of DoS attacks and the like. the attacker's ISP is informed.
The following rules also apply:
- We reserve the right to delete accounts that have not been used for a period of 12 months.
- We reserve the right to delete accounts that are registered but never used (i.e. never correctly logged in) after 7 days at the earliest.
- User names that indicate more rights than available (e.g. admin99) or violate applicable rights will be contacted and, if there is no satisfactory answer, deleted after 24 hours at the latest
>We do not keep logs of any kind
>Archived messaged are auto-deleted after 7 days
With these lines their policy contradicts itself. Archived messages count as logs, no? Well, users opt-in to message archiving, so this can be reasoned away. But, some IP addresses must be logged somewhere for some duration of time in order for them to be blocked. We can assume that they won't log non-offending IPs indefinitely, unlike offending IPs. Additionally, an XMPP server must retain rosters for its users, that counts as logged information. This "no logs" business that virtually every online service speaks of nowadays can be very misleading. "Logs" is a vague term that can mean many different things. In the case of 0day, they assumedly keep server logs relating to network activity and messages, for as little time as possible. The software running on their server(s) must be configured to not store any network logs. In spite of that configuration, some information about network activity will exist on the server during the time that activity is taking place. If the server was to be seized by law enforcement, for example, while it was running, information about whatever was happening on the server in the immediate time that it was seized would be available. Bear in mind that this is the case for every online service that does not keep logs. The software these "no logs" services run does contain what are effectively the "logs" any average person will be concerned about, like IP addresses, in the present moment.
Many of the XMPP servers I will cover make claims similar to 0day. For the sake of brevity, I have only commented on it at length once; here.
Rating:
IPs are not logged. Server logs stored for 7 days.
Server logs = JID; client-to-service encryption; Message content (if message is identified as spam); Connection timestamps; http_upload filename.
The admin(s) reserve the right to put the server in debug mode for a short time periodically. In this event, server logs will consist of:
All the previously listed types of information; Message sender, recipient, message type; IP address; Internal information about data processing
In-band registration disabled. Registration is through their site.
Passwords hashed with SCRAM-SHA-1.
Has a hidden service and transparency report.
Server: ejabberd git
SASL mechanism(s): PLAIN, SCRAM-SHA-1-PLUS, SCRAM-SHA-1, X-OAUTH2
Gajim chose SCRAM-SHA-1
Excerpts from their policy:
Your passwords are only stored in hashed form on the server.
With which algorithm?
Your IP addresses are not logged (neither by the XMPP nor by the web server), but would be easy to find out during an open connection. To get around this, you can also connect via our .onion address.
Description and scope of data processing
Every time our website is accessed, our system automatically records data and information from the computer system of the accessing computer.
The following data is collected:
- Information about the browser type and version used
- The user's operating system
- Date and time of access
- Websites from which the user's system accesses our website
The data is also stored in the log files of our system. This data is not stored together with other personal data of the user.
The data will be deleted as soon as it is no longer required to achieve the purpose for which it was collected. In the case of data collection to provide the website, this is the case when the respective session has ended. If the data is stored in log files, this is the case after seven days at the latest. Storage beyond this is possible. In this case, the users' IP addresses are deleted or altered so that it is no longer possible to assign the calling client.
Data processing
The following information is required in order to be able to offer you the service (Art. 6.1b) and is stored for as long as your account exists:
- Login information is stored encrypted and never passed on to third parties.
- Your Jabber ID (JID) or XMPP address is only passed on to users or services with whom you interact.
- Your contact list (roster, bookmarked chat rooms) will not be shared with third parties unless you allow it (XEP-0321: Remote Roster Management)
- Information about your availability (presence) is kept in RAM and automatically shared with your contacts or chat rooms you join and possibly other services (transports).
- The date and time of your last login is stored with your account. This allows us to identify inactive accounts.
Content you send or that is sent to you is stored on your behalf so that you can access it from all your devices:
- Messages sent to you while you are offline are stored until you connect or your account is deleted.
- Message archives of sent and received messages are stored for 7 days if you have enabled XEP-0313: Message Archive Management.
- Uploaded files are stored for 30 days (some clients store messages but not files, so they are kept for a longer period).
- Chat room history is stored according to the configuration of the respective chat room and can be published by other participants.
- Your public profile information (vCard) and avatar image are stored next to the account and can be accessed by users who know your Jabber ID.
Server logs
To ensure the proper operation of the service, including network and information security, the server logs are stored for 7 days (Recital 49 of the EU GDPR). As a rule, only error messages are logged and no other data. However, we reserve the right to set the log level to information or debug for analysis purposes. In this case, the log file contains the following information:
Information
- Metadata (JID, C2S encryption)
- Message content, if the message was automatically recognized as spam. These messages are most likely to be manually reviewed afterwards.
- Connection information (time stamp)
- http_upload Slot Name of the upload
Debug
- All information listed under information
- Metadata (sender, recipient, message type)
- Connection information (time stamp, IP address)
- Internal information about data processing
The server is located at comtrance Düsseldorf, Germany and runs on hardware from caix.
They have a transparency report. Here it is:
Transparency report
5222.de team
29 Oct 23 00:00 CET
2022: 7 requests, 7 answered
2021: 2 requests, 2 answered
2020: 1 request, 1 unanswered
2019: 1 request, 1 answered
Rating:
Server logs deleted after 24 hours.
I registered successfully in the past, but now in-band registration denies me access. There appears to be no other method of registration. Maybe they block Tor now.
Excerpts from their privacy policy:
Every time you access our websites, you transmit data. This data includes, among other things:
- Information about the web browser used
- Information about the operating system used
- Your IP address
- Date and time of access
- Possibly the address of the website that led you to our site (referrer)
This data is stored in the server log. An administrator can view these logs and thus trace the accesses.
Server logs are deleted after 24 hours.
When you visit this website, no cookies are generally set. Since you cannot log in to the site, we also do not use session cookies.
However, there is an admin area that absolutely requires a cookie. This is therefore only set by accessing the admin area.
Rating:
IP addresses are only saved in the event of incorrect login attempts. They will be removed after 14 days.
Server: Prosody 0.12.4
SASL mechanism(s): SCRAM-SHA-1, PLAIN
Gajim chose SCRAM-SHA-1
Excerpts from their privacy policy:
The operator of the XMPP server reserves the right to keep all data stored on the server in the form of backups on external systems for up to six months.
Starting off strong.
Provision of the website and creation of log files
Every time our website is accessed, our system automatically collects data and information from the computer system of the accessing computer.
The following data is collected:
- Information about the browser type and version used
- The user's operating system
- The user's IP address
- Date and time of access
- Websites from which the user's system accesses our website
The data is stored in the log files of our system for 7 days. This data is not stored together with other personal data of the user.
[...]
Duration of storage
The data will be deleted as soon as it is no longer required to achieve the purpose for which it was collected. If the data is collected to provide the website, this is the case when the respective session has ended.
If the data is stored in log files, this is the case after 7 days at the latest. Storage beyond this is possible. In this case, the users' IP addresses are deleted or altered so that it is no longer possible to assign the calling client.
Log files including saved IP addresses are deleted after 7 days at the latest. File uploads will also be deleted after 7 days at the latest.
Take note of this.
[...]
XMPP
What data is stored?
We strive to offer a “data-efficient” server as a WhatsApp alternative. However, there are a few things to keep in mind:
By default, user IP addresses are not logged. Exception: In the event of incorrect login attempts, the IP address is logged to ward off attacks on accounts.
The password for the Jabber account for identification when the Jabber client logs on to the server (saved encrypted!).
How is it "encrypted"?
A user's contacts stored in the lineup along with information about the direction(s) of visibility associated with that contact. This is saved so that you can log in from different clients and always have the same contacts.
Date and time when the user account was created and when it was last used. This is done so that unused user accounts can be automatically deleted.
In order to keep messages synchronous across multiple devices and to be able to exchange messages even when two participants are not online at the same time, messages are cached on the server for up to 4 weeks. This feature is called "MAM" [...] Message Archive Management
Content uploaded via http_upload remains stored on the server for 3 days
The Jabber server data is backed up weekly to a server in a different location. The data is encrypted and transferred to the backup server and secured. The backups are kept for 4 weeks and then deleted on a rotating basis
Overview of stored data
- IP addresses (e.g. incorrect login attempts) for 14 days (firewall rules)
This is a contradiction. First they say 7 days, then 14. Which is it?
- Message history (4 weeks long. Optional: deactivate MAM.)
- HTTP_Upload files are stored on the server for 3 days
- Time of last login (to detect inactive users)
- Profile information (VCard) and avatar
- Contacts and MUCs added to the account
Okay, so anonym.im reserves the right to keep backups containing all server data for up to six months, and will store backups for 4 weeks. There isn't much emphasis given as to what those backups will contain. Is it the information they previously outlined under "What Data is Stored", alongside account information e.g username, password, avatar, etc, and nothing more? Or is there metadata contained as well? I can't say, because there's no indication.
Rating:
Excerpts from their privacy policy:
Login credentials are stored in encrypted form and never shared with other parties.
What type of encryption?
We do not log IP addresses at this time, informational logging is disabled.
[...]
Messages sent to you while you are offline are stored until you connect or your account is deleted.
Message archives of the messages you send and receive are stored for 7 days, if you have enabled [MAM]
Uploaded files are stored for 7 days.
The removal of expired uploads happens when either a new upload slot is requested or a scheduled clean up once per week, whichever comes first.
Chatroom history is stored according to the configuration of the respective chatroom, and might be made public by other participants.
Note about backups
In flux at the moment.
Despite the fact that they claim their server is "open to anyone who would like to use it", I cannot seem to establish a connection when attempting to register with my client. Is it because I used Tor?
Rating: L?,
No privacy policy to be found.
Rating:
Registration conducted through website which uses hCaptcha.
Server: Prosody 0.12 nightly build 221 (2024-07-11, 997d9ad12477)
SASL mechanism(s): SCRAM-SHA-1, PLAIN
Website connects to: chart.googleapis.com
IPs stored upon failed login attempts; duration of storage unspecified. Otherwise, IPs not logged. Connection timestamps (last login/logoff) are stored.
Passwords stored hashed as SCRAM-SHA-1.
From their privacy policy:
Please note that if we are forced by law to cooperate with law enforcement agencies we will (have to). This might also include surrender data.
Most online services will sell you out to law enforcement. The only way to know they won't is if they find themselves in trouble over not selling you out.
Jabber and Transport passwords:
Jabber passwords are stored as hashed SCRAM-SHA-1 and in plain text for all Jabber transport services.
Offline messages
Private messages are instant messages that you send to other XMPP/Jabber users on our or other servers. If your messages are sent through other services then it is possible that those services can log your messages, and we do not have control over those services. However, your messages are never intentionally logged here on our server. If you are not online when someone sends you a message, the message is stored on our server for delivery when you log in again. This so called offline message storage is not encrypted and messages are kept for 93 days. After delivery, the offline messages are deleted automatically and also before the expiry of the specified retention period on our server.
IP addresses
Our XMPP/Jabber services do not log information about your IP address. As the only exception we log IP addresses from failed login attempts. Also we reserve the right to block specific IP addresses as well as whole IP address ranges that threatened or may [threaten] our services and to keep a list of such offending IP addresses. This list of blacklisted IPs will not be made public.
Our web forms for registering and deleting an XMPP/Jabber account and also for adding an email address or changing the password to this account run through our web server. So IP addresses are logged when performing these tasks.
In order to prevent service interruptions, we back up data related to our services. These backups include system backups, configuration files and databases.
Rating:
Website connects to: google.com, translate.google.com, fonts.googleapis.com, fonts.gstatic.com, paypalobjects.com.
Cannot register on clearnet or hidden service through client. I'm fed the message:
This server does not allow signup
Going off of their homepage:
Class A XMPP Chats is a NO LOGS server
In fact, we do not record any information regarding the origin of your connection in our access logs.
No data of any kind is collected on the end users of this network structure.
We don't know who you are or where you come from.
Currently all services exposed to the public on this server are protected by TLSv1.2 connections with RSA certificates (4096 bits) guaranteed by Letsencrypt Certificate Authority.
This is all well and good, but what they're saying can't possibly be true. It's not possible for them to store absolutely no logs whatsoever. For the service to function they have to store some amount of information — however miniscule — on their users.
Libertarian for us means that this server defends the privacy of its users.
Furthermore, anyone intent on using this service to spread advertising [...] will be canceled without notice
As you will soon see they cannot even live up to their own standards.
Their privacy policy says so little with so many words. It was created using a preset template. Paraphrasing their policy:
While using "the service" jabber.tcpreset.net may collect information such as your IP address, browser type, browser version, the pages of their service that you visit, the time and date of your visit, the time spent on those pages, unique device identifiers and other diagnostic data.
While using "the service" by or through a mobile device, jabber.tcpreset.net may collect certain information automatically, including but not limited to; the type of mobile device, UUID, the IP address of the mobile device, mobile operating system, the type of mobile internet browser, unique device identifiers and other diagnostic data.
jabber.tcpreset.net may embed "web beacons" (tracking pixels) which they also refer to as "clear gifs, pixel tags, and single-pixel gifs" (very banal sounding) in emails and web pages to count users who have visited or opened the given pages or emails, and for other related website statistics such as gauging the popularity of a certain section of their website, or verifying system and server integrity.
They go on to give numerous potential uses of this collected data. Going over their uses, they haven't yet explicitly stated that they will sell the data off to third parties, all their given examples are at large self serving e.g using the data to harass you with news updates and other rubbish you don't care about.
Nevermind
We may share Your information with Our business partners to offer You certain products, services or promotions.
We may share Your information with Our affiliates, in which case we will require those affiliates to honor this Privacy Policy. Affiliates include Our parent company and any other subsidiaries, joint venture partners or other companies that We control or that are under common control with Us.
"Common control"
We may disclose Your personal information for any other purpose with Your consent.
I wonder if this line below (appears earlier in the document) serves to obtain consent:
You agree to the collection and use of information in accordance with this Privacy Policy
The Company may disclose Your Personal Data in the good faith belief that such action is necessary to: Comply with a legal obligation Protect and defend the rights or property of the Company Prevent or investigate possible wrongdoing in connection with the Service Protect the personal safety of Users of the Service or the public
Now to see if I can create an account through their website using Tor without enabling javascript
There was an error creating the account: Not allowed
Makes sense.
If they're collecting all of these data points, and you can't use anonymizers, there's no way they can't know where you're from while you're signing up. On their front page they say they don't keep logs on the "Class A XMPP" server. Maybe they run some other kind of services? Maybe they have instated a barrier of sorts, a separation between XMPP and whatever other services they provide, opting to only surveil all of their non-XMPP customers. I don't see any other services they run, and I don't think they're part of some larger company. Who knows. All I know is that their privacy policy is terrible.
As I was reading their privacy policy I was imagining that they had just randomly generated this awful policy, and tacked it onto their site, thinking that having a privacy policy would make them look more official, not realizing how its contents would reflect upon their XMPP server. Perhaps they really do run a private XMPP server. I have serious doubts considering everything I've seen so far. Even if this is all some kind of misunderstanding, it just shows that they don't care all that much about their service, I mean they literally used a half-assed readily-made prompt, which authorizes them to collect and sell their users data, as their privacy policy. This privacy policy is diametrically opposed to the stuff they spout off about on their front page, they do a complete 180. You're going at breakneck speeds from privacy protector to data swindler within five seconds. It's like being catapulted from a tropical privacy paradise to the South Pole of surveillance.
Hopefully there's just some misunderstanding here. I think there is because it's completely absurd to think they would be datamining people when the majority of their userbase's activity is going to be end-to-end encrypted anyway. There's no way this could be profitable to them, they're not going to be raking in the big bucks by spying on XMPP users. Regardless of that, I don't trust these people.
Conversations.im gives jabber.tcpreset.net a 100% in compliance with specification standards. All because they comply with the standards of features an XMPP service should provide, there's never any emphasis given to whether or not a provider may be spying upon people.
Rating: L1?,
They don't specify how long connection logs are stored for. I've probably read their policy over five times now, paranoid that I've missed something. They state that packets sent/received from the server are stored for the duration of a login, so perhaps IPs and other metadata are stored for a similar time?
Excerpts from their privacy policy:
In principle, the server stores the following data:
- The Jabber ID (JID) consisting of the user name and domain to identify the user account.
- The password for the Jabber account to identify the user when the Jabber client logs into the server. For compatibility with old clients, this was stored in plain text on the server for a while. However, since August 2014, when a user logs in, the password has been overwritten with a hashed version.
Which algorithm?
- The contacts of a user stored in the list together with information about the direction(s) in which visibility exists with this contact. This is stored so that you can log in from different clients and always have the same contacts.
- The date and time when the user account was created and when it was last used. This is done so that unused user accounts can be automatically deleted.
- While the user is not logged in, incoming messages addressed to him are cached so that they can be delivered to him the next time he logs in. The time when these messages arrived is also recorded.
- While a user is logged in, the length of time they have been online and how many data packets they have received and sent during this time is recorded. This is done so that the performance and utilization of the server can be monitored and sources of overload can be identified.
- If there are errors in the delivery of a message, the information about who sent the message to whom and why the delivery did not work is recorded. However, the content of the message is not recorded. This is necessary in order to be able to identify a problem if errors occur frequently.
[...]
It is also possible for the Jabber client to store data on the server. This data can be stored by the Jabber client either in such a way that it can be requested by other Jabber users (e.g. vCards containing contact information) or in such a way that only the user of the account can retrieve the data (e.g. configuration settings of a Jabber client). Which data is stored, to what extent and for how long is up to the Jabber client.
Backups of all of the above data are created regularly and kept for around 30 days. In these backup copies, data that has actually already been deleted can continue to exist for a few days.
Statistics on the use and utilization of the server are obtained from the collected data. These statistics are created anonymously; it is not possible to draw conclusions about individual people from these statistics.
A large part of the policy is taken from something else.
(Version 1.1 from October 23, 2015 - This text was largely taken from http://web.amessage.info/FAQ/privacy.)
Rating:
Website connects to: googlesyndication.com, pagead2.googlesyndication.com.
IPs logged at registration, and stored for 31 days.
This server may no longer be open. I can't seem to register. Maybe it blocks Tor.
Passwords stored hashed as SCRAM-SHA-1.
From their privacy policy:
These regulations were shamelessly copied from jabber.at.
At least they're honest. A lot of servers steal policies.
The SCRAM-SHA1 hash of the password to your account for authorization when your client connects to the server.
The Jabber-service itself does not store any regular connection information. This means we will never be able to tell in hindsight where you connected from.
The webserver that serves this website (as well as accounts.jwchat.org) keeps access logs (in the standard Apache log format) that are stored for up to four weeks.
If an error occurs while delivering messages, we save a log entry detailing who sent the message to whom at which point of time and why it failed. The actual content of the message is not a part of that entry. We only need the metadata to determine the root of the problem when things go awry.
Our account registration website at accounts.jwchat.org stores the IP-Address used for registering an account for 31 days to help detecting automated registrations.
The data of the jabber-server is backuped daily to a remote location. The data is GPG-encrypted before it is send over the wire, therefore, only Stefan and Georg (the server operators) can decrypt the backups, even if the backup-server is compromised.
In Germany, a public court can order us to cooperate with law enforcement agencies to help with a criminal investigation. Such an order is only possible if the supposed criminal offense is punishable by at least a year in prison. An order is always only valid for a single accounts and must have a fixed time limit. Cooperation usually means that we have to hand over any stored data as well as start logging the connection (including all messages henceforth send from and to the user) and hand over this data as well.
In case of such an order, we are:
legally forced to cooperate with law enforcement and provide all information requested by the court order.
legally barred from informing the person under surveillance.
This of course means that in case of such an order, we will comply, even if we don't like it. None of us is willing to go to prison for an anonymous account. You are of course, regardless of any legal situation, advised to use either OTR, GPG or any other technology for end-to-end encryption.
They list the amount of court orders issued to them from 2003-2015, that amount being zero. Strangely, the index ends in 2015, have they gotten any in these 8 years?
It's unclear how long the backups are retained for. Do they cycle them out every day, do they keep them for 31 days?
They claim to support in-band registration, however I was rejected upon my attempt.
Rating:
There's just one problem with their privacy policy. It says they will delete or anonymize IP addresses after 7 days, and that IP addresses will only be retained beyond 7 days under certain circumstances. The circumstances are vague, but can be assumed to be in the event of say, an attack on their server, or something of the sort. Either way, it is still vague. I do not mean to be unfair to magicbroccoli.de, other servers listed here have similar policies.
Otherwise, server logs are only retained for a week, whatever metadata is contained within will go with them.
Passwords stored hashed as SCRAM-SHA-1.
Server: ejabberd 24.06.11-magicbroccoli.de
SASL mechanism(s): PLAIN, SCRAM-SHA-1
Gajim chose SCRAM-SHA-1
Excerpts from their privacy policy:
Deletion of data
We, or our hosting provider, collect data about every access to the server on which this service is located (so-called server log files) based on our legitimate interests within the meaning of Article 6 Paragraph 1 Letter f of the GDPR. The access data includes the name of the website accessed, file, date and time of access, amount of data transferred, notification of successful access, browser type and version, the user's operating system, referrer URL (the previously visited page), IP address and the requesting provider.
Log file information is stored for security reasons (e.g. to investigate acts of abuse or fraud) for a maximum of 7 days and then deleted. Data whose further storage is necessary for evidentiary purposes is excluded from deletion until the respective incident has been finally clarified.
In general, only the data necessary to operate the server is stored on the server. The following data is stored in detail:
Password (stored as SCRAM-SHA1 hash)
User inventory data is automatically deleted after 365 days of inactivity. File uploads or HTTP uploads are automatically deleted after 31 days. Offline messages are cached on the server for a maximum of 365 days, or until the user logs in again. Log file information is stored for security reasons (e.g. to investigate acts of abuse or fraud) for a maximum of 7 days and then deleted. Storage beyond this is possible, in which case the users' IP addresses are altered so that user allocation is no longer possible
Duration of storage
The IP addresses will be anonymized or deleted after 7 days at the latest. The access time, which is collected to protect against misuse and other unauthorized use, will be deleted as soon as the user account is deleted. This is the case if no user activity is recorded for 365 days, or the user has not logged in after registration, or the user deletes the account using a common XMPP client.
I doubt that this last segment of the privacy policy quoted below actually applies to magicbroccoli.de, skip ahead if you like.
Integration of third-party services and content
Within our online offering, we use content or service offerings from third-party providers based on our legitimate interests (i.e. interest in the analysis, optimization and economic operation of our online offering within the meaning of Art. 6 Para. 1 lit. f. GDPR) in order to improve their content and To integrate services such as videos or fonts (hereinafter referred to as “content”).
This always assumes that the third party providers of this content are aware of the user's IP address, as without the IP address they would not be able to send the content to their browser. The IP address is therefore required to display this content. We strive to only use content whose respective providers only use the IP address to deliver the content. Third parties may also use so-called pixel tags (invisible graphics, also known as “web beacons”) for statistical or marketing purposes. The “pixel tags” can be used to evaluate information such as visitor traffic on the pages of this website. The pseudonymous information can also be stored in cookies on the user's device and may contain, among other things, technical information about the browser and operating system, referring websites, visiting time and other information about the use of our online offering, as well as being linked to such information from other sources.
Youtube
We integrate the videos from the “YouTube” platform of the provider Google LLC [...] Data protection declaration: Google Privacy Policy, Opt-Out: AdSetting Opt-Out.
Google Maps
We incorporate the maps from the “Google Maps” service provided by Google LLC [...] Data protection declaration: Google Privacy Policy, Opt-Out: AdSetting Opt-Out.
Functions and content from the Twitter service can be integrated into our online offering, offered by Twitter Inc [...] This may include, for example, content such as images, videos or texts and buttons with which users can express their preference for the content, subscribe to the authors of the content or subscribe to our posts. If the users are members of the Twitter platform, Twitter can assign access to the above-mentioned content and functions to the users' profiles there. Twitter is certified under the Privacy Shield Agreement and thereby offers a guarantee of compliance with European data protection law [..] Data protection declaration: Twitter data protection declaration, opt-out: https://twitter.com/personalization
Their site makes no connections to Google, or Twitter, so I'm not sure why this was tacked onto their privacy policy. Maybe they copied the format for their privacy policy from someone else, and forgot to remove this? They have a blog. Maybe their blog features this embedded content? I checked, and it doesn't. Maybe they were legally obligated to add it for some reason, I don't know.
Rating: Website connects to: fonts.googleapis.com, gstatic.com, fonts.gstatic.com, wp.com, stats.wp.com. Japanese server. I don't know Japanese, so I had to translate their privacy policy. It might read a little strange at times. Attempted in-band registration, was served a Japanese captcha. I can't solve this shit. Trying another circuit.
Still Japanese.
Well, if you want to register then use a Japanese keyboard.
Japanese keyboard isn't working for some reason, I'll just move on to the privacy policy now: With which algorithm are they hashed? How long are these kept for? Is it the aforementioned 20-100 days? Through process of elimination, which is aided by tracking pixels, users can be identified. How long are these kept for? Is it the aforementioned 20-100 days? It's not clear, as with the 'connection records'. I asked the admin how passwords are stored, since the privacy policy did not specify. The admin said they are stored as SCRAM-SHA. Rating: XMPP server log files retained for a week. Webserver retains logs for as long as is necessary to display a page to a visitor. Registration is done manually via email. Excerpts from their privacy policy: This same line shows up in anonym's policy. I guess they both are using a template. This line also shows up in anonym's policy. Use a throwaway email when registering. Rating: L?, Cannot register via client. You can register through their website while using Tor without enabling javascript. They don't have a privacy policy. Rating: Backup data is created daily and "stored for some time" Server: ejabberd 24.7.0 SASL mechanism(s): PLAIN, SCRAM-SHA-1-PLUS, SCRAM-SHA-1 Gajim chose SCRAM-SHA-1 xabber.de is controlled by draugr.de so this is just draugr.de's policy: Definitely one of the better XMPP providers, I would just like to know how long they keep backups for. I'll have to ask sometime. They don't speak of how metadata is handled, but they do say that their website does not store any requests, and IP addresses are retained only for the duration of a login, so metadata is probably handled similarly. Rating: L4?, Registration uses reCAPCTHA. Website connects to: fonts.googleapis.com, gstatic.com, fonts.gstatic.com, googletagmanager.com. They don't say how long IPs are stored for. It might be a month, but I can't know. Cannot register in-band, and can't register through their website without enabling javascript. They appear to run some paid services, but I think it's free to register an XMPP account, though I'm not entirely certain. I cannot log in to my account after having registered through their website. They may block Tor. Excerpts from their privacy policy: Which algorithm? Rating: One of the larger XMPP servers. Server: Prosody 0.12 nightly build 223 (2024-08-18, 2fb79fe54390) SASL mechanism(s): SCRAM-SHA-1, PLAIN Excerpts from their privacy policy: How are they encrypted? Rating: French server Server: ejabberd 23.01-1 SASL mechanism(s): PLAIN, SCRAM-SHA-1 Their policy is stated on their front page: Okay, IPs aren't logged. Is other information, like connection, and message metadata logged? If so, for how long? Are backups made? It's impossible to know. Appears to be a dead website. Last year they were using CloudFlare. Rating: L1-2?, They don't explicitly state how long any particular form of data is retained for. They basically say they will store data for as little time as possible. They're a large server, so maybe logs are retained for up to two weeks. Server: Prosody 0.11.2 SASL mechanism(s): SCRAM-SHA-1-PLUS, DIGEST-MD5, SCRAM-SHA-1, SCRAM-SHA-1 Gajim chose SCRAM-SHA-1 XMPP servers specs noted here: I'll get to their privacy policy momentarily. Excerpts from the privacy policy: Quite a long policy, though I cut it down a fair bit. It does not once state exactly how long data like IP addresses will be stored, it is simply deleted "on a regular basis", retained for "a limited time", etc. I believe it is reasonable to assume that it is the shortest time possible. Rating: IPs are not logged. XMPP server logs are retained for 3 days, and their website retains logs for 7 days. File uploads are retained for 14 days. Runs a hidden service. Supports in-band registration Limited registration (500 users). Registration opens here and there, but is usually closed in my experience. From their front page: Supposedly runs a hidden service Supposedly supports in-band registration without captcha. A year has passed, and this website is still unresponsive. Rating: Server is located in Japan.
The administrator will provide information about this server, make announcements, respond to inquiries, etc. only in Japanese. It does not support other languages (so when you create an account on this server, her CAPTCHA is a quiz (hint: moon) to test your basic Japanese knowledge).
The following data is stored on the XMPP server: We will not disclose it unless forced to do so by law:
(*)The number of storage days is set on the server side within the range of 20-100 days, taking into account the free space on the server.
MUC (multi-user chat) chat rooms may allow participants to know each other's real girlfriend's JID [huh?], depending on the settings of the chat room host. Also, even if it is not set up that way, the host and administrator of that common room will know her real JID.
Please note that some XMPP clients may also store data on the server side.
Connection records are only used by server administrators for troubleshooting purposes. We will not disclose it unless forced to do so by law.
This website uses technologies called cookies and web beacons for some of its content. Cookies are used to identify the computer used by the user, but do not identify the individual user. Web beacons are used to collect information such as site usage status, but they do not contain any information that can identify individual users.
Records of website browsing (including records of connections made when using the web client and his BOSH) are used only by the administrator for troubleshooting purposes. We will not disclose it unless forced to do so by law.
trashserver.net
Sorry! Zur Zeit ist die automatische Anmeldung wegen Spamattacken gesperrt. Kontaktiere mich gerne via E-Mail - dann erstelle ich Dir manuell einen Account.
As the operator of a data protection-friendly alternative to WhatsApp, I strive to offer a “data-efficient” server. However, there are a few things to keep in mind:
IP addresses for incorrect login attempts
Message history (4 weeks. Optional: turn off message logging.)
Uploaded files (4 weeks long)The operator of the service reserves the right to keep all data stored on the server in the form of backups on external systems for up to six months.
Every time our website is accessed, our system automatically collects data and information from the computer system of the accessing computer.
The following data is collected:
Information about the browser type and version used
The data is also stored in the log files of our system. This data is not stored together with other personal data of the user.
The data will be deleted as soon as it is no longer required to achieve the purpose for which it was collected. If the data is collected to provide the website, this is the case when the respective session has ended.
If the data is stored in log files, this is the case after seven days at the latest. Storage beyond this is possible. In this case, the users' IP addresses are deleted or altered so that it is no longer possible to assign the calling client
The IP address is only stored in a log file in the event of incorrect login attempts, but is not logged during normal operation. Longer-term message logging is enabled by default to provide the user with the best possible experience. Message logging (MAM) can be permanently switched off via a client function, so that no messages remain permanently on the server and are only stored temporarily for transmission purposes
Log files including saved IP addresses are deleted after 7 days at the latest. Message logs (MAM) and file uploads are deleted after 4 weeks.
[...]
For archiving and data backup purposes, data received via email is stored on our own systems for an indefinite period of time.
tunny.xyz
xabber.de and draugr.de
Draugr.de does not store any requests on this website. This includes the address accessed, IP address of the request, browser type, operating system and similar.
If you use the XMPP server on Draugr.de, the following data is generally collected and stored:
Your client may store additional data on the server that is not listed above. This can include, for example, profile information (vCards), bookmarks for chats and the like. It is up to the client whether this data has been saved publicly accessible or not.
No IP addresses are stored beyond the duration of a login to the XMPP server.
This data is stored until a user deletes it via their client or completely removes their account. Accounts that have been used for 1 year or never will be automatically removed. A backup copy of this data is created daily and stored for some time so that data that has actually already been deleted can continue to exist.
The data is used to operate the service. The data will not be passed on to third parties unless the user of the service makes the data publicly visible (e.g. via a vCard).
Furthermore, the data is used to trace cases of misuse of the server and to troubleshoot problems.
If you are unclear, you can ask at any time. You also have the right to information at any time about the data stored about you and the purpose of the storage.
xabber.com
Signup not permitted through client.
We store user data that is required for providing communication services to users of communication services provided by Redsolution OÜ. We do not store or have any access to user data who do not have Xabber Account or XMPP accounts on our servers.
We do not have any access to application data stored on user devices.
Xabber account is required to subscribe to communication services provided by Redsolution. To provide service we gather following information:
If Xabber Account is created using XMPP address provided by us, registration IP address is stored to help detect automated registrations.
XMPP servers store the following data about users:
Additionally, an XMPP client may store data on the server. If that data is accessible to others (like a vCard which contains contact details) or accessible only to you (like configuration settings for a XMPP client) is determined by a client application you use.
We will not disclose these information, and we will not do any other behavior that would compromise your privacy and security, except as otherwise requested by domestic law of the Republic of Estonia.
yax.im
The following information is needed to provide the service to you (Art. 6.1b) and is stored as long as your account exists:
services that you are using (e.g. transports). The date and time of your last login is stored alongside your account to identify inactive accounts.
creep.im
Creep.im is a free XMPP/Jabber server operated by an individual, running for use by a general public. The service is setup and operated with users' security and privacy in mind. The service is setup in a dedicated server with FDE. Please not abuse it and use appropriately.
IPs are not logged
Current certificate's SHA-1 fingerprint of Creep.im is [...] If your client asks you to accept some other certificate, do not allow it, since this may be a malicious activity from some third party.
evil.im
calyxinstitute.org
The server does not create any records of who you communicate with.
It does not log the content of any communications (and in fact since the server forces you to use Off-The-Record Messaging, we can never get access to the plain text of your communications) For more information about what Off-The-Record is and why we require it, as well as links to XMPP clients that support OTR, see this page.
The use of this server is governed by The Calyx Institute's privacy policy
StartTLS / SSL encryption is required for all client connections. The server is configured to prefer ephemeral (Forward Secrecy) encryption ciphers, but will fall back to AES256-SHA or AES128-GCM-SHA256 if servers or clients don't support the ephemeral flavors.
Our RSA key size is 4096 bits. In recent years, various security organizations have recommended that RSA key sizes less than 2048 bits be discontinued. In particular the United States National Institute of Standards and Technology (NIST) recommends using 2048 bit RSA keys until 2030 at which time it predicts they will not be considered strong enough any longer. But really, why wait until 2030? We have chosen to skip 2048 bits and have adopted a 4096 bit key size now.
Tor Hidden Service - So that users can access the server more anonymously, it is also available as a Tor hidden service at the address: ijeeynrc6x2uy5ob.onion If you use XMPP through the .onion address then that makes it much more difficult for observers to know (through metadata collection or passive observation) who is connecting to the server. At the moment the only client that we know of that has built-in ability is ChatSecure on Android. It should be possible with just about any client however to direct it to use a tor socks proxy.
The calyxinstitute.org DNS zone is signed with DNSSEC You can check the status of the chain of trust using the dnsviz tool operated by Sandia National Laboratories.
We have published DANE/TLSA dns records containing the fingerprint of the SSL certificate used on the server. We are unsure if any XMPP clients actually check the DANE/TLSA records however. Hopefully we will find out more soon.
[...] This privacy policy ("Privacy Policy") details the information about you that we collect, including personally identifiable information ("personal information"), to provide you with our programs and services. Personal information is information that can be used to identify you.
[...]
[...]
This Privacy Policy governs your privacy in connection with your use of the following Calyx programs and services:
[...]
Use of our Websites requires disclosure of limited personal information. Your IP address may be logged, but we will delete such logs on a regular basis. We make our Websites available via the Tor Project’s anonymity network as "hidden services" which makes it easier for users to cloak their true IP address and protect their web browsing metadata from third parties. We may use cookies on our Websites for the purposes of tracking your session but we do not include third party cookies.
Calyx may provide Internet Services via its servers. Connecting to these servers may reveal your IP address, but as with our Websites logs, we plan to retain this information only for a limited period of time as set forth in this Privacy Policy.
Calyx depends almost entirely on contributions from the public to provide its Internet Services, Websites and Educational Programs and Materials, and we strongly urge anyone who values our mission to become an active participant with Calyx. Without your generous support, Calyx is unlikely to be able to provide its programs and services. If you become a member of Calyx ("Member") we will collect the personal information that you provide, including your name, address, email address and telephone number. Furthermore, when you become a Member, you are assigned a unique membership identifier and we will collect payment information. If you pay via either cash or Bitcoin, we retain no personal information other than the information you provide and your membership identifier. If you pay by check, then we retain the information available on the check. If you pay by credit card, Calyx retains the name, billing address, and credit card information necessary to charge your credit card. If you establish a recurring credit card payment to pay for your membership, Calyx retains your name, billing address, and credit card information until we are notified that you cease to be a Member.
If you become a Sustaining Member, and elect to subscribe to the wireless broadband service that is offered as a benefit to Sustaining Members and above, we also collect and retain information related to the equipment associated with your subscription. This is only the membership identifier and the MAC address of the device.
Any personal information will be maintained and protected on an encrypted basis for as long as you are a Member or maintain your registration with us. If you cease being a Member of Calyx, your personal information will be deleted promptly once we are no longer required to retain such information in accordance with our retention policy and applicable law.
B. Technical and Usage Information
Calyx may collect aggregate information in order to ensure the quality of the network, Internet Services, Websites and Educational Programs and Materials. We maintain this information only for as long as reasonably necessary.
[...]
[...]
The confidentiality of your personal information is very important to us. We will use your personal information only in connection with providing our Internet Services, Websites and Educational Programs and Materials. Thus, membership information will be used for maintaining your registration and active membership. Specific logging information will be used to diagnose problems with our Websites, and potentially to improve what we provide on our Websites. These activities typically include:
[...]
We will share personal information available to us with law enforcement or other government agency in any of the following circumstances:
Sometimes a law enforcement or other government agency request may contain a “gag order” that prohibits us from disclosing to a user that a request has been made for his or her personal information (for example, a “National Security Letter” pursuant to 18 USC § 2709(c)). Calyx's Executive Director has experience challenging the Constitutionality of a National Security Letter. Although we may not be able to able to challenge all secrecy demands, we have designed our Internet Services (including our system infrastructure), Websites and Educational Programs and Materials with an eye toward user privacy, as described in other Sections of this Privacy Policy and elsewhere on our Websites. In addition, regardless of the nature of the legal proceeding, we will carefully consider every third-party attempt to get your personal information to determine how much and what kind of data we must share. Our foremost goals are to communicate with you whenever possible about who is attempting to acquire information related to you and to use our best efforts to respond in a way that protects your privacy to the extent the law permits.
However, we will not violate the law and we must comply with lawful governmental orders and investigations. We will try to protect your privacy to the extend the law permits.
jabber.cat
Due to limited server capacity, the number of accounts is limited to 500.
Unused accounts will be deleted after 3 months.
Server-side message archiving is turned on. This enables your different devices to fetch the chat history if they were offline. Please be aware of unencrypted chats being saved on the server as clear text! Use end-to-end encryption! The archive expires after 14 days. Some clients, e.g. Conversations for Android, let you configure the archiving behaviour (in the account settings).
jabber.otr.im
jabber-germany.de
Server: Prosody 0.12.4
SASL mechanism(s): SCRAM-SHA-1, PLAIN
Here is their privacy policy.
Due to the increased incidence of spam messages, a registration is required from now on. There are two options available:
- Send an email to the address below with the desired name to be registered. The account will be created as soon as possible and a response with a temporary password will be sent. Please use this way in case you want to get recovered (or reset) your password at a later stage as this is only way to verify you unambiguously.
EMail address for registration: jomo@morbitzer.de
PGP/GPG: 4096R/D982BBD6 (12/24/2013)
- Use the web registration form. Please note that resetting the password with this method is not trivial in case of password loss. If in doubt, please select option 1 (see above).
I hope for your understanding, the fight against spam has become an important issue, and this new method of registration finally helps all users.
By using this server to communicate with third parties you agree that data will be passed to third parties. Messages sent to other users are subject to policies those users agreed to.
The current configuration is as follows:
- XMPP software version: Prosody 0.12.4
- Activated XEP Modules: XEP-0198, XEP-0280, XEP-0065, XEP-0012, XEP-0092, XEP-0030, XEP-0163, XEP-0199, XEP-0090, XEP-0202, XEP-0054, XEP-0237, XEP-0357, XEP-0191, XEP-0124, XEP-0206, XEP-0352, XEP-0363, XEP-0313, mod_muc_mam, mod_vcard4, mod_vcard_legacy, XEP-0384, csi_battery_saver, XEP-0411, XEP-0410, XEP-0288, XEP-0215, XEP-0045, cloud_notify_filters, cloud_notify_encrypted,firewall,unified_push,pubsub_serverinfo
- Password storage: hashed
Which protocol?
- CA: Let's Encrypt
- Certificate Key size 4096
- Certificate sha256 Fingerprint=CF:51:12:86:22:01:70:44:5D:31:3C:2C:A4:31:38:0B:98:F3:17:92:7F:02:C7:9B:D3:23:BC:AE:4A:29:2C:D1
- OS: Debian Linux 64 Bit
- Server location: Germany
- Hosting provider: Netcup
- Internet link: 2.5 Gbit/s
- Backup procedure: borgbackup, nightly snapshot (external destination)
- C2S require encryption: Yes
- S2S require encryption: Yes
- Inband registration allowed: No (see above)
- Group chat support: Yes
- Contact (email): admin
jabber-germany.de - Contact (xmpp): admin
jabber-germany.de - Offline Messages: 31 days (MAM: 14 days)
- http upload file size limit (XEP-0363): 20 MB
- http upload file expiration after: 14 days
- http upload quota per day: 200 MB
- http upload quota global : 1024 MB
- Tor address: xmpp://gku6irp4e65ikfkbrdx576zz6biapv37vv2cmklo2qyrtobugwz5iaad.onion:5222
- Converse.js address: https://jabber-germany.de:5281/conversejs
Privacy Policy:
Things that are being stored:
- User name and hash of password.
- Offline messages. If someone sends you a message while you are offline that message will be stored until you get back online.
- Archive. By default we will be keeping an archive of your messages for later retrieval by yourself. This can come in handy if you log in with a new device and want access to your message history and is also required if you want to use the OMEMO encryption with multiple devices. You can opt-out of this by setting your server-side archiving preferences with your XMPP client.
- Files. Every file you share with a contact or a conference will be uploaded and stored for later retrieval by the recipients.
- A list of your contacts (Roster, Buddylist). This list is maintained by you. You decide who goes on that list and who gets deleted.
- Semi public data you are publishing for your contacts to see like your avatar or the OMEMO public keys.
- Other private data your XMPP client might upload like a list of conference bookmarks.
- Registering for a push does make an HTTP call which logs a user’s IP temporarily, this is necessary for the service to operate.
- I might activate and keep logs temporarily if this helps mitigating attacks (service maintenance).
Things that are not being stored:
- IP addresses.
- Any connection and/or duration times.
Rating: L?,
Supposedly runs a hidden service
No privacy policy.
Server: ejabberd 23.10-1~bpo12+1
SASL mechanism(s): PLAIN, SCRAM-SHA-1-PLUS, SCRAM-SHA-1
Their website only displays an nginx landing page. I successfully registered an account here
Rating:
IPs are anonymized or deleted after 7 days, however they do not mention how long other metadata is stored for.
Server: ejabberd 24.2.0
SASL mechanism(s): PLAIN, SCRAM-SHA-1-PLUS, SCRAM-SHA-1, X-OAUTH2, SCRAM-SHA-1
Gajim chose SCRAM-SHA-1
Excerpts from their privacy policy:
Types of processed data:
- Inventory data (eg, personal master data, names or addresses).
- Contact details (e.g., email, phone numbers).
- Content data (e.g., text input, photographs, videos).
- Usage data (e.g. websites visited, interest in content, access times).
- Meta/communication data (e.g. device information, IP addresses).
Purpose of processing:
- Making the online offer, its functions and content available.
- Answering contact requests and communicating with users.
- Security measures.
Cooperation with processors, joint controllers and third parties
If, as part of our processing, we share data with other people and companies (processors, joint controllers or third parties ) disclose them, transmit them to them or otherwise grant them access to the data, this is only done on the basis of legal permission (e.g. if transmission of the data to third parties, such as payment service providers, is necessary to fulfill the contract), users have consented to a legal obligation provides for this or on the basis of our legitimate interests (e.g. when using agents, web hosts, etc).
Transfers to third countries
There is no transfer of data to third countries. The service is operated in Germany.
[...]
[...] It is the user's responsibility to back up their data before the end of the contract in the event of termination. We are entitled to irretrievably delete all of the user's data stored during the contract period.
The contract being you having an account registered with them.
As part of the use of our registration and login functions and the use of the user account, we save the IP address and the time of the respective user action. The storage takes place on the basis of our legitimate interests, as well as the user's protection against misuse and other unauthorized use. In principle, this data will not be passed on to third parties unless it is necessary to pursue our claims or there is a legal obligation to do so in accordance with Article 6 Paragraph 1 Letter c. GDPR. The IP addresses will be anonymized or deleted after 7 days at the latest.
Doesn't speak of how any other information is handled by their servers.
Rating:
Runs a hidden service
Successfully registered an account off website without enabling javascript.
Server: Prosody 0.12.4
SASL mechanism(s): SCRAM-SHA-1, PLAIN
Update: Registration is now only conducted via email or XMPP (message the admin).
Their privacy policy is stated on their front page:
This server does not log your IP address, files and messages older than 30 days will be deleted automatically.
By messages they presumably mean MAM and offline (cached) messages.
Their privacy policy does not specify the algorithm with which stored passwords are hashed, so I asked the admin. Passwords are stored hashed with SCRAM-SHA-1.
Rating:
Web registration only; Depends upon javascript. Requires an email to verify account; disposable emails blocked.
Server logs (IP, message metadata) retained for 14 days. Uploaded files stored for 30 days.
Server: ejabberd 24.7.2
SASL mechanism(s): PLAIN, SCRAM-SHA-1, X-OAUTH2
Gajim chose SCRAM-SHA-1
Excerpts from their privacy policy:
Information associated with your account
The following information is necessary to provide you with the service (Art. 6.1b) and is stored as long as your account exists:
- Login credentials are stored in encrypted form and are never shared with other parties.
Encrypted how?
- Your account identifier (Jabber ID) is only shared with the Jabber/XMPP users and services you interact with.
- Your contact list (list, chat room bookmarks) is not shared with other parties except when you give explicit permission (XEP-0321: Remote List Management).
- Your availability (presence) information is stored in memory and automatically shared with your contacts and the chat rooms you enter, and may be shared with other Jabber/XMPP services you are using (e.g. transports). The date and time of your last login is stored together with your account to identify inactive accounts.
- The IP address of your registration and your last login are stored together with the account. This is necessary to detect and remove spammer accounts (Art. 6.1f). The IP addresses of identified spammer accounts will be shared with other server operators to prevent further abuse.
User Content
Content you send or that is sent to you is stored on your behalf, so that you can access it from all your clients (Art. 6.1b):
- Messages sent to you while you are offline are stored until you go online or your account is deleted.
- Message archives for messages you send and receive are stored for 14 days, if you have enabled XEP-0313: Message Archive Management.
- Uploaded files are stored for 30 days (some clients cache messages but not archives, so they are kept for longer).
- Chat room history is stored according to the settings of the respective chat room, and can be made public by other participants.
- Your public profile information (vCard) and avatar image are stored alongside your account and can be viewed by users who know your Jabber ID.
Server logs
To ensure the proper functioning of the service, including network and information security, server logs are stored for 14 days (recital 49 of the EU GDPR). The server log contains, among other data:
- Message metadata (sender, receiver, message type).
- The message content of messages is automatically flagged as potential spam. These messages may be subject to manual review.
- Connection information, including IP addresses and timestamps.
- Internal processing information.
Rating:
IPs not logged, but they don't speak of other metadata.
Server: Prosody 0.12.4
SASL mechanism(s) SCRAM-SHA-1, PLAIN
Dug through the HTML for their privacy policy, because javascript is needed to display it. As per usual, the hash algorithm is not disclosed.
Here are the specific privacy notes for the tchncs.de Jabberserver:
- Your password will be stored hashed
- tchncs is forcing servers and clients to use a trusted TLS connection. Unsecured connections will be refused.
- Except for technical debugging, no IP address is logged.
- Messages and files are stored for one month.
Rating:
You can register in-band via their hidden service. But their web registration uses hCaptcha.
Server: Prosody 0.12.4
SASL mechanism(s): PLAIN, SCRAM-SHA-1
Our dedicated server is generously provided at no cost to us from FlokiNET! We are not affiliated with them, although they were kind enough to provide a very nice server for free.
Configuration & Transparency: xmpp.is/about/transparency
General Server Facts:
- Server Country: Romania
- Backups: Encrypted and synced off-site daily
Are they overwritten on a daily basis?
- Security Access Policy: xmpp.is/about/security
- File Upload Size Limit: 100 MB
- File Upload Expiry: 1 week
- MAM Archive Policy: Off by default, must be enabled by client
- MAM Archive Expiry: 30 days
Clearnet Server Details:
- Domain/Host: xmpp.is, xmpp.chat, xmpp.co, xmpp.cx, xmpp.fi, xmpp.si & xmpp.xyz
- SOCKS5 Bytestream Proxy (domain dependent): envoy.xmpp.*
- TURN/STUN Server (domain dependent): turn.xmpp.*
- BOSH URL: http.xmpp.is/http-bind
- In-band Registration: Closed
- Web Registration: Open
- C2S Port: 5222
- S2S Port: 5269
Hidden Service Details:
- V2: y2qmqomqpszzryei.onion
- V3: 6voaf7iamjpufgwoulypzwwecsm2nu7j5jpgadav2rfqixmpl4d65kid.onion
- In-band Registration: Open for Tor HSv2 and v3
- C2S Port: 5222
- S2S Port: 5269
XMPP.is is operated by Unredacted Inc, a 501(c)(3) non-profit organization. You can read more about Unredacted’s security efforts here: unredacted.org/about/security
Server Access Policy
- Access to the server is only done over encrypted protocols and is available to one person. SSH keys are enforced. All admins encrypt their local computers and adhere to modern privacy & security standards.
Server-Side Security & Privacy
- The logs kept only contain information about info, warnings and errors. The info log does not contain user’s IP addresses, however, it does log when a user authenticates. We don’t store anything else besides the user’s hashed password, mod_offline messages, mod_mam archives, vcards, rosters and other module data based on our configuration.
- Our XMPP daemon, Prosody only interacts with flat-files on the filesystem level. No databases. All data is stored in flat-files. This significantly lowers the potential of user data being stolen.
- Our configuration is fully open source, if you’re wondering how it all runs you can view it here.
XMPP.is is operated by Unredacted Inc, a 501(c)(3) non-profit organization.
Now to check the organization that has made xmpp.is exist.
Unredacted is a 501(c)(3) non-profit organization that provides free and open services that help people evade censorship and protect their right to privacy
[...]
Connect with other privacy & security enthusiasts in our Discord
Why does every free/libre software oriented project do this?
unredacted's warrant canary states that they have not been compromised by law enforcement, nor cooperated with law enforcement in any way.
Summary of unredacted's privacy policy:
When you visit their websites:
Rating: L?,
Website connects to: cloudflare.com, cdnjs.cloudflare.com.
I thought it was Italian at first.
Supports in-band registration.
Their website now blocks Tor. Back in 2023 it didn't. Since I can no longer access their privacy policy through their website, you will have to trust that this isn't falsified:
The site is hosted on a private amateur server in Hamburg, Germany and is fully operated by us.
Most of the following is based on the privacy policy template provided by WordPress.
The privacy policy says nothing about their XMPP server. I don't think they intend to provide it to the public, but nonetheless, I registered an account successfully.
Rating: L?,
Successfully registered account with my client.
No mentions of a privacy policy.
This probably isn't intended to be a public XMPP server.
Ranking: L?,
Successfully registered account with my client.
Privacy policy says nothing about their XMPP server.
This probably isn't intended to be a public XMPP server.
Server: ejabberd 24.7.0
SASL mechanism(s): PLAIN, SCRAM-SHA-1
Rating: L?,
Their motto is:
Be Corpo-Free
And yet:
In-band registration attempt rejected. Web registration depends upon javascript.
No privacy policy, just some vague promises on their front page:
PRIVACY:
We don’t need your phone number. We only keep the necessary logs.
STABLE & SECURE:
Our server are located in a stable cloud. The server uses only stable software.
If any server in this article was a honeypot, it would probably be this one.
Server: ejabberd 21.12
SASL mechanism(s): DIGEST-MD5, PLAIN, SCRAM-SHA-512-PLUS, SCRAM-SHA-512, SCRAM-SHA-256-PLUS, SCRAM-SHA-256, SCRAM-SHA-1-PLUS, SCRAM-SHA-1, X-OAUTH2
Rating: L?,
Website connects to: fonts.googleapis.com, gstatic.com, fonts.gstatic.com.
No privacy policy.
Web registration only; Uses reCAPTCHA.
Rating:
IPs not logged. Date and time of last login are logged. The webserver logs pages visited, time of access, site reference, browser type and version, operating system. This is deleted after 7 days.
Registered an account off their site without enabling javascript.
Passwords stored hashed as SCRAM-SHA-1.
Their website is currenly down for maintenance. I don't have the URL for their privacy policy. Regardless, here are the relevant excerpts:
The following data is stored about users who register here and use the service:
- the selected username (the Jabber ID)
- the password in hashed form (as a SCRAM-SHA-1 hash). The actual password cannot be reconstructed from this hash according to the current state of technology.
- the user's contact list
- Date and time of last login
- the current presence information (online status)
- the status message
- the user's email address, if he optionally provided it during registration
- Offline messages: If messages are received for one of our users who is not currently online, these messages will be cached on the server. As soon as the user logs in again with a client, the messages are transmitted and deleted from the server.
- Further profile information: Client software can create so-called vCards and also upload them to the server; It is the user's responsibility to set up his client accordingly and to prevent uploading
- File Upload: [...] The limit is 20MB per file and 200MB per user.
- Message Archive Management: [...] If this function is activated by the user in his client, all messages will also be saved on the server [...] for a maximum of 30 days and then automatically deleted from the server.
Use of this data
The above data represents the “standard data set” that a Jabber server creates. They are needed to ensure the basic operation of the service.
A user should not use optional functions such as MAM or file upload if they do not want data to be stored on the server.
Any stored data will not be passed on to outside third parties in any way.
Duration of storage and deletion
The above list of data is stored for the entire period that an account exists on the server (with exceptions for messages, see above).
Inactive accounts are automatically deleted after a period of at least 2 years of inactivity.
Every user has a function available to delete their user account.
When a user account is deleted, all of the above-mentioned data and messages are irrevocably deleted from the database and system. This process cannot be undone.
Backups
As of April 2021, there is no separate backup of the server or user data.
The server is set to only allow encrypted connections. On the transport route from the user to the server, the transferred data is therefore adequately protected according to the technical standards.
The inventory data from the above list is stored on the server unencrypted in plain text.
Server location and data transfer
This website and all services are hosted by our IT service provider ip-projects.de, whose web servers are located exclusively in Germany (in Frankfurt/Main).
Data transmission with this website over the Internet is encrypted. Current and secure procedures are always used for this purpose. Certificates created by “Let’s encrypt” are used for authentication. They are renewed every three months and use secure encryption algorithms.
Access data / server logs
Due to our legitimate interest (see Art. 6 Para. 1 lit. f. GDPR), we collect data about access to this website and store it as “server log files” on the website server. The following data is logged like this:
- Page visited
- Time at the time of access
- Source/reference from which you came to the site (so-called referrer)
- the browser you use: brand of browser (e.g. Google Chrome or Firefox); Software version of the browser
- operating system used
- Your IP address is NOT stored in the logs
The server log files are stored for 7 days and then deleted.
Our legitimate interests in this data are the following:
- in order to be able to analyze server failures or other errors in the operation of the website
- For security reasons: if external attacks occur on the website from the Internet, the log files can be used to create a perpetrator profile or to determine the origin of the attackers; Furthermore, the target of the attack could possibly be identified using the information in the logs (e.g. attack on the database or a specific plugin)
- for legal reasons: e.g. to be able to investigate criminal acts or cases of abuse; If data has to be kept for evidentiary reasons, it is exempt from deletion until the incident has been finally clarified
GeoIP Check
We use a so-called GeoIP check on our site. This means that based on the visitor's IP address, an attempt is made to determine the country of origin of that IP.
Uh oh.
Certain countries from which a page view appears to come regularly represent an increased risk. And since our target audience is almost exclusively in Germany or German-speaking countries, we block some views from such “risk countries” so that no access to our pages is possible is.
They're just a fucking XMPP server? How much harm is caused to them by these supposed "risk countries"?
With this function, only the user's IP address is used as at least personally identifiable data. This is sent anyway with every page view (request). The IP is not permanently stored on our system and is not forwarded to third parties. We only use the IP to compare it against a locally existing database. This database contains lists of IP address ranges and the associated country origin - there are specialized companies that maintain such databases. After the local comparison, the IP is immediately discarded.
Our legitimate interest (see Art. 6 Para. 1 lit. f. GDPR) in using this function is to detect or directly prevent potential attacks on our website, and thus to prevent damage to us and data leakage or disruptions in the operation of the website to prevent website.
Rating: L?,
They don't say how long connection logs are stored for.
Server: ejabberd 21.12-1
SASL mechanism(s): DIGEST-MD5, PLAIN, SCRAM-SHA-512-PLUS, SCRAM-SHA-512, SCRAM-SHA-256-PLUS, SCRAM-SHA-256, SCRAM-SHA-1-PLUS, SCRAM-SHA-1, X-OAUTH2
Gajim chose SCRAM-SHA-512
Their front page outlines their practices:
ChatterboxTown.US is a public XMPP instant messaging service provider hosted in the USA. XMPP is a privacy and security focused, instant messaging protocol. No phone number or email required to create an account. With OMEMO enabled messaging clients, your communication is end to end encrypted.
The ChatterboxTown.US XMPP server has been configured with the following settings:
- Server-side message archiving of up to 30 days. However, you can prevent server-side message archiving altogether by explicitly turning it off in your chat client setting.
- One on one chats are archived by default, unless the chat client explicity disables chat archiving.
- Group chats (or Multi-User Chat, MUC) have message archiving turned off by default. It must be explicitly enabled by the room admin in room settings via the chat client[...] There is a 20 message history retrieval limit.
- You can transfer files up to 2GB in size. However, your user account will only accomodate up to 4GB total file data in a 7 day period. So, if you send a 2GB file, you will be only be able to transfer another 2GB of files until the previous files expire and free up space.
- File retention maximum 7 days
- Audio and Video calls are available on messaging clients that support them. So far, only Movim (web client), JSXC (web client), Conversations and blabber.im (Android), and Siskin (iOS) are known to actually be able to do audio and video calls with each other. Gajim (Linux) is known to have working audio and video calling, but only with other Gajim clients. Gajim for Windows has not had working audio or video for decades.
- We do not collect personal information and we respect your privacy. But, we would like to remind you that YOU are in charge of your privacy with XMPP. Be sure to use a client that supports OMEMO or OpenPGP and enable it for end to end encryptioin of messages and data between you and your recipient. Yes, the server will archive these exchanges for a short amount of time, but with end to end encrytion enabled on YOUR and YOUR RECIPIENT'S messaging client, the server only recieves encrypted data that only YOU and YOUR RECIPIENT can decrypt.
- Accounts inactive for 1 year are automatically deleted.
Rating:
Registration through email.
They only retain error logs, which contain scant information about a request. Sometimes the error logs contain IP addresses. These can be stored for 90 days. It seems their website will track page views, but the information is only retained for a week.
Their privacy policy is pretty sparse. Here's the relevant excerpts:
This data protection policy applies to all websites and services that can be accessed under the domains crapwa.re, cr4.pw, thor77.org, thor77.dev, s-seydel.de and jonas-seydel.de as well as subdomains of these.
When using the websites and services mentioned above, log files are automatically created.
Most of our servers are configured so that only errors are recorded in the log files. When an error is recorded, the time of the call, the URL called and the respective error message are saved. Depending on the service, the error message may also contain the user's IP address.
These log files are used to analyze errors and are deleted after 90 days at the latest.
In addition to these logs, some servers and services also write log files that log every single page view. The time of the view, the IP address, the URL accessed and other data transmitted by the browser are then stored in these files.
These log files are used to evaluate improper use, such as attacks on our infrastructure, and are deleted after 7 days at the latest.
Rating:
They don't store logs of any kind.
Server: ejabberd 20.07
SASL mechanism(s): PLAIN, SCRAM-SHA-1, X-OAUTH2
Gajim chose SCRAM-SHA-1
Their privacy policy is outlined on their front page.
Crime.io is an XMPP (jabber) service securely designed for business users with high discresionary requirements. Our services are hosted in a privacy-first facility with strict laws against government interference.
More information on xmpp can be found at: xmpp.org
For the best experience with our service, make sure to use OTR encryption and select a strong password so your account can not be hijacked.
Logging is never allowed. Trust is the cornerstone of smooth business transactions
A: We will NEVER store logs of any kind, including session, connection, and conversations
B: LE requests are pointless (as we do not keep any information) and will be posted for full transparency
They can compel you to begin logging a user's communications.
C: Account passwords can be reset if you include a recovery email address during registration
D: LE requests will be posted for full transparency
Rating:
They say that logs older than 6 months are deleted. What are contained in those logs? They say that IP addresses are not logged, but they could still be logging metadata like connection timestamps, bytes sent/received from the server, messages sent and received from specific individuals, etc.
They have blacklisted Tor exit nodes from registration.
XMPP web browser client. They run their own XMPP server.
Their privacy policy is outlined on their front page. Here is the only relevant segment of it:
Our XMPP server runs in a Hetzner data centre in Strasbourg, France.
Your chat messages are archived for a period of 1 month, after which they are deleted.
Currently the conversejs.org XMPP server does not support HTTP-file upload (although Converse the client does), which means that we don't host any uploaded files of users.
During normal operations we don't log or process IP addresses, although it might be necessary in certain cases where a problem needs to be debugged (hasn't happened yet). Logs older than 6 months are deleted.
Rating: L?,
I don't think this is intended to be a public server.
Rating:
Their registration page depends upon javascript. Additionally, a "verification email" is necessary. This is the one thing I absolutely despise about disroot. Thankfully, you can get away with using a disposable email e.g guerillamail.com, cs.email.
Server logs containing IP addresses, and probably metadata as well, are deleted after 24 hours.
Server: Prosody trunk nightly build 1902 (2024-07-11, 05f028de4c45)
SASL mechanism(s): PLAIN
I asked some admins if they stored passwords in hashed form. They said they do, but did not want to disclose the algorithm they use. I asked them to reconsider, maybe they will some day in the future.
Excerpts from their privacy policy:
Definitions used on this Privacy Statement:
- Data: According to the GDPR, data is any information that can be used to identify a person, either directly (real name, phone number, IP address, etc.) or indirectly (any combination of the aforementioned plus device fingerprints, cookies, etc.). In the specific context of the use of our platform, it is the minimum information required for the proper operation of the services provided by Disroot.org as well as the information the user optionally submits on any of them.
- Services: the set of different software, protocols and standards used to exchange data between web applications.
- User or you: any person or third party that access and uses the services provided by Disroot.org.
- Platform: the set of services provided by Disroot.org and that are hosted on our servers.
- Disroot credentials: they are the username and password created and used by the user to log in to the services provided by us.
- Federated services: services that operate on the basis of so-called federation protocols which enable users who signed up at different services providers to interact with each other. Examples of these services are Nextcloud, Email, Akkoma and XMPP.
- Brute-force attack: is a cryptographic attack that consists of submitting many passwords or passphrases, hoping to eventually find the right ones.
The Data covered by this Privacy Statement
This Privacy Statement applies to all services hosted on Disroot.org and its sub-domains.
1. What data do we collect?
If a user chooses to use any of the services provided by us, the following data will be required and therefore collected by Disroot.org:
- A valid email address: required for account creation. This email address is deleted from our database after the account has been approved/denied, unless the user chooses during the registration process, to keep it for password reset process.
- An username and a password: required to identify the account holder and provide the services offered by Disroot.org.
- Necessary information related to the operation and functioning of the services which may include, for example, IP address, User Agent, etc. More detailed information about this and how we handle it can be found in the Privacy notices per service.
- When a user makes an online donation to Disroot.org, we collect personal data such as, but not limited to, username (if any), country (in case of extra storage request for tax purposes), transaction IDs or bank account/reference. The purpose for which we use this data is merely administrative (verification of regular donations, accounting management) and is maintained under the same security measures described in the "How do we store your data?" section. Since all the data we collect is previously processed by a third-party payment processor such as PayPal, Patreon or Liberapay, by using these or similar services, their use of your information is based on their terms of service and policies, not ours, so we encourage you to review those policies carefully.
- Any additional information that the user chooses to supply while using the services provided by us (whether it is chats, posts, emails, etc.). This additional information is optional and with the user's consent.
1.1. What do we do with your data?
- Our processing of your information is limited to providing the service.
- We store logs of your activity for a period no longer than 24 hours (unless specified otherwise per service). This data is used to help diagnose software issues, maintain security of the system against intrusion and monitor the health of the platform.
1.2. How do we store your data?
To protect your data we use the following security measures:
- We use disk encryption on all servers to prevent data leak in case the servers are stolen, confiscated or in any way physically tampered with.
- We provide and require SSL/TLS encryption on all "user-to-server" and "server-to-server" communications on all provided services.
- We utilize "end-to-end" and/or "server-side" encryption technologies whenever it is made available by services that allow it to provide maximum security for the users.
3. Where the data is stored?
We store all data in our own servers, located in a data center in the Netherlands.
4. Detailed privacy notices per service
I will check the services other than XMPP to see if they do anything horrible, and only quote them if they do.
4.3. - Disroot XMPP Chat
- This service requires login with Disroot credentials.
- The roster (your XMPP contact list) is stored on the server's database.
- Chat history is stored on the server in the same form as on the chat itself, meaning unencrypted chat is stored in plain-text and encrypted chat is stored encrypted. Additionally, the chat history, if not specified by the user on per chatroom basis, is stored on the server for a period of 1 month. You can decide to not have any history stored on the server per chat.
- Server logs, which store information such as, but not limited to, your IP address and your username are stored for a period of 24 hours after which they are deleted from the server. No backup of log files is created. Logs are kept to prevent brute-force attacks on accounts and to provide quick insight when debugging issues.
- Given that XMPP is a federated protocol, when interacting with users or chat-rooms hosted on third party servers, data is sent to other independently operated and owned servers in the network over which we have no control.
- Files uploaded to the server are stored as is (plain-text or encrypted) for a period of 1 month.
- If using Movim, all the articles and comments published by you on our services are stored on the server. Using the Movim configuration panel you can choose to leave the instance. If you do so, all the data related to your XMPP account will be destroyed.
Rating:
They don't really keep any logs.
Server: Prosody 0.12.4
SASL mechanism(s): SCRAM-SHA-1, PLAIN
Their privacy policy is outlined on their front page:
One of the motives for creating gnu was to build a jabber server that will keep a minimum amount of (meta)data and only the bare minimum that is required for its core functionality, in respect to users privacy.
Data that we do not keep on the server:
Assuming you use E2EE it won't know the contents.
- Connection metadata. Exact time and duration of connection to the server.
- Access logs. Both on the jabber and on the web server that hosts this website.
- Chat data. It may seems obvious, but it is important to note that the server has no knowledge to the chats content.
In order for this service to work, it is necessary to keep these data:
- Users contacts (roster). This ensures that the contact list remains the same for a given account, regardless of which application or device is being used for connection.
- Offline messages. These are incoming messages that are stored in case a user is offline. These messages are automatically deleted once the user gets online.
- We keep a record, on a month basis, for the last time a user is connected to the server. This way we can delete accounts that are inactive for more than a year, so we do not need to keep user data that no longer use our service or have forgotten their password.
Rating:
IPs not logged, except during times of debugging, after which they are wiped. Offline messages are cached for up to 7 days, and wiped after they are received.
The server does not log connection details (metadata assumedly) either.
Their cert is expired. After registering an account with them, I tried to connect with Gajim; I was asked for my password, I entered it; my client warned me of the expired cert, I connected anyway; authentication failed and the server told me to enter my password again, I did, then received the same error. This continued in an infinite loop. Afterwards I tried an unencrypted connection, which also failed.
Passwords stored hashed as SCRAM-SHA-1.
Server: ejabberd 20.07
SASL mechanism(s): PLAIN, SCRAM-SHA-1, X-OAUTH2
Website connects to: fonts.googleapis.com, gstatic.com, fonts.gstatic.com, jquery.com, code.jquery.com, googletagmanager.com.
From their front page:
Secure password storing
Unlike many other Jabber/XMPP servers, we no do not store passwords in plain text but encrypt them using the Blowfish algorithm.
We are a non-profit privacy group founded in Germany with roots in establishing the German Data Protection Laws, and an credible track record in internet security, privacy and liberty.
Our Jabber (XMPP) instance is hosted on our own co-location servers in a highly secure German data center. We don’t log anything.
From their privacy policy:
By registering an account with JabberX and any of its associated global domains, you agree to the following terms:
[...]
You agree that you are aware that the following, possibly identifying information is stored; hashed passwords, mod_offline messages, mod_mam archives, vcards and rosters. We do NOT store user’s IP addresses.
a. The only exception is when debug logs are temporarily enabled to troubleshoot an issue with the server. After the logging is disabled, the log file is wiped.
(Just a clarification if someone needs it) IPs are logged during troubleshooting period.
2. Stored Data
The following information is stored by our servers:
- Jabber ID (JID) – your username and domain (e.g. user@jabberx.com)
- Jabber and Transport passwords (Jabber passwords are stored as hashed SCRAM-SHA-1.
- Roster (your contact list)
Our XMPP servers do not store any chat history. A small buffer is maintained when messages are sent to offline users. This buffer is automatically deleted after 7 days. Once the user reads the messages in their queue, the messages are removed from our servers.
We have absolutely no storage of historical messages or logs of any kind.
The JabberX servers do NOT keep an archive of your chat logs. Unfortunately, this means that your messages will not synchronize to multiple devices. We realize this may be inconvenient but we do not believe in sacrificing security for convenience.
With the exception of offline buffer messages, user chat messages are never retained for any period of time. Offline buffer messages are automatically purged once they are received by the recipient, or automatically after 7 days.
Every file you share with a contact or a group conference will be uploaded and stored for later retrieval by the recipients.
Files you upload in unencrypted group chats are accessible via the web server: they are only "protected" by a long, automatically generated web address. Anyone who has the link can download the file
All uploaded are automatically deleted after 14 days.
3. Data Not being Stored
JabberX does not store the following:
- IP addresses : Our XMPP/Jabber services do not log user connection details or IP address information of any kind. As the only exception, we log IP addresses from failed login attempts in order to protect from brute force attacks.
Also we reserve the right to block specific IP addresses as well as whole IP address ranges that threaten the security or continuity of our services.- Any connection and/or duration times.
- Conversation log
4. Data Security and Data Encryption
All cloud servers operate within either a SOC2 or ISO 27001 certified data centers.
All stored data is encrypted, with the server encryption keys residing in other data centers in different jurisdictions, providing safeguards from being accessed by local law enforcement.
Only TLS 1.2 or greater is permitted for the connection from your Jabber client to any of our jabber servers, as well as for communication between our servers and any other external Jabber servers.
7. Law Enforcement Requests
It is possible that a public court can order us to cooperate with law enforcement agencies to help with a criminal investigation. Such an order is only possible if the supposed criminal offense is punishable by at least a year in prison.
Cooperation means that we would be legally forced to cooperate with law enforcement and provide any and all information related to a specific account, which means handing over any stored data.
JabberX, by design, does not store any data making any and all law enforcement requests completely worthless.
Rating:
IPs and connection times aren't logged. Aside that, they say other information is stored for as little time as possible. It would be nice to know if other metadata is stored, and for how long.
Server: ejabberd 23.10-1~bpo12+1
SASL mechanism(s): PLAIN, SCRAM-SHA-1
Their privacy policy:
Server location is Germany.
What we store
Website:
As always. when using a website or the Internet at large, your IP address will be transmitted and can be logged by the server. Usually the IP address is not stored, but can be used to detect malicious traffic. When the filter systems think they have detected such malicious traffic, it will block the IP address and store that IP address in a database.
Accounts:
- User name and hashed password
- Other profile related data that you enter voluntarily in your XMPP client, eg. mail address or postal address.
- Date of account creation and last login.
Messages
- Offline messages, when someone sent you a message while you were offline.
- Archive. By default we will be keeping an archive of your messages for later retrieval by yourself. This can come in handy if you log in with a new device and want access to your message history and is also required if you want to use the OMEMO encryption with multiple devices. You can opt-out of this by setting your server-side archiving preferences with your XMPP client.
- When you upload files to share with your contacts or a multi-user conference chat it will be stored for later retrieval by the recipients.
Other data
- A list of your contacts (Roster, Buddylist). This list is maintained by you. You decide who goes on that list and who gets deleted.
- Semi public data you are publishing for your contacts to see like your avatar or the OMEMO public keys.
- Other private data your XMPP client might upload like a list of conference bookmarks.
What we don’t store
- Your IP address or any information that could be inferred by that address like your location.
- The time when you login. – Or more general the times when you use our services.
- A correlation between your account and your payment information for longer than it is necessary to fulfil our return policy.
How we handle your data
- Currently all cost of operation is payed by me as a hobby (system administratio) so I simply don’t have to sell or analyse your data in any way.
- If you delete your account all related information will be deleted with it. Including your files and messages.
Rating:
Server: ejabberd 24.7.0
SASL mechanism(s): PLAIN, SCRAM-SHA-1-PLUS, SCRAM-SHA-1
Gajim chose SCRAM-SHA-1
Runs a lot of different services. Last time I read their privacy policy, it sucked. Let's see if it improved:
IP Address
Some applications (Gitea, Mumble, XMPP, and NixNet Mail) collect your IP when you register. At the moment, that information is kept indefinitely. However, I’m working on either completely disabling it or setting something up that will periodically delete stored IP addresses. When I do, this document will be updated accordingly.
How long can it take to change this indefinite storage of IPs? It's been FOUR YEARS that you've been saying this. Is there some Good Will Hunting-esque equation that must be solved in order to fix the logging issue?
Email Address
When you register for a service using an email address, that is obviously collected. You can control whether it’s a real one or not. Even though I can see them for services like Gitea and Mastodon, I don’t care and won’t send you unsolicited mail.
Well, at least fake emails can work.
Browser Fingerprint
[...] As far as I know, nothing collects or uses any of that information.
Usage and storage of collected information
Whatever data is collected is stored on servers I have sole control over and it won’t be shared with any third parties whatsoever.
Exceptions
I do live in the US; I have two servers here, one in Finland, and another in Luxembourg. If, for whatever reason, I’m compelled by law enforcement to give up your email, IP address, or any other information, I will even though I don’t want to. As such, I do whatever I can to make sure I don’t have that information. If I don’t have it, I can’t share it.
If you have the ability to run 18 services concurrently, how is it that you can't disable IP logging? Are you just that preoccupied by running your services, or are you hoarding data for some future use?
Rating:
Their cert is expired. After registering an account with them, I tried to connect with Gajim; I was asked for my password, I entered it; my client warned me of the expired cert, I connected anyway; authentication failed and the server told me to enter my password again, I did, then received the same error. This continued in an infinite loop. Afterwards I tried an unencrypted connection, which also failed.
Server: ejabberd 20.07
SASL mechanism(s): PLAIN, SCRAM-SHA-1, X-OAUTH2
From their front page:
Connection information
Server:
Internet rows.im
Tor coming soon
Tor has been "coming soon" for a year now.
Server is hosted in Germany under strict privacy regulations
Security:
- This is a completely free service to promote privacy. There is no logging of any kind
- Law enforcement requests will be ignored.
- Require SSL/TLS
Rating:
Hosted by Oracle Corporation
Their logs contain metadata like IPs, and JIDs (what those JIDs are linked to isn't clear, but presumably messages). They don't specify how long they retain logs for. It can be anywhere for a week to a few months, depending on the service. There is no service-by-service explanation of how long logs are retained for.
Their web registration uses reCAPTCHA.
I tried in-band registration, but it wouldn't resolve. A year has now passed, and even their website doesn't resolve for me anymore. I can only view their website through Morty, so they must block Tor.
A friend who tried visiting the website through RiseUp VPN experienced the same issue. Their connection wouldn't resolve, but the site wouldn't 403 either. It seems that lightwitch is gaslighting the users of anonymizers.
Excerpts from their privacy policy:
Regarding the use of Disposable E-Mail Addresses to register to the service:
Furthermore you’re NOT entitled to use a DEA [disposable email address] to register to our services, your mail address won’t be stored more than the log rotation time in our mail server.
What is the log rotation?
Throw-away addresses are mainly used for malicious intents and most of these services simply let the messages being web harvested, which is UNACCEPTABLE. Periodically (within the week) we perform checks for registrations done through Throw-away E-Mail providers (which aren’t catched by Metronome’s DSA/Spam filtering system itself), if found, the accounts will be assumed, no matter what, as ToS breaching without the possibility of an appeal.
Logging, data retention:
We do not monitor data content (e.g. message content) passing through our services, only stanza headers are logged and they will contain the jid of the source, the jid of the destination, and other attributes like id and type etc.
Some public multi-user chatrooms which have the “room logging” configuration option explicitly enabled will have the sole groupchat activity logged and exposed via Message Archive Management (XEP-0313) or a web interface, and you will be warned appropriately as mandated by XEP-0045 when you join and able to leave said room or use a client supporting Message Processing Hints (XEP-0334) to prevent your messages from being logged. These logs will be completely deleted in case the logging gets disabled via room configuration.
Users who have explicitly enabled Message Archive Management (XEP-0313) could have upto 100000 sent and received private messages (not MUC) historic recorded on the server, otherwise clients may signal our server to not store messages using Message Processing Hints (XEP-0334), messages are stored unlimitedly until the previously mentioned threshold is reached when that happens the oldest of the messages will get deleted. Metronome also offers a custom protocol to purge the personal archive should the need arise more details can be found here.
When you connect to our xmpp service or use our mail services data like ip address, jabber id or username, mail from/rcpt and subjects are recorded in our logs and will be aggregated along other server data to help with debugging/troubleshooting and eventual abuse tracking/prevention.
How long is this data stored for?
This service offers a HTTP Upload (XEP-0363) component[...] [File uploads] will be expired as new content gets uploaded after two days have passed. They will also be removed on user deletion.
LW.Org will never willingly disclose any personal data pertaining to its users to any third party with the exception of E-Mail which is matched against the NameAPI database to verify that it isn’t a disposable address. Also we don’t require you to provide any information which would make it possible to identificate yourself (Name, Surname, Residence etc.) to register to it, with the exception of the mail address as mentioned above used to send you the verification token to complete the account registration process, which beside syslog/mail logs isn’t retained anywhere and is eventually garbage collected whit the said logs’ rotations (usually from a week to a few months depending on the service).
Alright, so they log stuff across their services for a week to a few months.
The above statement would partially or not apply in case of abuse or ToS breach as every measure deemed necessary will be taken in order to settle the situation and pursue investigations including disclosure of data to middle parties, involved or to be involved parties and/or recognized authorities, etc.
[...]
Passwords are stored into the server in hashed format strengthened by a randomly generated key salt making it way harder for ’em to be decoded or cracked for both xmpp or mail.
Would be nice to have specifics.
The SPIM blocking module uses reCAPTCHA to protect its form from automated solving by bots.
This means the following data will be handed out to Google Services: the requester origin IP address.
To note that the requester origin ip address will be also logged by our systems to troubleshoot and prevent any possible abuse.
Rating: L?,
They control a million different domains, this is one of them.
Server: ejabberd 17.11
SASL mechanism(s): PLAIN
Website connects to: coinpayments.net, google.com, paypalobjects.com, twitter.com, platform.twitter.com, zendesk.com, assets.zendesk.com, google-analytics.com, ssl.google-analytics.com.
Their terms of use doesn't provide much useful information. Here's some quotes from it anyway:
Users undertake to use the XMPP/Jabber services of the Jabbim family in such a way that the operator does not incur damages. In the event of excessive exploitation of the server's resources and its connectivity, the operator will be forced to take such measures (temporarily disconnecting the user, limiting his services or notifying the connection provider of excessive traffic) so that problems do not arise when serving other users. In case of particularly inappropriate and immoral behavior (harassment of other users, promotion of movements suppressing human rights, verbal and physical aggression against administrators, administrators and developers of the server, etc.), the server operator is entitled to take immediate measures to correct the problems. The last measure is to remove the Jabber account from the Jabbim servers. However, you don't have to worry, no one will persecute you for your decent, even if disagreeable, opinion.
This is a list of the most important data processed by XMPP/Jabber servers of the Jabbim family. We generally do not collect any information that you do not provide to us yourself, and we do not disclose such information unless it is intended to be disclosed. The list was inspired by the XSF Privacy and Security Policy.
Jabber ID and password
The data provided during account registration, i.e. username (Jabber ID) and password, are required to log in and authenticate the user. For technical reasons, the password is stored on the server in readable form. However, it is transmitted in unreadable form when logging in, even if no encryption is used. Although we do our best to prevent password disclosure to unauthorized persons, we recommend using a unique password for Jabbim services.
Unfortunately, their website doesn't display their terms of use in English, although there appears to be a button to press to switch it into English, it doesn't work for me for some reason. It's all in Czech. I don't know Czech, nor do I know any Czech speakers, so I've had to use automated translators (Google, LibreTranslate), and make assumptions. They say that they store passwords in "readable" form. I assume by "readable", they mean plaintext. I believe this because of the fact that they say passwords are "transmitted in unreadable form when logging in," what does this refer to if not encryption? The Czech word they used was "čitelné" which translates as "readable", and words derived from the same root as čitelné involve legibility and reading, so it seems that the translation of "čitelné" as "readable" is accurate. I translated "plaintext", which came back as "prostý text" in Czech. In English "readable" and "plaintext" could be deemed to be synonymous, I'm not sure about Czech. Nonetheless, the only logical assumption is that by "readable" they mean that they store passwords in plaintext, and not in encrypted form. Anyway, if I'm off the mark, let me know.
Messages sent offline are stored indefinitely until the user connects. These messages are not encrypted.
If you use OMEMO/OTR/PGP they will be.
Jabbim servers support the Multi-User Chat protocol. Messages from multi-user conferences can be archived. This setting is determined by the room administrator. Newly created rooms are not archived. Messages from the archived room can be found at http://nezmar.jabbim.cz/logs/. If you do not want your messages to be archived, please do not enter these rooms.
Transports to other networks store the data necessary for their operation, i.e. in particular the username and password for the given network. This data is stored in readable form and is not knowingly disclosed to third parties, except to the extent necessary to connect to the given network.
Rating:
From their front page:
Welcome to Neko IM!, a free public XMPP Server running Prosody, currently hosted with Panix in New York. It is administrated by Nulani.
Please contact nulani[at]neko.im via e-mail. Do not forget to include a username.
Privacy: No more information is collected and stored than what is absolutely necessary. Rosters, vcards, and so forth.
I'll give them the benefit of the doubt and assume IP addresses aren't a part of that, or that they're stored for the shortest possible time.
Rating:
There's little indication as to how long logs are stored, but IPs seemingly are only stored in the event of incorrect login attempts. Backups are stored on a daily basis. Presumably they are overwritten each day.
Server: ejabberd 24.7.0
SASL mechanism(s): PLAIN, SCRAM-SHA-1-PLUS, SCRAM-SHA-1
Gajim chose SCRAM-SHA-1
Here are excerpts from their privacy policy:
Accounts will also be deleted if they did not login for 1 year.
I try to reduce the logging of user activities to a reasonable minimum so that the privacy of each user is protected at all times
Only I as the only admin have legitimate access to the server
Stored data
- Date of registration and last login (to detect inactive users)
- Username and password hash
- Profile information and avatar
- IP addresses for incorrect login attempts
- Contacts and MUCs added to the account
- Uploaded files (30 days)
- Message archive (MAM) (can be disabled on your client)
- Offline messages
As per usual, the hash algorithm isn't disclosed.
More information
- Bus Factor: 1
- Operating since: 2021-02-24
- Operator: marzzzello (private)
- Backup info: Daily and encrypted backups stored on a storage server in Finland
- Hosting: Netcup root server in Germany
- OS: NixOS with full disk encryption
- XMPP server: ejabberd
- In-Band registration: Enabled
- http_upload max file size: 5 GiB
- http_upload storage quota: 10 GiB
Rating:
Server: ejabberd 22.5.0
SASL mechanism(s): PLAIN, SCRAM-SHA-1-PLUS, SCRAM-SHA-1, X-OAUTH2
Gajim chose SCRAM-SHA-1
Website connects to: cloudflare.com, cdnjs.cloudflare.com, google.com, fonts.googleapis.com, gstatic.com, fonts.gstatic.com, jquery.com, code.jquery.com, jsdelivr.net, cdn.jsdelivr.net, googletagmanager.com.
Really vague policy. From their front page:
We don't keep logs of any kind. Enjoy your privacy!
Rating:
In the future they may actualize their reserved right to backup data for up to six months. As of this time they don't have the capability, so I won't say there is a potential for it to occur.
They state "Log files including saved IP addresses are deleted after 72 hours at the latest." They do not speak of connection or message metadata, perhaps it is fair to assume it is included in those log files deleted after 72 hours.
Their privacy policy didn't specify if passwords are stored in hashed form, so I asked the admin via email. He said they are stored as SCRAM-SHA, though he didn't state the version it is probably SCRAM-SHA-1 considering that is what they use for SASL. Either way, something is better than nothing.
Server: ejabberd 23.01-1
SASL mechanism(s): PLAIN, SCRAM-SHA-1,
Relevant excerpts from their privacy policy:
We only process our users' personal data to the extent that this is necessary to provide a functional website and our content and services. We do not use analysis software and do not involve third parties (Google Fonts, etc).
When registering and using the XMPP service, the following data is recorded:
- User name
- Password
- IP address of the client
- PEP account information, if set up
- XMPP contacts (XMPP IDs) and associated names
- Messages sent
- Online status (status, time of last change)
- File uploads
- Technical information about the client used (supported (protocol/) versions)
- Time of last login / logout
The IP address is only stored in a log file if login attempts fail and is not logged during normal operation. Long-term logging of messages is deactivated by default. Message logging (MAM) can be permanently switched on via a client function so that the messages are not only stored temporarily for transmission purposes.
Log files including stored IP addresses are deleted after 72 hours at the latest, message logs (MAM) and file uploads after 2 weeks.
The user can have the data recorded for their personal XMPP account deleted at any time upon request (client side). Further use of the service may then no longer be possible for technical reasons. An objection regarding the collection and use within the scope of the service is generally not possible, as the service offered cannot otherwise be provided.
The user agrees that by commissioning the following companies to provide services, data will be passed on to them:
- Hetzner.de: Server hosting. All data that arises from offering servers and the anoxinon.de website is stored on server systems of Hetzner Online GMBH. The company is responsible for the company: Hetzner Online GmbH, Industriestr. 25, 91710 Gunzenhausen, Germany.
The personal data of the person concerned will be deleted or blocked as soon as the purpose of storage no longer applies. Storage can also take place if this has been provided for by the legislator. The data will then be blocked or deleted when the prescribed storage period expires. It is possible that there is still a need to further store the data for the conclusion or fulfillment of a contract.
The operator of the service reserves the right to keep all data stored by the server in the form of backups on external systems for up to six months. (Note: We are currently not using this framework and will announce the exact period here after evaluation)
Rating: L?,
Website connects to: cloudflare.com, cdnjs.cloudflare.com, google.com, fonts.googleapis.com, gstatic.com, fonts.gstatic.com, jquery.com, code.jquery.com, jsdelivr.net, cdn.jsdelivr.net, googletagmanager.com.
Web registration failed. In-band registration worked.
Their cert is expired. After registering an account with them, I tried to connect with Gajim; I was asked for my password, I entered it; my client warned me of the expired cert, I connected anyway; authentication failed and the server told me to enter my password again, I did, then received the same error. This continued in an infinite loop. Afterwards I tried an unencrypted connection, which also failed.
Privacy policy webpage 404s.
Rating: L1?,
During times of troubleshooting, IPs can be logged. It's not stated how long they are stored for. They do say that they will not "evaluate" IPs. Backups are made regularly and kept for "a few days".
Tor IPs blacklisted from in-band registration
From their privacy policy:
In principle, the server stores the following data:
- The Jabber ID (JID) consisting of username and domain to identify the user account.
- The password for the Jabber account for identification when logging in the Jabber client to the server (stored encrypted!).
- The user's Contacts stored in the lineup along with the information about which direction (s) the visibility exists with that contact. This is saved so that you can log in from different clients and always have the same contacts.
- Date and time when the user account was created and when it was last used. This is done so that unused user accounts can be automatically deleted.
- While the user is not logged in, incoming messages addressed to him are cached so they can be delivered to him the next time he logs on. These messages also record when they arrived.
- In the case of server problems / troubleshooting we can view IP addresses, but these are neither forwarded to users nor evaluated.
- In case of delivery errors a message is saved by whom the message went to and why the delivery did not work. But not the content of the message. This is necessary in order to be able to determine a problem with accumulated errors.
- If your client uses XEP-0363: HTTP File Upload , uploads to the server will be delayed for max. 10 days deleted. Please note that some clients only store this data unencrypted on the server!
- If XEP-0313 MAM Through the user, the server stores message content for 1 month. The entertainment recordings are then automatically deleted. By default, MAM is not active and must be explicitly enabled by the user or the XMPP client being used!
When using gateways / transports, these transitions store more data:
- Network transitions to other IM systems store the username and the password for the foreign IM system.
- Network transitions to other IM systems write a log when which Jabber ID was used to establish which user identity in a foreign IM system
It is also possible for the Jabber client to save data to the server. This data can either be stored by the Jabber client so that it can be queried by other Jabber users (e.g., vCards containing contact information) or so that only the user of the account can retrieve the data (e.g. Configuration settings of a Jabber client). What data, to what extent and for how long are stored so is the Jabber client.
Of all the above data, backups (backup copies) are made regularly and kept for a few days. In this backup, actually deleted data may persist for a few more days.
[...]
The data stored about a user will not be used commercially. They will not be sold or shared with third parties. No advertising is sent to the users of this service, not even in their own right.
[...]
From the collected data statistics about usage and usage of the server are obtained. These statistics are created anonymously; a conclusion on individuals is not possible from these statistics.
They have to retain server data long enough to create statistics. Depending on the size of their server, maybe that could take around two weeks. It's really not possible for me to say. That data also has to have been attributable to specific people, seeing as it must be "anonymized". Could IP addresses, and other metadata be in there?
Rating:
Website connects to: fonts.googleapis.com, gstatic.com, fonts.gstatic.com
Logs retained for two weeks. They also create backups, which are overwritten on a daily basis.
Their privacy policy:
For Teftera.com XMPP accounts:
- Your username, a hash of your password and related data (vcard, profile picture)
- Your email, if provided, to allow you to recover your password
- Articles All the articles and comments published by you on our services
- Messages All the messages sent to and from your contacts, or from the chatrooms you are connected to. You can configure message storage using the Movim configuration panel.
- Files All the pictures and files uploaded using your account.
- Contacts Your contact list (XMPP Roster)
- All the data published by Movim or other XMPP clients you are using on your XMPP account (OMEMO public keys, bookmarks.)
All the data above are stored as long as we can on our services until you destroy your account, see Withdrawal.
For XMPP accounts using our Teftera.com public Movim instance:
- Your username, an encrypted version of your password (the key is sent back to your browser, this allow Movim to quickly log-you back in)
- Articles A cache of all the articles published by you on our services and other XMPP services you accessed
- Messages A cache of the messages published and received by you or your contacts or from the chatrooms you are connected to
- Files A cache of the pictures accessed using your account
- Contacts Your contact list (XMPP Roster)
- A cache of all the data published by Movim or other XMPP clients you are using on your XMPP account (OMEMO public keys, bookmarks.)
All the data above are stored as long as we can on our services. Using the Movim configuration panel you can choose to leave the instance. If you do so, all the data related to your XMPP account will be destroyed.
To operate our services we are also storing some amount of logs and related data, those logs are rotated daily and destroyed using the following rules:
- ejabberd (our XMPP server): 14 days, errors and general info (failed connections, security errors)
- nginx (our Web server): 14 days, errors and pages accessed (containing your IP and browser User-Agent)
- A global backup of our main databases (XMPP and Movim) is done daily on a local self-hosted server in Bulgaria. This backup is refreshed each night and is only used for restoration purposes
Some limits also apply to our services:
- File Upload is limited to 10MB per file. There is no other limit (total volume or time) regarding the storage of those files
- XMPP and HTTP connections we have some connection limitations in place, both on our XMPP services and web services to limit the bandwidth and amount of requests per user
- XMPP registration also known as "In-band registration" is disabled on our services. To register an account you must use our Registration page
Rating:
IPs, and account login/logout timestamps are not stored. Messages cached for up to a week.
Website connects to: google.com, fonts.googleapis.com, gstatic.com, fonts.gstatic.com, jquery.com, code.jquery.com, googletagmanager.com.
Server: ejabberd 22.5.0
SASL mechanism(s): PLAIN, SCRAM-SHA-1-PLUS, SCRAM-SHA-1, X-OAUTH2, SCRAM-SHA-1
Gajim chose SCRAM-SHA-1
Their privacy policy:
Our general policy regarding your data is to save as much and as little as possible. In this document, we will try to explain what personal data we store and how we handle it.
We do not save:
- Your IP address or any information that can be obtained from this address, such as your location.
- Login time. - Or, more generally, the time you use our services.
- The connection between your account and your payment information longer than is necessary to fulfill our refund policy.
How we work privately
Our servers are located in Ukraine and are hosted by Ukraine Host.
If someone sends you a message when you are offline, that message will be stored until you reconnect to the network. Messages are stored for 7 days.
All account data is hashed and encrypted on our server.
With what?
While we never view the contents of your messages or files or process them automatically, we strongly encourage you to use OMEMO encryption whenever possible.
Rating:
Backups made daily and stored for a month.
Passwords stored hashed as SCRAM-SHA-1.
They have a warrant canary.
Here's excerpts from their privacy policy:
Overview of user's data
- JID.
- SCRAM-SHA1 hashed password, used to authenticate clients.
- Registration and last login timestamp, used to purge unused accounts after 3 months of inactivity.
- User's contact list and subscriptions.
- Offline messages and MAM.
- User's vcard; it might contain a profile picture and other user configured information.
Data processed
- IP addresses are not stored by default, however might be retained for as long as 1 hour to prevent bruteforce attacks.
- Messages might be stored for as long as 24 hours on the server to provide cross device synchronization.
- Messages might be stored on the server in case the recipient is offline, messages are deleted after being delivered or in any case after 7 days.
- Files uploaded via the http_upload module are stored on the server for as long as 24 hours.
- [...]
- If we are required to cooperate with LEA, it will be done in accordance with the applicable laws.
Backups
Backups are taken daily and are stored encrypted on a remote location for 1 month.
Rating: L?,
Uses reCAPTCHA. In-band registration not permitted.
Their privacy policy.
Privacy Policy
We hold user account, roster, connection information for our service.
We will not disclose these information, and we will not do any other behavior that would compromise your privacy and security, except as otherwise requested by domestic law of Japan.
User profile information(vcard) is intended to be published. Therefore, it will be publish.
MUC conversation will be publish by default. If you are admin of MUC room and you don't want to publish MUC conversation, please change room configration(logging: off)
Rating:
XMPP server retains "errors and general info (failed connections, security errors)" for 14 days. Their web server retains errors and pages accesses containing IPs and browser user agents for 14 days.
Uses hCaptcha, in-band registration not permitted. Backups overwritten on daily basis.
Server: ejabberd 24.7.0
SASL mechanism(s): PLAIN, SCRAM-SHA-1, X-OAUTH2
Gajim chose SCRAM-SHA-1
Excerpts from their privacy policy:
[The term:] Our services is used to designate the following services:
Hosted in Germany at netcup GmbH
- The movim.eu and jappix.com XMPP service and related services
- The mov.im Movim instance
Hosted in France on a personal self-hosted server
- The XMPP services and Movim instance database backups
Laws
Our services are stored in Germany and France. For the correspondig data hosted in each country, the French and German juridiction applies.
All our services are hosted in the European Union, therefore the GDPR applies to all the data we are managing.
Privacy Policy
What we store
For movim.eu and jappix.com XMPP accounts:
- Your username, a hash of your password and related data (vcard, profile picture)
Which algorithm?
- Your email, if provided, to allow you to recover your password
- Articles All the articles and comments published by you on our services
- Messages All the messages sent to and from your contacts, or from the chatrooms you are connected to. You can configure message storage using the Movim configuration panel.
- Files All the pictures and files uploaded using your account.
- Contacts Your contact list (XMPP Roster)
- All the data published by Movim or other XMPP clients you are using on your XMPP account (OMEMO public keys, bookmarks.)
All the data above are stored as long as we can on our services until you destroy your account, see Withdrawal.
For XMPP accounts using our mov.im public Movim instance:
- Your username, an encrypted version of your password (the key is sent back to your browser, this allow Movim to quickly log-you back in)
- Articles A cache of all the articles published by you on our services and other XMPP services you accessed
- Messages A cache of the messages published and received by you or your contacts or from the chatrooms you are connected to
- Files A cache of the pictures accessed using your account
- Contacts Your contact list (XMPP Roster)
- A cache of all the data published by Movim or other XMPP clients you are using on your XMPP account (OMEMO public keys, bookmarks.)
All the data above are stored as long as we can on our services. Using the Movim configuration panel you can choose to leave the instance. If you do so, all the data related to your XMPP account will be destroyed.
To operate our services we are also storing some amount of logs and related data, those logs are rotated daily and destroyed using the following rules:
- ejabberd (our XMPP server): 14 days, errors and general info (failed connections, security errors)
- nginx (our Web server): 14 days, errors and pages accessed (containing your IP and browser User-Agent)
- A global backup of our main databases (XMPP and Movim) is done daily on a local self-hosted server in France. This backup is refreshed each night and is only used for restoration purposes
Rating:
They do log IPs at their account registration page for 31 days, but beyond that, they don't log IPs.
Date and time account was created and last used is stored. Offline messages are cached for up to 31 days until you log in, then they are wiped. In the event of message delivery errors, message metadata will be saved.
Passwords stored hashed as SCRAM-SHA-1.
Server: Openfire 4.2.1
SASL mechanism(s): PLAIN, SCRAM-SHA-1, PADE, CRAM-MD5, DIGEST-MD5, JIVE-SHAREDSECRET
Gajim chose SCRAM-SHA-1
Here's the relevant chunks from their privacy policy, translated into English of course:
The Jabber service does not store any regular connection information. This means that we will never be able to tell from a retrospective perspective which one you were connecting to. The web server hosting this site (and for example http://jabber.sytes24.pl) stores access logs (in the standard Apache log format) that are kept for a maximum of four weeks. This includes access to HTTP-based Jabber services, e.g. network presence and any connections to BOSH e.g. http://jabber.sytes24.pl/chat.html
By default, the server stores the following data about you:
- Jabber identifier (jid), consisting of username and domain, used to identify the account.
- SCRAM-SHA1 hash of your account password for authorization purposes when your client connects to the server.
- Saved user contacts and visibility information between this account and your contacts. This ensures that your friends list will be the same, no matter which client you use.
- The date and time your account was created and the last time you used it. We use this data to periodically purge unused accounts. “Offline messages” (i.e. messages sent to you while offline) are stored until you log in again (but only for up to 31 days) along with the time the message was sent. If there is an error in delivering a message, we save a log entry that shows who sent the message to whom, when, and why not. The actual content of the message is not part of this log. We only need the metadata to determine the source of the problem when something goes wrong.
- Our account registration page at http://jabber.sytes24.pl/rejestracja/ stores the IP address used to register the account for 31 days to help detect automated registrations.
- If your client uses XEP-0313: Message Archive Management, your chat messages are stored for 21 days.
- If your client uses XEP-0363: HTTP file upload, uploaded files are stored for up to 31 days. Note that some clients only store an encrypted version of the file.
- The most important thing is that the jabber.sytes24.pl server has disabled archiving of conversations or public chats. Only messages sent in offline mode [will be stored], as mentioned earlier.
Poland currently has no data retention laws. It would be illegal to retain data for longer than necessary to run this service. In Poland, a court can order us to cooperate with law enforcement to help with a criminal investigation. Such an order is only possible if the alleged crime is punishable by at least one year in prison. Such an order is always valid only for individual accounts and must have a set time limit. Cooperation usually means that we have to hand over any data we hold, as well as start recording the connection from that point (including all messages sent to and from the user from that point on) and pass on this data as well. In the event of such an order, I am legally compelled to cooperate with law enforcement and provide any information requested by the court order. Unfortunately, it is prohibited by law to inform such a person under surveillance. This of course means that in the event of such a court order, we will comply with the requirements, even if we do not like it. None of us wants to go to jail for an anonymous account. Of course, regardless of the legal situation, it is recommended to use OTR, GPG or any other technology for end-to-end encryption. To tell you the truth, I have not yet encountered such a court order
Well, if you got one, you might not be able to tell us for a long time.
Rating: L?,
Server: ejabberd 23.10
SASL mechanism(s): PLAIN, SCRAM-SHA-1, X-OAUTH2
Gajim chose SCRAM-SHA-1
No privacy policy, but supports in-band registration.
Rating: L?,R?
In-band registration redirects to a web-registration page, which 404s.
Rating: L?,
In-band registration disabled. Uses hCaptcha. No privacy policy.
Server: Prosody trunk nightly build 1900 (2024-06-18, 3e6d5738ea09)
SASL mechanism(s): SCRAM-SHA-1, PLAIN, OAUTHBEARER
Gajim chose SCRAM-SHA-1
Rating:
In-band registration successful.
Server: ejabberd 23.10
SASL mechanism(s): PLAIN, SCRAM-SHA-1, X-OAUTH2
Gajim chose SCRAM-SHA-1
From their privacy policy:
Websites
We do not use external services like GoogleAnalytics, external fonts or GoogleMaps.
From your Website request is only saved:
- Address Family: IPv4 or IPv6
- Requested Domain: e.g. chat.sum7.eu
- Duration of delivery: How long a request take time (in histogram cumulated in buckets)
We excuse us, but we think it is necessary for enhanced the delivery of your webserver.
Chat (XMPP)
For easy use, there is Message Archiving enabled by default. Hopefully you use OMEMO or you should disable MAM. Otherwise your messages are stored plain on this server for other clients.
HTTP-Uploads are stored for 7 days before it will be deleted automatically. Accounts after 1 year unused will be deleted.
Everthing else
We delete every week the Logfiles and try to configurate each application log just error messages.
Rating: L?,
Uses reCapcha.
They translated their site into 19 languages, yet they can't bother to have a privacy policy.
Server: ejabberd 19.09.1
SASL mechanism(s): PLAIN, SCRAM-SHA-1, X-OAUTH2
Gajim chose SCRAM-SHA-1
Rating: L?,R?
Registration page 404s.
Website connects to: facebook.net, connect.facebook.net, wp.com, stats.wp.com, googlesyndication.com, pagead2.googlesyndication.com, googletagmanager.com
Rating: L?,
In-band registration successful.
Server: ejabberd 24.7.0
SASL mechanism(s): PLAIN, SCRAM-SHA-512, SCRAM-SHA-256, SCRAM-SHA-1, X-OAUTH2, SCRAM-SHA-512
Gajim chose SCRAM-SHA-512
Website connects to: fonts.googleapis.com, gstatic.com, fonts.gstatic.com
Rating:
jix.IM is a free, stable and secure XMPP server made with thought to be one of the best servers in the entire decentralized XMPP network.
I doubt it.
Registration uses reCAPTCHA and requires an email account. Email must be verified. After verifying my account, I still could not log in.
Backups are made every four hours, and stored for 14 days at remote location.
Webserver logs IPs and web browser information for 30 days, but the XMPP server does not log connection information.
Messages are cached until you log in.
Their privacy policy did not state how passwords are stored, whether or not they are hashed, so I asked the admin. Passwords stored hashed as SCRAM-SHA-1.
Server: ejabberd 24.2.0
Could not log in to my account after registering. Tor might be blocked.
Website connects to: fonts.googleapis.com, google.com, googletagmanager.com, gstatic.com
From their privacy policy
What data is collected?
Connection information
Connection Information is about your connection to this service and what you do from where. When you use the XMPP server or this website, your IP address will be transmitted and can be logged by the server:
- IP address can be used to detect malicious traffic. When the filter systems determine that they have detected such malicious traffic, they will block the IP address and store it in the database for a period of time until the traffic is unblocked.
- The XMPP service itself does not store any connection information.
- The web server that serves this website collects standard access logs (including the IP address and information about the used browser) that are stored for up to 30 days.
Website related information
This website sends and collects information using these third-party sources:
- Google Analytics – a tool provided by Google for analyzing website statistics. IP addresses are anonymized when data is transmitted to Google.
How can you know that, when the code is proprietary? Google Analytics is a backdoor into your server, to feed Google your network logs. Your users can be deanonymized.
- Google reCAPTCHA – a tool provided by Google that protects websites from spam and abuse by using advanced risk analysis techniques to tell humans and bots apart. Used on this website to protect all forms.
- MailCheck.ai – a service used to prevent users to sign up with temporary email addresses. In order to protect personal data, only the domain name from the e-mail address is transmitted to this service.
So that's why I couldn't use a disposable email.
- Akismet – a spam fighting service that checks contact form submissions.
Account information
The following data directly related to your account is stored:
- The Jabber ID (JID), consisting of username and domain, used for identifying your account.
- Your email address to enable you to reset your password in case you lose it.
- The SCRAM-SHA1 hash of the password to your account to authorize login.
- Date of account creation and when your account was last used. This data is used to periodically delete unused accounts.
XMPP related information
An XMPP client can send data to the server, and whether this data will be available to others or only to you is entirely up to you or the settings of the XMPP client you are using.
The server may store the following data:
- Account related data that you can voluntarily provide in your XMPP client, e.g. home address or phone number.
- A list of your contacts (often called as “roster” or “buddies”) and information about the visibility between your account and those contacts. This list is managed by you, you decide who gets on this list and who gets removed.
- Offline messages, when someone sent you a message while you were offline, are stored until you log in again.
- Message Archive, which is disabled by default and to enable it, you need to change server-side archiving preferences with your XMPP client. This can come in handy if you are logging in with a new device and want access to your message history and is also required if you want to use the OMEMO encryption with multiple devices.
- If your XMPP client uses XEP-0363: HTTP File Upload, your file uploads are stored on the server. It is useful when you want to share files with your contacts or a multi-user conference chat for later retrieval by the recipients.
- Semi-public data that you are publishing for your contacts, such as your avatar or the OMEMO public keys.
- Other private data that your XMPP client might upload, such as a list of conference bookmarks.
[...]
Statistics about the server load are created from the collected data. These statistics are anonymous and information about individual persons cannot be obtained from them.
Backups
Every four hours, an encrypted backup of the XMPP server data is performed to a remote location. Backups are kept for 14 days.
Notes
This server is subject to the laws and regulations of the Republic of Poland and the European Union.
Rating: L?,
Registration page depends upon javascript, and demands an email account which must be verified. Does not accept disposable emails.
No privacy policy.
Their about page says you can register via client, but I cannot connect with mine.
There doesn't seem to be a privacy policy anywhere.
Website connects to: fonts.googleapis.com, gstatic.com, fonts.gstatic.com, youtube.com
Rating: L1?,
Registration depends upon javascript, and requires an email account, which must be verified. Disposable emails work.
Server: Prosody 0.12.3
SASL mechanism(s): PLAIN
Excerpts from their privacy policy:
The monocles search which is based on a highly modified open source meta search eninge and the monocles translator does not log or save any data or information of users. This includes no logging of the IP. If you change the default settings the search engine only saves information for this settings and only locally on your devices. We will never know what you've set, searched or translated. But we are not responsible for the sites and the sites contents which are linked in the search results.
Terms of use
The monocles services are available or to purchase from 18 years of age, but they are excluded if the services are used for illegal purposes or if server operation is disturbed, for example, by excessively high traffic or by too many connection attempts per second etc. If someone disregards these rules, their account and/or the IP address will be blocked as soon as possible. In DoS attacks and the like, the attacker's ISP is informed. Accounts whose registration has been initiated but not paid within a period of 7 days will be deleted unannounced after this period. In addition, we do not accept or delete accounts with brand names or inappropriate names.
They have some information about their backups here.
The monocles project is online since the 28th february 2018. The locked monocles server rack is standing in Germany. Only the four admins, who can each individually maintain the operation of the system in case one fails, can have access to the servers with a key, a long password and a TOTP code. Additionally the server is fully encrypted to avoid any intruders to get access to your files. Even the end-to-end encrypted files and messages are fully encrypted. We make automatic backups every 3 hours and seperated backups every 7 days. The seperated backups are stored outside the servers building in a fireproof safe.
It's unclear how long the backups are stored for.
Rating:
No logs
Server: ejabberd 20.07
SASL mechanism(s): PLAIN, SCRAM-SHA-1, X-OAUTH2
Their cert is expired. After registering an account with them, I tried to connect with Gajim; I was asked for my password, I entered it; my client warned me of the expired cert, I connected anyway; authentication failed and the server told me to enter my password again, I did, then received the same error. This continued in an infinite loop. Afterwards I tried an unencrypted connection, which also failed.
Website connects to: bootstrapcdn.com, maxcdn.bootstrapcdn.com, fonts.googleapis.com, gstatic.com, fonts.gstatic.com
Their privacy policy is outlined on their front page:
We only store data that is needed to provide you with a functioning Jabber/XMPP service.
User passwords are stored in hashed with BCrypt.
We do not collect or store logs of ANY kind
Data Retention
This is completely anonymous service by design.
OG.im is hosted in Austria, which has no data retention laws.
It would be illegal for us to retain data longer then necessary for running this service.
IMPORTANT: It is possible that a court may require us to cooperate with law enforcement
ONLY if the crime is punishable IN AUSTRIA for a period of longer than 1 year.
Cooperation means that we will have to "hand over" any stored data, including conversation and sessions logs pertaining to the users in question.
In these cases, it will not matter because we do not store any of this information!
Not if they compel you to begin logging data on a user, and they don't use Tor and OMEMO.
Rating: L?,
Uses Amazon AWS for hosting.
In-band registration successful. It asks for a "real email". I gave a fake one without issue. Be prepared for them to verify your email address after registration, because I did not bother to see if this would occur. Later I re-registered with a real one.
sure.im is controlled by Tigase, and is one of several domains Tigase owns. Some of their other domains do not support in-band registration. Overall, this seems like a messaging service intended for people who know each other in real life to communicate with. It seems to cater towards social media-users. Not a server I would use.
Server: Tigase 8.4.0-SNAPSHOT-b12539/3d39e2f1
SASL mechanism(s): PLAIN
Excerpts from their privacy policy::
2. Collection of Information
"Personal Information" is personally identifiable information such as your name, address, telephone number and e-mail address and any other non-public information about you that is associated with or linked to any of the foregoing information. We collect Personal Information from you on our Site and when you use Tigase Messenger as described below.
2.1 Accounts.
We will ask you to provide your first and last name and email address, and to choose a user name and password when you register for an account on Tigase. After downloading Tigase Messenger you will also be asked to verify your account via email.
2.4 Messages.
Tigase Messenger may be used to send messages between users. If you send a message to one or more other user(s), we will retain the message sender and recipient data (but not the message) and associate it with your Tigase user name. We will delete the message promptly after the message has been delivered to the intended recipient(s). If the message is not delivered, we may retain it on our system.
2.10 Information Collected Via Technology.
To make our Site and Tigase Messenger more useful to you, our servers (which may be hosted by a third party service provider) collect information about you and your mobile device and such information may be associated with your Tigase username. Such information may include what type of device you have, if you have an iphone, your iphone device IDs and push tokens, if you have an android device, a generated android device id internal to Tigase Mesenger, Internet Protocol (IP) address of the tcp connection for each authentication request the date/time stamp for various Tigase Messenger activities, and other similar diagnostic logs. We may also use Cookies (as defined below) and navigational data like Uniform Resource Locators (URL) to gather information regarding the date and time of your visit and the solutions and information for which you searched and which you viewed. Cookies are small pieces of information that a website sends to your computer or smart phone while you are viewing a web site. We may use both session Cookies (which expire once you close your web browser) and persistent Cookies (which stay on your computer until you delete them) to provide you with a more personal and interactive experience on our Site. Persistent Cookies can be removed by following Internet browser help file directions. If you choose to disable Cookies, some areas of our Site may not work properly. Like most companies, we automatically gather the information described above (Technology Data) and store it in log files each time you visit our Site or use the Tigase Messenger.
3. Use of Information
3.1 Generally, we collect, store, use and disclose information to enable us to provide the Site and Tigase Messenger, create your account, identify you as a user, respond to your inquiries and emails, improve the Site and Tigase Messenger, send you administrative and service related communications, and send you newsletters, surveys, offers, and other promotional materials. Except as set out in this Privacy Policy, your Personal Information will not be used for any other purpose without informing you first by updating this Privacy Policy. See further Amendment of this Policy.
3.3 Anonymous aggregate statistics that do not personally identify a Tigase user will be kept and used by us for various purposes including analysis and reporting of usage patterns. Tigase reserves the right to use and disclose anonymous aggregate statistics for any purpose and to any third party in its sole discretion.
4. Disclosures & Transfers
4.1 Our servers are located in the United States, Canada and Europe and as such your Personal Information may be available to the U.S., Canadian and European government or its agencies under a lawful order made in that country, irrespective of the safeguards we have put in place for the protection of your Personal Information.
4.2 From time to time we may employ third parties to help us provide or improve our Site and Tigase Messenger. These third parties may have limited access to databases of Site user information or registered member information solely for the purpose of helping us provide or improve the Site and Tigase Messenger and they will not be able to use the information about our members or visitors for any other purpose.
4.3 We may disclose Personal Information in some other limited circumstances, but we will specifically describe them to you when we collect the information, such as in the terms of use for a new service or by revising this Privacy Policy.
4.4 We may, and you hereby authorize us to, disclose your Personal Information (including messages) to a third party without your consent: (a) if we have reason to believe that disclosing this information is necessary to identify, contact or bring legal action against someone who may be causing injury to or interference with (either intentionally or unintentionally) our rights or property, other website users, or anyone else (including the rights or property of anyone else) that could be harmed by such activities, (b) in connection with any legal investigation, and/or (c) when we believe in good faith that such disclosure is required by and in accordance with the law or to respond to subpoenas or warrants served on Tigase.
When you "believe in good faith" that such disclosure is required by and in accordance with the law? So, you might give out information when doing such is unnecessary, but you believed "in good faith" that it was? What does this "good faith" belief consist of?
4.5 We may also disclose your Personal Information in connection with a corporate re-organization, a merger or acquisition with another entity, or a sale of all or a substantial portion of our assets or stock provided that the information disclosed continues to be used for the purposes permitted by this Privacy Policy by the entity acquiring the information. Although we currently do not have a parent company, any subsidiaries, joint ventures, or other companies under a common control (collectively, Affiliates), we may in the future. We may share some or all of your Personal Information with these Affiliates, in which case we will require our Affiliates to honor this Privacy Policy.
It's not as if those affiliates would suffer anything more than a slap on the wrist if they decided to not honor your privacy policy. This strikes me as something they have left here to indemnify themselves should they sell their users out to Big Tech.
Rating: L?,
Server: ejabberd 21.01-2
SASL mechanism(s): PLAIN, SCRAM-SHA-1
In-band registration worked. No privacy policy.
Rating:
IPs and date and time of login stored for 48 hours.
Server: Prosody hg:ae65f199f408
SASL mechanism(s): OAUTHBEARER, PLAIN, SCRAM-SHA-1
Gajim chose SCRAM-SHA-1
IPs and date and time of login won't be backed up. From their policy:
JabberFR also reserves the right to terminate your account if you do not log in to your account for a period exceeding 6 months.
Personal data
Like other online services, JabberFR automatically records certain information necessary for your use of the service (example: contact list), as well as other information that can identify you (example: IP address, date and time of access), the latter is kept for a maximum of 48 hours to allow proper administration of the service (diagnosis of attacks, connection problems, etc).
We use this information internally to improve the user interface of JabberFR services and maintain a consistent and reliable user experience.
This data is neither sold nor transmitted to third parties.
Backups and data persistence
Daily backups are made of all user data that we host, including Prosody (our Jabber server), and Biboumi (our IRC gateway). These backups are made using borg, encrypted, then sent to a remote server that cannot decrypt them. Only server administrators have the key to decrypt them.
The backups kept are:
- One backup per month for the last 6 months
- One backup per week for the last 4 weeks
- One backup per day for the last 7 days
The purpose of these backups is to be able to quickly restore the service in the event of server unavailability due to a failure (e.g. disk problem, etc).
Rating:
Server: ejabberd 24.2.0
SASL mechanism(s): PLAIN, SCRAM-SHA-1, X-OAUTH2
Gajim Chose SCRAM-SHA-1
From their privacy policy:
IP Addresses and User Agents
We do not keep access logs - so we can't see who has connected. However, our server uses modsecurity to protect against different types of attacks. Most of the time the modsecurity audit log is disabled, meaning it doesn't log anything. However, we might enable it for short periods of time for debugging purposes, after which we would disable and clear the log. Modsecurity logs may contain IP addesses or user agents!
Username and password
We will require a username (which could be considered sensitive and/or private and/or personally identfiable). Other users will be able to see your username.
Your password is salted and hashed. (This generally means your password is safe, as long as it is strong enough.)
Data retention
The modsecurity log, when enabled, should be cleared after any debugging is done. We also keep your registration details (username) and published content until you either delete what you can yourself and/or tell us to remove it. (If you want to delete your entire account please ask for help, since you can't do that by yourself.)
Data sharing
We do not share any data with third parties unless we have to by law or state otherwise.
Exceptions
Here are some services that make exceptions to the above statements:
XMPP
Our XMPP server caches messages and uploads for up to seven days. If your client uses encryption (such as OMEMO) the cached messages and uploads will be encrypted. We strongly advise using encryption.
Rating:
System logs will contain IPs, connection timestamps, and "way of authentication".
It could take weeks to months for connection logs to be purged.
Server: ejabberd 24.7.0
SASL mechanism(s): PLAIN, SCRAM-SHA-1, X-OAUTH2
Gajim chose SCRAM-SHA-1
The privacy policy didn't specify if passwords are stored hashed, and if they are with which algorithm, so I asked the admin. They said they are hashed with SHA. For ejabberd this would presumably be SCRAM-SHA, probably SCRAM-SHA-1 considering that is what they offer as an SASL mechanism, though 256 and 512 are supported.
Here is their privacy policy:
In order to stay functional and work as intended, macaw.me services collect the following information:
- The content of your profiles, contact lists, subscriptions, bookmarks
- Your file uploads
- Your posts, messages, reactions and other activities
- All of the versions of your projects (for Gitea)
- All of the content of your network folders (for mail IMAP folders and Nextcloud)
These are needed for providing services of public and private communication proper. None of these are shared with third parties unless it’s a case of federation protocol such as sending an email to a user of another server, joining conversation on another server, etc.
For technical purposes, as part of the system logs, also collected are:
- Your IP addresses
- Time of access
- Way of authentication
Keep in mind, that I theoretically have access to your meta information. I will probably be able to see your unencrypted messages, how often, when and with what accounts you contact using my services. All of this is collected purely for debugging purposes. I have absolutely no intention to provide this information to any third party nor do I want to read it or study it. I will read those logs only if there is a complaint that something is not working well or when I perform technical actions such as updates and database migrations.
The databases are stored for the time being. The logs are stored until they reach a specific size. It is nearly impossible to tell how long it will take them to get purged, but you may estimate it to be several weeks or months.
Rating: L?,
Captcha depends upon javascript. Account verified via email.
Logging duration unspecified.
Server: Prosody 0.12.4
SASL mechanism(s): PLAIN
A pattern is emerging. Community-driven servers with email verification tend to store passwords in plaintext. Hear that, hackers?
From their privacy policy:
Collection of Information
"Data" is potentially identifiable information such as your e-mail address and connection details and any other non-public information about you that is associated with or linked to any of the foregoing information. We collect data from you on our Site and when you use or visit any of our services.
Accounts
We will ask you to provide your email, and to choose a username and password when you register for an account on Worlio. Worlio will also ask you to verify your account via email.
[...]
Messages
Worlio monitors and maintains messages and posts made on its services, with the exception of our alternative communication services like XMPP and Mumble.
Use of Information
Generally, we collect, store, use and disclose information to enable us to provide the Site, create your account, identify you as a user, respond to your inquiries and emails, improve the Site, send you administrative and service related communications, and send you newsletters, surveys, offers, and other promotional materials. Except as set out in this Privacy Policy, your data will not be used for any other purpose without informing you first by updating this Privacy Policy.
Except for the limited disclosures described in this Privacy Policy, we don't sell customer lists and we will endeavor to keep your email address private.
Anonymous aggregate statistics that do not personally identify a Worlio user will be kept and used by us for various purposes including analysis and reporting of usage patterns. Worlio reserves the right to use and disclose anonymous aggregate statistics for any purpose and to any third party in its sole discretion.
Disclosures & Transfers
In addition to the disclosures described in Section 2, we may additionally disclose your information as follows:
- Our servers are located in the United States and as such your data may be available to the U.S. or its agencies under a lawful order made in that country, irrespective of the safeguards we have put in place for the protection of your data.
- From time to time we may employ third parties to help us provide or improve our Site. These third parties may have limited access to databases of Site user information or registered member information solely for the purpose of helping us provide or improve the Site and they will not be able to use the information about our members or visitors for any other purpose.
- We may disclose data in some other limited circumstances, but we will specifically describe them to you when we collect the information, such as in the terms of use for a new service or by revising this Privacy Policy.
- We may, and you hereby authorize us to, disclose your data (including messages) to a third party without your consent: (a) if we have reason to believe that disclosing this information is necessary to identify, contact or bring legal action against someone who may be causing injury to or interference with (either intentionally or unintentionally) our rights or property, other website users, or anyone else (including the rights or property of anyone else) that could be harmed by such activities, (b) in connection with any legal investigation, and/or (c) when we believe in good faith that such disclosure is required by and in accordance with the law or to respond to subpoenas or warrants served on Worlio.
- We may also disclose your data in connection with a corporate re-organization, a merger or acquisition with another entity, or a sale of all or a substantial portion of our assets or stock provided that the information disclosed continues to be used for the purposes permitted by this Privacy Policy by the entity acquiring the information. Although we currently do not have a parent company, any subsidiaries, joint ventures, or other companies under a common control (collectively, "Affiliates"), we may in the future. We may share some or all of your data with these Affiliates, in which case we will require our Affiliates to honor this Privacy Policy.
I've seen this segment before, at sure.im.
Security
The security of your data is important to us. We use commercially reasonable efforts to store and maintain your data in a secure environment and have implemented commercially reasonable procedures designed to limit unauthorized access, use or disclosure of your Personal Information. Despite these measures, you should know that Worlio cannot fully eliminate security risks associated with your data.
Choices, Modifications, and Retention
[...]
You may change your email address, and profile picture (but not username) within Worlio. You may request deletion of your data by us, but please note that we may be required to keep this information and not delete it (or to keep this information for a certain time, in which case we will comply with your deletion request only after we have fulfilled such requirements). When we delete any information, it will be deleted from the active database, but may remain in our archives. We may retain your Technology Data on our system. We will retain your other data for as long as it remains necessary for the identified purpose or as required by law, which may extend beyond the termination of our relationship with you.
This last part makes me distrust them, although this could simply be them writing a thorough privacy policy to completely indemnify themselves. Maybe they won't really retain your "technology data",. And I don't see what "identified purpose" could justify them retaining data for a long period of time, aside the aforementioned legal reasons e.g a criminal case.
Rating: L?,
They don't seem to have a privacy policy.
Registration is in-band, but confirmed via email.
Website connects to fonts.googleapis.com, gstatic.com, fonts.gstatic.com, yandex.ru, mc.yandex.ru
Rating: L?,
Server: ejabberd 24.02
SASL mechanism(s): PLAIN, SCRAM-SHA-1, X-OAUTH2
Gajim chose SCRAM-SHA-1
There's no privacy policy, but in-band registration is supported. I don't know if this is meant to be a public server.
As stated at the introduction, I randomly selected 200 servers in order to see if there was a significant change in the current state of XMPP, as opposed to how it was last year in 2023. Listed below are the server I found.
All of these servers support in-band registration, and do not have privacy policies:
ewaku.deServer: Prosody 0.12.3
SASL mechanism(s): SCRAM-SHA-1, PLAIN
Gajim chose SCRAM-SHA-1
exploit.imServer: Unknown
SASL mechanism(s): PLAIN, SCRAM-SHA-1-PLUS, SCRAM-SHA-1
Gajim chose SCRAM-SHA-1
gnu.glServer: Prosody 0.12.4
SASL mechanism(s): PLAIN, SCRAM-SHA-1
jabber.banuareload.comServer: Openfire 4.2.3
SASL mechanism(s): PLAIN, SCRAM-SHA-1, CRAM-MD5, DIGEST-MD5
Gajim chose SCRAM-SHA-1
vcambria.orgServer: jabberd 2.7.0
SASL mechanism(s): EXTERNAL, PLAIN, DIGEST-MD5
Gajim chose plaintext
xmpp.076.ne.jpServer: Prosody 0.12.4
SASL mechanism(s): SCRAM-SHA-1, PLAIN
gramelspacher.chServer: Prosody 0.12.3
SASL mechanism(s): SCRAM-SHA-1, PLAIN, SCRAM-SHA-256
Gajim chose SCRAM-SHA-256
jab.undernet.czTheir cert is expired. After registering an account with them, I tried to connect with Gajim; I was asked for my password, I entered it; my client warned me of the expired cert, I connected anyway; authentication failed and the server told me to enter my password again, I did, then received the same error. This continued in an infinite loop. Afterwards I tried an unencrypted connection, which also failed.
SASL mechanism(s): PLAIN, SCRAM-SHA-1, X-OAUTH2
This server only permits website registration, which depends upon javascript, and does not have a privacy policy:
1jabber.comServer: Unknown
SASL mechanism(s): DIGEST-MD5, PLAIN, SCRAM-SHA-1, X-OAUTH2
Gajim chose SCRAM-SHA-1
I only discovered two servers with privacy policies.
Rating: L?,
I was debating whether or not to include this server, because I highly doubt that men are allowed an account, which would make this server partially private. I mercilessly excluded every private server I encountered that was overtly members only, making it feel hypocritical to add this one. On the other hand, I have already listed other servers in this article that are probably private, but are not proven to a certainty to be so. Ultmately, I felt that it would be dishonest to omit this server, having had discovered it through random selection.
Registration confirmed through email. Registration page has some type of captcha that depends upon javascript.
Passwords stored hashed as SCRAM-SHA-1.
Data protection
As a rule, our website can be used without providing personal data. Insofar as personal data (e.g. name, address or email address) is collected on our website, this is always done on a voluntary basis as far as possible. These data will not be passed on to third parties without your express consent.
In connection with your access, data is temporarily stored in our server for the purpose of data security, which may allow identification (website visited, time of access, amount of data sent in bytes, source / reference from which you came to the page, browser used, operating system used, visible IP address). The data collected are only used for statistical evaluations. However, we reserve the right to check server log files retrospectively if there are concrete indications of illegal use. An evaluation, with the exception of statistical purposes in anonymous form, does not take place.
How long is the data "temporarily" retained for?
At its core, the FeministWiki doesn't save anything about you other than your chosen username, a "cryptographic hash" of your current password, and the username of the member who added you. In addition, it can save an e-mail address and a "display name" of your choosing, if you enter these in the account settings page or provide them in the account request form. A detailed listing of all data stored in relation to your FeministWiki account follows.
The username
Your username doesn't need to correspond to your real identity in any way. If it does, note that other members can see it in some places such as the list of names in the chat service. It's almost impossible to keep 100% of malicious people from getting a FeministWiki membership, so a malicious person could end up seeing your username too. Furthermore, if you edit the wiki, post on public parts of the forum, publish a FeministWiki blog post etc., then your username will be publicly visible. If this is a problem for you, please contact the technician to change your username to one that doesn't relate to your real identity.
The password
Your password is not saved in plain text. Rather, a "salted SHA1 hash" of your password is saved. In layperson terms, this means: even in case of a data leak, attackers won't immediately know your password, though it's technically possible for them to figure it out if they spend a lot of time processing the leaked data. For this reason, the password you use here should not be a very important one, such as the password you use for online banking. (This issue applies to almost all websites that use passwords; the FeministWiki is not any less secure in this regard than other websites.) All FeministWiki services use encrypted communication, so your password doesn't travel over the network in plain text either.
The member who added you
The username of the FeministWiki member who created your account is visible to the technician, if she/he cares to look it up from the internally kept database.
Your regular e-mail address
In the account settings, you can set an e-mail address that should be associated with your FeministWiki account instead of the default address of (username)@feministwiki.org. (In the account request form, this corresponds to the address you provide in the first e-mail input field.) While this address won't be listed publicly anywhere, it's possible that other FeministWiki members may see it. Given that it's practically impossible to keep out 100% of malicious persons from getting a FeministWiki member account, you should consider the risk that a malicious person will see this e-mail address. As such, consider not providing one and just using the (username)@feministwiki.org address provided by the FeministWiki, or providing one that cannot be traced to your real identity, if keeping your identity hidden is important to you.
Data provided in the account request form
If you use the account registration/request form, if you leave out the primary e-mail address field, you are asked to fill out a secondary e-mail field so your account request can be responded to. While this address is not recorded in the member database (unless you explicitly opt in), it will appear in the automatic e-mail sent to admin@feministwiki.org. Likewise with the text you write in the "personal declaration" field of the form. The e-mail containing this data is stored on the mail server of the FeministWiki, meaning that the same data leak concerns as explained in the previous section might apply. That said, the technician will try to make sure that these e-mails are deleted after the account request is processed. (So far, a technical guarantee of this is not provided; this will come in a future rework of the account request system.)
Activity data
When you use any of the FeministWiki services, like visiting any part of the website, editing wiki pages, posting to the forum, sending chat messages, sending FeministWiki e-mail, uploading files, or writing or commenting on blog posts, you generate data that is stored on the server, some of which is also publicly shown. Details follow.
Visiting pages
Every new page of the FeministWiki that you open or navigate to (including forum pages, blog posts, the on-site chat or email clients, etc.) generates an "access log" entry on the web server. These entries contain your IP address, the time of access, and optional information sent by your web browser. This helps with alleviating abuse of the website, and searching for technical problems.
Usually, your IP address cannot easily be traced back to your real identity. However, it reveals information about your Internet Service Provider and an approximate geographic location (such as the nearest large city). If this is an issue for you, please look into software such as the Tor Project, a VPN Provider, or other ways to hide your IP address from websites you visit.
The FeministWiki will never reveal the contents of the access logs to anyone, unless mandated by law enforcement.
All individual edits made to the wiki (including talk pages and other types of special pages) are permanently recorded, with the username of the editor and the date and time of the edit. These records remain even if the page is later edited by someone else so thoroughly that none of the content written by you remains. This recording of all edits helps to resolve issues with vandalism by malicious editors. (E.g. if someone removes all content on a page and replaces it with garbage, the original content can be recovered in a few clicks, and the edit logs will show who did the vandalism.)
Chat messages sent through the FeministWiki chat service are only visible to the recipient(s) of the message. However, they are stored on the server to provide you your chat history when you log in to the chat with a different device. Ideally, don't ever send personal information through the FeministWiki chat service if you want it to remain absolutely secret.
The files you upload to the FeministWiki file storage are private by default. You have the option of sharing them with others by creating a sharing link or making files or whole folders accessible to other members. Since the files are stored on the server however, you should ideally never upload any files with personal information that you want to keep absolutely secret.
They never specify how long IPs are retained for, nor other metadata (web browser, bytes sent, source of connection, etc). They are retained "temporarily".
Rating:
Registration page depends upon javascript, and demands an email account, which must be verified.
I tried registering with a disposable email. They sent me a confirmation link, which I clicked on. At the activation page I was handed the error "[BAD CSRF]", preventing me from registering an account. Then I tried a real email, which was successful, however, I could not log in to my account after registering it. There might be a block on Tor IPs.
Website connects to googletagmanager.com
From their privacy policy:
We collect information from you when you register on our site and gather data when you participate in the forum by reading, writing, and evaluating the content shared here.
When registering on our site, you may be asked to enter your name and e-mail address. You may, however, visit our site without registering. Your e-mail address will be verified by an email containing a unique link. If that link is visited, we know that you control the e-mail address.
When registered and posting, we record the IP address that the post originated from. We also may retain server logs which include the IP address of every request to our server.
Any of the information we collect from you may be used in one of the following ways:
- To personalize your experience — your information helps us to better respond to your individual needs.
- To improve our site — we continually strive to improve our site offerings based on the information and feedback we receive from you.
- To improve customer service — your information helps us to more effectively respond to your customer service requests and support needs.
- To send periodic emails — The email address you provide may be used to send you information, notifications that you request about changes to topics or in response to your user name, respond to inquiries, and/or other requests or questions.
We will make a good faith effort to:
- Retain server logs containing the IP address of all requests to this server no more than 90 days.
- Retain the IP addresses associated with registered users and their posts no more than 5 years.
Fuck... Well, at least it's not
We use cookies to understand and save your preferences for future visits and compile aggregate data about site traffic and site interaction so that we can offer better site experiences and tools in the future. We may contract with third-party service providers to assist us in better understanding our site visitors. These service providers are not permitted to use the information collected on our behalf except to help us conduct and improve our business.
Do we disclose any information to outside parties?
We do not sell, trade, or otherwise transfer to outside parties your personally identifiable information. This does not include trusted third parties who assist us in operating our site, conducting our business, or servicing you, so long as those parties agree to keep this information confidential. We may also release your information when we believe release is appropriate to comply with the law, enforce our site policies, or protect ours or others rights, property, or safety. However, non-personally identifiable visitor information may be provided to other parties for marketing, advertising, or other uses.
"We don't sell your data, but we sell your data." None of these companies compile or sell "personally identifiable information", and yet they all make money by "sharing" or "trading" it. It's because they typically consider "personally identifiable information" to be what is directly associated to your real identity, like your name, billing address, personal email account. But this is not necessary, your network addresses, and browser fingerprint will sufficiently deanonymize you.
These are servers I found after this article was finished. I will add everything I find here from now on.
In-band registration denied. Website only loads through Morty, meaning they block Tor. The latest update to their website was 14 years ago, and it displays "0 users online". Place is a ghost town.
There's no privacy policy.
In-band registration rejected with the message "Access denied by server policy." Must be a block on Tor.
There's no privacy policy.
In-band registration denied. Web registration depends upon javascript and wants a valid email address.
Web registration failed. Seeing as they should support in-band registration, I can only surmise that block Tor.
There's no privacy policy.
In-band registration denied. Web registration fails to display captcha. Maybe they are freaking out because I'm using Tor?
There's no privacy policy.
In-band registration redirected to a web registration page which 404s
The XMPP network is largely comprised of private (members-only) servers. This won't come as a surprise to anyone familiar with XMPP. These private servers probably have no need for privacy policies, since their members are likely to be acquainted with the policies of the server. Once XMPP is cut down to its public sphere, it is extremely smaller than it first appears. Out of almost 2000 servers, this article has only identified 96 that could be rated.
Out of the 96 servers covered in this article:
The remainder have privacy policies, most of which describe reasonable practices, but there are varying levels of vagueness with which they are written. Their vague language leaves the reader to assume the intentions of the author. Terms like "logs" and "data" may not be adequately defined, leaving the reader to apply their own definitions to those terms, which could differ from the author's intended definition. They may not specify how long network logs are retained, leaving the reader to infer that they are retained for the same duration of time as some other data point, such as a browser user agent. They may simply state that they log information for a little time as possible, leaving the user to estimate what duration of time that would be. Usually, servers' privacy policies aren't written so vaguely as to leave their practices a complete mystery, but sometimes they are.
Most XMPP servers with privacy policies do not specify how they store passwords. They do not disclose whether or not they hash passwords, and if the passwords are kept in encrypted storage. When the hash algorithms are disclosed, it is always SCRAM-SHA-1, a variant of SHA-1, which is a demonstrably insecure hashing algorithm that was broken over 10 years ago, and has suffered the discovery of new exploits over the years. For the time being, SHA-1 is not vulnerable to preimage attacks, which should be necessary in breaking SHA-1-hashed passwords. The ease in computing SHA-1 allows for passwords to be bruteforced quicker, but this is not the case for XMPP because of its mandated use of SCRAM, which implements PBKDF2. The XMPP developers and XMPP servers are presumably relying on the fact of how improbable it is for SHA-1 passwords to be broken on the basis of their hash algorithm alone. I think this is a dangerous mentality, as further weaknesses in SHA-1 are discovered, the security of its usage in password hashing could change dramatically. Not to mention what government agencies like the NSA could do to break it. SHA-1 is getting to be a very old algorithm.
XMPP servers don't have to use SCRAM-SHA-1, most servers and clients support SCRAM-SHA-256. I am left to wonder if they use SHA-1 merely because it computes quicker, and the likelihood of the passwords being cracked is low? The probability may be low at this current time, but in the future SHA-1 will likely be broken. XMPP server developers and admins are waiting for such a day to come, before they will switch to a newer, more robust hash algorithm. This kind of mentality it what creates crises. In the event SHA-1 is broken there will have to be a rushed implementation of a stronger algorithm which may create issues with users' accounts. It is better to prepare for crises than to react to them as they occur.
Many clients and servers support the "-PLUS" variant of SCRAM mechanisms, which adds channel binding to the authentication method, to provide greater protection against MITM attacks. However, TLS v1.3 does not support channel binding, causing clients to avoid the use of the SCRAM-PLUS. The only solution is to use TLS 1.2, or beg for TLS 1.3 to support channel binding.
There is no way of knowing what hash algorithm a server uses without that server's disclosure of such. The best evidence available for determining what hash algorithms are used for stored passwords by an XMPP server are the SASL mechanisms that server provides its users with to hash passwords sent over the wire. Assumedly, a server would use one of the algorithms listed under those supported SASL mechanisms, likely the strongest one. This has been the case for servers that have disclosed what algorithm stored passwords are hashed with. However, this 'evidence' is not reliable, once passwords are received by a server, the admin can store them however they like, they could easily use none of the SASL algorithms. Hashed passwords can be dehashed and stored in plaintext, or hashed into another algorithm, passwords received in plaintext can be hashed. At the very least, to have passwords transmitted in plaintext poses a greater risk to those passwords being compromised if they should be intercepted in transit to a server. The SASL mechanisms provided by a server are one of the few publicly observable aspects of a server's security, but servers cannot be judged entirely upon them alone due to the fact that servers may privately store passwords however they like. Without a server disclosing what hash algorithm they use upon stored passwords, a full judgement cannot be made. Unfortunately, the majority of servers do not disclose what hash algorithm they use upon stored passwords, if any.
While having someone log into your XMPP account doesn't necessarily pose a grave danger to yourself, as it won't expose your private messages, assuming you used OMEMO/OTR/PGP, it can still pose a serious threat to your contacts. Somebody could log in to your account, and impersonate you. They could get your contacts to reveal, or reiterate previously-disclosed private information to them, compromising your contacts. They could send your contacts malware that they would unwittingly execute on their machines, because they trust you enough to download and open files you send them.
Proportionally few XMPP servers describe what types of data they log. It is typically only IP addresses that are mentioned. Metadata like connection timestamps, bytes sent/received from the server, and message senders/recipients are seldom taken into account, despite the fact that these can be of great significance in determining what activities somebody may be partaking in. A serious issue I find with my article is that I did not differentiate the types of data logged by servers, instead opting to gauge what duration of time "logs" in general, were stored for. I only did this because how inconsistent the privacy policies of the XMPP network are. I tried to differentiate forms of logging from one another in an initial draft, but it complicated things too deeply. I will look for a way to reconcile this issue, because I dislike my use of a single broad sweeping category.
I believe that I have enough data to reasonably assert that the public sphere of the XMPP network is doing poorly when it comes to its servers outlining their privacy/security practices.
As explained at this article's introduction, I scraped the majority of the network in 2023. I am in no way claiming to have scraped the entirety of the network. 23% of it went unscraped, which is a significant margin. However, you have to realize the various reasons some servers may have went unscraped. I know a fair bit of the servers that weren't scraped were offline. Others may have blocked me for using Tor; to me those ones are trash that don't deserve a review. Yet still, there very well may be plenty of online servers that do not block Tor, which I failed to discover, but it is doubtful that the amount of them is significant enough to disprove my assertion, because:
And the random selection produced about 40-50 servers I had already covered, which I had to skip over and not count towards the total of 200. Most of those 200 servers were miscellaneous, offline, or their servers and webpages were broken. Some were private servers. Essentially, the results were not unlike what my scrape already told me.
It took me several days of constant work to create the foundation for this article, using the data provided by the scrape. It was miserable. Doubtless, before doing such a thing again, I will first question if it is necessary. Seeing the results of my random selection, I do not believe it is necessary to scrape the XMPP network again to reasonably assert that the network is doing poorly.
As for how the network could improve is quite obvious. Here are my thoughts:
In all likelihood, the majority of people reading this article will already know why things like Cloudflare, Oracle, reCAPTCHA, and javascript should be avoided, but there will inevitably be some who do not know why. Since nothing I will say here will be new to most people, I've chosen to leave this segment nearer to the bottom. I am in the process of working on a much larger text, part of which covers the subject of online anonymity, where all of these things will be explained within a greater context. I will probably link this article to it from here. However, for the time being, I will have to leave my reasoning within this article.
Web browser fingerprinting is the process of identifying a web browser through collating various distinctive traits that a web browser possesses, and extracting information about the type of device running the web browser, through the web browser itself. The web browser may for example, allow a website to discover the CPU type, GPU type, operating system type and version, browser type and version, among other attributes, of the computer the web browser is running off. I am calling these attributes and traits 'identifiers'. When these various identifiers are collated together, they can form a "fingerprint" of a web browser, which can be compared against other browser fingerprints, allowing browsers to be tracked across the internet. Back in 2010, the EFF reported:
In our analysis of anonymized data from around half a million distinct browsers, 84% had unique configurations. Among browsers that had Flash or Java installed, 94% were unique, and only 1% had fingerprints that were seen more than twice. However, our experiment only studied a limited number of variables, and the companies that offer specialized fingerprinting services are likely to use a wider and therefore more powerful range of measurements.
And this was back in 2010, in a study using a limited number of variables to trace browsers with. Technology has advanced a great deal since then, and with it, the diversity of web browsers, operating systems, and hardware to identify individuals with, as well as the methods for tracking web browsers. It is now likely that virtually every web browser can be entirely distinguished from its peers, given the proper circumstances. And unfortunately, the internet in its current state is designed to keep browsers perpetually under these "proper circumstances", with its widely-enforced usage of javascript.
Web browser fingerprinting could not be as granular as it currently is were it not for javascript, and everything based upon javascript i.e WebGL. There is a plethora of information about one's device that can be made accessible to a website host when a browser executes its javascript. All the host needs to do is design their javascript code to extract the information. The use of user agents and IP addresses alone would be a far less effective means of fingerprinting the masses than the collection of device identifiers through the use of javascript, as IP addresses and user agents change over time, can be spoofed, and are (or can be) shared by large groups of people. The identifiers revealable with javascript span a much broader range, are far more diverse and thus distinguishable, change with much lesser frequency than IP addresses and user agents, and are more difficult to obfuscate. Identifiers such as browser type and version, operating system type and version, CPU type, GPU type (if applicable), IP and MAC addresses, custom fonts, audio devices, timezone, date, geolocation data, among an array of other data points, when collated can form an almost (if not entirely) unique fingerprint for the majority of web browsers. If this fingerprint is not immediately unique it can become distinguished over the passage of time, as the person associated with it visits websites that participate in various surveillance networks, associating their activities, and online accounts, with their fingerprint, all while their browser caches data that websites can access (assuming they use an easily traceable browser like the majority of people).
Websites like Cover Your Tracks can give you an idea of your fingerprint's uniqueness. I tested mine after doing everything in my power to harden Tor Browser against fingerprinting, and even still, my current fingerprint is as such:
Within our dataset of several hundred thousand visitors tested in the past 45 days, one in 78.44 browsers have the same fingerprint as yours.
Currently, we estimate that your browser has a fingerprint that conveys 6.29 bits of identifying information.
Even if you do everything in your power to mitigate fingerprinting, your browser will still have some level of uniqueness, but it will be far less distinguishable than the typical Google Chrome user's browser.
At websites like AmIUnique, a much more dramatic picture can be painted for some people. AmIUnique does not give you a general ratio to gauge your browser's uniqueness with (e.g one in 78), they merely display a list of identifiers, tell you what percentage of browsers share those identifiers with you, and then declare you to be unique. I haven't ever not been told my browser was unique by AmIUnique. At AmIUnique, disabling javascript puts your browser in a pool that composes 0.98% of web browsers. In my experience, the sight of this strikes a sense of hopelessness into people, and causes them to reason that enabling javascript makes you less traceable than having it disabled. This is a false belief. Disabling javascript does not make you more traceable. While it might place you in a smaller pool of browsers, it also makes you extremely difficult to identify, which is what makes you unique. It is slightly paradoxical. The majority web browsers have unique fingerprints, and in this way are not unique, so when a web browser does not, that browser is unique. However, that web browser, devoid of any identifiers, could theoretically belong to anyone. The same cannot be said for a web browser that has javascript enabled, with an array of identifiers available to whomever should wish to extract them. For example, here is my fingerprint after testing Tor Browser at Cover Your Tracks, with Tor Browser at the "Standard" security level:
Within our dataset of several hundred thousand visitors tested in the past 45 days, only one in 14826.69 browsers have the same fingerprint as yours.
Currently, we estimate that your browser has a fingerprint that conveys 13.86 bits of identifying information.
Bear in mind my fingerprint still contains far less information than the typical Chrome or Firefox user's. When I enable HTML5 canvasing, my fingerprint becomes even more distinguishable:
Currently, we estimate that your browser has a fingerprint that conveys at least 17.56 bits of identifying information.
That being said, enabling javascript absolutely does not help you blend in.
In addition to browser fingerprinting, javascript has the potential to spread malware. Javascript is typically executed on a website visitor's machine, which is what makes the spread of malware through browsers feasible. A website host, or anyone with the ability to compromise the connection between the website host and website visitor such as law enforcement running a targeted attack against the user of an online service, a hacker who has hacked a website, Cloudflare (perhaps at the behest of law enforcement), could introduce malicious javascript to a website visitor's web browser. There are a few ways for the javascript to infect the visitor, for instance, javascript code, designed to exploit some vulnerability in the browser and operating system, gains some level of privilege over the victim's system. The victim's browser downloads a payload which is installed, and executed, infecting the machine.
There is also the potential for WebRTC to leak one's IP address, assuming it is enabled by the browser. The solution here is obviously to have it disabled, and/or create a firewall to force all of your connections through Tor, that way you have a "leak shield", as some people call it, to fall back upon in the event a malicious entity should try to discover your IP address. Operating systems like Whonix and Tails already provide said leak shields.
With all of that said, creating a website with content that cannot display itself without the aid of javascript exposes your visitors to needless risk, when a mere web registration page or privacy policy is all that you are providing to them.
An analytics program provided by Google; the code is proprietary. Google Analytics functions as a backdoor for Google to access websites' traffic with, although Google does provide website admins with analytics about how their site is used in exchange, a fair trade no less. The analytics are provided free of charge — by Google, of all companies, couldn't be any ulterior motive there. It's not as though there is over a decade of constant news headlines and exposés detailing how Google datamines and manipulates the masses, and participated in PRISM with the NSA.
Google, and site administrators (some listed in this very article) try to sully website visitors' warranted concerns about datamining by saying that IP addresses collected by Google are "anonymized". Seeing this, I began to wonder how IP addresses are anonymized. Does "anonymization" occur on the website, or on Google's servers? What does the anonymization consist of? Furthermore, what other information does Google collect? Even if they don't collect IP addresses whatsoever, should they collect browser information, they could deanonymize people via browser fingerprinting.
https://support.google.com/analytics/answer/12159447?hl=enTo measure a website, you first have to create a Google Analytics account. Then you need to add a small piece of JavaScript measurement code to each page on your site. Every time a user visits a webpage, the tracking code will collect pseudonymous information about how that user interacted with the page.
[...]
The measurement code will also collect information from the browser like the language setting, the type of browser (such as Chrome or Safari), and the device and operating system on which the browser is running. It can even collect the “traffic source,” which is what brought users to the site in the first place. This might be a search engine, an advertisement they clicked on, or an email marketing campaign.
Meaning you put a piece of code on a webpage, and it siphons site data off to Google's servers, in order to be processed. The data is not processed locally. IP addresses are received by Google, and then anonymized, before being delivered to the website administrator through Google Analytics' control panel; the same administrator who can see everyone's IP addresses anyway, making the supposed "anonymization" completely pointless. In spite of this, IP addresses are not necessary for tracking people to begin with, thanks to browser fingerprinting, which Google is capable of performing via Google Analytics. Even if Google Analytics provides its customers with the ability to disable methods of data collection that lend to browser fingerprinting, it is doubtful that customers can reliably determine said data is not being collected without inspecting the packets transferred to Google's servers, or monitoring how Google Analytics interacts with their server. Google Analytics provides its customers with a single tracking code to insert into the HTML header of their webpage(s), which then siphons website data off to Google's servers. They can add tags to the code, to configure what data is or is not collected, but there is nothing to prove that these tags have an impact on anything but what a website administrator sees through their Google Analytics control panel, because the code composing the Google Analytics software is proprietary. Without further analysis into how Google Analytics behaves, or its source code, Google Analytics customers have no ability to meaningfully regulate what data Google does and does not harvest, because they are unable to confirm that the regulation afforded to them by Google is anything but illusory.
The potential threat posed by Google Analytics is bad enough, no matter what it does or does not do. By using it, you are planting a blackbox on your server that you have no ability to examine the inner machinations of, designed by a company who exists because they surveil the masses and sell their data, and trusting it to not collect data from your server for the sake of surveilling the masses. It's incredibly naive.
reCAPTCHA can allow Google to fingerprint your browser (also capturing its IP address while doing so) as you're visiting a webpage using it, and also allows Google to run timing attacks against you as you solve their captchas, as explained here:
Cloudflare's insistence on solving reCAPTCHA puzzles when visitors are coming from Tor exit nodes to one of the 2 million web sites that Cloudflare 'protects' can be very instrumental for traffic analysis and de-anonymizing of Tor users. This is how:
The only non-public prerequisite for the de-anonymizing entity is the ability to monitor traffic between ISPs and Tor entry nodes, and traffic entering Cloudflare servers (no decryption required in either case). There are, of course, no 2 million Cloudflare servers, probably there is no more than few hundred.
Each click on one of the images in the puzzle generates a total of about 50 packets between Tor user's computer and the Cloudflare's server (about half are requests and half are real-time responses from the server.) All this happens in less than a second, so eventual jitter introduced in onion mixing is immaterial. The packet group has predictable sizes and patterns, so all the adversary has to do is note the easily detectable signature of the "image click" event, and correlate it with the same on the Cloudflare side. Again, no decryption required.
There likely are many simultaneous users (thousands), but they do not solve puzzles at the same time, and they do not click on the puzzle image at the same time. Simple math shows that disambiguating is trivial. If there is some ambiguity left, Cloudflare can conveniently serve few more images to specific users (or even random users, as long as within the same few seconds different users get different amount of 'correct' images.)
This obvious opportunity is not the proof, but NSA would have to be utterly incompetent not to be exploiting it. No one is that incompetent.
Same as reCAPTCHA.
I don't think I need to remind you of Amazon's years of widely reported mass surveillance, and participation in the NSA's PRISM program alongside Apple (privacy is Apple), Google, Microsoft, and Facebook, that was exposed by Edward Snowden. Traffic destined for a server hosted by Amazon AWS can be captured by Amazon. This permits Amazon to harvest user data, and also facilitates traffic analysis by the NSA which can deanonymize users of anonymizers like Tor.
Oracle was created in 1977 by the CIA under Project Oracle, which is where it got its name from. Oracle is owned by Larry Ellison, a megalomaniacal Zionist billionaire who has proposed a national biometrics tracking database. It isn't widely known, but Oracle is a major dataminer. Just a few years ago Oracle found itself in a lawsuit because it had compiled detailed dossiers on 5 billion people. I could go further, and outline Oracle's history in depth, but I would rather not make this article longer than it needs to be.
By using Oracle as a host, Oracle is given the opportunity to harvest user data, and again, the NSA is permitted to analyze traffic which can deanonymize users of anonymizers like Tor (Oracle has tons of contracts with and ties to the DoD).
CloudFlare is the internet's largest Content Delivery Network (CDN) and reverse proxy. As of this year, CloudFlare provides these services, among other services, to 24 million websites. According to deCloudFlare, over 40 million domains use CloudFlare, with CloudFlare serving more web traffic than Twitter, Amazon, Apple, Instagram, Bing & Wikipedia. At least 20% of internet traffic passes through CloudFlare's infrastructure.
CloudFlare's most popular service is their reverse proxy, it is what made CloudFlare what it is today. Its marketed-purpose is to protect websites from cyber attacks. With CloudFlare's reverse proxying, traffic directed toward any website using CloudFlare is decrypted, analyzed, and re-encrypted, before being shuttled off towards the website. Communications between the website visitor and website are mediated by CloudFlare. This can achieve two things:
Many people refer to CloudFlare's reverse proxying as a MITM attack, which is completely accurate. All of a website's encrypted traffic is reduced to plaintext, including hashed passwords. CloudFlare executes a complete MITM attack against websites under its control.
CloudFlare is vastly overcentralized. As of now (09/2024) CloudFlare has 164 datacenters, and services 24.03 million websites. Divide the two and that makes 146,524 websites per datacenter, nevermind the people accessing those websites. CloudFlare's level of centralization is a recipe for disaster. Just one datacenter getting hacked could compromise millions of people's private information in one fell swoop. Similarly, one datacenter going offline can render thousands of websites inaccessible.
CloudFlare was hacked just this year:
Web security company Cloudflare on Thursday revealed that a threat actor used stolen credentials to gain access to some of its internal systems.
[...]
According to Cloudflare, the attackers managed to access an AWS environment, as well as Atlassian Jira and Confluence, but network segmentation prevented them from accessing its Okta instance and the Cloudflare dashboard.
With access to the Atlassian suite, the threat actor started looking for information on the Cloudflare network, searching the wiki for “things like remote access, secret, client-secret, openconnect, cloudflared, and token”. In total, 36 Jira tickets and 202 wiki pages were accessed.
On November 16, the attackers created an Atlassian account to gain persistent access to the environment, and on November 20 returned to verify that they still had access.
On November 22, the threat actor installed the Sliver Adversary Emulation Framework, gaining persistent access to the Atlassian server, which was then used to move laterally. They attempted to access a non-production console server at a São Paulo, Brazil, data center that is not yet operational.
The attackers viewed 120 code repositories and downloaded 76 of them to the Atlassian server, but did not exfiltrate them.
“The 76 source code repositories were almost all related to how backups work, how the global network is configured and managed, how identity works at Cloudflare, remote access, and our use of Terraform and Kubernetes. A small number of the repositories contained encrypted secrets which were rotated immediately even though they were strongly encrypted themselves,” Cloudflare notes.
[...]
According to CloudFlare, it found no evidence that the threat actor accessed its global network, customer database, configuration information, data centers, SSL keys, workers deployed by customers, or any other information except from the “data in the Atlassian suite and the server on which our Atlassian runs”.
According to CloudFlare, more than 5,000 individual production credentials were rotated following the incident, close to 5,000 systems were triaged, test and staging systems were physically segmented, and every machine within the CloudFlare global network was reimaged and rebooted.
Luckily for them, the attack was thwarted. But it goes to show that CloudFlare's defenses are not impregnable, and could one day be bypassed. Considering the rising power of foreign nations hostile towards America like China, and Iran, and the world's growing animosity towards America and its corporations, a day may come when a state actor breaches one of CloudFlare's datacenters successfully.
CloudFlare has also had bugs like Cloudbleed which have leaked the private data of countless customers
Cloudbleed was a CloudFlare buffer overflow disclosed by Project Zero on February 17, 2017. CloudFlare's code disclosed the contents of memory that contained the private information of other customers, such as HTTP cookies, authentication tokens, HTTP POST bodies, and other sensitive data. As a result, data from CloudFlare customers was leaked to all other CloudFlare customers that had access to server memory. This occurred, according to numbers provided by CloudFlare at the time, more than 18,000,000 times before the problem was corrected. Some of the leaked data was cached by search engines.
CloudFlare's captchas depend upon javascript and WebGL in order to function. Without enabling these elements, captchas will not load, and so, pages blocked by them cannot be viewed. To view those websites, you are then forced to enable javascript, which in turn makes you vulnerable to web browser fingerprinting, and also makes your computer vulnerable to malware infection by malicious javascript. Sometimes these websites themselves do not depend upon javascript in order to display their content, causing viewers to take a needless risk.
If you choose to visit a CloudFlare-controlled website through Tor, CloudFlare will force you to complete a captcha where one may otherwise not be required had you not used Tor. Sometimes you may to forced to complete a protracted series of captchas. At times, you might not even be able to view a webpage at all. I've had instances where I have been put in an infinite loop of ever-repeating CloudFlare captchas, the webpage reloading after each captcha was completed with yet another challenge.
To entrust one lone company with processing billions of people's private data is a recipe for disaster. These people have the power of God at their hands, they have the ability to read the plaintext traffic of any website that chooses to use their reverse proxy. Websites dedicated to virtually every aspect of life use CloudFlare, meaning CloudFlare can access the emails of practically anyone, as well as government ID's, financial details, billing records, medical documents, passwords to online accounts, and other sensitive information. The sale or leakage of this information to third parties could have disastrous consequences.
CloudFlare is the perfect source of data for an intelligence agency like the NSA, because they have the ability to access the plaintext traffic of any website that uses their services. Instead of having to go to individual web servers, the NSA can simply pull the traffic of several web servers from CloudFlare.
The founders of CloudFlare have already shown that they have no aversion to selling data to the United States Government, in fact, it is actually what caused them to create CloudFlare.
Back in 2004 Matthew Prince and Lee Holloway, the future creators of CloudFlare, developed a service they called Project Honey Pot. It was a system to identify, block, and report spam email addresses by capturing the IP addresses of bots scraping email addresses off of websites. Later, in 2008, Prince received a phone call from someone at the Department of Homeland Security, who asked him about the information he had gathered on spammers. In this article, Prince recalls the exchange:
"Do you have any idea how valuable the data you have is? Is there any way you would sell us that data?"the DHS agent asked. Prince then added up the cost of running the project, multiplied it by ten, and said
"How about $20,000?"The DHS paid. Later in the article Prince said:
"I was telling the story to Michelle Zatlyn, one of my classmates, and she said, 'if they'll pay for it, other people will pay for it'."
And this gave them the idea for CloudFlare. I'm not kidding.
CloudFlare's initial investors also raised my eyebrows a bit, but this part might be a stretch.
From this article:
https://www.cloudflare.com/our-story/
Prince and Holloway founded CloudFlare in July of 2009. In November of 2009, they raised $2.1 million in funding from Venrock and Pelion Venture Partners. They spent their time building their infrastructure up, and gathering beta testers, until September of 2010 when they launched their service. The specific investors were Ray Rothrock, from Venrock, and Carl Ledbetter, from Pelion Venture Partners.
Venrock, a venture capital firm, was founded by Laurance Rockefeller. Ray Rothrock is a part of the Nuclear Threat Initiative, which, back in 2021 through the '2021 Monkeypox Tabletop Exercise' predicted the monkeypox outbreaks of 2022. Rothrock strikes me as an evil businessman with ulterior motives. Venrock too strikes me as evil. It was born out of the Rockefellers, and they had their hands in all sorts of shady government dealings throughout the 20th century. Maybe it's nothing, after all, Venrock invested in Intel and Apple, among hundreds of other companies. And once you begin networking with wealthy people, it's an inevitability that some of them will be involved in shady events. But maybe that's the point, maybe CloudFlare is yet another company providing technology to enslave the masses with, just like Apple and Intel. Is this the intention of their investors? Well, that's a question outside the scope of this article (one I would like to answer elsewhere). Either way, seeing that just rubbed me wrong.
CloudFlare's centralization of the internet is completely antithetical to the values expressed by the libre software movement. CloudFlare has no business handling the traffic of XMPP servers or their websites, assuming those servers value privacy and anonymity.
I personally don't mind if an XMPP server does not store backups. I do mind if an XMPP stores them for a duration of time greater than the period for which they log server data. A lot of times, it is not entirely clear what data is held within backups. It could be MAM messages, which are in control of the user. I don't take issue with MAM being backed up for this reason. However, account information will have to be backed up i.e username, password, roster, vCard, etc. This can leave a trace of someone having had used a server behind, long after they have left it. If login/logout, message delivery/receipt times, and/or other metadata are backed up alongside that account info, a fair bit of information may be accrued upon a user, at least enough to deduce their timezone, and perhaps their daily/weekly routine.
I am aware that XMPP server operators have claimed that they will not assist law enforcement. Some have claimed that their backups are encrypted, and they won't give up the keys. I do not believe them. I have seen enough run-ins with the authorities to realize that the only way to know if someone truly will not assist law enforcement is if they are being persecuted by law enforcement for that very reason. I've written about this subject in greater depth in a much larger thing I'm working on, I'll eventually publish it.
I color coded the log retention durations to my own tastes. I personally would not be comfortable using a server that retains logs of IP addresses for over 2 weeks. I believe that generally, in the case of XMPP, it is not necessary for servers to retain IPs for a period of time longer than that, and so I become less trusting of them. My main concern with respect to logging durations is their ability to suggest whether or not an XMPP server might be inclined toward selling user data. A server like nixnet for instance, that has had an indefinite logging policy for four years under the pretense that they are "trying to change it", is in my opinion, more likely to sell user data one day in the future, than a server like jabber-germany.de that does not store IPs or the date and time of account logins.
I believe that the logging durations of IP addresses, alongside message and login metadata, have little significance in evading apprehension from law enforcement. Logs may not be stored on an XMPP server with a "no logs" policy, but what are the chances of a user predicting a future law enforcement investigation into that server, unless that user specifically chose to use that server for an activity they knew would elicit the attention of law enforcement? The chances are very low. And so, in spite of a "no logs" policy, law enforcement can compel a "no logs" server to begin logging a user's activities, and the user has no ability to forsee this and leave the server before this should occur. The user must then trust the server admin to inform them of this manifestation. This is unreasonable, as the admins can easily be handed a gag order. The user must then trust the admin to defy a gag order. I have never seen anyone involved in internet privacy/anonymity stuff defy a gag order, but I have seen them comply e.g Riseup. Regardless, the punishment for defiance makes it unlikely.
The immediate threat of logs comes down to metadata, unless you don't use OMEMO, and have MAM enabled. You can easily hide your IP address with Tor or I2P, making the presence of IPs in log files of lowered importance, but you can't hide metadata without communicating using a peer-to-peer protocol through Tor or I2P. Metadata may not directly lead to your identity, but it can reveal a great deal about your routines, which can provide insight into your identity. The longer the duration of time for which a server retains metadata, the more successful someone might be in using it to deanonymize people.
In spite of believing that logging durations are of little significance in evading law enforcement, I do still find servers with shorter logging periods more desirable. There is always the potential for law enforcement to request data from a no-logs server, only to retrieve no data, and give up their investigation. According to some of the transparency reports listed in this article, that has happened. Additionally, there is the potential for servers belonging to an XMPP admin to be seized by law enforcement in a raid, like with what happened to cock.li. In such a case everyone is aware that their data has been compromised, and can do nothing but worry about what may happen to them as a result. At least if this were to happen to a "no logs" server, the authorities would retrieve little useful information on the majority of users.
XMPP server admins could easily be lying in their privacy policies, and realistically, nobody can know without hacking their servers to see what they store. Not many people are willing to go off and hack random XMPP servers to audit their stated claims. Acknowledging this, I concede that a leap of faith is being taken in trusting these servers' policies to be truthful, as they easily could not be. Even if you did hack their servers, nothing but a physical inspection of the servers could completely rule out potential spying.
This can be applied to virtually all of the technology we use. There is probably nobody intending to participate in the internet anonymously with an understanding so absolute of the hardware and software they use, that they can be completely certain of their anonymous online activities being invulnerable to compromise by some kind of backdoor(s) embedded in their hardware/software. To completely rule out the possibility of a backdoor being hidden in the code composing their kernel, and operating system, would be a monumental task, especially if they were to re-examine said code upon every software update. Examining the code alone is a task that demands a technical knowledge most people do not possess. And in the case of hardware, there are few civilians, if any, with the resources to completely rule out the possibility of backdoors. The backdoors already exist to begin with.
People trust that their hardware's backdoors cannot be remotely exploited (meanwhile, in the case of Intel and AMD CPUs, people's entire knowledge of the backdoors has been offered to them by the creators of the backdoors, whom they presumably distrust); they trust that their kernel and operating system are not backdoored, and do not spy on them, because other people have audited the code, and examined their machines' network activity, and they trust that nobody would dare backdoor the code, because "It's open source, it would be too bold"; they trust that the encryption algorithms they use are secure, while most likely having little to no knowledge of how they function, especially at a mathematical level, instead trusting cryptographers and government authorities to dictate this for them; they trust mixnets like Tor to provide a reasonable level of protection against government-level observers. Trust is incontrovertibly linked to our confident feeling that we can use internet-connected devices anonymously and securely.
Most of us subconsciously reason our trust in the technology we use. Some people do so consciously, developing a basis for their trust in it. But few go so far as to rule out any possibility of a backdoor being embedded within it. For any regular person the task is impossible. So we reason that there are no highly pervasive, powerful, actively-exploited, yet-to-be-discovered backdoors, nestled in our hardware (chiefly our CPUs, most don't think of their motherboard, GPU, HDD/SSD), kernel, and OS. I do not intend to imply that our trust is misplaced, I do not believe that it is misplaced, but that does not mean the reasoning it is based upon is flawless. It is flawed, and not sustainable in the long term. Governments and corporations are only increasing their surveillance measures, while the complexity of the software necessary to use the internet in a meaningful way continues to grow, the necessity of the internet in daily life increases, and we continue to lack the means of producing our own non-backdoored hardware.
Only the SASL mechanism (hash algorithm) chosen by the clients (Gajim and Psi+) will be listed.
I used versions of Gajim and Psi+ that support SCRAM-SHA-1-PLUS, and SCRAM-SHA-256-PLUS (and Psi+ SCRAM-512-PLUS) according to this documentation.
| Server | Logs | Registration | Backups | Stored hash | SASL mechanism | Tor | Transparency report | Presence of Big Tech | Privacy policy? |
|---|---|---|---|---|---|---|---|---|---|
| 07f.de | Errors only. Duration unspecified, presumably short. | In-band | Daily. Storage duration unspecified. | Unknown | SCRAM-SHA-1 | No | No | No | Yes |
| 0day.im | No logs | In-band | Unknown | Unknown | SCRAM-SHA-1 | No | Yes | Site connects to Google | Yes |
| 0nl1ne.at | Unknown | Broken | Unknown | Unknown | TBD | No | No | No | No |
| 1jabber.com | Unknown | In-band | Unknown | Unknown | SCRAM-SHA-1 | No | No | No | No |
| 5222.de | 1 week (IPs not logged) | Website | Unknown | SCRAM-SHA-1 | SCRAM-SHA-1 | Yes | Yes | No | Yes |
| 616.pub | Unknown | hCaptcha | Unknown | Unknown | SCRAM-SHA-1 | No | No | No | No |
| aesym.de | 24 hours | Unknown | Unknown | Unknown | TBD | No | No | No | Yes |
| anonym.im | 7 days (14 in case of errors) | In-band | Reserves right to backup all server data for up to 6 months | Unknown | SCRAM-SHA-1 | Yes | No | No | Yes |
| anoxinon.me | 3 days | Website | Reserves right to backup all server data for up to 6 months | SCRAM-SHA-1 | SCRAM-SHA-1 | No | No | No | Yes |
| be3.ovh | Unknown | reCAPTCHA | Unknown | Unknown | SCRAM-SHA-512 | No | No | Hosted by Oracle | No |
| blah.im | Unknown | reCAPTCHA | Unknown | Unknown | TBD | No | No | Site connects to Google | No |
| calyxinstitute.org | "Shortest time possible" | In-band | Unknown | Unknown | SCRAM-SHA-1 | Yes | No | No | Yes |
| chat.sum7.eu | 1 week | In-band | Unknown | Unknown | SCRAM-SHA-1 | No | No | No | Yes |
| chatterboxtown.us | Unspecified | In-band | Unknown | Unknown | SCRAM-SHA-512 | No | No | No | Yes |
| colloquy.ca | IPs not logged | Closed? | "In flux" | Unknown | TBD | No | No | No | Yes |
| conversejs.org | IPs not logged | Javascript | Unknown | Unknown | TBD | No | No | No | Yes |
| crapwa.re | 7 days | Unknown | Unknown | TBD | No | No | No | Yes | |
| creep.im | IPs not logged | In-band | Unknown | Unknown | SCRAM-SHA-1 | Yes | No | No | Yes |
| crime.io | No logs | In-band | Unknown | Unknown | SCRAM-SHA-1 | No | No | No | Yes |
| delirus.biz | 5 years for registered users | Javascript+email | Unknown | Unknown | TBD | No | No | Site connects to Google | Yes |
| disroot.org | 24 hours | Javascript+email | Unknown | Unknown | PLAIN | Yes | No | No | Yes |
| draugr.de | IPs purged after logout | In-band | Created daily & "stored for some time" | Unknown | SCRAM-SHA-1 | Yes | No | No | Yes |
| egregore.fun | Unknown | In-band | Unknown | Unknown | SCRAM-SHA-1 | No | No | No | No |
| eigenlab.org | Unknown | Javascript | Unknown | Unknown | TBD | No | No | No | No |
| ewaku.de | Unknown | In-band | Unknown | Unknown | SCRAM-SHA-1 | No | No | No | No |
| exploit.im | Unknown | In-band | Unknown | Unknown | SCRAM-SHA-1 | No | No | No | No |
| feministwiki.org | "Temporarily" | Javascript+email | Unknown | SCRAM-SHA-1 | TBD | No | No | No | Yes |
| gnu.gl | Unknown | In-band | Unknown | Unknown | SCRAM-SHA-1 | No | No | No | No |
| gnu.gr | No logs | In-band | Unknown | Unknown | SCRAM-SHA-1 | No | No | No | Yes |
| gramelspacher.ch | Unknown | In-band | Unknown | Unknown | SCRAM-SHA-256 | No | No | No | No |
| hookipa.net | IPs and connection times not logged. | In-band | Unknown | Unknown | SCRAM-SHA-1 | No | No | No | Yes |
| jabber.banuareload.com | Unknown | In-band | Unknown | Unknown | SCRAM-SHA-1 | No | No | No | No |
| jabber.cat | 7 days | In-band | Unknown | Unknown | TBD | Yes | No | No | Yes |
| jabber.ccc.de | Unknown | In-band. Might block Tor. | Unknown | Unknown | TBD | No | No | No | No |
| jabberes.org | Unknown | Unknown. Likely blocks Tor. | Unknown | Unknown | TBD | No | No | No | No |
| jabber.fr | 48 hours | In-band | Highest backup storage bracket is 6 months. IPs and account login times not backed up. | Unknown | SCRAM-SHA-1 | No | No | No | Yes |
| jabber-germany.de | IPs + connection duration and time not logged | Website | Nightly snapshot. Storage duration unspecified. | Unknown | SCRAM-SHA-1 | Yes | No | No | Yes |
| jabber.hot-chilli.net | IPs upon failed logins. Duration unspecified. | In-band | Unknown | SCRAM-SHA-1 | SCRAM-SHA-1 | Yes | No | Site connects to Google | Yes |
| jabber.meta.net.nz | Unknown | In-band. Blocks Tor. | Unknown | Unknown | TBD | No | No | No | No |
| jabber.no | Unknown | In-band & Website. Blocks Tor. | Unknown | Unknown | TBD | No | No | Site connects to paypal, wp.com, elegantthemes.com | No |
| jabbers.one | Unspecified | In-band | Made "regularly"; stored for "a few days" | Unknown | TBD | Yes | No | No | Yes |
| jabber.systemausfall.org | Unknown | Website | Unknown | Unknown | SCRAM-SHA-1 | No | No | No | No |
| jabber.sytes24.pl | Registration page logs IPs for 31 days | Website | Unknown | SCRAM-SHA-1 | SCRAM-SHA-1 | No | No | No | Yes |
| jabber.tcpreset.net | "No logs" | Broken | Unknown | Unknown | Unknown | Yes | No | Site connects to gstatic.com, fonts.googleapis.com | Yes |
| jabber.ua | IPs not logged | In-band | Unknown | Unknown | SCRAM-SHA-1 | No | No | Site connects to Google | Yes |
| jabber.uk | Unknown | reCAPTCHA | Unknown | Unknown | SCRAM-SHA-1 | No | No | Not beyond reCAPTCHA | No |
| jabber.ulm.ccc.de | Probably for the duration of a login | "Around 30 days" | Unknown | TBD | No | No | No | Yes | |
| jabberx.ru | IPs & other metadata not logged | In-band | Unknown | SCRAM-SHA-1 | SCRAM-SHA-1 | No | No | Site connects to Google | Yes |
| jabberzac.org | Unknown | Broken | Unknown | Unknown | TBD | No | No | No | No |
| jabb.im | Unspecified | In-band | Unknown | Unknown | PLAIN | No | No | Site connects to Google, Paypal, Twitter, Zendesk | Yes |
| jabbxi.de | Unknown | In-band | Unknown | Unknown | SCRAM-SHA-512 | No | No | Site connects to Google | No |
| jabjab.de | IPs anonymized or deleted after 7 days | In-band | Unknown | Unknown | SCRAM-SHA-1 | Yes | No | No | Yes |
| jab.undernet.cz | Unknown | In-band | Unknown | Unknown | TBD | No | No | No | No |
| jix.im | Web server logs IPs & web browser information for 30 days | reCAPTCHA | Unknown | SCRAM-SHA-1 | TBD | No | No | Site connects to Google | Yes |
| jodo.im | Unknown | Javascript+email | Unknown | Unknown | TBD | No | No | No | No |
| jwchat.org | IPs logged at registration for 31 days | Unknown. May block Tor. | Unknown | Unknown | TBD | No | No | No | Yes |
| laberzentrale.de | IPs not logged. Logs wiped after 7 days. | Website | Unknown | SCRAM-SHA-1 | TBD | No | No | No | Yes |
| lightwitch.org | IPs logged for weeks to months | reCAPTCHA | Unknown | Unknown | TBD | No | No | Hosted by Oracle | Yes |
| linuxlovers.at | Unknown | Broken | Unknown | Unknown | TBD | No | No | No | No |
| macaw.me | Logs could be stored for weeks to months | In-band | Unknown | SCRAM-SHA-1 | SCRAM-SHA-1 | No | No | No | Yes |
| magicbroccoli.de | 7 days | In-band | Unknown | SCRAM-SHA-1 | SCRAM-SHA-1 | No | No | No | Yes |
| meckerspace.de | Unknown | In-band | Unknown | Unknown | SCRAM-SHA-1 | No | No | No | No |
| monocles.de | Presumably 7 days | Javascript+email | Backups stored. Duration unspecified. | Unknown | PLAIN | No | No | No | Yes |
| movim.eu | 14 days | hCaptcha | Backup of database made daily. Refreshed each night (presumably overwritten?) | Unknown | SCRAM-SHA-1 | No | No | No | Yes |
| neko.im | Presumably no logs stored | Unknown | Unknown | TBD | No | No | No | Yes | |
| nixnet.services | Indefinite | In-band | Unknown | Unknown | SCRAM-SHA-1 | Yes | No | No | Yes |
| og.im | No logs | In-band | Unknown | Unknown | SCRAM-SHA-1 | No | No | Site connects to Google | Yes |
| pimux.de | No logs | In-band | Unknown | SCRAM-SHA-1 | SCRAM-SHA-1 | Yes | No | No | Yes |
| qwik.space | No logs | In-band | Unknown | Unknown | SCRAM-SHA-1 | Yes | No | No | Yes |
| rows.im | No logs | In-band | Unknown | Unknown | SCRAM-SHA-1 | No | No | No | Yes |
| step.im | Vague; could be 20-100 days | In-band | Unknown | SCRAM-SHA-1 | TBD | No | No | Site connects to Google | Yes |
| suchat.org | 14 days | Javascript | Unknown | Unknown | SCRAM-SHA-1 | No | No | No | Yes |
| sure.im | Unspecified | In-band | Unknown | Unknown | PLAIN | No | No | Hosted by Amazon AWS | Yes |
| tchncs.de | IPs not logged | In-band | Unknown | Unknown | SCRAM-SHA-1 | No | No | No | Yes |
| teftera.com | 2 weeks | In-band | Backup of database made daily. Refreshed nightly (overwritten?) | Unknown | TBD | No | No | Site connects to Google | Yes |
| thesecure.biz | Unknown | In-band | Unknown | Unknown | SCRAM-SHA-1 | No | No | No | No |
| trashserver.net | 7 days | Reserves right to backup all server data for up to 6 months | Unknown | TBD | No | No | No | Yes | |
| tunny.xyz | Unknown | Website | Unknown | Unknown | TBD | No | No | No | No |
| vcambria.org | Unknown | In-band | Unknown | Unknown | PLAIN | No | No | No | No |
| xabber.com | Vague; might be a month | reCAPTCHA | Unknown | Unknown | TBD | No | No | Site connects to Google | Yes |
| xmpp.076.ne.jp | Unknown | In-band | Unknown | Unknown | SCRAM-SHA-1 | No | No | No | No |
| xmpp.gg | No logs | In-band | Unknown | Unknown | SCRAM-SHA-1 | No | No | Site connects to Google, Cloudflare | Yes |
| xmpp.is | No logs | reCAPTCHA | Created and synced daily. Duration unspecified. | Unknown | SCRAM-SHA-1 | Yes | Yes | Not beyond reCAPTCHA | Yes |
| xmpp.jp | Unspecified | reCAPTCHA | Unknown | Unknown | TBD | No | No | Not beyond reCAPTCHA | Yes |
| xmpp.sg | Unknown | Broken | Unknown | Unknown | TBD | No | No | Site connects to Google, CloudFlare | No |
| xmpp.worlio.com | Unspecified | Javascript+email | Unknown | Unknown | PLAIN | Yes | No | No | Yes |
| yax.im | 2 weeks | In-band | Unknown | Unknown | SCRAM-SHA-1 | No | No | No | Yes |
| yourdata.forsale | Can be retained for 1 hour | In-band | Taken daily, stored for a month | SCRAM-SHA-1 | TBD | No | No | No | Yes |