Much of the rest is incorrect or hyperbolic however
I think you need to do better than that. I'll avoid duplicating my reply from Hacker News and focus on fact checking. When we put together our research, we used a very simple methodology:
Anyone who believe we are incorrect can simply use the following methods to double check everything:
tail -f, that will contain each endpoint called and when; we give links to the related endpoints.You certainly try hard to present the whole research under a worse light by pointing to proposals that are not implement yet, but those are irrelevant. The point of this document is not to give Matrix.org a list of things to improve for whenever they feel like it. The point of this document is to tell Matrix users what is happening, so they can start hardening their config if they care. That you plan to solve the issues at some point in the future doesn't change the fact that those are happening right now, and some for years and years.
You have every right to reply to such a research document if you believe it is incorrect. But then I ask that you do so in a respectful manner, by showing with hard facts and protocol exchanges that things are not happening in a comprehensive manner. I did not work alone on this document, far from it. Please be mindful that we worked hard to put this together, but we did not do it for you. We did it for Matrix users who are unaware of what is going on. We did it for Grid users who want something better.
And because we strongly believe we should put our money where our mouth is, we will work on not having such leaks in The Grid protocol, Gridepo and Soler. This certainly should show with hard facts that much of this document is not, as you put it, incorrect.
Which service would you recommend instead?
@juliangaal We purposefully held off making any recommendation, because the research highlights many issues/behaviour that can be solved in several ways. Each way would depend on your use case. We can discuss it further in the Matrix room (see end of the paper). We wish to keep this research page neutral.
@maxidorius I understand. Great work nevertheless
For anyone subscribed, we have corrected some sections, added several new sections and new identified leaks thanks to Community feedback since the original publishing! See the revisions.
@ara4n Given that we're not going to be significantly changing the doc anymore, as the target audience has given us the feedback we were looking for, I'll wrap this up by answering your notes at the time posted as a gesture of good faith and respect. I'll use the comment numbering from the PDF directly.
The integration manager is closed source, and its behaviour has been documented here. So the only way to learn about its behaviour was to reverse engineer it with the client and the homeserver. Reverse engineering is factual and we did use it. 100% relevant.
Does it really?. It can, but it doesn't have to. It's just your choice is making synapse do it.
The document does not say it is mandatory. Only that the user is strongly pushed to do it.
The document does not say it is mandatory. Only that the user is not informed of the specifics (single contact vs the whole phonebook).
Except that's not what we're talking about. You're in the TL;DR section, read everything first.
That the file is called "MatthewPicture2015.jpg" or "dkjkjfoeDSDfdsfkERR" makes no difference that it's publicly accessible. And that all files in the repo are. There is no access control.
But encryption is not enabled by default, and the doc states it reviews default behaviour.
all of the current non-centralised identity servers (e.g. mxisd) either restrict you from being contactable(by not publishing your email address to the wider identity db) or from being able to contact people (because their emails are not published on the wider identity db)
Let's get some facts straight:
So while the previous quoted statement is technically correct as of today, ignoring everything since start of 2017, the following is not:
The fact that mxisd can delegate lookups to the vector.im server doesn't change this, and this is why the warning exists. This is also why we've been holding out for genuinely decentralised rather than federated identity architecture to replace sydent.
You haven't been holding out for decentralised because of mxisd since mxisd supported the needed features for at least 18 months. During that time, you never reached out to us despite our efforts. Matrix.org always had higher priorities than Identity and privacy.
mxisd is NOT the reason why no progress was made. Your prioritization which you did all on your own is. We can also talk about how you deprioritized working on 1194 purposefully only because I requested updates about it and triggered its own Email removal section.
You have been well-informed about mxisd capabilities which you even mentioned in FOSDEM presentations in 2017 (or maybe 2018, possibly both). Dave is in the room and his role as a core board member is to be aware of what is going on. You have been purposefully lying about this for years now in an attempt to hide what mxisd could accomplish while remaining spec compliant. Why?
There are at least two other identity serve implementations out there, fwiw
You highlighted this:
only other
but the full sentence is this:
Riot devs are well aware of the only other Identity server mxisd which federates and can include data from vector.im.
Please give a link to the source that those two fit the requirements in the same sentence: which federates and can include data from vector.im..
We agree.
Thank you for confirming that our statement is factually correct.
Thank you for confirming that our statement is factually correct.
So to find the privacy policy of vector.im we need to go to github.com, then find a doc under a matrix.org folder...
How is a user new to Matrix supposed to know that if all they see is vector.im in the Identity Server URL field of their client?
What about a link on your main website: https://vector.im/?
Ok for the oversight.
But you still need the Identity server to add the Email to the user setting, right? Your comment seems out of place.
This is considered acceptable UX; if a user is trusting the HS to deliver them messages reliably, it is also reasonable to trust the HS to unbind 3PIDs non-maliciously rather than pester the user with confirmation, given the user already confirmed they wanted the HS to bind the 3PID in the first place
We shown in the document in the first section of Riot that the user was never told about the binding. That would make your UX unacceptable, right?
It is obvious that the act of locating people by email address and phone number will involve sharing them.
Yes, for the people that the user wants to talk to, not for the full address book before the user can even start looking for the contact. What about only when a person click on the contact they are interested in? (or whatever UX you could wipe up).
OK.
OK.
My gut feeling is that it would be stated in their terms of services or their cookie policy which you need to accept upon using their services. Double checking will be left as an exercise to the readers. I don't think explaining why it's set makes it any relevant when the website is very sensitive to privacy. You would definitely not want that to be set.
The research paper does not have proposals in scope, only spec documents published as standard/stable at the time of writing.
I don't see the relevance of your comment. We gave the link so people can see the request/response. That it's federation doesn't matter to the point made.
Until we wrote the doc (so not including your last comment on it written after), the bug never talked about removing the calls, just to not duplicate them. The privacy issue around it is not even mentioned once, and the issue is open for ~18 months. That it was already documented would not have helped for the issue at hand.
Do you have some other documentation that shows you were aware of the privacy issue around the behaviour, or that the behaviour was problematic in the first place?
The context that you miss to quote in its entirety (emphasis mine):
vector.im is receiving the following information without the user's knowledge, some without the user even opening the Integration server window:
- A steady stream of requests directly related to user activity and usage pattern of Riot and Matrix.
- Their Matrix ID and their IP, Riot directly connecting to scalar.vector.im.
- The rooms which the user is part of.
The sentence means:
In both cases, the request you've given as an example is indeed the one. Thank you for confirming this is factually correct.
Github again? Is this link also given one way or another to the user directly in Riot when they use the integration manager? If yes, could you show us a screenshot please?
Yes, and the document specifically state at the beginning that default settings is what is taken into account, which is therefore well in scope.
Thank you for confirming that our statement is factually correct.
Yes, and the document specifically state at the beginning that default settings is what is taken into account, which is therefore well in scope.
Thank you for confirming that our statement is factually correct.
I believe we are now at our 3rd one.
Which is the case by default as per comment 26.
Thank you for confirming that our statement is factually correct.
But it is secure right? You do not seem to oppose the statement.
But End-to-End encryption is not enabled by default, so it's not in scope of this document.
So for now, they are not.
Thank you for confirming that our statement is factually correct.
We recognise we used a bad example to illustrate that the files are forever accessible under the same ID. We have corrected our document with a better illustration. Thank you for pointing it out.
But still in use. And I'm guessing always been in use. So it only was obvious during reverse engineering (!).
Thank you for confirming that our statement is factually correct.
Thank you for confirming that our statement is factually correct.
OK
Double check your document. Your copy/paste screwed up the formatting and the full context is there. Compare with the Gist view of the original doc.
About other Homeservers being affected in their use of the Matrix.org services by the outage: Thank you for confirming that our statement is factually correct. The context is clear and the next sentence specifically list what was affected. We do not state that they were compromised. The next section talks about how they could have been impacted from a security point of view, or be affected by Denial of Service.
We removed that sentence soon after reading your feedback. Thank you for clarifying.
Thank you for confirming the impact that the pattern of centralisation outlined in this document could have allowed the attacker to do "a lot of very unpleasant things".
Thank you for confirming that our statement is factually correct.
Let's respectfully agree to disagree.
We've clarified our wording soon after seeing your feedback of taking a sentence out of the important context. We recognise that our wording could have been misleading.
OK, but you do not answer the questions. GDPR is a law in effect for more than a year. You simply cannot process the personal identifiable data that you currently get without a lawful basis.
What is the lawful basis under which you process their personal data, since we've illustrated all over the document that you do not get informed consent?
I did disclose Grid in previous research document like The Server ACL one, but you used it against us to say "look, they are promoting their hostile fork by using Matrix weaknesses instead of contributing to it!". Now that we don't and make sure it's only about Matrix in the document, you also use it against us. You also never fail to slander us for something which is your own fault in the official Matrix rooms.
So here is me asking you officially, in a public setting, on record: Which one do you want? Disclosure or not disclosure?
I hope all the links, sources and issues I have linked and mentioned here are proof enough that I was very much trying to make you aware of all of this, but nobody was listening, or was purposefully dragging their feet to make a point instead of thinking for their users.
@ara4n Following some links in my own links, I came accross this old issue: prism-break#1936 where I list the main concerns that I've re-documented in details in this research paper.
To which you reply. So you've been aware of the major points of this document for more than a year now. I believe this changes some of your comments where you claim ignorance or oversight.
We also mentionned having Google TURN servers hardcoded, and it seems like this issue is still happening on mobile clients. Could you confirm or deny?
You have been well-informed about mxisd capabilities which you even mentioned in FOSDEM presentations in 2017 (or maybe 2018, possibly both). Dave is in the room and his role as a core board member is to be aware of what is going on. You have been purposefully lying about this for years now in an attempt to hide what mxisd could accomplish while remaining spec compliant. Why?
You are accusing me of "purposefully lying for years" in paragraphs of shouty bold text, while simultaneously acknowledging that I've been promoting mxisd and its capabilities in my talks. (And for that matter we've also been promoting it on matrix.org/blog). This is an almost farcical paradox. It's also starting to sound as if the root of all your unhappiness here may be due to feeling upset that mxisd doesn't get more recognition...
I maintain that the point of an IS is to discover people to talk to on Matrix based on 3PID, and the only way today to usably publish yourself as discoverable is by using the logically centralised sydent servers at vector.im/matrix.org. You can of course run a local IS like mxisd, but it will only render you discoverable to users on the same identity server (unless it delegates to the central servers), which is of very limited usage. The mxisd could try querying other ISes based on the domain of the 3pid (if it has a domain), but this relies on the 3pid having the same domain as the mxid, which is pretty unusual in the real world.
I would much rather (as I said to you years ago when trying to provide input into your IS work) that we spent the time instead providing a reliable and privacy-preserving way of letting users globally publish their 3PID->mxid mappings (if they want to), which doesn't depend on centralised servers at all - which is why we haven't prioritised the federated bodge.
An alternative approach would be to use DNS itself or a DNS-equivalent architecture, similar to ENUM, to let servers recurse identity lookups to a root server and then back down to a given deployment-specific server. But as far as I know, mxisd doesn't support that, nor has anyone proposed it as a design. Plus it would still depend on root servers being a SPOF/SPOC, and would suffer all the same attacks as DNS itself - and be tantamount to reinventing the DNS.
This is why we'd rather pursue an approach which is fully decentralised - i.e. a signed shared datastructure of hashed-3pid -> mxids, scoped to whatever visibility the publisher desires, which anyone can participate in hosting, rather than depending on centralised ISes for global lookups to function.
You also never fail to slander us for something which is your own fault in the official Matrix rooms.
I'm sorry you consider this slander(!)
This sort of hyperbolic rhetoric is why we gave up trying to work with you months ago.
I believe this changes some of your comments where you claim ignorance or oversight.
No, the word oversight means "an unintentional failure to [...] do something." - i.e. the issue in question is an unintentional failure, and one which we haven't solved yet.
We also mentionned having Google TURN servers hardcoded, and it seems like this issue is still happening on mobile clients. Could you confirm or deny?
Yup, the bug is still open, and Google STUN is still hooked up as a last resort to help people who have failed to configure their own VoIP servers:
https://github.com/matrix-org/matrix-ios-sdk/blob/develop/MatrixSDK/VoIP/MXCallManager.m#L34
https://github.com/matrix-org/matrix-android-sdk/blob/master/matrix-sdk/src/main/java/org/matrix/androidsdk/call/MXWebRtcCall.java#L602
This is a good example of where a relatively low priority (for us) issue has not been higher prioritised, as it only affects people who have failed to configure TURN servers on their homeservers.
You are accusing me of "purposefully lying for years" in paragraphs of shouty bold text, while simultaneously acknowledging that I've been promoting mxisd and its capabilities in my talks. (And for that matter we've also been promoting it on matrix.org/blog).
Please don't take my sentence out of context and only reply to it like it was a standalone sentence. I give you the courtesy to not do so, please do the same. My sentence is a reply to your comment, which claims mxisd cannot do those things [1] and shifts the blame on us for not moving Matrix forward.
I have shown proof that:
[1] "those things" refer to the two restricted actions of your comment #8, quoting:
Even if you refute we told you, you had every chance to check your facts before making such a statement. So yes, I have no problem claiming you are purposefully lying. The question is to what goal. Please do not comment further on this point unless you can prove you did in fact do your background check of mxisd features/source code and that mxisd cannot technically perform lookup on the central IS due to the lack of code for it.
Yup, the bug is still open, and Google STUN is still hooked up as a last resort to help people who have failed to configure their own VoIP servers:
Thanks, we'll incorporate this important info and create a new section about VoIP altogether. Thank you for this useful feedback.
Edit: It's here
I will not reply to the rest of your comments given their personal nature, and their lack of relevance for the document.
[Edit: removed section that was replying to an irrelevant section by mistake, clarify what those things are]
So after double-checking again, it seems like Comment 38 is not factually correct and that Cloudflare DOES TLS termination, directly having access to all the data in clear.
Here is a Client request done now:
$ curl -sv https://matrix.org/_matrix/client/r0/login
* Trying 2606:4700:10::6814:15ec...
* TCP_NODELAY set
* Connected to matrix.org (2606:4700:10::6814:15ec) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS Unknown, Certificate Status (22):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS change cipher, Client hello (1):
* (304) (OUT), TLS Unknown, Certificate Status (22):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using unknown / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=www.matrix.org
* start date: Jun 11 11:32:44 2019 GMT
* expire date: Sep 9 11:32:44 2019 GMT
* subjectAltName: host "matrix.org" matched cert's "matrix.org"
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* (304) (OUT), TLS Unknown, Unknown (23):
* (304) (OUT), TLS Unknown, Unknown (23):
* (304) (OUT), TLS Unknown, Unknown (23):
* Using Stream ID: 1 (easy handle 0x55974db54580)
* (304) (OUT), TLS Unknown, Unknown (23):
> GET /_matrix/client/r0/login HTTP/2
> Host: matrix.org
> User-Agent: curl/7.58.0
> Accept: */*
>
* (304) (IN), TLS Unknown, Certificate Status (22):
* (304) (IN), TLS handshake, Newsession Ticket (4):
* (304) (IN), TLS handshake, Newsession Ticket (4):
* (304) (IN), TLS Unknown, Unknown (23):
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
* (304) (OUT), TLS Unknown, Unknown (23):
* (304) (IN), TLS Unknown, Unknown (23):
* (304) (IN), TLS Unknown, Unknown (23):
< HTTP/2 200
< date: Sun, 07 Jul 2019 09:39:09 GMT
< content-type: application/json
< set-cookie: __cfduid=dc79ff628c73af629e2cb1ccbe2c117be1562492349; expires=Mon, 06-Jul-20 09:39:09 GMT; path=/; domain=.matrix.org; HttpOnly
< cache-control: no-cache, no-store, must-revalidate
< access-control-allow-origin: *
< access-control-allow-methods: GET, POST, PUT, DELETE, OPTIONS
< access-control-allow-headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: 4f28d9820c6bd4b4-BRU
<
{
"flows": [
{
"type": "m.login.password"
}
]
}
* (304) (IN), TLS Unknown, Unknown (23):
* Connection #0 to host matrix.org left intact
Here is a Federation request done now:
$ curl -sv https://matrix.org:8443/_matrix/federation/v1/version
* Trying 2606:4700:10::6814:14ec...
* TCP_NODELAY set
* Connected to matrix.org (2606:4700:10::6814:14ec) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS Unknown, Certificate Status (22):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS change cipher, Client hello (1):
* (304) (OUT), TLS Unknown, Certificate Status (22):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using unknown / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=www.matrix.org
* start date: Jun 11 11:32:44 2019 GMT
* expire date: Sep 9 11:32:44 2019 GMT
* subjectAltName: host "matrix.org" matched cert's "matrix.org"
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* (304) (OUT), TLS Unknown, Unknown (23):
* (304) (OUT), TLS Unknown, Unknown (23):
* (304) (OUT), TLS Unknown, Unknown (23):
* Using Stream ID: 1 (easy handle 0x56503e398580)
* (304) (OUT), TLS Unknown, Unknown (23):
> GET /_matrix/federation/v1/version HTTP/2
> Host: matrix.org:8443
> User-Agent: curl/7.58.0
> Accept: */*
>
* (304) (IN), TLS Unknown, Certificate Status (22):
* (304) (IN), TLS handshake, Newsession Ticket (4):
* (304) (IN), TLS handshake, Newsession Ticket (4):
* (304) (IN), TLS Unknown, Unknown (23):
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
* (304) (OUT), TLS Unknown, Unknown (23):
* (304) (IN), TLS Unknown, Unknown (23):
* (304) (IN), TLS Unknown, Unknown (23):
< HTTP/2 200
< date: Sun, 07 Jul 2019 09:36:05 GMT
< content-type: application/json
< set-cookie: __cfduid=db97ca0304b4159c2ac95eb7e37e734851562492163; expires=Mon, 06-Jul-20 09:36:03 GMT; path=/; domain=.matrix.org; HttpOnly
< cache-control: no-cache, no-store, must-revalidate
< access-control-allow-origin: *
< access-control-allow-methods: GET, POST, PUT, DELETE, OPTIONS
< access-control-allow-headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: 4f28d4f6fcf5442b-BRU
<
{
"server": {
"name": "Synapse",
"version": "1.1.0rc1 (b=matrix-org-hotfixes,43e01be15)"
}
}
* (304) (IN), TLS Unknown, Unknown (23):
* Connection #0 to host matrix.org left intact
Edit: vector.im as an identity server:
$ curl -sv https://vector.im/_matrix/identity/api/v1 | jq
* Trying 2606:4700:30::681f:475f...
* TCP_NODELAY set
* Connected to vector.im (2606:4700:30::681f:475f) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
} [5 bytes data]
* (304) (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* (304) (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* (304) (IN), TLS Unknown, Certificate Status (22):
{ [1 bytes data]
* (304) (IN), TLS handshake, Unknown (8):
{ [15 bytes data]
* (304) (IN), TLS handshake, Certificate (11):
{ [2170 bytes data]
* (304) (IN), TLS handshake, CERT verify (15):
{ [80 bytes data]
* (304) (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* (304) (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* (304) (OUT), TLS Unknown, Certificate Status (22):
} [1 bytes data]
* (304) (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using unknown / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=CA; L=San Francisco; O=CloudFlare, Inc.; CN=vector.im
* start date: Feb 14 00:00:00 2019 GMT
* expire date: Feb 14 12:00:00 2020 GMT
* subjectAltName: host "vector.im" matched cert's "vector.im"
* issuer: C=US; ST=CA; L=San Francisco; O=CloudFlare, Inc.; CN=CloudFlare Inc ECC CA-2
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
} [5 bytes data]
* (304) (OUT), TLS Unknown, Unknown (23):
} [1 bytes data]
* (304) (OUT), TLS Unknown, Unknown (23):
} [1 bytes data]
* (304) (OUT), TLS Unknown, Unknown (23):
} [1 bytes data]
* Using Stream ID: 1 (easy handle 0x560bab614580)
} [5 bytes data]
* (304) (OUT), TLS Unknown, Unknown (23):
} [1 bytes data]
> GET /_matrix/identity/api/v1 HTTP/2
> Host: vector.im
> User-Agent: curl/7.58.0
> Accept: */*
>
{ [5 bytes data]
* (304) (IN), TLS Unknown, Certificate Status (22):
{ [1 bytes data]
* (304) (IN), TLS handshake, Newsession Ticket (4):
{ [230 bytes data]
* (304) (IN), TLS handshake, Newsession Ticket (4):
{ [230 bytes data]
* (304) (IN), TLS Unknown, Unknown (23):
{ [1 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
} [5 bytes data]
* (304) (OUT), TLS Unknown, Unknown (23):
} [1 bytes data]
* (304) (IN), TLS Unknown, Unknown (23):
{ [1 bytes data]
* (304) (IN), TLS Unknown, Unknown (23):
{ [1 bytes data]
< HTTP/2 200
< date: Sun, 07 Jul 2019 22:57:56 GMT
< content-type: application/json
< set-cookie: __cfduid=d14ef1f6254ebb5c211fdb3493dfabfbf1562540276; expires=Mon, 06-Jul-20 22:57:56 GMT; path=/; domain=.vector.im; HttpOnly
< access-control-allow-methods: GET, POST, PUT, DELETE, OPTIONS
< access-control-allow-origin: *
< access-control-allow-headers: Origin, X-Requested-With, Content-Type, Accept
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: 4f2d6b993a53d4b4-BRU
<
{ [2 bytes data]
* (304) (IN), TLS Unknown, Unknown (23):
{ [1 bytes data]
* Connection #0 to host vector.im left intact
{}
In all cases, we can see the headers set-cookie, server, cf-ray and expect-ct with values set by Cloudflare, which would not be possible if TLS termination was done directly on matrix.org/vector.im servers.
Thanks for the detailed analysis. Some of the points are accurate, specifically:
Much of the rest is incorrect or hyperbolic however, and I've posted a response at https://matrix.org/~matthew/Response_to_-_Notes_on_privacy_and_data_collection_of_Matrix.pdf (apologies for the PDF, but Google Docs doesn't seem to expose a read-only view of commented docs.)