[HN Gopher] Element One - All of Matrix, WhatsApp, Signal and Te...
___________________________________________________________________
Element One - All of Matrix, WhatsApp, Signal and Telegram in one
place
Author : mcjiggerlog
Score : 466 points
Date : 2021-10-26 08:42 UTC (14 hours ago)
(HTM) web link (element.io)
(TXT) w3m dump (element.io)
| mfer wrote:
| From the post...
|
| > It's also worth noting that end-to-end encryption is
| necessarily broken as messages to (and from) WhatsApp, Signal and
| Telegram pass across the bridge(s).
|
| They store everything encrypted but this may open the door for
| legal requests to get access.
| est31 wrote:
| Yeah ideally they should sell e.g. raspberry pi devices which
| allow you to self host it at home.
| jakecopp wrote:
| They don't even need to sell this package, it's free and a
| lot of people do it: https://github.com/spantaleev/matrix-
| docker-ansible-deploy/
|
| The benefit to hosting by a company is it should be more
| reliable.
| superkuh wrote:
| While the software support is there to run bridges to many
| other communications services, the actual bridges are
| direct agreements worked out between the various
| comporations and non-profits. You would have to be
| important enough to start such a dialog and relationship if
| you wanted to run the bridging features locally. So, don't
| expect to bridge to Libera IRC just because there's a
| software option.
|
| You can always run bots, but that's not a real bridge like
| what is being described here.
| mfer wrote:
| That does not sound like the kind of experience general
| consumers expect and it doesn't match Up with their
| subscription model.
| dncornholio wrote:
| Paying for this as a service? No thanks. Too many subscription
| based services already.
| elnygren wrote:
| I already have a way to unify my messaging across different apps.
| It's called MacOS and cmd+tab. Sometimes on the road I use
| something called iOS. Sure it's not the same. But is it that
| different either?
|
| All messaging apps have their own native features, some have E2E
| encryption etc. Not sure if there's a common subset that is
| enjoyable enough to use that it's worth it.
|
| That being said, I do wonder what will be the "Facebook Events"
| (invite all your friends to an event) equivalent in the future
| when everyone is in a closed garden chat platform instead of
| Facebook.
| yetanother-1 wrote:
| I use normal calendar event, it is forwardable, and I get
| confirmations per email who will be coming. I find it to work
| just as well.
| fastball wrote:
| There is definitely a benefit to having a unified interface.
| The vast majority of the time I don't want to use each chat
| apps specific features, I just want to message people. And then
| sometimes I want to be distraction free and turn off
| notifications. This is much easier if everything is routed
| through one app.
|
| I'm also on macOS but I've been using Texts[1] for a few months
| and it has been a great experience.
|
| [1] https://texts.com/
| chirau wrote:
| Do you have an extra invite by any chance?
| fastball wrote:
| Sure if you DM me on Twitter I can send one your way.
| MayeulC wrote:
| It would be nice to see PSTN/SMS as well, those are more
| complicated to self-host!
| bubblethink wrote:
| Whatsapp was $1 a year when they launched, and even that was
| rolled back after the FB acquisition. Ain't nobody got money for
| this.
| stjohnswarts wrote:
| This seems like a really bad idea since it gives another attack
| vector if you're really trying to maintain secure communication.
| modeless wrote:
| I am in the Beeper beta. Beeper supports Matrix, Whatsapp,
| Signal, and Telegram, but also Slack, Discord, Hangouts,
| Instagram, Linkedin, Facebook Messenger, SMS, Twitter, and
| crucially, _iMessage_ on non-Apple devices! It is a beta but it
| works pretty well so far. AMA
| arianvanp wrote:
| The fact that content sent to signal and Whatsapp resides
| unencrypted at the matrix homeserver makes this product
| completely useless to me.
|
| I don't think I want to sacrifice the security for having all my
| chats in one place.
|
| If they can fix that I might reconsider.
|
| They already reverse engineered the Whatsapp protocol. I see
| little reason why it can't live in the client? I don't really
| follow why they move the bridge to the homeserver.
| iforgotpassword wrote:
| Why don't you encrypt your hard drive?
| krageon wrote:
| What problem do you feel this would solve?
| arianvanp wrote:
| I don't follow. What does my hard drive have to do with
| plaintext messages on Element's servers?
| square_usual wrote:
| As far as I can tell, the messages don't live in plaintext
| on Element's servers - they are _bridged_ in plaintext to
| Matrix, which is end to end encrypted.
| iforgotpassword wrote:
| Aj, my bad. I skimmed over the part where it says they are
| hosting the bridge for you. Since matrix is focused on
| privacy etc I assumed this is available as a container/VM I
| can run at home or on a VPS.
|
| Indeed then very weird why I should trust them more with my
| personal data than anybody else.
| IceWreck wrote:
| > Since matrix is focused on privacy etc I assumed this
| is available as a container/VM I can run at home or on a
| VPS.
|
| All bridges, and the matrix homeserver itself have been
| open source and self-hostable for years. I host a
| homeserver + some bridges myself.
|
| This is just the sugar-coated SaaS for people who dont
| want to do it themselves.
| radicalbyte wrote:
| WhatsApp's backups are already stored unencrypted* on Google
| Drive if you use that feature.
|
| * Encrypted with a private key which Google have access to.
| bogwog wrote:
| So the encryption is there so that you can't access your own
| data (and migrate to a competing app/service), rather than to
| protect your privacy. I kind of ran into this issue myself
| when I was helping a family member move to iPhone. Since
| Whatsapp uses Drive on Android and iCloud on iOS, there was
| no way to transfer the data.
|
| I wonder if you can get them via one of those data access
| requests?
| miguelrochefort wrote:
| > They already reverse engineered the Whatsapp protocol. I see
| little reason why it can't live in the client? I don't really
| follow why they move the bridge to the homeserver.
|
| Matrix bridges are rather complex. They rely on a combination
| of private APIs (WhatsApp), Chrome extension scraping (LINE),
| bots (Telegram), mobile clients (Android SMS), and jailbroken
| iPhones (iMessage).
| have_faith wrote:
| This is all very interesting from a technological perspective
| but it sounds incredible brittle. Do I break any terms with
| these 3rd parties by paying Matrix to scrape them?
| miguelrochefort wrote:
| I've been using Beeper.com for a while and it's
| surprisingly stable despite how brittle one would expect
| these bridges to be.
|
| Given that puppeteering should be indistinguishable from
| real application usage and that $5/month/user should be
| more than enough to diversify IP addresses, I suspect the
| model can actually be sustainable in the long term.
| chayleaf wrote:
| they haven't, they simply host a VM with Whatsapp and connect
| to it via Whatsapp Web
| liotier wrote:
| > They already reverse engineered the Whatsapp protocol. I see
| little reason why it can't live in the client ?
|
| Because Whatsapp crushes any client other than their official
| client. Everyone else is confined to scraping Whatsapp Web.
| kjaftaedi wrote:
| At least it's better than getting zero-clicked.
| kirimita wrote:
| Data does not _reside_ unencrypted with End to Bridge
| Encryption : https://docs.mau.fi/bridges/general/end-to-bridge-
| encryption...
| arianvanp wrote:
| But the bridge is not hosted by me but by them. I need to
| trust matrix not to MITM me
| tremon wrote:
| Yes, in the same way that you need to trust Whatsapp not to
| MITM you. What's your perceived difference between these
| trust levels, other than one is something you pay for with
| money, and the other doesn't require money?
| grassjumper wrote:
| The Signal protocol (which WhatsApp still uses, I
| presume) is very good. WhatsApp can't MITM it.
|
| Element, on the other hand, is MITM by design.
| crossroadsguy wrote:
| It's for power users (assuming it actually works as advertised) -
| people who constantly keep messaging across apps; either for
| personal or professional needs. They already have multiple apps
| on their phones and they _have to_ use them.
|
| Not for people who find two messaging apps too much to have on a
| phone, or for people who're talking about privacy.
| titaniumtown wrote:
| what about discord? :(
| chayleaf wrote:
| sadly, discord ToS forbid "self-botting", so the only legal
| option is to use a Discord bot, and that's far from seamless
| and requires guild admin cooperation, I assume that's why they
| aren't advertising it
| maltalex wrote:
| I'm happy to see that element found another potential revenue
| stream, but will people pay the 5$/month to unify their
| messaging?
|
| I don't know about others but it's not that much of a pain point
| for me, and I'm using all of the apps they mention - WhatsApp,
| Signal, Telegram as well as few others like IRC and Discord.
| encryptluks2 wrote:
| Too bad they didn't spend the efforts on actually creating a
| decentralized protocol.
| rglullis wrote:
| I have nowhere near the same reach and marketing capacity as
| Element, but if my experience running a managed hosting service
| [0] for Matrix (and other messaging/social media services) is
| anything to go by: _individuals_ really don 't care enough
| about that to the point of paying $5/month, but there is a
| growing opportunity for business that want to have some control
| over their communications.
|
| These bridges can be amazing if you want to have a chatbot, or
| a support desk that can put all their conversations in one
| place, etc, but to replace the mainstream apps it is too much
| of a tall order. At the moment the mobile clients have so many
| bugs that makes it hard even for me to go when offering support
| for my "customers", which at this point is just the couple
| dozen friends and family that I managed to rope into it. They
| don't even have feature parity with any of the competitors, so
| for end-users it's just easier to switch apps on their phone
| depending on who they want to talk _and_ their will have a
| better experience doing so.
|
| I still use and support Matrix, but their clients still need to
| improve a _lot_ if they ever hope to reach mainstream. I am
| focused now on another project [1], but when /if I ever get to
| work back on communick, I will pivot away from end-users and
| into SMB.
|
| [0] https://communick.com
|
| [1] https://hub20.io
| rkangel wrote:
| > I'm happy to see that element found another potential revenue
| stream, but will people pay the 5$/month to unify their
| messaging?
|
| As one data point, I probably would pay $5 a month just for
| that. Combining that with all the other Matrix goodness is a
| bonus.
| solarkraft wrote:
| If the available Matrix clients were not a pain to use I
| probably would.
| gtirloni wrote:
| Exactly. The Element UI isn't the best selling point of
| Matrix right now and that would be a requirement for someone
| to switch from all those apps to Element.
| [deleted]
| causi wrote:
| My concern is whether Element One is in it for the long haul. If
| I stick with using Whatsapp and Signal I can be fairly certain
| they'll still be working in five or maybe even ten years. Is
| Element One committed?
| ridaj wrote:
| The very story of each of WhatsApp, Signal, etc. is a testament
| to why interoperability across apps matters much less than user
| reach and feature velocity within an app ecosystem. Most people
| don't actually mind using different apps for different things
| once their friends are there, because functionality tends to
| break at the edges (even creating a simple group chat becomes a
| pain across non-cooperative networks)
| censormenow wrote:
| Let's save the NSA the trouble of hacking into all our secure
| chat clients and just drop our authentication for everything into
| an app they made.
| commoner wrote:
| There is no evidence that Element was "made" by the NSA.
| Element is developed by New Vector Ltd., a UK company.
| [deleted]
| censormenow wrote:
| The UK is a surveillance state. They have more CCTV cameras
| than China.
| miguelrochefort wrote:
| Beeper provides a similar service for $10/month (private beta).
|
| https://www.beeper.com/
| leohonexus wrote:
| There's also one from Fitbit's founder, Texts app - this space
| is getting crowded!
|
| https://texts.com/
| jakecopp wrote:
| There seems to be little information about the company/people
| who runs Texts on the website which is strange - where did
| you find the info of who runs it?
| leohonexus wrote:
| My bad - Beeper is the one that's founded by Pebble founder
| (not Fitbit). Kishan Bagaria is the one behind Texts.
|
| https://twitter.com/KishanBagaria
| miguelrochefort wrote:
| I can't find any link between Texts and Fitbit, but I know
| that Eric Migicovsky founded Pebble (acquired by Fitbit)
| before founding Beeper.
| leohonexus wrote:
| Ah my bad - I must have mixed them up.
| [deleted]
| c0wb0yc0d3r wrote:
| You can also self host it for free according to their website.
| 3np wrote:
| I wonder why Facebook Messenger is not included? From experience,
| the Messenger Matrix bridge has been surprisingly robust, moreso
| than the signald bridge.
| ulzeraj wrote:
| It doesn't look to be as good as it sounds. Privacy matters
| aside, you still have to keep WhatsApp installed on your phone.
|
| > To connect your WhatsApp account, scan the QR code below: >
| Open WhatsApp on your mobile device. > Go to "Linked devices" >
| Press "Link a device". > Scan the code below.
|
| Would pay money to get rid of Facebook software in my devices.
| aceArtGmbH wrote:
| there are bridges for several Facebook services which you can
| self-host https://matrix.org/bridges/#facebook-messenger
| https://matrix.org/bridges/#instagram
| tao_oat wrote:
| > It's also worth noting that end-to-end encryption is
| necessarily broken as messages to (and from) WhatsApp, Signal and
| Telegram pass across the bridge(s). The bridge(s) operates in
| Element's trusted EMS environment, with no content scanning or
| datamining, but currently bridged conversations are not stored
| end-to-end encrypted in Matrix (they will be in the future).
|
| As a Signal user, I kind of don't want this to take off. I like
| knowing that when I message someone on Signal, it's for their
| eyes only. It feels like this service starts fragmenting some of
| the privacy guarantees of the bridged providers.
| Iv wrote:
| You can self-host. I suspect they use this:
| https://github.com/spantaleev/matrix-docker-ansible-deploy
| Arathorn wrote:
| You can indeed self host (although Element One doesn't use
| slavi's ansible playbooks but instead the Element Matrix
| Services hosted infra we use to host Mozilla, FOSDEM, HOPE,
| KDE, GNOME etc)
| ElijahLynn wrote:
| Very good point on not wanting this to take off so that you
| know if you send it to someone, it is for their eyes only.
|
| It does seem like since both Signal and Matrix are open source,
| including the servers, that there should be a path to let one a
| Signal user know if they are sending it to a Matrix bridge and
| the encryption is no more.
|
| Also worth noting is that you do need to trust the person on
| the other end for Signal to have a chance at working, e.g. they
| can take screenshots or real camera pictures of the messages.
| So establishing trust with the recipient is rule #1, and this
| should go for if they are using a Matrix bridge with Element
| One too.
| grassjumper wrote:
| There's a difference between malice and ignorance, though. My
| mom in her 70s is using Signal, and I don't think I can blame
| her for not realizing the vulnerability. I doubt most people
| will read the Element webside that carefully.
| ergl wrote:
| For all you know your Signal contacts are using a CLI client
| and then forwarding the messages through SMS to their feature
| phones :^)
| dane-pgp wrote:
| If you believe that, then I have a bridge to sell you. :^)
| freeopinion wrote:
| If privacy mattered that much to you, you wouldn't depend on
| Signal to encrypt your messages. You would encrypt them before
| handing them to Signal.
|
| So you should have an encrypted message that you hand to
| Signal. Signal encrypts it again and hands it to the bridge.
| Eventually, whether at the bridge or at the other end or
| wherever, something decrypts the Signal message. Then the
| person you are communicating with applies the final decryption
| outside of Signal, Matrix, or whatever.
|
| If this sounds terribly inconvenient to you, perhaps privacy is
| not as important as you claim. Security and convenience are
| almost always in conflict.
| grassjumper wrote:
| This is like saying "If you don't sweep the bathroom for
| bugs/cams, you don't really care about privacy. Why do you
| bother closing the door"
| idrios wrote:
| This is a very all or nothing mentality. It's also kind of
| like saying you should put locks on your locks. Signal's core
| reason for existing is that it puts a focus on privacy. They
| say this all over their homepage [0].
|
| One of the founders of WhatsApp donated $50M to Signal [1]
| out of regret for how WhatsApp shifted away from privacy
| after being acquired by Facebook.
|
| The entire project is freely visible to anyone on github [2].
| They've made it so even if you don't trust their servers, you
| can set up your own server and clone your own android/ios
| app, change some settings and have everything hosted
| yourself.
|
| There's no reason not to expect Signal to maintain the focus
| on privacy that they've put in thus far.
|
| [0] https://www.signal.org/ [1]
| https://www.wired.com/story/signal-foundation-whatsapp-
| brian... [2] https://github.com/signalapp
| freeopinion wrote:
| For most people, privacy is a nice-to-have thing. When it's
| just nice to have, Signal checks that box.
|
| If your life depended on it, you would be foolish to depend
| solely on Signal.
|
| How nice it is that encryption has emerged from the dark
| corners of life and death to become a fashion accessory.
| But for those that still exist in the world beyond fashion,
| your criticism seems naive.
| [deleted]
| phicoh wrote:
| In theory, signal could work with matrix people to support
| bridging with e2e encryption.
|
| But as far as I know, signal wants to be walled garden. So then
| it is expected that people create work arounds.
| [deleted]
| mindslight wrote:
| So then advocate for Signal to fully support third party
| clients, so that such functionality can be widely supported by
| multi protocol clients (ala pidgin) rather than needing
| centralized non-E2E bridges to cope with the administrative
| overhead of maintaining interoperability.
| trenchgun wrote:
| You don't know that when you message someone on Signal it's for
| their eyes only.
|
| What you know is that unless their device is compromised, it is
| up to them to decide who can read the messages that you send to
| them.
|
| Thus the situation with the bridge is not in reality different
| from the situation now.
| throw10920 wrote:
| Exactly - someone could be running a (the?) third-party
| Signal client, or they could be intercepting the Google push
| notifications that Signal sends using one of those Play
| Services compatibility layers, or they could do one of the
| low-tech things of showing their device with your messages on
| it to someone else in-person.
|
| Although, to be fair, all of those things are far more
| difficult than using Element One, so there's an argument to
| be made about reasonable expectations and the actual
| likelihood of your messages being private...
| allset_ wrote:
| The messages are encrypted end to end so compromising push
| notifications doesn't get you anything. That's the problem
| with this bridge, it adds a new server with access to the
| unencrypted messages.
| 2Gkashmiri wrote:
| come on. can we just drop this end to end encrypted bs on
| whatsapp atleast ? when you report a message, you allow
| admins to see the last 3-4 messages. if only you and your
| receipent is supposed to see the messages, "e2e", how can
| an admin see them?
|
| edit:https://www.huaweicentral.com/new-whatsapp-report-
| feature-wi...
| dtparr wrote:
| While I can't vouch for WhatsApp's implementation of
| course, the capability could easily maintain e2e
| encryption by just forwarding those 5 messages directly
| to WhatsApp admins. E2E just means it gets to your
| recipient without being exposed on the way. It doesn't
| mean they can't take and then re-distribute it to others.
| zepto wrote:
| No - the bridge could be compromised without your
| conversation partner's involvement.
|
| I.e. the bridge is a vulnerability that enables man in the
| middle attacks.
| tshaddox wrote:
| Your conversation partner's device could also be
| compromised remotely.
| TeMPOraL wrote:
| From your POV, the threat model is equivalent to your
| partner being compromised themselves, and reporting your
| conversation to criminals/terrorists/law
| enforcement/intelligence agencies/boogeyman du jour.
|
| Bridges don't install themselves in place of platform's
| messengers - it's the user that has to make an active
| choice to use one. If you don't trust your partner making a
| right choice for both of you, you can't really trust them
| not to tattle on your conversation, or get their computer
| compromised by generic system-wide malware.
|
| And if the bridges themselves are shoddy? Well, I kind of
| blame the platforms like Signal and WhatsApp, for forcibly
| bundling their messaging service and their chat client.
| Were they to open up their APIs to alternative frontends,
| they could make it so that those alternative frontends
| identify themselves to the other party in the conversation,
| and it would remove the need to develop fully transparent
| bridges for legitimate use.
| zepto wrote:
| > From your POV, the threat model is equivalent to your
| partner being compromised themselves, and reporting your
| conversation to criminals/terrorists/law
| enforcement/intelligence agencies/boogeyman du jour.
|
| Not even close. I can evaluate the likelyhood of my
| partner being compromised. I can't evaluate the
| likelyhood of a gateway I _may not even know about_ being
| compromised.
|
| The introduction of these gateways makes the entire
| system less trustworthy.
|
| Honestly I can't see how Matrix/Element can stand behind
| this in good conscience. It is strictly a harm to the
| goal of enabling private communications. I literally
| found myself thinking it was a joke when I read it, and I
| no longer think matrix/element are serious.
| feanaro wrote:
| > Not even close. I can evaluate the likelyhood of my
| partner being compromised. I can't evaluate the
| likelyhood of a gateway I may not even know about being
| compromised.
|
| Why? It is your partner that is deciding to use what is
| essentially a Signal client installed on a remote server
| controlled by Element. If it is true that you are able to
| estimate this likelihood for your partner, this fact
| should already have been accounted for in the
| calculation.
| zepto wrote:
| This is only true _now_ that Element have introduced this
| compromised way to access signal.
|
| So yes, Element have introduced a new fact that
| downgrades everyone's estimate.
| feanaro wrote:
| > This is only true now that Element have introduced this
| compromised way to access signal.
|
| It's never not been true since Signal is just a protocol
| which you can use programatically. It's certainly not
| been true at least since signald became a thing. And
| Element is not the first one to come out with such an
| offering (see e.g. Beeper).
|
| It's just better known now.
| [deleted]
| zepto wrote:
| That makes as much sense as saying nuclear war was as
| likely before the Manhattan project as afterwards.
|
| It was always possible to build nuclear bombs. It was
| just 'better known' after they were dropped on Japan.
|
| And in this case "better known" is what is being
| criticized. It's one thing for someone who understands
| how to do so to build their own proxy and take their own
| risks.
|
| It's another thing entirely to make a consumer product
| that does this and normalize the practice.
|
| That hadn't been done before by anyone credible.
| ruined wrote:
| the threat model is not the same, there is an additional
| vector. it's not hard to see how a bridging service
| provides a single point of compromise and is a high value
| target compared to a million independent endpoints
|
| it is literally a step back towards the centralized
| unencrypted messenger model
|
| say what you will about the centralized e2e model, but
| you can't argue that the previous situation was better.
| acomar wrote:
| this is extremely not true. federal authorities can
| compel the bridge operators to log messages sent over the
| bridges and disclose them on receipt of a national
| security letter or other sealed warrant. this is just not
| the case right now - messages sent between parties on
| signal cannot be intercepted. that the communication
| endpoints are vulnerable is and remains true but this
| creates a new vulnerability in the interlink.
|
| worse:
|
| > currently bridged conversations are not stored end-to-
| end encrypted in Matrix (they will be in the future)
|
| suggests some kind of re-encryption for storage which
| appears to resolve the issue but does literally nothing
| to solve the problem. if the bridges have your keys and
| can decrypt your messages, you're exposing yourself to
| attacks on the bridges themselves.
| jbverschoor wrote:
| Well, not entirely true, because sginal has sent random
| images out to wrong contacts before.
| lvass wrote:
| I concur. I really wouldn't mind anyone using this for whatsapp
| as I consider any message I send there is also available to
| 14-eyes, but bridge usage really should be disclosed to Signal
| users.
| pkulak wrote:
| > I like knowing that when I message someone on Signal, it's
| for their eyes only.
|
| That's not how it works at all. E2E encryption only guarantees
| that your message is securely delivered to the other party, not
| that the other party can't do as they please with it. Signal
| messages are still stored in plain text on the end devices.
| They can still be backed up to the cloud (when I used Signal,
| all my chats were). Hell, photos/screenshots can still be taken
| of the app. If you want total security, you have to trust the
| delivery AND the end user. Bridging doesn't really change any
| of that.
| [deleted]
| barbazoo wrote:
| I got so excited for this until I read that, too. I wish there
| wasn't fragmentation like there is now but MITMing all my comms
| is definitely not a smart choice if I chose any of the comm
| systems it bridges based on privacy.
| pmlnr wrote:
| I want this to take off. I'm tired of having to follow trends
| because people suddenly think there's a new shinyshinytrendy
| thing around: IRC to ICQ to MSN to Skype to Google Talk to
| Facebook Messenger to Whatsapp to Signal.
|
| Pidgin is good (I also miss the ancient Trillian, even though
| it was closed source), but limited to a local device.
|
| There are XMPP Transports as well for these (see
| https://git.eta.st/eta/whatsxmpp ,
| https://gitlab.com/nicocool84/spectrum2_signald , but sadly
| https://spectrum.im/ is surprisingly finicky to set up.)
|
| EDIT: for encryption fans, I've been wondering for a long time
| now: why would you trust ANY 3rd party with your so sensitive
| data instead of running your own service? Are you not aware of
| OMEMO for XMPP? (See https://omemo.top/ )
| MisterTea wrote:
| > I'm tired of having to follow trends
|
| Then don't. I have none of those things save for IRC. I get
| all my work done and live a full life.
| user3939382 wrote:
| I remember when I first installed Trillian around 2000, it
| was so cool!
| stjohnswarts wrote:
| Encryption fan here, bridging is one more avenue for failure,
| is why I won't buy in. Security is about odds, and nothing is
| 100% safe. I'm pretty sure signal is way better than anything
| I could come up with, so I choose it.
| teekert wrote:
| Maybe it's not for you but more for those of us forced onto
| FB's WhatsApp and their phone book scanning/uploading by
| social conventions. This presents a way out without giving
| up the benefits.
| hellojesus wrote:
| Doesn't grapheneos allow some type of sandboxing to wall
| off your true contacts, etc. for exactly this purpose?
|
| https://www.reddit.com/r/privacy/comments/nkyzdw/what_is_
| the...
| jcul wrote:
| Shelter can be used for this purpose if desired.
|
| https://github.com/PeterCxy/Shelter
| hellojesus wrote:
| Thanks!
| ev1 wrote:
| You know people that have the FB app installed. And all
| their messages and SMS running through the FB app. And
| you can't get all of them to stop this madness.
| hellojesus wrote:
| Maybe. I probably don't relate well because I talk to
| maybe 10ish people regularly.
|
| Everyone else, if they don't migrate to a secure and
| preferred method, I just use email (with pgp if possible)
| and call it good.
| txtsd wrote:
| Trillian was awesome! It's just a shell of its former self
| now.
| koheripbal wrote:
| > why would you trust ANY 3rd party with your so sensitive
| data
|
| Because trust is not a binary value and I don't have the time
| to do literally everything myself
| jacob019 wrote:
| I wrote a bridge between signald and prosody (without
| spectrum) so I can use xmpp clients with signal. Async
| python, only non-standard library dependency is slixmpp. It's
| working well.
| pmlnr wrote:
| I've seen your project! Congrats, it is very nice. I
| stopped fiddling with transports because signald doesn't
| compile/run on freebsd (some of the java libs behind it
| rely on native libs which have problems compiling), and for
| now I've put it aside.
| finnn wrote:
| https://www.freshports.org/net-im/signald/
| pmlnr wrote:
| Huh. I wasn't aware of this. I tried for quite a long
| time to compile it myself a while ago and failed, I'll
| give it another go, thank you!
| loriverkutya wrote:
| I don't run my own service for the same reason I don't build
| my own car or I don't do accounting for my company, I don't
| have the time to learn how to do it nor doing it.
| pmlnr wrote:
| No, this is not the same. You want the utmost privacy, yet
| you still decide to trust someone over it.
| noirbot wrote:
| I don't want "the utmost privacy". I want something
| better than raw SMS. I'm not an international secret
| agent. I encrypt things out of principal more than
| because I really care if some government force reads
| them. If a nation-state decides I'm of interest to them
| for malicious reasons, I'm probably screwed either way.
| 2Gkashmiri wrote:
| remember that xkcd https://xkcd.com/538/
|
| yeahh. thats not exactly a meme but i am personally
| facing these same state sponsored actions read here
| https://thekashmirwalla.com/not-pegasus-kashmiris-are-
| worrie...
| wayoutthere wrote:
| Yeah, infosec has its limits. But if you're gonna
| challenge the state, it does help keep things quiet until
| you are numerous and armed.
| jeltz wrote:
| Then these bridges are fine. Virtually everything is
| better than raw SMS.
| JasonFruit wrote:
| But Signal is better than Signal over these bridges, and
| it's easy too. Just because you don't want to run your
| own service doesn't mean you have to choose a poor option
| over a pretty good one.
| grassjumper wrote:
| That depends _a lot_. In a civilized country with low
| risk of 2G downgrade attacks and sensible telecom laws
| /law enforcement restrictions, SMS is a lot more secure
| and private than many other options.
|
| Obviously still a long way off actual secure
| communication though.
| godelski wrote:
| You're right, it isn't the same. Instructions on how to
| build a car don't change every week. As a hobbiest I
| wouldn't trust my life on getting in a car if that was a
| requirement. There's more in my life than that single
| hobby that I need to do and I only have so much time.
| lxgr wrote:
| The threat model is vastly different, though.
| mdavis6890 wrote:
| I also want utmost security for my money, which is why I
| put it in a bank rather than holding the cash myself.
| tigroferoce wrote:
| And you want utmost security for your body, which is why
| you go to the doctor instead of self threat. And also
| doctors go to _other_ doctors when they are ill.
|
| The sad reality is that things are complex and you
| probably get suboptimal results trying to do everything
| yourself, what other spend their lives trying to
| accomplish the same.
|
| WhatsApp scaled to 1B users with only 50 engineers, but
| there were 50 people working full time to provide what
| people think they can provide in their spare time?
|
| Also as the other end of any communication is quite
| scaring thinking I am communicating securely with
| someone, but then finding out that their server is
| compromised because of an out of date library or service.
| tommek4077 wrote:
| That is the kind of comment that freaks me out on HACKER
| news.
| otterley wrote:
| Not everybody hacks on everything. Many of us pick and
| choose our hobbies. I don't sysadmin my phone for the
| same reason.
| aeturnum wrote:
| If you know a problem is hard and the consequences for
| doing it wrong are potentially serious, it would be
| irrational to not consider selecting a well-managed third
| party solution. Being a hacker doesn't mean being all-
| knowing and the best hacks are done with the knowledge of
| human limits (both of the hacker and of the maker of the
| system being hacked).
| godelski wrote:
| Why? Specialization is a thing. Not everyone specializes
| in security. Which let's be real, being an expert in
| security is really difficult, especially since it's a
| constantly moving goal post. Unless you're an expert it's
| probably not a good idea to roll your own.
| tigroferoce wrote:
| Also, to run your own service you must specialize in
| security AND devops. The two thing overlaps a bit, but
| not 100%. And you must hope that every contact you are
| talking to has the same knowledge.
| xchaotic wrote:
| so much this - you can make a service 100% secure - by
| shutting it down. But if you want to stay online and be
| secure at the same time, there's always some resource
| tradeoff between the two
| approxim8ion wrote:
| > why would you trust ANY 3rd party with your so sensitive
| data instead of running your own service?
|
| Because end to end encryption means you don't have to trust a
| third party? The channel goes out of the equation, at least
| with reference to the content of your messages. Metadata is
| definitely handled differently by different services but
| that's a question of threat model.
| [deleted]
| CreateAccntAgn wrote:
| I dont have a PhD in crypography and am not sure I will do a
| good enough job in covering even potential mid-level
| vulnerabilities. I still care about privacy and so use
| Signal.
| freeopinion wrote:
| The point of encryption in the first place is to allow an
| untrusted transport. If you trust the transport, you don't
| need encryption.
|
| OMEMO nor XMPP provide trusted transport.
|
| Perhaps the point you are reaching for is that encryption and
| transport should be different parties. The message should be
| encrypted before you hand it to the Western Union agent.
| After that, the decision between Western Union, Union
| Pacific, or Pony Express hinges on other concerns.
| SECProto wrote:
| > I'm tired of having to follow trends because people
| suddenly think there's a new shinyshinytrendy thing around:
| IRC to ICQ to MSN to Skype to Google Talk to Facebook
| Messenger to Whatsapp to Signal.
|
| As someone who used trillian, you should recognize that
| you're likely to need to follow someone to a new trendy
| messaging service within a few years, regardless of an
| aggregator taking off.
| TheRealPomax wrote:
| Because your own service is not an alternative if you
| actually _need_ to secure-message others because of the line
| of work you 're in, or the regime you're under. The idea that
| "just do it yourself" is more secure than a company that
| can't just be walked into and have their computers taken
| without it causing a huge problem for everyone from your mom
| to heads of state is a bit naive.
| phicoh wrote:
| The advantage of having your servers at home is that when
| the police shows up with a search warrent you know you
| can't trust that server anymore.
|
| If you use a 3rd party, it can be compromised and you only
| find out when it is too late.
| godelski wrote:
| I'm pretty sure my server at home is less secure since
| I'm not a professional security expert. I can recognize
| that I'm dumb and going to make a lot of mistakes.
|
| The disadvantage of having your server at your home is
| that you don't know if it's compromised from day one. I
| may never even find out and just fool myself the entire
| time.
| [deleted]
| 2Gkashmiri wrote:
| what about when cisco or "someone" helped india government
| impose censorship on aroun 8 million people so that they
| cannot use a vpn or access only whitelisted websites?
| https://theprint.in/india/us-firm-helps-jk-build-firewall-
| to... https://tech.hindustantimes.com/tech/news/this-us-
| firm-is-re...
|
| there is a news by arstechnica that updates by cisco who
| deny the same but these curbs were imposed and i personally
| suffered so i am not sure if "have their computers taken
| without it causing a huge problem for everyone from your
| mom to heads of state is a bit naive"... even a big company
| like cisco must bow down and bend rules to a dictatorial
| country like india.
| comice wrote:
| > for encryption fans, I've been wondering for a long time
| now: why would you trust ANY 3rd party with your so sensitive
| data instead of running your own service? Are you not aware
| of OMEMO for XMPP?
|
| we ran our own XMPP server for over 10 years using the "off
| the record" plugin for end to end encryption. Development
| seem to basically stop on open chat clients a few years ago
| and everything started getting crufty. (I see Pidgin dev has
| apparently picked back up again to some extent, as has Adium,
| to a much lesser extent).
|
| "off the record" mostly worked ok, between Pidgin users, but
| failed with other clients.
|
| A couple of OMEMO plugins came along but making them work
| (and keeping them working) was a continual drain - and we're
| only a small team with only 2 operating systems (Linux and
| OSX)!
|
| My hunch is that enough people just moved to things like
| Whatsapp and Slack etc that developers were no longer using
| chat clients they could hack on. People stopped being able to
| scratch their itches.
|
| Not to mention lack of any/decent XMPP client support for
| syncing histories between multiple clients, or handling
| inline images and things. All that modern stuff people
| expect.
|
| Things like Mattersmost tried to fit in here but we just
| didn't get along with them.
|
| Eventually Element/Matrix matured enough and while it was far
| from perfect, it worked and we sadly finally gave up on XMPP.
| topdancing wrote:
| For the past two years; I've been using Conversations
| (Android), Dino (Linux), and friends of mine have been
| using Gajim (Windows), Monal/Siskin (iOS).
|
| All of these work fine with OMEMO (the iOS ones gained
| better OMEMO and push support in the past few months) and
| message history retrieval between clients. Gajim doesn't do
| inline images, but the rest do.
|
| I occasionally use profanity as a console client and that
| recently had message archive support land in Git.
|
| So, yeah, no idea what you mean by developers giving up -
| if anything, the ecosystem has greatly improved (minus
| group OMEMO on iOS).
|
| Oh, and Dino got support for doing encrypted calls to
| Conversations a few months ago:
| https://fosstodon.org/@dino/106228549009869402
| jeltz wrote:
| Maybe not developers in general, but development of
| Pidgin certainly stalled, which is why I stopped using
| it. Too man features not implrmnted in XMPP and no
| working support for e.g. Skype.
| KAMSPioneer wrote:
| I use Conversations and Dino daily, they're awesome. When
| I'm stuck on MacOS or iOS I use BeagleIM and ChatSecure,
| though Monal looks a little more slick...maybe I should
| try that.
|
| There are a few options yet for XMPP clients, I have some
| hope for the ecosystem...!
| Arathorn wrote:
| (Element CEO here). Honestly, it depends on your threat
| profile. Any kind of bridge has to inevitably MITM your
| conversations in order to work, and we've tried to spell that
| out in all the product info about Element One.
|
| If you want to avoid your E2EE conversations on Signal or
| WhatsApp being relayed via a service like Element One (because
| you're an activist or whatever), then your options are to not
| bridge at all, or run a bridge yourself. Clientside bridging
| may be an option in future, but reliably running a bridge in
| the background on mobile is somewhere between non-trivial and
| impossible.
|
| Finally, we are currently crunching on getting E2EE to work
| nicely between the bridges and the Matrix clients (so bridged
| conversations are stored E2EE on the Element One server) and it
| should be coming in the coming weeks. It's worth noting again
| that even when that lands the bridge will still necessarily be
| able to see bridged conversations at the point of bridging.
|
| TL;DR: if you don't trust Element with your Signal
| conversations for whatever reason, don't hook up Signal to your
| Element One account :)
| gfodor wrote:
| Signal's core value proposition is radically increasing the
| expectation that one is having an e2e encrypted conversation.
| I love Element's product and mission, but a product which
| explicitly is eroding and complexifying privacy around a 3rd
| party product which is _about_ privacy seems to be a bad
| tradeoff, and also stands to undermine the public perception
| of what Element is all about. I would suggest either carving
| out the e2e platforms (particularly Signal), or introduce
| functionality that will ensure conversations had through the
| bridge inform the counter party that the messages are not e2e
| encrypted. It 's the right thing to do.
| fsflover wrote:
| > Any kind of bridge has to inevitably MITM your
| conversations in order to work
|
| Can't you just pass the encrypted message further without
| decrypting it? Of course, there needs to be the same
| decryption mechanism on both sides, but it doesn't make it
| impossible.
| KingMachiavelli wrote:
| It's possible but a lot harder. If the keys/tokens for
| fetching messages are similar/interlinked to those used to
| decrypt the messages then you can't separate the two. In
| this case you would have to do the message 'fetching' and
| decryption on the client side which would be very difficult
| for any JS based clients.
|
| Then there's the issue of syncing those messages between
| Element One clients which means the client now has to re-
| encrypt the messages and send them back to the server. And
| if the client is responsible for fetching messages then
| providing push notifications will be very difficult.
|
| So if you can actually decouple polling/listening for
| messages from decryption then it would probably be
| possible.
|
| A brute force approach would be to provide an open source,
| self-hostable server but can be configured from the
| centralized Element One service. This server would hold the
| actual service tokens & decryption keys and would just be
| sending re-encrypted messages back to Element/Matrix.
| Arathorn wrote:
| At that point it's basically clientside bridging (or
| multihead messagering), given having decrypted the message
| (even if you had the right keys available) you'd need to
| speak the protocol of the remote service.
| KAMSPioneer wrote:
| That's all well and good, but I believe the original
| complaint was more concerning the second party in the
| conversation. There's no way for me, a hypothetical person
| who wants to keep my Signal messages 100% encrypted in the
| Signal ecosystem, to opt out of my contacts using an Element
| bridge.
|
| Sure, I can go around and tell everyone I know that they
| shouldn't bridge Signal to Element One because <cryptonerd
| rant>, but there's no way for me to tell that my advice has
| been followed. Previously, the chances that someone had set
| up such a bridge were small, but by nature of making these
| things accessible, Element One also increases the risk of my
| conversations being (benevolently?) MITM'd.
|
| I think it's a great offering, but I share GP's reticence
| about a system that puts what used to be zero-knowledge
| conversations in plaintext on a third-party server...all
| without me realizing.
| [deleted]
| _red wrote:
| >There's no way for me, a hypothetical person who wants to
| keep my Signal messages 100% encrypted in the Signal
| ecosystem, to opt out of my contacts using an Element
| bridge.
|
| This sounds like a made-up concern.
|
| How do you stop me from screenshotting your convo and
| posting on twitter, or just copying and pasting from one
| app to the next?
| KAMSPioneer wrote:
| Those are distinct from my concern. In your scenarios, I
| have trusted you to keep the conversation secret, and you
| betrayed that trust.
|
| My concern is about giving messages in an automatic
| fashion to a third party, which I'm completely unaware of
| and have no way of making an informed decision about. The
| third party could be breached (they run an online
| service, which is much, much easier to attack than some
| dude's iPhone).
| feanaro wrote:
| Just ask your conversation partner?
|
| An Element bridge is just a Signal client hosted on
| Element's infrastructure. Them using an Element bridge is
| no different than them using an extra device you didn't
| know about. That device could've well been insecure, or
| shared by many people, or hosted in the cloud. If you
| care about this, you should ask.
| KAMSPioneer wrote:
| I thought I addressed that in my original comment: I
| _could_ go to each of my contacts and explain why I don't
| want them to do things like use the cool new Element
| service with Signal. But 1) I (finally) have a lot of
| contacts using Signal, so that would be a pain to manage;
| 2) to me, the entire idea of Signal is that I can pretty
| much set it and forget it on any relatively-modern
| smartphone for friends, family, etc. and not have to
| worry about anything but the biennial phone migration for
| my mother.
|
| In the end it isn't a huge deal, as most conversations
| are extremely innocuous, and those I care about I'll take
| the time to verify. But after all the trouble to
| proselytize Signal, I get nervous about large public
| projects that could, in my opinion, strictly reduce the
| security of my secure messaging system.
| tshaddox wrote:
| > I _could_ go to each of my contacts and explain why I
| don't want them to do things like use the cool new
| Element service with Signal. But 1) I (finally) have a
| lot of contacts using Signal, so that would be a pain to
| manage; 2) to me, the entire idea of Signal is that I can
| pretty much set it and forget it on any relatively-modern
| smartphone for friends, family, etc. and not have to
| worry about anything but the biennial phone migration for
| my mother.
|
| Yes, I totally agree that this would be a huge hassle.
| But what's your proposed alternative? Reaching out to
| every programmer in the world and convincing them to
| never write any software that can act as a Signal client?
| Or pushing for legal prohibition on any non-Signal
| developers creating software that can act as a Signal
| client?
| KAMSPioneer wrote:
| Hahaha of course not. I don't really propose an
| alternative. I'm just lamenting the situation and trying
| to provide context to the Element CEO about why the
| original commenter, and people like him, might not be
| 100% jazzed about the democratization of technology that,
| in terms of message _security_, is a step backwards.
|
| Doesn't mean I'm in favor of such ridiculous things as
| you've suggested here.
| feanaro wrote:
| > jazzed about the democratization of technology that, in
| terms of message _security_, is a step backwards.
|
| Well, you can always switch to Matrix and have
| democratized _and_ secure native messaging which uses a
| cryptographic protocol comparable to Signal. ;)
| Strom wrote:
| > _Them using an Element bridge is no different than them
| using an extra device you didn 't know about._
|
| It is different in a big way. That extra device would
| most likely only transit this one user's messages. The
| Element bridge transits a ton of users and as such is an
| attractive target for mass surveillance.
|
| > _That device could 've well been [..] hosted in the
| cloud._
|
| The capability of self-hosting is very niche. Only
| technical people could pull that off. Element is working
| hard to make using this bridge so easy that your
| grandmother could do it.
| tshaddox wrote:
| How much do you know about your conversation partner's
| cyber hygiene? They might leave their phone unlocked at
| the library or even unknowingly install malware.
| KAMSPioneer wrote:
| All of that is true, and remains true if they're using a
| bridge service as well. The bridge service is strictly
| reducing the security of messages.
|
| Look, I'm not up in arms or anything, I just can
| immediately see a drawback to bridging Signal
| _specifically_. There exist many other services
| (Telegram, Slack, Discord, the list goes on) that can be
| bridged to Matrix without compromising the security
| posture in any terrificly meaningful way, IMO. So the
| idea is great in principle.
| tshaddox wrote:
| > The bridge service is strictly reducing the security of
| messages.
|
| Perhaps in some sense, yes, but in precisely the same
| sense that you reduce the security of your messages each
| time you send a new message, or each time you start a
| conversation with a new person, or each time any of your
| contacts reads a message on the train where someone might
| be looking over their shoulder. None of these things
| strike me as a meaningful reduction in security, at least
| in the threat models that are appropriate for most
| average people (namely where you don't expect to be
| personally targeted by an attacker with resources).
| KAMSPioneer wrote:
| The Matrix bridge service is compromised (their infra has
| been successfully attacked before, and other similar
| platforms have had catastrophic data breaches as well)?
| That doesn't require a targeted attack, involves complete
| history disclosure and probably far more metadata than
| Signal even stores on their servers.
| xanaxagoras wrote:
| > I think it's a great offering, but I share GP's reticence
| about a system that puts what used to be zero-knowledge
| conversations in plaintext on a third-party server...all
| without me realizing.
|
| Element CEO here, you must be a tinfoil hat crazy person,
| everyone should communicate in cleartext, you're not a
| terrorist are you
| dunefox wrote:
| Element CEO here, why won't anybody think of the
| children?!
| 0xdeadb00f wrote:
| Element CEO here, this comment thread made my day!
| drummer wrote:
| Element CEO here, I don't know wtf got into us breaking
| Signal E2EE, I am stepping the fuck down.
| acomar wrote:
| because "trust us" has such a great track record.
| xanaxagoras wrote:
| > (because you're an activist or whatever)
|
| How about because I'm a regular person, and I don't want
| everything I say analyzed by the federal government and
| stored in perpetuity? I'm increasingly repulsed by this
| notion that unless I'm doing something illegal or in
| opposition the the ruling party, encryption is just a luxury.
| Encryption is for anyone with any desire to express
| themselves honestly without modifying their behavior because
| someone is watching.
|
| People flock to Signal for a reason and a lot of them will
| use this "bridge" without understanding what they're giving
| up. You're doing more harm that good to try to usher people
| towards your platform.
| grassjumper wrote:
| I very much agree with you.
|
| > I'm increasingly repulsed by this notion that unless I'm
| doing something illegal or in opposition the the ruling
| party, encryption is just a luxury.
|
| Making encryption and privacy a common thing is important
| to maintain the anonymity of those who have something to
| hide for various reasons. It's the same as law enforcement
| using dubious methods: We don't object because we're
| criminal, we object because we're _not_ (i.e. and don 't
| want to risk false charges).
| fsflover wrote:
| > People flock to Signal for a reason
|
| Why would you go to a walled garden if you want more
| freedom/control? You should just go to Matrix and host it
| yourself (and keep all the metadata to yourself, too!).
| xanaxagoras wrote:
| People available to communicate with is a key metric of a
| communications platform. All of these services lack a
| large number of regular people. For better or for worse,
| Signal is the one with the most.
| Steltek wrote:
| If you self-host Matrix, you can still bridge to Signal
| while avoiding the walled garden trap and having complete
| control of your data?
|
| If you don't want to self-host, then you must be
| comfortable extending trust to someone. SaaS Matrix and
| Signal seem to be two sides of the same coin, in that
| case.
| allset_ wrote:
| Your cavilier tone here about casually introducing a MiTM
| threat that many people won't understand to the e2e encrypted
| messaging ecosystem is pretty disgusting. As others have
| noted, the issue is that I can't opt out of other people
| using this which breaks the security guarantees of the chat
| system.
| stryan wrote:
| That's not part of the security guarantee; The message was
| encrypted from user-controlled end to user-controlled end.
| It's neither Signal nor Element's fault that your
| conversation partner has decided to move conversations un-
| encrypted afterward. That was always allowed.
| sneak wrote:
| You misunderstood what he said if that is your TLDR.
|
| Furthermore, this is not the first time privacy issues with
| Matrix have been brought up to you and dismissed without
| understanding.
|
| I am going to begin recommending that people actively avoid
| adopting Matrix/Element.
| tentacleuno wrote:
| Could you expand on the "privacy issues", please? Not
| sealioning or whatever, I am genuinely interested.
| colbyhub wrote:
| Not sure what exactly they were referring to, but here
| are some of them: https://github.com/libremonde-
| org/paper-research-privacy-mat...
| Arathorn wrote:
| sneak's pet issue is https://github.com/vector-
| im/element-web/issues/11655: that element web assumes
| that you want to log into the matrix.org homeserver by
| default unless you change its config to default to a
| different one.
|
| The libremonde research is over 2 years old now, and the
| valid bits of it were addressed at the time
| (https://matrix.org/blog/2019/09/27/privacy-improvements-
| in-s...)
| superdisk wrote:
| Sure, but this defeats the entire point of Signal. You don't
| use it to get the maximum amount of reach to other contacts,
| you use it because you're confident that what you send ISN'T
| being MITMed... that's the entire value of the app! So
| unfortunately if this takes off, you never know if the reason
| you're even using the application is just being violated. It
| destroys the entire purpose. That said, I love Matrix more
| than Signal and enjoy its E2EE capabilities.... but I also
| wish this doesn't take off.
| dunefox wrote:
| It's still a chat app and if I can't reach enough people
| it's useless.
| tshaddox wrote:
| > You don't use it to get the maximum amount of reach to
| other contacts, you use it because you're confident that
| what you send ISN'T being MITMed...
|
| Sure, but this doesn't actually introduce a new party in
| the middle of two Signal clients. Someone has to just
| decide to authorize a Signal client running on a server
| somewhere to receive messages from you and forward them
| onward outside of Signal.
| asymmetric wrote:
| > TL;DR: if you don't trust Element with your Signal
| conversations for whatever reason, don't hook up Signal to
| your Element One account :)
|
| AFAIU GP's point was that even if I don't bridge, the
| recipient of the message might, thereby diluting the trust
| _all_ users have in E2E on Signal, since you can't know who's
| bridging and who isn't.
| monkeywork wrote:
| That has always been the case no? You can't know what the
| person you are sending the message to is doing with it, the
| status of their device, or anything else.
|
| I fail to see anything that Element is doing "wrong" here,
| the issues you are describing are issues between you and
| your conversation partner
| asymmetric wrote:
| That is true, but there is a difference between some
| messages being screenshotted, and a service that acts as
| a bridge storing _all_ communication that passes through
| an account. It 's a matter of how likely it is that the
| assumption "my communication is not going to leak beyond
| the two participants" is broken. Every step in the wrong
| direction counts, IMO.
|
| Also, AFAIK it wouldn't be trivial to extract all the
| Signal chat histories from an iPhone device - this new
| service makes that much, much easier (not least because
| they'd be remotely accessible).
| ThatGeoGuy wrote:
| It seems like you're trying to hold Element to some kind
| of impossible standard here. It's not like the tech they
| used to build the bridge didn't already exist.
|
| The bridge itself serves a specific purpose (opening up
| Signal to the Matrix API, allowing for the use of a
| single app), and succeeds at that. Of course there's a
| trade-off, and the team (at least allegedly) appears to
| be working on encrypted bridges so that even if the
| bridge decrypts from Signal, it re-encrypts on the
| homeserver at rest in a way that only the user (not the
| bridge) can decrypt in the future.
|
| I think the complaint here is "you advertised a service
| doing a thing that was already possible, people might use
| this." I may be mis-characterizing that, but I think it's
| worth stepping back and thinking a bit more on the actual
| threat model you face, and how the proposed product
| (Element One) somehow subverts that. Sure it can do so at
| scale, but that just means this is one incremental
| improvement that needs more work, not that the idea needs
| to be thrown out entirely.
| gfodor wrote:
| Companies whose mission is centered on user control and
| privacy can be held to a higher standard than other
| companies when it comes to these kinds of questions. It's
| perfectly reasonable to suggest that Element should have
| tossed out the idea of supporting Signal for this
| specific software offering, given the potential for
| collateral damage in the form of person A using it
| without person B being aware of this, particularly if
| person A does not grok that they are compromising person
| B's communications if they are using it.
|
| Disclaimers and warnings are not universal solutions to
| questions on ethics since they are not certain to be read
| or understood and will have some failure %. If the
| residual negative effects are likely to exceed the kinds
| of outcomes a company's core values can tolerate, then
| making those states unrepresentable by abandoning product
| ideas is sane.
| teekert wrote:
| I won't use it for signal indeed, for whatsapp though... can't
| wait to throw it of my phone!!
|
| I didn't dive into it, but can you also self-host this? Looking
| forward to some docker-compose snippets in that case :)
| stryan wrote:
| All the bridges (and the matrix server itself of course) are
| self-hostable.
| zuck9 wrote:
| Been using https://texts.com -- they preserve E2E for
| Signal/WhatsApp.
| lvs wrote:
| Um, how do they do that?
|
| > All integrations were implemented in-house using the Texts
| Platform SDK. The SDK will be open sourced at a later date.
|
| Seems like a big nope.
| zuck9 wrote:
| https://texts.com/privacy says:
|
| > Messages, contacts, auth credentials, account information
| never touch Texts servers.
|
| > Your messages are sent directly to the messaging
| platforms.
|
| > All end-to-end encryption is preserved when the platform
| supports it.
|
| > Texts is a client and works like the official app.
|
| Apparently all the code runs on the user's device.
| 5- wrote:
| > _hosted by Element Matrix Services; constantly maintained to
| the highest standard and best practices by the experts who
| created Matrix - giving an infinitely better experience than the
| typical free-for-all of public homeservers._
|
| so much for the federation.
| Arnavion wrote:
| The only experience I have with EMS is that their bridge to the
| libera.chat IRC network doesn't work. Specifically, the
| libera.chat homeserver that they host sends like 10% of the
| events that it should be sending to my (self-hosted)
| homeserver. I know it's not a problem with my homeserver
| because multiple other (non-EMS-hosted) homeservers work with
| mine just fine.
|
| And there's no way to get help about it; none of the folk who
| run it are active in the #libera-matrix channel, and the
| libera.chat folks themselves don't have any knowledge of it
| because it's entirely maintained by EMS.
|
| People who use matrix.org as their homeserver reported no
| problems with it when I asked, but at least one other person
| using their own homeserver said it was broken in the same way
| for them too.
|
| "Infinitely better experience" my ass.
| feanaro wrote:
| What's wrong with this? How is it opposed to federation?
| Steltek wrote:
| This is nicely timed.
|
| Brief history: when Hangouts was going away and Google Chat
| coming in, I pitched Matrix to my friends as a better alternative
| that didn't require unique phone numbers, awkward desktop
| limitations, and a better federated future. We stuck with Google
| Chat because inertia and networks suck that way.
|
| I revisited the instance I had setup and got the mautrix-
| googlechat bridge working. It's pretty nice but one friend
| lamented that he did not have the technical skills to self-host
| such a thing. And here comes this announcement! Sadly, there is a
| major hurdle: neither Google Chat nor SMS/GVoice are listed here
| and those are the major protocols that my social group uses.
|
| At the same time, my social group is conservative in adopting new
| core technologies and wary of cloud lock-in for critical roles
| (Google being both an unfortunate anchor and precipitator of
| that). I'm not sure adding those protocols would tip the balance.
| scrollaway wrote:
| Beeper implements Google Chat. I've been using it, it works
| really well.
|
| https://www.beeper.com/
| bluesign wrote:
| Only if you can signup though, been very long time since I
| registered for invite.
| pimeys wrote:
| I've been waiting for an invite for almost a year now. Even
| gave my credit card for them, but still waiting...
|
| I'm just yelling here to take my money, but nobody answers.
| your_challenger wrote:
| Yup. And looks like element One is a direct competition to
| beeper
| krageon wrote:
| Does anyone know what this product is based on? Is it just a
| ready-made image with all the bridges preconfigured (and
| prerequisites such as a small android vm for a viable whatsapp
| bridge), or has there been some evolution on the existing
| package? Is there documentation on what was done to achieve this?
|
| Purely on the content of the article: Given that the messages are
| not stored encrypted locally and that this service is connected
| to the US, I do not see how it can be viable for the privacy-
| conscious.
| jakecopp wrote:
| > Purely on the content of the article: Given that the messages
| are not stored encrypted locally and that this service is
| connected to the US, I do not see how it can be viable for the
| privacy-conscious.
|
| Matrix chats (direct and group) are E2E by default. There is no
| bridge that will let you keep E2E encryption between
| Signal/WhatsApp and another service - it has to be broken
| somewhere. I believe Element is a UK company.
|
| The blog post on This Week In Matrix states it uses modified
| versions of the open source (and self hostable) Mautrix bridges
| which are primarily built by tulir [2] of Beeper [3]:
| https://matrix.org/blog/category/this-week-in-matrix#element...
|
| > However, in addition to being a fast, snappy Matrix account,
| it also comes with unlimited personal bridging to Whatsapp,
| Signal and Telegram thanks to mautrix-whatsapp/signal/telegram!
|
| [2]:https://github.com/tulir [3]: https://www.beeper.com/
| krageon wrote:
| > There is no bridge that will let you keep E2E encryption
| between Signal/WhatsApp and another service - it has to be
| broken somewhere
|
| Yes, but it doesn't have to be stored plain on a completely
| untrusted (because again, the company touches the US - that
| is an ideologically privacy-hostile space) server. This makes
| data collection much easier, including data collection of
| data in the past (as opposed to only communication from a
| certain point in time, as with an ongoing tap of the machine
| itself).
|
| > The blog post on This Week In Matrix
|
| Thank you :)
| jelv wrote:
| From there Terms of Service: Where you read 'Element' or _'
| we'_ or _' us'_ below, it refers to Element, a trading name
| of New Vector Ltd., its French subsidiary: New Vector SARL,
| its U.S. subsidiary: Element Software Inc, and their agents.
| https://element.io/terms-of-service
|
| So UK, French and US.
| GrayShade wrote:
| I've been running the Signal bridge for a couple of months and
| it seems pretty unstable. Sometimes it stops delivering
| messages and I have to restart either signald or the bridge. At
| other times, it broke completely and started working again only
| after a couple of days, when I updated signald.
|
| I haven't tried the WhatsApp bridge yet because it needs to go
| through my phone or an Android VM. WhatsApp recently announced
| support for using WhatsApp Web without the need to have your
| phone online, but I don't think it's available for everyone
| yet.
| your_challenger wrote:
| Yes this has been my experience too. The WhatsApp bridge I
| used had been pretty unstable. I thought it might be a
| configuration issue from my side.
| rkangel wrote:
| I've just signed up (after reading this message). My hope is
| that as a paid service effort will be made to make it
| reliable (through development, configuration, whatever).
| Having some users paying for it should hopefully make issues
| much more visible (through complaints to support if nothing
| else!).
| krageon wrote:
| That's a bummer. I was excited about running a home instance
| to bridge my (many) chat platforms. To me the point of such a
| thing is you can set it up and mostly leave it alone, so if
| it needs frequent fiddling it is mostly not fit for purpose.
| GrayShade wrote:
| Well, try it. It's a paid service so you might get some
| support, or maybe I'm plain unlucky.
| miguelrochefort wrote:
| > Does anyone know what this product is based on?
|
| It's very likely based on https://github.com/spantaleev/matrix-
| docker-ansible-deploy
| gnabgib wrote:
| It is not, according to this comment[0] "although Element One
| doesn't use slavi's ansible playbooks but instead the Element
| Matrix Services hosted infra"
|
| [0]: https://news.ycombinator.com/item?id=29000978
| ptman wrote:
| IIRC element/EMS do their own automation not based on that
| ansible project. But the bridges are the same open source
| ones.
| krageon wrote:
| This is cool, thank you! Very well documented and (from the
| looks of things) feature-complete.
| ho_schi wrote:
| This kind of stuff never works reliable of even fully. Because?
| There is no standard. And especially Telegram and WhatsApp will
| have absolutely no interest in keeping it working reliable. If
| you send your data anyway over this questionable services you're
| already in a concerning situation adding more possibilities for
| failure doesn't help.
|
| I use Matrix and it is certainly a good thing and the connections
| to other stuff like IRC, too. The fix is getting rid of WhatsApp.
| Signal is fine, the non-native desktop applications (i.e. fat and
| ugly Electron with Chrome behind) needs a rewrite with Gtk and
| Qt.
| skinkestek wrote:
| > And especially Telegram and WhatsApp will have absolutely no
| interest in keeping it working reliable.
|
| One of these is not like the others:
|
| Telegram both provides a library to bootstrap alternative
| clients and prior to that they also sponsored a competition to
| create a second semi official Telegram client for Android,
| Telegram X.
|
| So I guess Telegram won't be a big problem.
|
| But of course, saying something bad about Telegram, true or
| not, feels pretty safe here.
| arp242 wrote:
| > especially Telegram and WhatsApp will have absolutely no
| interest in keeping it working reliable.
|
| Telegram at least seems to have pretty decent libraries
| available to communicate with their API. I don't know how often
| it breaks, but I've been using the "tg" CLI Telegram client in
| the last week, and it seems to work fairly well (better than
| their own web interface anyway).
|
| I looked a bit at writing my own as I have some issues with the
| tg UI; I haven't written the code yet but just looked at the
| options, and overall it seems fairly decent.
| anthk wrote:
| I use Telegram with Bitlbee perfectly, with sic as the IRC
| client, it's magical.
| mst wrote:
| I confess to finding this tempting just for the whatsapp bridge
| because frankly while https://matrix.org/docs/guides/whatsapp-
| bridging-mautrix-wha... is very clever I really don't want to
| actually have to maintain an instance of it.
| anthk wrote:
| Run a local Bitlbee server with Hexchat or Quassel if you like
| GUI's and stop using middleware services.
|
| Yes, there are public Bitlbee servers out there, but these are
| for an emergency.
| Ndymium wrote:
| One thing I didn't spot, does this tier allow you to use a custom
| domain name on Matrix, or will you be :matrix.org still? $5/mo is
| an interesting price point for me if it can do that, I don't need
| the bridges but I could support the project this way.
| jakecopp wrote:
| I believe this tier only lets you use the new ...one.ems.host
| domain [1].
|
| Element Home pricing might be better for you if you have a few
| friends who are also interested ($10/month for 5 users), and
| won't use bridges [2].
|
| [1]: https://matrix.org/blog/category/this-week-in-
| matrix#element...
|
| [2]: https://element.io/personal-plans
| Ndymium wrote:
| Sadly I don't have a single friend on Matrix that I could
| consider doing this with, and it's unlikely I could convince
| my wife to use it either. So it would be double the money for
| only that piece of flair.
| rglullis wrote:
| You don't need to convince your wife to _switch_ , you can
| start by helping her setup the app on her phone and tell
| her to use this app when talking to you.
|
| Lower the stakes and the expectations. Even if she is
| starting conversations with you on any other app, you can
| still start the conversations on Element. There will be
| bugs and quirks she will find, you just offer help and ask
| her for patience.
|
| With time, they get used to the app and will be okay with
| starting the conversation with you there.
|
| That's what I did with my wife, my parents, closer family
| and friends. Then you get one day like the recent Facebook
| outage, and _they_ will come to you to ask if you can help
| _their_ friends to sign up to it.
|
| Slow and steady is the way I found to run this race. I
| already managed to get rid of WhatsApp and Messenger on my
| phone, it's only telegram for the odd group chat that is
| still resisting a full change.
| andrewaylett wrote:
| Element's regular matrix services are bring-your-own-domain,
| and I use them for our family's hosting. Unfortunately it seems
| they've decided that bring-your-own-domain is a feature for
| companies, and also given it "contact sales" pricing.
|
| The plan I'm on pre-dates "Element Home" and sits at the same
| price-point.
|
| Unfortunately a side-effect of the split is that I can't use
| the new bridging product without moving back to a shared
| domain, and the billing model for bridges on custom domains
| really doesn't work for consumers, at $0.50 per month per
| person who talks to you.
|
| The newer products are good upgrades for someone on the regular
| matrix.org server, but not so good for people who already
| upgraded :P.
| hnarn wrote:
| I just have a really hard time understanding who this is
| targeting. If you're on average more willing to sacrifice privacy
| over ease of use, you're very likely not using Signal or Matrix
| anyway. So if you're not, but you're using _both_ WhatsApp and
| Telegram, how is using two apps a big enough problem to set up a
| third one?
|
| Even if we disregard that, I can honestly say that I don't think
| using four separate apps is a problem. I don't even think using
| ten different apps is a problem, because it's mostly transparent
| to the user anyway. You get (configurable) notifications from all
| of them when you need to care about something, and the "sharing"
| feature on both iOS and Android these days is normally smart
| enough to figure out who, or at least which app, you want to
| share something to -- so for me this "multi app confusion" is
| already pretty well solved on an OS level, at least on mobile.
| chayleaf wrote:
| why would privacy enthusiasts not use Matrix, considering it's
| fairly easy to self-host?
| hnarn wrote:
| That's not what I wrote.
| Arathorn wrote:
| I constantly miss messages on TG, WA and Signal because I
| forget to check them regularly. It also really irks me that my
| conversations are trapped in those platforms without a public
| API, and I'd like to gather them together on an open platform
| like Matrix, and access them from every/any Matrix client i
| choose. Hence the use case for Element One :)
| hnarn wrote:
| Why do you need to "check them" in the first place though?
|
| And yes, I can understand that for some people the inability
| to easily transfer and collect those conversations is a
| problem, but for many people (imo probably more people) the
| ephemeral nature of these messages is a feature, not a
| problem to be solved. At least that's why I use Signal over
| Messenger, for example.
| zfnmxt wrote:
| > Why do you need to "check them" in the first place
| though?
|
| I have this problem; most Android apps send background
| notifications via Google's Firebase Cloud Messaging instead
| of rolling their own services. (Signal is an exception to
| this.)
|
| So, if you're unwilling to use Google Play services (or us
| an OS which doesn't support it), you're fucked and will not
| receive background notifications. The primary reason I use
| bridges with Matrix is not to unify my messaging experience
| into one app, it's to get notifications on my phone.
| rnestler wrote:
| > So, if you're unwilling to use Google Play services (or
| us an OS which doesn't support it), you're fucked and
| will not receive background notifications.
|
| I don't know about WhatsApp, but at least Telegram and
| Threema can fallback to polling if push notifications
| aren't available. With polling there is of course the
| trade off between battery usage and message delay, but
| you shouldn't miss any messages.
| NikolaNovak wrote:
| If I can enhance understanding on any level, FYI FWIW I will
| sign up for this likely.
|
| 1. Yes - In this context I prefer convenience over
| impractical/unrealized encryption. (Not privacy - I find
| Whatsapp, which hinges on my personal private phone number, far
| less "private", than other traditional messenger apps which I
| can sign up for anonymously; and for my use cases it's not a
| realized encryption, as people I talk to have no concept of
| security and I should assume anything I send to them has been
| scrubbed by malware and any other apps they've intentionally
| installed and agreed to).
|
| 2. Dozen apps are annoying impractical and I darn tooting well
| do _Not_ have their notifications enabled. I 'll agree that
| Android sharing is awesome; my experience with iPhone sharing
| has been Far more limited.
|
| 3. Whatsapp is darn near impossible to effectively use multi-
| device. If this will let me chat to my in-laws (who are stuck
| on Whatsapp not for any privacy or encryption reasons but
| because "everybody uses it") from comfort of my computers and
| keyboards, reliably, then this is a shut up & take my money
| proposition.
|
| 3a. Anybody about to comment "But whatsapp works on computers",
| see my other replies:)
| rkangel wrote:
| I've just signed up for this.
|
| I think "on average more willing to sacrifice privacy over ease
| of use" is probably a reasonable description of me. I'm not a
| fan at all of FB though, I have absolutely no trust in them at
| all. As such, I tried to get my world moved from WhatsApp to
| Signal. Inevitably I didn't succeed completely (although more
| than I expected) but now I'm split between those two. Plus I
| have some people who only communicate via FB messenger, and a
| few friends on Discord.
|
| To message someone I first have to remember which platform they
| prefer and then find it in my folder of chat apps. It's not an
| insurmountable problem obviously, but it does add friction. If
| I can have that all in one place, cross-platform with a decent
| UX then that's definitely worth $5 a month to me, plus all the
| bonuses:
|
| * I am actually moving in a more privacy focused direction. Yes
| I understand the caveats with bridges, but being on Matrix
| means that I can start a (slow) process of moving my
| interactions onto it * I don't have to worry about backing up
| my Signal messages (which is a pain to have automatically sync
| 'offsite' from your phone) * I can use it as my IRC client
| (with message history hanging around), etc.
|
| Let me put it another way - I've wanted to be on Matrix for a
| while but haven't quite managed it. I like the decentralised
| philosophy, both from a technical perspective and a privacy one
| but every time I've signed up it hasn't been worth it and/or
| it's too painful. This gets it over the hump for me (if it's as
| promised).
| noworld wrote:
| Welcome to WUPHF.com
| fleaaa wrote:
| Seriously, should've named it WHUPF..
| quda wrote:
| Pay for chat ? Burn it!
| lvass wrote:
| Do they also host the WhatsApp native instance (Android VM)?
| That'd be great for those using Pinephones who still want easy
| access to WA. Otherwise the WA bridge would only work if you run
| a client yourself.
| pimeys wrote:
| They do not. You need to have the app installed to your phone,
| which is a big no for me.
| worble wrote:
| How safe is this to use? Couldn't WhatsApp or Signal detect
| you're routing everything to a shared hosting server somewhere
| and ban your account as a bot, stating the fact you're probably
| breaking some ToS clause?
| jakecopp wrote:
| I can't speak to WhatsApp, but I've been using the self hosted
| Signal bridge [1] and it is brilliant, no bot troubles at all.
| Behind the scenes it uses signalid [2].
|
| [1]: https://github.com/mautrix/signal [2]:
| https://gitlab.com/signald/signald
| remram wrote:
| I am wondering the same. Did WhatsApp ok this or will it get
| shut down the moment it gets any traction?
|
| Their terms of service [1] clearly state:
|
| > You must not (or assist others to) directly, indirectly,
| through automated or other means, access, use [..] our Services
| in impermissible or unauthorized manners [...] including that
| you must not directly or through automated means: [...]
|
| > (g) sell, resell, rent, or charge for our Services or data
| obtained from us or our Services in an unauthorized manner;
|
| > (h) distribute or make our Services available over a network
| where they could be used by multiple devices at the same time,
| except as authorized through tools we have expressly provided
| via our Services;
|
| > (i) create software or APIs that function substantially the
| same as our Services and offer them for use by third parties in
| an unauthorized manner
|
| [1]: https://www.whatsapp.com/legal/terms-of-service
| craigmart wrote:
| So this service consists basically in paying to compromise E2EE,
| adding an attack vector, storing my otherwise encrypted
| conversations on centralised servers, using an arguably worse
| client with less features just for the convenience of not having
| to open 3 separate apps? Who is this for?
| uhtred wrote:
| It's for all of us! Created by those nice folks over at the
| NSA! I make joke!
| sorenjan wrote:
| What's the point of this? Matrix, Signal, and Telegram all have
| open source clients, so you could make a client that used the
| native protocols and not route your messages through this third
| party's servers. Like Pidgin, Miranda IM, Trillian, and others.
| But I guess a monthly fee and cloud services are the more modern
| approach.
| Thorentis wrote:
| Conspiracy: Element has been taken over secretly by the US
| government, and Element One bridges will now have access to all
| the encrypted messages across multiple platforms that people
| assume are only destined for the recipient.
|
| It's brilliant actually. The more I think about it, the more that
| Matrix bridges seem like a perfect NSA tool. It's a man-in-the-
| middle attack of grand proportions, hidden in plain sight.
| solarkraft wrote:
| Matrix and a Element are great in theory, too bad the available
| clients still suck.
| maelito wrote:
| Element for Android is far from bad. Lacks threads, though. But
| same for Telegram and Whatsapp.
| leppr wrote:
| Both the Android and web clients are promising, it's clear
| there's been a lot of work put into it, but they're also way
| too buggy and unpolished to recommend. As such, I'm really
| not eager to use this feature.
|
| I would pay/donate just for them to improve the clients,
| regardless of this "Element One" service. It's an extremely
| important project.
| novocaine wrote:
| Threads are currently under active development :)
| johnisgood wrote:
| Any plans on making this free, or self-hosted?
| pimeys wrote:
| It is possible. I've been running my own for a year, but it
| takes quite a hefty server at least with Synapse, and it's not
| cheaper compared to the quite nice 5 euros a month pricing
| here.
|
| If you want to give it a try, this is what I used:
| https://github.com/spantaleev/matrix-docker-ansible-deploy
| zfnmxt wrote:
| You can run Synapse on a cheapo VPS for <$5/month; it doesn't
| exactly require much.
| pimeys wrote:
| I have Synapse and quite quite many bridges running and
| especially syncing a newbdevice takes a long time.
|
| Hope I could go with Conduit at some point.
| apetresc wrote:
| It always has been, since the beginning. This is purely
| convenient hosting for those not inclined to self-host.
| johnisgood wrote:
| Oooh, I may have misunderstood something, I think. :P
| ekianjo wrote:
| Relevant if you want to do it on your own :
|
| https://boilingsteam.com/how-to-bridge-discord-in-matrix/
| personjerry wrote:
| Back in the day before the rise of Facebook, there was an open
| source service that combined all the popular messaging protocols
| - MSN, AoL, IRC, etc.
|
| It was called Pidgin[0], and it never got particularly big.
|
| I see the same thing here. While it's interesting, I'm failing to
| see what the use case is. What's the niche that needs this solved
| in a big way?
|
| [0] https://www.pidgin.im/
| jakecopp wrote:
| > While it's interesting, I'm failing to see what the use case
| is.
|
| I'm unclear if it supports relay mode, but if so, you can
| invite Matrix, Signal, and WhatsApp users _into the same group
| chat!_ [1] Edit: Relay mode is not currently supported in
| Element One, I tried it out. I contacted support and they said
| "we will discuss this internally and possibly enabled it later"
|
| I've been using this on my self-hosted version of the bridge
| and it does wonders for those friends who are on Signal but
| don't want to try another app.
|
| Also, a lot of people just don't want to swap between apps for
| direct messaging people on different services. This means you
| can use any Matrix compatible app [2] to chat with anyone on
| Matrix/WhatsApp/Signal/Telegram.
|
| [1]:
| https://github.com/mautrix/docs/blob/master/bridges/python/s...
|
| [2]: https://matrix.org/clients/
| estaseuropano wrote:
| I think Trillian was even older, and I think there were some
| KDE apps that did it even before that...
| emilsedgh wrote:
| Kopete
|
| https://apps.kde.org/kopete/
| dTal wrote:
| No, it wasn't a "service" - it was a program. Unlike this
| thing.
|
| The main difference between this and Pidgin seems to be that
| you pay a monthly fee for someone to man-in-the-middle all your
| communications.
| surajrmal wrote:
| Meebo was a service that did roughly the same thing as pidgin
| (leveraging libpurple to do so iirc). It's a shame it was
| turned down.
| briffle wrote:
| Can you run Pidgin on your phone and tablet and laptop and
| move between them?
| lostmsu wrote:
| Depends on the services you connect to.
| IceWreck wrote:
| > you pay a monthly fee for someone to man-in-the-middle all
| your communications.
|
| All Matrix homeservers and bridges are open source. I self
| host some of them myself. Have been doing that long before
| Element One was a thing.
| tiagod wrote:
| How can I verify you're running unmodified, unhooked source
| in your server if I'm a user?
| cyborgx7 wrote:
| You can't. You can find a provider you trust or set them
| up yourself.
| dunefox wrote:
| How can anyone verify that?
| IggleSniggle wrote:
| You don't, you self-host your own server.
|
| My problem with the self-hosted model is that I don't
| trust myself to get it right and/or keep it updated. My
| problem with the 3rd-party model is that I don't trust
| them, either. So, lacking trust in either myself or the
| third-party, I'm just one of those people you can get
| only via secure e-mail, clear-text SMS, or whatever well-
| supported encrypted service happens to be the one with a
| plurality of users in my friend/family group. Clear-text
| sucks, but it can be used to negotiate a secure channel.
|
| Unfortunately, the levels of spam in my traditional
| telephony services have dramatically increased in recent
| years, and as a tradeoff, I've just gotten harder and
| harder to get in touch with directly as I increasingly
| default to ignoring more and more methods of
| communication. I don't even _think_ I 'm someone with
| anything to hide or anything to fear my communications
| being in the public, there's just too much information to
| manage.
| colbyhub wrote:
| I feel the same way, I don't fully trust hosted solutions
| but don't completely trust myself to host my own -- which
| is where E2E encryption comes into play, but a malicious
| host would still have access to loads of metadata
| (timestamps, IPs, etc.).
|
| Blockchain-based solutions like Status.im appear to do
| away with these sorts of issues through decentralization
| -- but you still have to put trust into their network.
|
| Solutions like TLS & OMEMO over Tor for XMPP seem to be a
| very strong privacy-centered solution outside of
| blockchain-based applications.
| mindslight wrote:
| I'm excited about NixOS (/GuixSD) because they would seem
| to provide a straightforward path to running secure
| services (self-compiled from publicly reviewable source)
| while keeping them automatically updated (build rules
| administered by a third party). I'm not saying this is a
| good approach for you personally right now, but I can
| definitely see it becoming popular in several years.
| h0nd wrote:
| Why would I want a man in the middle of my communications?
| realce wrote:
| Because the A-Series round of financiers think that's a
| great idea.
| noahtallen wrote:
| The real answer is because you want all your conversations
| to happen in the same app/protocol. You never have to
| download a shiny new messenger again
| hypertele-Xii wrote:
| I'ved heard that pitch before. It's always true only for
| some length of time. Protocols change, services evolve,
| companies transform, products are deprecated and people
| are fickle.
|
| I've used all-in-one messengers before. They come and go
| like the wind. You'll be downloading a shiny new all-in-
| one messenger periodically anyway.
|
| Just trading one kind of inconvenience for another.
| TeMPOraL wrote:
| Perhaps if we normalized messenger interoperabiltiy,
| there would be less churn in "all-in-one" clients. That
| churn exists mostly because platforms actively fight
| their users on this.
|
| And still, periodically changing an all-in-one messenger
| is still better than keeping and changing half a dozen
| messengers.
| Vinnl wrote:
| Of course the protocols Pidgin bridged were only used for
| real-time communication, rather than for leaving messages
| which could be attended to (or delivered) later.
| oblio wrote:
| No, it wasn't. Yahoo had offline messages. So did many of
| its other protocols.
| Vinnl wrote:
| Ah you're right, I think I indeed had that for MSN as
| well. Must've gotten confused.
| ufmace wrote:
| It's worth remembering again _why_ we don 't do this. Even if
| you fully trust whoever is running the MITM server, being
| that it's MITMing all of your comms, and it's on a server so
| it's actually a lot of people's comms, it's a massively
| tempting target for all sorts of bad actors. Plenty of
| governments and criminal gangs would just love to compromise
| that for all sorts of reasons. Odds are one of them will
| eventually.
|
| For all you know, someone else on the server is a high-value
| target for somebody, and if they compromise the server to get
| their comms, they may not be very picky about what happens to
| the private communications of everyone else on that server.
| dtonon wrote:
| It _is_ a service, because the bridge is a software that need
| to be keep operational 24 /24h and sometimes this is not so
| trivial (if I don't get wrong WA need an Android emulator
| running).
| RNCTX wrote:
| It is not a service, if it's a link to a download and a
| bunch of community-developed plugins.
|
| When you take away the motivation to mitm all of the users'
| chats, there's nothing left.
| saurik wrote:
| Pidgin doesn't use a "bridge"... it is just a generic local
| client that supports plugins for various protocols that are
| implemented via adversarial interoperability.
| Spivak wrote:
| And because of that Pidgin is horribly unreliable. Don't
| get me wrong, I used it for years, but over time all the
| plug-ins broke for one reason or another.
| capableweb wrote:
| Law makers are required here to solve the situation, as
| platforms themselves refuse to work with each other. If
| Facebook and Google had to operate a common protocol
| (just like IMAP), Pidgin would work much better or
| wouldn't even be needed.
|
| But no, they want to prevent people from talking with
| each other via other platforms because "we're best" or
| whatever.
| hellojesus wrote:
| It's probably because they don't want to lose users.
|
| If you have FB, and I have Twitter, and we can chat, why
| would I ever make a FB profile or you a Twitter profile?
|
| The mutual exclusivity is the competitive advantage. All
| these companies are competing with one another for your
| eyes. It wouldn't make sense for them to give that up for
| no return value.
| capableweb wrote:
| Exactly! Providing a walled garden just for the sake of
| keeping users should not be legal, just like abusing any
| other market position wouldn't be legal.
|
| I get that they want their "network effect" and keep it
| to themselves, but this is no good for users and the
| industry doesn't "regulate itself" as we've heard so many
| times, so time for law makers to step up finally.
| hellojesus wrote:
| My point is that the walled garden is the competitive
| advantage.
|
| A law like this could regulate businesses out of
| existence.
|
| Which websites fall under it? Only social? What about
| forums, etc. What if the companies just rebase to non-US
| jurisdictions? Even if you make this law, it's unlikely
| it would actually compel anyone to comply.
| TeMPOraL wrote:
| > _A law like this could regulate businesses out of
| existence._
|
| Only if they didn't change their business model to
| something less incredibly antisocial than walling people
| in and serving them ads.
|
| There are many ways to operate a communications business
| on-line. That only the bad one is used in practice is a
| consequence of it being the most profitable of available
| options. If it weren't available (say, because of being
| regulated away), companies would pick the next most
| profitable one.
| acdha wrote:
| Yes -- this line of argument sounds exactly like the
| people who very confidently said that the economy
| couldn't survive ditching asbestos or CFCs, emissions
| laws would destroy California, etc.
|
| The key part is having regulations apply the rules evenly
| so everyone prices it into their decisions. Trying to
| limit specific companies makes that feedback cycle less
| effective.
| hellojesus wrote:
| Yes, but what if this is the only way to have a
| profitable business such as these? Are you okay losing
| them entirely?
|
| More generally, my view of regulation is that it should
| only exist if there is some quantifiable harm to an
| involuntary third party (negative externality). Where is
| the demonstrative harm here, and who is it impacting?
| Having one friend on FB and another on MySpace, requiring
| the user to log into each platform separately isn't harm.
| The effect is the same as having one friend call you on a
| phone to communicate and the other only use text.
|
| Every single person using these platforms makes a
| conscious decision to use them given their limitations.
| Nobody is forcing anyone to use these platforms. The
| government still runs a post office. You could use that
| to communicate with people if you wanted.
|
| Instead of passing legislation to fix your problem, how
| about you just talk to your friends and get them to agree
| on using a single platform?
| TeMPOraL wrote:
| > _Yes, but what if this is the only way to have a
| profitable business such as these? Are you okay losing
| them entirely?_
|
| But it isn't. We know it isn't - exchanging text, audio
| and video messages wasn't invented by adtech giants. Two
| prime examples:
|
| 1) Telephony and mobile telephony operators have strong
| businesses to this day, despite being made interoperable
| by law.
|
| 2) Non-adtech e-mail providers exist and make money,
| despite being interoperable and not subsidized by
| advertising and personal data misuse.
|
| > _Where is the demonstrative harm here, and who is it
| impacting? Having one friend on FB and another on
| MySpace, requiring the user to log into each platform
| separately isn 't harm._
|
| In my opinion, there is harm - creating unnecessary
| burden and confusion for everyone, especially non-tech-
| savvy people. It is tying people down to services via
| network effects, and then further harming them by
| exfiltrating their personal data and exposing them to
| advertising (either directly or indirectly, making the
| ads more potent thanks to aforementioned personal
| information).
|
| > _The effect is the same as having one friend call you
| on a phone to communicate and the other only use text._
|
| No, it isn't. It's just having one friend text you,
| another friend write you a Messenger message, yet another
| a WhatsApp message, yet another a Telegram message...
|
| > _Every single person using these platforms makes a
| conscious decision to use them given their limitations.
| Nobody is forcing anyone to use these platforms._
|
| But that's not true at all. People are coerced to use
| these services, and coerced to stay with them. That's the
| literal definition of _network effect_. I have to use
| WhatsApp /Facebook/whatever because my mom is there and
| doesn't want yet another chat app, and my local plumber
| only communicates through it. I have to stay, because
| neither my mom nor my plumber will move. The more people
| are trapped in the net, the stronger its hold.
|
| Contrast that with phone and e-mail service: I can
| communicate with anyone regardless of the provider they
| use. I don't even need to know what provider they use.
| And I can switch my providers at any time, and nobody
| else has to know, or care.
|
| > _Instead of passing legislation to fix your problem,
| how about you just talk to your friends and get them to
| agree on using a single platform?_
|
| These platforms are as successful as they are exactly
| because your proposed solution is impossible to implement
| by most people. Again: network effect.
| hellojesus wrote:
| > Telephony and mobile telephony operators have strong
| businesses to this day, despite being made interoperable
| by law.
|
| True, but their business model also requires payment
| unlike all these "free" services.
|
| Moreover, the interop requirements here seem to me to be
| more preventative of physical monopoly than anything
| else. Physical phone lines and wireless frequencies
| impose physical barriers to entry or are only usable
| without transmission interference. Without an interop
| protocol, it's clear the first mover would steal the
| entirety of the market.
|
| Websites are not the same. They are an interface built
| upon an already interop'd internet, from tcp up to http.
| There are no barriers to entry apart from the barrier to
| physcially access the internet, which is already interop
| among providers.
|
| > In my opinion, there is harm - creating unnecessary
| burden and confusion for everyone, especially non-tech-
| savvy people. It is tying people down to services via
| network effects, and then further harming them by
| exfiltrating their personal data and exposing them to
| advertising (either directly or indirectly, making the
| ads more potent thanks to aforementioned personal
| information).
|
| I don't think inconvenience qualifies as legislation-
| requiring harm. Yes, it is a pain if your network doesn't
| centralize, but email is still completely interop and
| free (not your data) or low-cost if you set up a domain
| on your own or pay for private email.
|
| Tools are generally adapted because they make life
| easier. It is super easy to snag a Gmail account and then
| use it to create a WhatsApp, or Telegram, etc. account
| and immediately start chatting with your friends via the
| app' identification of them due to your phone book. No
| argument there. But to say that because other companies
| have done it and attracted your other friends first, they
| must now be _compelled_ to allow you to export the data
| elsewhere, or at least define their systems by some
| standard, makes no sense to me. We have standards already
| and there is no physical barrier to entry for
| competition. There is a reason new apps keep coming out,
| and the low barrier to entry is one of the main factors.
|
| > But that's not true at all. People are coerced to use
| these services, and coerced to stay with them. That's the
| literal definition of network effect. I have to use
| WhatsApp/Facebook/whatever because my mom is there and
| doesn't want yet another chat app, and my local plumber
| only communicates through it. I have to stay, because
| neither my mom nor my plumber will move. The more people
| are trapped in the net, the stronger its hold. (...)
|
| Email is an interop standard. You sign up for an email
| account knowing you can communicate to any other email
| account. When you sign up for FB, you know you can only
| talk to people on FB. The difference is by design.
|
| Coercion by your network that is not inhibited by
| physical barriers to entry is a personal problem. Your
| mom only wants to use FB, fine. Just speak with her
| elsewise or explain to her why you won't use FB. This is
| a personal negotiation and is not of relevance to
| lawmakers. Similarly, if your plumber only communicates
| with potential clients over WhatsApp, find a different
| plumber if you don't want to use WhatsApp. It's really
| that simple. No other plumbers around? Great! You've
| identified a huge opportunity that you or anyone can
| fulfill.
|
| > These platforms are as successful as they are exactly
| because your proposed solution is impossible to implement
| by most people. Again: network effect.
|
| My proposed solution is not at all impossible to
| implement. Difficult? Yes, extremely, but let's not
| confuse impossibility with difficulty. It is possible,
| but you'll have to be willing to make sacrifices along
| the way. The golden light in this is that you currently
| have the opportunity to make a chat system that defines
| an interop standard. Build it and they will come.
|
| Anecdotal: when I joined my current employer my manager
| requested that I download and install WhatsApp to be able
| to communicate with the continent-spanning team chat for
| production issues. I contested. WhatsApp was not an
| approved company platform, and I was unwilling to install
| it on my personal device. I would happily install it on a
| work provided device, but I would not carry the work
| device with it on 24/7 because I didn't want to leak
| telemetry, etc. data to FB. So I don't use it. The team
| does, but I don't. They reach me through work channels if
| necessary or directly by phone/text.
| josteink wrote:
| WA works with a pure go-based bridge. No Android required.
|
| The rest of your comment is true though. Keeping these
| bridges up 24/7 is quite a bit of work. Most people (even
| technical ones) probably won't bother with that.
| lvass wrote:
| Which bridge is it? Mautrix/whatsapp does require an
| Android instance of whatsapp.
| your_challenger wrote:
| You need WhatsApp to be installed on a real device or a
| VM for mautrix-whatapp [1] (the bridge) to work. You also
| need to connect to that real device using WhatsApp web
| [2].
|
| I know because I've used the bridge.
|
| [1] https://github.com/mautrix/whatsapp [2] https://docs.
| mau.fi/bridges/go/whatsapp/authentication.html
| EVa5I7bHFq9mnYK wrote:
| And FB will probably not like running WA in an emulator,
| and will kill that option as soon as it reaches ~100k
| users.
| pi7h3n wrote:
| how can they kill it?
| hypertele-Xii wrote:
| They have so much money and influence, I trust them to
| find a way :)
| unicornporn wrote:
| Thank you. Let us not forget what general purpose computing
| was like.
| unicornporn wrote:
| Following up on this... I was Miranda user. With it I was
| able to run ICQ, MSN Messenger and other instant messengers
| with an encrypted layer slapped on top (as long as I was
| able to talk my friends out of using the official client).
| Today it's called Miranda NG[1] and it seems alive and
| kicking[2].
|
| [1] https://www.miranda-ng.org/en/ [2]
| https://github.com/miranda-ng/miranda-ng
| stavros wrote:
| _uhoh.wav_
| arp242 wrote:
| > I see the same thing here. While it's interesting, I'm
| failing to see what the use case is. What's the niche that
| needs this solved in a big way?
|
| I used Pidgin a lot. I always found it very convenient to have
| everything in one place and UI. Better one client than MSN +
| AOL + ICQ + IRC + Yahoo! + XMPP.
|
| In the last few years I haven't used it much, but that's
| because it just doesn't support the popular messaging apps of
| the day (or maybe it now does, I haven't checked in a while).
|
| Also, as others have pointed out, Pidgin is not and never has
| been a "service", it's just a library (libpurple) that
| implements various protocols, with Pidgin as the GUI (they also
| make Finch, a TUI).
| anthk wrote:
| Bitlbee can optionally use Libpurple too.
| oblio wrote:
| Pidgin was extremely convenient. But it was commoditizing
| messaging platforms so of course it had to be shot in the
| head by them.
| arp242 wrote:
| I don't think anything got "shot in the end"; the protocols
| of old were often just reverse-engineered too. Few bothered
| publishing anything about it, which is why Jabber/XMPP was
| created.
|
| Since then encryption made things a lot harder;
| specifically, E2E encryption. You can't "just" login to a
| server and send messages, you need to encrypt and decrypt
| things on the device with the right keys, and how do you
| handle things like message history WhatsApp and Signal
| solve this for the desktop/web versions by designating your
| phone as the only device that can connect to their service,
| and everything else communicates via that phone. Telegram
| solves it by having regular chats not be E2E encrypted, and
| having a special "secret chat" feature for it.
| pi7h3n wrote:
| who's them?
| tut-urut-utut wrote:
| > messaging platforms
|
| No need to pretend that what the previous comment was
| saying is some kind of conspiracy when it's obvious that
| business gonna business.
| josteink wrote:
| > Back in the day before the rise of Facebook, there was an
| open source service that combined all the popular messaging
| protocols
|
| It was not a not a service which was always on and synced
| between units.
|
| It was a client you had to run on your machine and keep
| connected. And it obviously didn't roam.
|
| Pretty much an apples to oranges comparison.
|
| Matrix and Element aims to bring all those things you mention
| to a single protocol, to which you can connect any client you
| like, on any device you like, and roam as you like with all
| your clients always in sync.
|
| It's what Pidgin used to deliver, levelled up and connected to
| the "modern" (read: closed) IM-silos the majority of people are
| using.
|
| It's definitely different and it's definitely interesting.
| ruffrey wrote:
| Fun fact, pidgin was developed by Mark Spencer, who also wrote
| Asterisk PBX and currently builds open source flight avionics.
| luke2m wrote:
| Pidgin works with a surprising number of modern services [0]. I
| used it last year on my 32 bit computer that couldn't run the
| official discord client.
| mcjiggerlog wrote:
| There was a good recent episode of Late Night Linux Extra[0]
| where the maintainer talks about Pidgin and how it compares
| with Matrix.
|
| [0] https://latenightlinux.com/late-night-linux-extra-
| episode-32...
| klntsky wrote:
| I really love libpurple plugins for pidgin and how they can be
| combined.
|
| For example, I was able to communicate using OTR on vk.com
| (russian facebook clone). Probably other niche messaging
| plugins work with OTR too (it's just plaintext messages, after
| all).
| fimdomeio wrote:
| Back in the day and for a little while platforms companies
| thought to at least have a common language (xmpp). Then they
| thought it would be a better idea if we all had 10 different
| apps on our phones for text messages.
|
| There's no reason for standardization and interoperability not
| to be forced on these companies.
|
| When you sent a physical letter you have to follow some
| standards on the envelope addresses, when you make a phone call
| to the other side of the world people can still hear your
| voice, same for sms, same for email, but apparently sending a
| string of text via internet in a standard protocol is an
| unsolvable problem.
| peoplefromibiza wrote:
| think about this: WA protocol was simply XMPP with shorter
| labels (one character when possible)
| mehdix wrote:
| Companies must be forced to implement a subset of their
| features as part of some interoperability standard. The rest
| they can keep for their competitive advantage. I can't recall
| any industry who ever volunteered for this. Car makers
| didn't, telecoms didn't, software makers won't. No one did
| and they all exploited their users/customers to the fullest
| until they were forced to do so.
| enlyth wrote:
| Anyone remember Trillian? I used to use it to combine Facebook
| Messenger, ICQ, and some other stuff.
|
| All my friends have since moved to Discord now which is way
| nicer than any other user experience.
| adamw2k wrote:
| Yep, brings be back... + AIM, MSN, they even had a primitive
| IRC connection if memory serves me right.
| Ntrails wrote:
| I still use pidgin regularly for various chat rooms and ircs
| etc. It is a great piece of kit imo
| h0nd wrote:
| Two decades ago I used trillian and mirianda for all the
| popular messaging protocols,
|
| https://trillian.im/ https://www.miranda-ng.org/en/
| k1rcher wrote:
| Ah, XMPP + OTR. Brings back fond memories.
| johnisgood wrote:
| Pidgin and Gajim.
| shmerl wrote:
| Pidgin is an IM client, not a service. A service would be
| something like XMPP servers (Google Talk used to be one and
| even federated until it went sideways).
| cookiengineer wrote:
| I thought about all that libpurple did back then, including OTR
| encryption that worked perfectly fine with others.
|
| These days I think that most services try to make money with
| stuff that was built decades ago already, and they're just
| keeping the reinventing cycle spinning.
|
| Anyone remember the franz app [1] ...which finally led to the
| hardfork of ferdi? [2] I feel that element one is franz all
| over again.
|
| [1] https://meetfranz.com
|
| [2] https://github.com/getferdi/ferdi
| briffle wrote:
| The Glory days, when both Google Talk and Facebook used XMPP,
| and you can run one client to chat with all of them. We ran
| Prosidy and Pidgin at my old job, and it worked great for our
| company chat server.
| ksec wrote:
| Everything old is new again.
| upofadown wrote:
| I think this is more like XMPP transports in that is is
| centralized at the server. Such things tended to end up
| centralized as it is a lot of work to keep up with the efforts
| of the people running the services to remain incompatible with
| the bridges. These days few XMPP servers bother with transports
| to commercial IM services. I suspect the same thing will happen
| in the Matrix case.
| Andrew_nenakhov wrote:
| Transports work against your platform. Running a WhatsApp
| transport, you enhance WhatsApp's network effect and dilute
| your own.
| TeMPOraL wrote:
| Transports work _for_ you when you 're an upstart, because
| it makes it less risky for users to adopt your platform.
| They work against you only once you get significant market
| share.
|
| See e.g. Slack, which propelled itself to success by
| offering an IRC transport, which prevented strong
| opposition for technically inclined people, and then
| promptly killing it when they became a major player in the
| office IM space.
| Gigachad wrote:
| Agreed, not sure what the use case is. It's super trivial to
| switch between messaging apps and it's not often that you are
| having a conversation with multiple people over multiple apps
| at once and even then it's still manageable.
|
| The only thing I can think of is people who do not wish to have
| the app installed for privacy / open source reasons.
| TeMPOraL wrote:
| Think of people who are:
|
| - Not tech-savvy and easily confused by keeping 6 different
| messengers around.
|
| - People for whom multiple clients becomes a cognitive
| burden.
|
| - Waste of storage space, memory and CPU power that those
| (hugely bloated, most of the time) clients incur, especially
| on mobile devices.
|
| - People like me, with diminished executive functioning
| capacity, who are _fucking tired_ of bad ergonomics of all
| those clients together and each individually, and who 'd
| prefer a single, consistent, ergonomic and powerful UI to
| manage the torrent of messages they receive.
| Gigachad wrote:
| The first two are not well solved by Matrix as the default
| client is far less user friendly than the proprietary
| alternatives.
|
| Storage space might be an issue on very low end phones but
| these days phones are starting with 128gb of storage which
| no IM app is close to filling. Mobile OSs are extremely
| good at sleeping apps and can receive messages while the
| app is not running at all using notification services. I
| would say that resource bloat is actually much more of an
| issue on desktop where you have 10 instances of chrome
| running and none can be closed while still receiving
| notifications.
| pmlnr wrote:
| There, it's still good:
|
| https://github.com/petermolnar/awesome-pidgin-plugins
| Animats wrote:
| This just has to be a backdoor.
|
| It shouldn't even be a service. It should be a local app that
| knows how to be a client for all those things. Just a unified
| inbox.
| NikolaNovak wrote:
| I fully understand that for many, this is not an acceptable
| security risk. It may have technical compromises.
|
| For me, Whatsapp is used by my non-technical in-laws for the
| simple reason of "because everybody uses it". I find whatsapp
| extremely impractical (I communicate better via large ergonomic
| keyboard on my computer, vs via 1.5"-wide screen; to each their
| own), so anything that makes Whatsapp and other proliferation of
| incompatible annoying chat services easier... yes, yes, please
| yes :)
| rrrrrrrrrrrrr wrote:
| There is desktop and web clients for WhatsApp by now tho
| NikolaNovak wrote:
| And they're broken broken broken, and such by design.
|
| Current app uses Phone as primary and allows for one other-
| non-phone-device. If you try to log in on e.g. your tablet
| and computer, or switch between them often, you'll hit any
| amount of trouble and will get locked out of account.
|
| The current beta has enhancements for multi-device support
| which may support several non-phone-devices at the same time,
| even if your phone is offline for short period of time. But
| it's buggy and your Phone is still your primary and it still
| won't allow you to sign up without one (it assumes Phone is
| Me and my life centers around my phone, which is true for my
| in-laws but not for me:), and the list of limitations is sky
| high and likely to remain that way.
|
| Whatsapp _fundamentally_ prioritizes end to end encryption;
| primacy of phone; and convenience of contacts for privacy-
| non-conscious, over everything else. It is good for those who
| highly value end to end encryption, for reasons of need or
| principles.
|
| For those who need multi-device support, Whatsapp is way way
| way worse than other chat services of today or 1990s. Right
| now, I am logged in to Hangouts on three computers, tablet,
| phone and Galaxy Note (whatever we call that these days:). I
| am available via Hangouts whatever I do and wherever I am.
| And frankly I find it more private as it doesn't advertise my
| existence to all my contacts and siphon them off, doesn't
| require my phone number which is one of my most private
| pieces of identifying information, and provides me actual
| privacy and anonymity if I choose, but that's a whole other
| discussion.
|
| Whatsapp does not, and will for foreseeable future not
| support my use case. It may or may not be rare, it may or may
| not be something anybody else thinks is important, but Phone
| is not the centre of my existence or my sole & preferred
| method of communication, and as such whatsapp is completely
| unusable for me. I may be 1% or 0.00001%, and I'm open about
| that, but this whole notion of "Whatsapp totally works on
| multi-device" is just getting tiring to misspell - it's right
| on their FAQ that it is counter-indicated by design by
| current production version.
| rkangel wrote:
| Note that the Matrix WhatsApp bridge is fundamentally
| pretending to be the WhatsApp web client (as I understand
| it at least). The phone is still the interconnection point
| and if you turn off your phone no WhatsApp messages would
| get through to Element. It is improved by being a once off
| 'pairing' though and you don't need to switch between
| multiple web clients.
|
| Of course the new 'multi-device' beta might improve the
| situation but that's not leveraged yet.
| contradictioned wrote:
| Now, I miss Miranda. It was a multi protocol messenger I used for
| icq, aim, and jabber. Friends were more into trillian. But one
| always had bittlebee, I somehow envied this...
| upofadown wrote:
| Correct me if I am wrong, but this means that you have to trust
| the people running the bridging server with not just the content
| of your messages but your account identity/login information as
| well?
| jakecopp wrote:
| > with not just the content of your messages
|
| Yes, for bridged chats. Matrix <-> Matrix direct & group chats
| are E2E by default.
|
| > but your account identity/login information as well
|
| Yes, however identity/login does not permit access to E2E
| messages (and cross signing prevents E2E compromise [1]).
| Matrix supports migrating accounts to other servers [2] while
| keeping your data/social graph (depending on your history
| viewability settings I believe, someone please correct me if
| I'm wrong!).
|
| [1]: https://matrix.org/blog/2020/05/06/cross-signing-and-end-
| to-...
|
| [2]: https://ems.element.io/tools/matrix-migration
| _pmf_ wrote:
| If we can also get Slack in there ...
| efields wrote:
| What does this solve? Makes switching between apps on my phone
| easier?
| a-dub wrote:
| this has been around since at least january of 2021.
|
| i looked into using something like this or setting up my own
| synapse+bridges and ultimately thought the synapse server had way
| too much in the way of complexity and attack surface for
| something that would ultimately end up being a consolidation of
| all my encrypted messaging. (it was also a bit weird to see
| public internet protocols using grpc, but i guess that's what
| people do now)
|
| that's the world we live in i guess. you either dedicate a bunch
| of time to watching your own infra, let tech giants read your
| messages or let hackers read your messages.
|
| this is fine.
___________________________________________________________________
(page generated 2021-10-26 23:00 UTC)