[HN Gopher] Notes on privacy and data collection of Matrix.org (...
___________________________________________________________________
Notes on privacy and data collection of Matrix.org (2019)
Author : chester-tan
Score : 96 points
Date : 2021-11-04 09:41 UTC (13 hours ago)
(HTM) web link (gitlab.com)
(TXT) w3m dump (gitlab.com)
| remram wrote:
| Oh wow, I never realized device names were visible to others. Is
| there any use-case for this?
| mike-cardwell wrote:
| Seems pretty private to me. I run a Matrix server (synapse) and
| have a handful of friends in a private encrypted room. Regularly,
| people become unable to read each others messages, for no obvious
| reason. Some cryptic message about not having each others keys or
| whatever. Doesn't get much more private than that.
| ninchuka wrote:
| I've only had this issue when its between 2 people on the same
| HS, but I've never had it happen when I'm talking to someone on
| another HS its weird as hell
| Arathorn wrote:
| This article is over 2 years old and contained a lot of very
| exaggerated concerns and questionable complaints. Some of them
| were legitimate though, and we addressed them at
| https://matrix.org/blog/2019/09/27/privacy-improvements-in-s....
| xbdm wrote:
| I recommend a secure home server, People home servers something
| are not reliable or secure. Got to find a home server to use and
| sign up to. I would recommend using kde.org, As it is 100%
| reliable and secure. Others may very.
|
| Use as much open source applications as possible, And if you want
| to. Do not force anyone to use them, Just be smart in providing
| your information.
|
| I use:
|
| Matrix - It's end to end encrypted but some groups i am in, The
| owners have it disabled for some reason. Keybase - Keybase was
| sold, But still end to end encrypted. Plus i was using it before
| they got sold so. Telegram - Telegram is not end to end encrypted
| by default, Unless you enable secret chats.
| ranger_danger wrote:
| There's no such thing as 100% reliable and secure.
| pkulak wrote:
| It's all tradeoffs. You can't have perfect security, _and_ store
| historical messages on the server, for example. But I use Matrix
| because I don't want ephemeral messaging. Matrix found a way to
| get 99% of the security of Signal while giving me the features I
| need, and that's why I use it.
|
| Plus, I self host, which, in my opinion, more than makes up for
| anything else. Hell, I'd take storing my own plain text over E2E
| on someone else's server even.
| notRobot wrote:
| It's important to note that this is from (2019).
| ninchuka wrote:
| so many people read these things and forget to check when it
| was written, its honestly infuriating since so much could
| easily change related to the article
| dijit wrote:
| I'm of two minds when it comes to reports like this.
|
| On the one hand, of course I _love_ that people have the means to
| audit assumptions.
|
| Both the ability to do so w.r.t the project being transparent and
| open, but also through time and technical ability.
|
| I am, however, a little upset when people poke at minor issues
| (that they themselves see as minor) and speak at length about
| them. *not* because those issues should not be addressed, but
| because it gives ammunition for people who recommend closed
| platforms, or more opportunity for people to think of the
| community as being more divided than it really is.
|
| The more uncertainty a thing is surrounded by: the more people
| are likely to just say "fuck it" and choose any option as long as
| it works, and guess what works? Closed platforms, especially
| those with coherent messaging like facebook or whatsapp.
|
| So, with that in mind: Kudos for such an analysis, but be mindful
| that such a lengthy document that discusses minor issues can
| actually harm the matrix project.
| rglullis wrote:
| I know it is going to sound like an ad-hominem, but once I
| realized that this is from the same person behind the "Grid
| protocol", I immediately closed the tab. This guy seems to be
| on a quixotic vendetta against msxid. It is the third or fourth
| persona (first it was from a personal account, then from his
| company, now he has even a non-profit advocating for privacy)
| that he created to re-hash the same old, _outdated_ and
| irrelevant argument.
|
| And the pathetic thing is, if he had spent more time working on
| his "Grid protocol" instead of pointless nitpicking, maybe he
| would have a lot more credibility on the matter.
| spurgu wrote:
| I don't get this kind of thinking? How does the _why_ of what
| he 's saying influence the _what_? Or even worse,
| _disqualify_ it? If it 's factually correct then the reason
| behind writing it seems quite irrelevant, to me at least.
|
| And you're mentioning it's outdated, which would be natural
| given that the last commit was over two years ago.
| eximius wrote:
| It doesn't, but you can spend less effort engaging with
| someone acting in bad faith.
| rglullis wrote:
| It was outdated two years ago already, people already back
| then assuming good intent and pointed out that the "issues"
| he complained about were being worked on, yet he adamantly
| continued to ignore it and claim that everyone using Matrix
| was being duped and that his implementation of the id
| server was the only way to go. _That is why_.
| spurgu wrote:
| Oh ok, I stand corrected. Wasn't clear to me from your
| original post, but it actually makes sense now that I re-
| read it.
| vorejdajo wrote:
| It is ad-hominem and bias
| junon wrote:
| Ad hom would be saying the author smells like moldy cheese
| and therefore we should disregard his opinion.
|
| The parent comment is not using ad hom. They're critiquing
| the author's work and assessing their credibility based off
| of that. It's perfectly fine, and a great viewpoint to
| consider.
| colordrops wrote:
| Is pointing out conflict of interest and hominem?
| capableweb wrote:
| > So, with that in mind: Kudos for such an analysis, but be
| mindful that such a lengthy document that discusses minor
| issues can actually harm the matrix project.
|
| Under "Purpose and Scope":
|
| > This document is a research paper by Libre Monde ASBL,
| nonprofit dedicated to protecting people's privacy. We had the
| need to document privacy points for The Grid Protocol project,
| fork of the Matrix protocol.
|
| So seems that they probably won't have issues with that it
| might harm Matrix, as they are a direct competitor. In fact,
| that might be why they are focusing on the issues they find,
| minors one included.
| southerntofu wrote:
| > So seems that they probably won't have issues with that it
| might harm Matrix, as they are a direct competitor.
|
| I was not aware of the Grid project, but they seem to make
| good points. Matrix is developed by a restricted group of
| people with a startup vibe and some cringy/questionable
| actions:
|
| - spitting on other protocols (or not even acknowledging
| their existence) without a technical reasoning (Matrix could
| have been a "simple" decentralized room extension of XMPP or
| any other established protocol) ; which takes us to the
| situation where Matrix has the exact same selling points
| which XMPP had 20 years ago... and keeps on reinventing the
| wheel
|
| - pushing for a broken state resolution algorithm
| (decentralized consensus) without a formal analysis, which
| means it's now reached its 5th or 6th version and Matrix
| clients are all incompatible with one another (because only
| Element implements them all) and once they have been upgraded
| rooms cannot be downgraded so in many places only Element can
| chat
|
| - requiring a web rendering engine for certain extensions
| (eg. Video chat) ; HTTP is a decent foundation for a
| protocol, but why is a Jitsi <iframe> considered a decent
| extension mechanism? it will just harm security/privacy
| (through potential XSS) and make it near-impossible for
| clients to be implemented without a Chrome-based engine,
| reinforcing Google's monopoly on the web
|
| - putting all of their $$$$ into a single web client with
| very bad performance, not caring for other platforms; beyond
| clients, investing in bridging with useless platforms like
| Microsoft Teams (though i did not find the code for that)
| while neglecting interop with open protocols like IRC/XMPP
| (relations with IRC/XMPP people are notoriously not very good
| though i hope it will improve over time)
|
| All in all, i'm very glad matrix exists because they have
| popularized bridging and they do care for UX concerns like
| Spaces. But claiming people who forked the project because of
| political and technical disagreements are biased because they
| are a "competitor" is itself a very biased position based on
| the idea that only one true protocol must remain and others
| are heretics trying to undermine our technical purity (for
| their economic gain).
|
| I wish we could have people from different protocols sitting
| across the table and working on interop so we can stop
| arguing about which network is best.
| novocaine wrote:
| > putting all of their $$$$ into a single web client with
| very bad performance, not caring for other platforms;
|
| hrm, maybe this was true a few years ago?
|
| Element currently develops _two_ web clients. Element Web:
| https://matrix.org/docs/projects/client/element and
| Hydrogen: https://matrix.org/docs/projects/client/hydrogen
|
| Element also sponsors development of at least one other
| community web client that I know of.
|
| Meanwhile, you can find Element's Android client here:
| https://matrix.org/docs/projects/client/element-android
|
| And the iOS client here:
| https://matrix.org/docs/projects/client/element-ios
|
| Within Element, new features are developed in cross-
| functional teams and released in tandem; e.g. Spaces was
| released on web and mobile at the same time.
|
| On performance - there are definitely some performance
| issues with matrix clients in general, particularly larger
| rooms and accounts which are in many rooms. This is an
| active focus of development, e.g. see work on sync v3, a
| more efficient matrix sync protocol
| https://github.com/matrix-org/sync-v3
|
| Disclaimer: I am an Element employee
| GekkePrutser wrote:
| The Jitsi thing is going away, matrix already has its own
| video chat for 1:1 chats, and it's coming for rooms soon
| too. The Jitsi option was a temporary setup.
|
| The clean rooms approach is a good thing I think. Xmpp is
| becoming a pileup of different add-ons and suffers from the
| same issues you mention for matrix (not all features
| supported by all clients). Probably in a worse way.
|
| I know the reluctance of IRC operators to allow (global)
| matrix bridges is often a case of different paradigms. On
| IRC a conversation can only be seen by users who are
| present at the time. A user joining a bridged matrix room
| can see the entire history from before they joined. This
| changes the privacy model a lot (insofar as IRC has any
| semblance of privacy, but whatever is there is regarded as
| very important). People running their own Heisenbridge
| puppeting bridges solves this issue though.
|
| I'm not a matrix dev but I do like it, especially the
| phenomenon of bridges.
| Maakuth wrote:
| > A user joining a bridged matrix room can see the entire
| history from before they joined.
|
| This is not the case, Matrix rooms can be set to allow
| viewing history only from joining time on. And that is
| how IRC bridge rooms are mostly configured, indeed based
| on policies from the bridged IRC networks.
| GekkePrutser wrote:
| Ah ok I remember this was a problem that was mentioned by
| the hackint network when people wanted to add a bridge
| there. We moved our community to OFTC as a result.
|
| Perhaps this was only introduced later? I'm talking about
| 3 years ago. But good to see this was fixed.
| ryukafalz wrote:
| > pushing for a broken state resolution algorithm
| (decentralized consensus) without a formal analysis, which
| means it's now reached its 5th or 6th version and Matrix
| clients are all incompatible with one another (because only
| Element implements them all) and once they have been
| upgraded rooms cannot be downgraded so in many places only
| Element can chat
|
| This is false. Clients don't do state res, servers do.
| Clients don't care.
| pkulak wrote:
| Yeah, I didn't want to say anything because I'm no
| expert, but as far as I can tell, Matrix clients use a
| Rest API. It's not like they are resolving state deltas
| locally or something. It seems like the big complexity
| right now is the encryption, since that, by definition,
| has to happen on the client. There's a concerted effort,
| however, to make that as easy as possible with shared
| libraries and such.
| Arathorn wrote:
| Meanwhile on the serverside, there have only been two
| versions of state resolution; the original beta version
| that turned out to be buggy, and the current fixed one
| which has been heavily scrutinized and is okay:
| https://matrix.org/blog/2020/06/16/matrix-decomposition-
| an-i....
|
| The amount of incorrect info in the GP post is very
| unfortunate - although I too wish that open standard
| comms protocols spent more time collaborating than
| spitting at each other.
| gefhfff wrote:
| > which takes us to the situation where Matrix has the
| exact same selling points which XMPP had 20 years ago...
| and keeps on reinventing the wheel
|
| I don't get it. XMPP had MEGOLM, cross signing,
| decentralized chat rooms, good iOS support in practice,
| very simple sync of e2ee chat history, ... 20 years ago?
|
| > spitting on other protocols (or not even acknowledging
| their existence) without a technical reasoning (Matrix
| could have been a "simple" decentralized room extension of
| XMPP or any other established protocol) ;
|
| This simply so wrong: Matrix was created exactly because if
| the failure of existing protocols [0]. And the mentioned
| extension was one failure in their mind.
|
| [0]: https://matrix.org/faq/#why-has-no-one-done-this-
| before%3F
|
| And imho it was the best thing to do. You don't repair a
| car if repairing costs much more than getting a new one
|
| > pushing for a broken state resolution algorithm
| (decentralized consensus) without a formal analysis, which
| means it's now reached its 5th or 6th version and Matrix
|
| In fact there are 9 versions today. Though afaik only one
| of them was due to a broken consensus algorithm. Others
| exist for new features. Strangely I can use even the latest
| ones with alternative clients such as Fluffy Chat -
| contrary to your claims
|
| > but why is a Jitsi <iframe> considered a decent extension
| mechanism
|
| It is? Source needed
|
| Native Matrix video chat is being implemented as of now
|
| > putting all of their $$$$ into a single web client with
| very bad performance, not caring for other platforms
|
| Also wrong: Element has a native Android and a native iOS
| clie t
| ninchuka wrote:
| I feel like they are just throwing out lots of old
| information they read without checking if its still true,
| since its up to room version 9 now :P and like you said
| they are working on native video calls in matrix
| ThePhysicist wrote:
| IMHO, aspects like metadata and application security are often
| much more important than the cryptographic protocol when
| assessing the security of a system like a messenger. People e.g.
| love to celebrate the Signal protocol because of its double-
| ratchet key rotation scheme, which is of course great and
| provides a little bit of additional security, but the other
| technical and organizational aspects of the system are just as
| important to assure privacy and security.
|
| From that angle I like systems like Matrix way more than
| centralized solutions like Signal, Threema etc., because the
| whole security and privacy guarantees of the latter can be
| completely nullified by a single software update. If users don't
| have full control over the software running on the endpoint then
| end to end encryption is little more than a marketing gag, IMHO.
| southerntofu wrote:
| Unless something has changed in the past years, Signal and
| Matrix have this in common that any room you join displays your
| identifier for every one to see (phone number / MXID) publicly,
| leading to problems of harassment/spam.
|
| But i entirely agree with your point that relying on a single
| actor for updates/security is really the worst.
| phicoh wrote:
| I'd say that revealing a phone number is probably worse than
| a matrix ID. But indeed, it would be nice if miatrix clients
| from element would support multiple identities.
|
| Then you can join a room with a disposable account.
| Zash wrote:
| One of the nice things with XMPP, where in public channels
| your address is generally only shown to room moderators, not
| to all participants.
| mikro2nd wrote:
| An project that looks interesting to me is Cwtch, precisely for
| its focus on metadata leak-resistance. It seems to be more of a
| research-focussed project right now, but I think looking in
| exactly the right direction.
| thepangolino wrote:
| And meanwhile people keep on ignoring Tox when not sh*ting on it.
| ad404b8a372f2b9 wrote:
| Hadn't heard of it before. It looks really good, any particular
| reason people shit on it?
| aero-glide2 wrote:
| Both have to be online to transmit messages. As there is no
| server.
| snvzz wrote:
| With grease around that. Clients will buffer offline
| messages, and send them when the other end is online.
|
| More or less how skype used to work, before it got bought
| by Microsoft and centralized.
| SuchAnonMuchWow wrote:
| That doesn't work if you are never (or not often) online
| at the same time as the other.
|
| I use signal to chat with my cousin who is in another
| continent, and he is online only when within reach of
| public wifi when he's outside, which is at night for me.
| My phone is always connected to 4G, so maybe what you
| propose could work in this specific case, but in other
| cases it could be an issue.
| snvzz wrote:
| >That doesn't work if you are never (or not often) online
| at the same time as the other.
|
| If that was the case, you'd use email, not a realtime
| chat platform.
|
| And keep in mind, it was never an issue with the old,
| decentralized Skype.
| nani8ot wrote:
| It does not support iOS, which limits it's uses.
| akvadrako wrote:
| I've never heard of Tox, but it doesn't even have an iOS
| client. That's a good reason to ignore it.
| INTPenis wrote:
| That's such a silly statement when you're a slave to Apple,
| which is closed source.
|
| You could be using an open source, non-googled, android OS
| with an open source Tox or Briar client.
| geraltofrivia wrote:
| Sure, you could. How many people do? I don't. I could. But
| that doesn't solve my problem with Tox.
|
| I use IM apps to keep in touch with people in my social
| circle. I've been coercing a lot of my close friends to
| switch to Matrix (I use the word "element" because they're
| not tech savy and I don't want them to be too off-put), and
| some of them actually do.
|
| If Tox does not have an app on iOS store, that, as of now,
| makes it impossible for me to suggest it to approx. 60% of
| my friends, folks I exchange instant messages with, on a
| daily basis. Due to this, I'm sure you could see why this
| limitation makes this platform/service absolutely useless
| for me.
| Multicomp wrote:
| from a certain pragmatic sense, I agree with you. a
| messenger app that wants wide adoption needs to have
| clients for the devices the userbase uses. adding device
| switching costs on top of app switching costs is not
| something i'm after.
|
| granted my goal is simply to have just a bit more privacy
| than the plaintext bulk scanning that messenger does, so
| i use centralized signal rather than something 'purer'
| like running my own matrix. (though i do run my own
| zulip)
|
| matrix p2p at general availability will be my next move
| after signal once signal has its next big outage
| southerntofu wrote:
| > If Tox does not have an app on iOS store, that, as of
| now, makes it impossible for me to suggest it to approx.
| 60% of my friends
|
| If iOS does not allow 3rd party programs on "their"
| phones (or GPL'ed software on their "store"), that, as of
| now, makes it impossible for me to suggest it to 100% of
| my friends. It's easy to shift the blame on volunteer
| developers when you have a multi-billion corporation
| making their lives miserable (see also the background
| notification issue on iOS).
|
| Also, mostly rich people use iPhones. The rest of us use
| cheap Android devices or dumb phones... iPhones are non-
| existent in my social circles, except for the odd second-
| hand-with-broken-screen iPhone someone got for free.
| ranger_danger wrote:
| Sounds like the bigger issue is your friends do not care
| about privacy.
| geraltofrivia wrote:
| > iOS does not allow 3rd party programs [ ... ] or GPL'ed
| software ...
|
| I one hundred percent agree that not allowing GPL
| software on the store is problematic. I am still torn on
| whether not allowing 3rd party programs on their store is
| problematic or not. As a person on HN, of course I would
| LOVE if they did allow third party stores/downloading
| application distributables and executing them.
|
| But considering the innovative nature of malware/spyware
| and the tech-illiteracy of my mother, I can't help but
| feel if she isn't better off on a platform where
| applications go through _some_ form of human
| verification, and a random pop up on some random website
| would not end in her details being leaked/accounts being
| hacked/phone being bricked?
|
| > iPhones are non-existent in my social circles
|
| That's a fair point. Developing one less app would make
| the turn around time for the rest of the stuff faster for
| the supported platforms. At some point of time though,
| the folks behind Tox would need to min-max this out for
| optimal availability and usability.
| ulzeraj wrote:
| I do care about all those things but after that response I
| might keep ignoring Tox for a while.
| forgotmypw17 wrote:
| Is that like ignoring something because it doesn't have an
| AOL keyword?
| hansel_der wrote:
| no, it is ignoring a communcation service that probably
| (acording to market share) half of your contacts cannot use
| 3np wrote:
| (Aug 2019)
|
| A lot has happened in and around Matrix since. While this looks
| like an honest and thorough review, as it's focusing on defaults
| and UX/expectations, I'm assuming several things to be outdated.
| Maybe some of the critique brought up here has even resulted in
| changes in docs, Element and Synapse already.
|
| Haven't yet read thoroughly enough to say what, will probably
| follow up here later.
|
| Note that mxisd (the "only other identity server" referenced),
| from the paper authors, is now deprecated and part of their "Grid
| Server". A community-maintained fork lives on as ma1sd. AFAIK
| this is the one identity server software to consider for self-
| hosters.
|
| Also for those new to Matrix, "Riot" referenced is now rebranded
| as "Element Messenger".
| ajvs wrote:
| These issues I'd consider pretty crucial to approaching Signal-
| like privacy and there's not been much progress on them
| unfortunately: https://github.com/matrix-org/matrix-doc/pull/1769
| https://github.com/vector-im/element-web/issues/11655
| https://github.com/vector-im/element-web/issues/2320
| https://github.com/vector-im/element-web/issues/2772
| https://github.com/vector-im/element-web/issues/2458
| fsflover wrote:
| Unfortunately Signal is a walled garden actively fighting
| against alternative clients and servers. This is enough for me
| to avoid it and recommend Matrix. If you feel that those issues
| are critical, please donate your money or time to solve them.
| tptacek wrote:
| This isn't responsive to the previous comment. Either the
| messenger meets or exceeds the privacy and security of Signal
| or it doesn't. If it doesn't, that's material regardless of
| what you believe about the aesthetics of Signal or their
| communitarian spirit. Most people who use secure messengers
| are LARPing (often in a good-willed performative way, as a
| way of supporting the privacy of others who truly need it).
|
| But some people aren't LARPing, truly need privacy, and
| compromising their safety to make a point about federation is
| immoral.
| fsflover wrote:
| Security is not everything there is to want from a
| messenger. Due to its centralized approach, Signal is
| having a problem with financing and I doubt it can be
| easily solved. It had a large downtime recently. Also, it
| becomes an easy target for all kinds of bad actors, since
| it's the single server. I trust it less for those reasons,
| even if it's "secure" by your standards. I just don't see
| it being secure long-term, not enough to suggest it to my
| friends or use myself.
|
| People who truly need privacy in the short term, should
| consult a professional and not trust random comments from
| strangers.
| tptacek wrote:
| I agree that security isn't everything there is to want
| from a messenger. But when the question being asked is
| "which messengers are secure", _it is the only question
| that matters_.
| fsflover wrote:
| No, there is also a question "how long can this messenger
| stay secure?" In case of Signal, IMHO, the answer is "not
| very long".
| tptacek wrote:
| None of what you've said to support that argument sounded
| persuasive to me. I think it's a pretty transparent
| rhetorical sleight of hand to say "the only way things
| can actually be secure in the long run is for them to be
| federated the way I want them to be". I get it, you want
| to run federated systems that you can build your own
| clients for. The evidence for those kinds of systems
| being the most private runs strongly in the opposite
| direction.
|
| Would you like an example that's especially relevant to
| this thread? Because I can provide you with one.
| fsflover wrote:
| > "the only way things can actually be secure in the long
| run is for them to be federated the way I want them to
| be"
|
| I never mentioned any particular kind of federation that
| I prefer. I also never mentioned word "private", which is
| mostly tangential to federation.
|
| My point is that, in the long run, only federated systems
| are sustainable, because nobody is able to fund huge
| servers with millions of users without infinite money.
| For example, Signal and Telegram are both struggling with
| that currently; the latter introduced advertisement
| recently. On the other hand, Mastodon does not seem to
| have such problem (you could argue that it's too early
| though).
|
| I do not want to build my own clients, I'm not even a
| programmer. I want a _sustainable_ network, which could
| be achieved by a large number of self-hosted instances
| federated with (possibly) large servers. It has been
| working fine with email for decades. Also, the
| competition of various independent clients improves the
| user experience (like any other healthy competition
| elsewhere).
| growse wrote:
| Dismissing a platform that's solving real problems for
| real people right now because it might not exist in 5
| years is a pretty weird thing to do.
|
| "Sustainability" is arbitrary. Everything burns
| eventually.
| tptacek wrote:
| Yeah. How'd that work out for Matrix? Here's a hint: find
| out when the project was started, and when the network
| first _required_ end-to-end encryption. Warning: the
| answer to that entirely vindicates Signal 's position on
| federation; you may not like it.
|
| That doesn't make Matrix bad. It makes Matrix
| _different_. Matrix has different goals than Signal, and
| those goals simply prioritize security and privacy
| differently than Signal does.
| Arathorn wrote:
| I'll bite: we first created Matrix in 2014; we started
| implementing E2EE in 2016 and we turned it on by default
| in 2020. The reason it took so long was because we
| focused first on getting decentralisation (not
| federation) correct, and then the protocol started to get
| prematurely successful and we got sucked into ensuring
| the implementations (and spec) scaled and the governance
| was correct... even before E2EE was stable enough to be
| on by default.
|
| You're completely right that we have different goals to
| Signal (openness + freedom rather than privacy-at-all-
| costs), but I'm not sure that blaming federation is the
| right answer here. We just prioritised building an open
| standard over having E2EE from day 1, instead choosing to
| design things so we could add it later.
| m-p-3 wrote:
| And Signal forces you to use your phone number as your
| identifier, which can be traced relatively easily to a person
| or at least a geographical position by the authorities.
|
| The content of the message might be encrypted, but metadata
| can provide valuable intelligence insights.
|
| At least Matrix can be used mostly anonymously through a
| user-generated identifier, without an email address or phone
| number, and can be used through Tor.
| shapefrog wrote:
| > And Signal forces you to use your phone number as your
| identifier
|
| Signal forces you to use "a" phone number as your
| identifier. It does not have to be your primary phone
| number, or home phone number or office phone number. Just a
| phone number that you have control of.
| fsflover wrote:
| > Just a phone number that you have control of.
|
| In most parts of the world, you cannot get "just" a phone
| number not tied to your real identity.
| snark42 wrote:
| Prepaid cellular phones and Google Voice aren't available
| in most parts of the world with a little effort?
| fsflover wrote:
| I was speaking about the prepaid cellular phones. Again,
| in most parts of the world, you cannot get an anonymous
| sim-card. AFAIK you also cannot create a Google account
| without a phone number.
| BeatLeJuce wrote:
| I recently changed my mind on this: being able to use phone
| numbers as identifiers also has some benefits: Last time I
| was on vacation, it was easy to get in touch with service
| providers (e.g. surf school, massage place) via WhatsApp,
| simply because I had their number, and everyone used
| WhatsApp anyways. If Signal would be more popular, I could
| instead contact them directly via Signal, since I only need
| their phone number. It allows for a more seamless
| transition.
|
| Matrix OTOH would have a harder time getting adopted:
| businesses would need to update their websites, facebook
| pages and flyers to add the matrix contact info. Which they
| wouldn't do until Matrix is more popular. Which is a
| chicken and egg problem.
| hansel_der wrote:
| > being able to use phone numbers as identifiers also has
| some benefits
|
| of course it has, but so has the ability to NOT use a
| phone number. different use cases
| bilkow wrote:
| Although optional, matrix actually has identity servers,
| which allow people to find you via phone number / email.
| 3np wrote:
| Matrix still has 3pids, including phone number and email.
|
| The most common client, Element, will by default ask you
| for your phone number when registering with the default
| matrix.org homeserver and the default vector.im identity
| server will associate your phone number with your matrix
| user.
|
| So by default (changing servers and/or opting out is easy
| and encouraged BTW), Matrix already works like you would
| prefer.
|
| This is BTW a main critique in the OP since it makes
| vector.im a PII and metadata aggregator.
| spurgu wrote:
| > The content of the message might be encrypted, but
| metadata can provide valuable intelligence insights.
|
| What metadata? Signal doesn't store anything about you
| aside the date you joined and the time of your last ping.
| uoaei wrote:
| Data is sent over a network, and has an origin and
| destination. Of course Signal wouldn't store things like
| that, but the network administrator wouldn't have much
| trouble collecting extra metadata such as that on top of
| what is stored.
| bigyellow wrote:
| > Signal doesn't store anything about you aside the date
| you joined and the time of your last ping.
|
| Last I checked, Signal uses AWS, Azure and GCP. All of
| those services are completely logged and although
| "Signal" may not be storing metadata, intelligence
| services on those networks definitely are.
| EGreg wrote:
| In terms of closed centralized services, I'd say Telegram is
| my top pick, followed by Signal. But I would take open source
| decentralized networks over them anyday, and my favorite is
| Freenet, or the much newer network, MaidSAFE because it is
| the most secure thing I have ever seen (but that's not
| mainstream yet).
| XorNot wrote:
| Telegram is not encrypted E2E by default at all.
| this_user wrote:
| And the encryption they are offering is custom, which is
| always at least suspect.
| EGreg wrote:
| I actually trust it more to not have backdoors. Signal is
| written by the same guys who sold to Facebook, and
| although both Moxie and Pavel are anarchists, I trust the
| guys who were actually ousted from their own country and
| yes, rolled their own encryption (with bounties to break
| it) rather than use an officially approved one
|
| https://twitter.com/durov/status/872891017418113024?lang=
| en
|
| https://telegra.ph/Why-Using-WhatsApp-Is-
| Dangerous-01-30-4
|
| Besides - Moxie is kind of against decentralization, he
| thinks that by centralizing trust in a certain entity,
| things can be better. I am not convinced that such an
| approach leads to a better model for me to have encrypted
| communications:
|
| https://news.ycombinator.com/item?id=21904469
|
| I like that Signal started using SGX though. It's not
| ideal (now I have to trust Intel instead) but at least if
| you're going to be running some code on a centralized
| service instead of byzantine consensus, let me know you
| aren't backdooring it:
|
| https://medium.com/@maniacbolts/signal-increases-their-
| relia...
| EGreg wrote:
| I don't need it encrypted BY DEFAULT. If I want to
| encrypt something, I can. It also means the chats aren't
| available on other devices and you lose other
| capabilities
| fsflover wrote:
| > It also means the chats aren't available on other
| devices
|
| Not, it doesn't. You would just need to copy the private
| key to the other devices.
| fsflover wrote:
| How about Ricochet instant messenger or I2P?
| Snitch-Thursday wrote:
| Think Ricochet got replaced by cwtch.im correct? At least
| the binaries I can find of Ricochet are super stale.
| fsflover wrote:
| https://www.ricochetrefresh.net/
| kown7 wrote:
| I don't see the allure of Telegram over anything; can you
| elaborate?
| hansel_der wrote:
| it works very well on every device/os and can easily be
| extended
| EGreg wrote:
| More user friendly
|
| Crypto that I trust more than Signal
|
| Far more documented and open (even though backend is not)
|
| Supports many clients
| foxfluff wrote:
| I think this one is also pretty bad. And years later still not
| fixed. https://github.com/vector-im/element-web/issues/2527
|
| In short? When you look at a room, your client sends a (public)
| read receipt. So stalkers get near-realtime data on your
| activity and the simple act of viewing different rooms (and
| maybe even just focusing the window) to see what's up causes
| data to be sent to the server. Ugh.
| [deleted]
___________________________________________________________________
(page generated 2021-11-04 23:02 UTC)