[HN Gopher] Briar Project
___________________________________________________________________
Briar Project
Author : fishmaster
Score : 62 points
Date : 2020-08-02 21:23 UTC (1 hours ago)
(HTM) web link (briarproject.org)
(TXT) w3m dump (briarproject.org)
| askxnakjsn wrote:
| Now that I think about it, why aren't most messaging apps peer to
| peer? Shouldn't that be the standard? I mean it's literally the
| point of messages: sending from one person to another.
| kyshoc wrote:
| > why aren't most messaging apps peer to peer [...] it's
| literally the point of messages: sending from one person to
| another.
|
| Messaging apps are more like postal services -- "please deliver
| this message to $person" -- you're describing driving across
| town to drop something in a mailbox directly. A peer-to-peer
| messaging system wouldn't have many benefits over an
| E2E-encrypted one (in a centralized E2E-encrypted service you
| already enjoy technical guarantees that the courier can't peek
| inside the metaphorical envelope), but would have several
| usability drawbacks that would drive away casual users, which
| the sibling comments mention.
|
| Driving away casual users has its own problems: you might drive
| them away to insecure services ("ah fuck it, this thing doesn't
| work, I'll just DM them on Twitter"), and the lack of casual
| users will make your remaining users stand out in traffic
| analysis (e.g. state agency says "hmm, askxnakjsn is using
| SuperEncryptoP2PMessenger, better go make sure they aren't a
| dissident").
| inglor wrote:
| For multiple reasons but first of all because it would require
| both devices to be connected and online.
|
| The common alternative to overcome this is to pass the messages
| through the server and encrypt/decrypt them on the device (aka
| e2e encryption). I acknowledge that might not be secure enough
| for certain use cases.
| raspyberr wrote:
| P2P requires both clients to be running at the same time in
| order to communicate. If you friend's phone is off and you send
| a message, they won't get it when they turn their phone on.
| myself248 wrote:
| Seems to me like there should be a DHT way to solve this.
| When you boot up, you take your place in the table and query
| your neighbors for messages. If someone's unreachable when a
| message is sent, you hand the message to their neighbors to
| hold it until they appear.
| untog wrote:
| Which requires you to trust your neighbours. To which you
| might say: aha! Just use end to end encryption! And sure,
| you can. But at that point, what benefits are you getting
| over using E2E with a centralised system? Very few. And
| you're getting a bunch of drawbacks in terms of reliability
| too.
| crazygringo wrote:
| Because:
|
| a) Often the intended recipient isn't online when the message
| is sent, and it may happen that there is never a time when both
| sender and recipient are online simultaneously (e.g. sender's
| device only turns on to send the occasional message, receiver's
| device is usually off but turns on occasionally to check if
| there are messages)
|
| b) Often one or both devices can only _connect_ to, but can 't
| be _connected_ to (because behind a NAT, a mobile device,
| firewall, etc.)
|
| c) Communication is often desired between accounts rather than
| devices -- I may want to send/receive on my work computer, home
| computer, phone, and watch
| IgorPartola wrote:
| In before someone suggests storing encrypted messages in a
| public blockchain. This is a really good overview of the
| challenges with these messaging systems. Store and forward
| has been our MO since email and Usenet were invented because
| always on always connected devices that aren't restricted by
| some network obstacle are not really feasible or even
| desirable most of the time. I do wonder what alternatives we
| have to something like a trusted online service to store and
| forward messages or a public blockchain. Some kind of crypto
| based system where nobody but the owner of a private key can
| even locate the message? A decentralized system where
| multiple copies of multiple fragments of your message are
| stored so nobody can piece together your (encrypted) message
| without controlling the majority of the nodes?
| aaravchen wrote:
| It seems like this might be the eventual intent of the
| Scuttlebutt protocol, and so far that's also the furthest
| along in approaching such a solution.
| raspyberr wrote:
| Do you have an opinion on Skype like centralised
| coordinator that then sets up P2P connections?
| IgorPartola wrote:
| This really isn't my field, I am more of a full stack
| developer who mostly works on web apps with a heavy
| interest in networking. So definitely not an authority on
| the subject.
|
| I think that's basically the sort of system that most
| places employ. It's nice because it's easy to set up but
| you really need to trust Skype. Say they actually try to
| use end to end encryption. How does that work? Well, you
| could say "I am Alice and I want to establish a
| connection to Bob. Here is my public key he can use to
| send me messages and I'd like his public key so I can
| send him his." That of course would need to happen in
| addition to establishing a network connection. So no if
| Skype is a good actor they will pass my public key to
| Bob, get his and send it to me as well as coordinate us
| establishing a direct connection.
|
| But what if Skype is a bad actor? Well they could take my
| public key and send Bob one of their own. Then they could
| also send me their own. Now they can listen in on my
| conversation. They can also in a similar fashion make it
| seem like I'm connected directly to Bob's networked
| device but really just relay the connection through their
| servers. Neither Bob nor I would have any way of knowing
| that without having exchanged public keys prior and
| having verified them. So this system is basically
| insecure against Skype wanting to listen to my
| conversations or being compelled to do so by a state
| actor.
| davidzweig wrote:
| Is IPv6 likely to be a practical solution to the router/NAT
| issue? Are routers assigning globally-routable IPs to their
| clients, is that already a thing?
| untog wrote:
| IPv6 solves _one_ of the reasons to use NAT. One more
| intractable reason is that many players (cellphone network
| operators, corporate networks) consider it a positive thing
| that individual devices are not globally accessible.
| dunefox wrote:
| I've been looking for secure messengers during the last few
| weeks. I use WhatsApp, Signal, and Telegram. Telegram isn't very
| secure, WhatsApp is owned by Facebook and even Signal - while
| very secure - requires a cell phone number... Briar seems great
| in this regard but isn't available on iPhone and has no support
| for images, calls, voice messages, etc. Apparently they're going
| to support images and a desktop client, though.
|
| In short, I just don't know what to use.
|
| Edit: Session looks great but is not fully released yet:
| https://getsession.org/ This might be what I'm looking for in the
| future.
| sdenton4 wrote:
| FWIW, I think you can just get a Google Voice or other short-
| term burner number to sign up for Signal, and then never worry
| about it again. Signal's an order of magnitude more trustworthy
| than the other messaging players and have built out a good base
| of features at this point. (telegram specifically is a joke...
| proprietary closed-source encryption is a recipe for disaster.)
|
| I would strongly advise against picking a tiny new-comer
| without some serious research beforehand... They're not battle-
| hardened, so will typically be less reliable than any of the
| existing larger players.
| shuringai wrote:
| care to elaborate on how telegram is unsecure? Their fat bug
| bounty program yielded no security issues for years and I'm
| unaware of any issues with MTProto
| cl3misch wrote:
| Their server backend code is closed source and they're
| running custom crypto. Also groups and desktop clients don't
| support end-to-end encryption.
| dijit wrote:
| Have you looked at 'threema'? I recently installed it and I'm
| actually pleasantly surprised.
|
| However, all of these bloody messengers mean that my contacts
| list is spread across a multitude of programs: we need the
| iOS/Android equivalent of pidgin.
| ssss11 wrote:
| Pidgin is exactly what we need.. and each messenger needs to
| be a pluggable module. Then we dont need to hound friends and
| family to switch messenger apps they just use pidgin.
| raspyberr wrote:
| But why would something like Facebook open up their walled
| garden? Does it even count as a walled garden when you have
| 2 billion people on the platform?
| dunefox wrote:
| Threema is closed source which is something I don't really
| like when it comes to security as there are no independent
| audits.
|
| Edit: Generally, Threema seems interesting feature-wise, but
| I think the price (4EUR) will prevent my contacts from using
| it...
| shuringai wrote:
| threema claims no having no identificable information yet the
| account IDs are just the unsalted hashes of your telephone
| number.
| PostOnce wrote:
| Signal is working on getting rid of the cell # requirement, but
| it'll take a while.
| myself248 wrote:
| It can't happen soon enough. I installed Signal a few years
| ago, and the first thing it did was notify a bunch of people
| I had in my contacts, that I was now using Signal...
|
| ...Including the unstable frenemy-guy who was only in my
| contacts so I'd recognize the number if he called and I'd
| know not to answer...
|
| ....who immediately PM'd me on Signal to push his latest
| delusion and make sure I didn't disagree.
|
| Great, just great. For a privacy-focused product, that's a
| pretty colossal fuckup.
| shuringai wrote:
| also, very soon signal won't require a phone numbet as the PIN
| feature (what is present now for storage encryption) will be
| extended to serve as account ID
| IgorPartola wrote:
| What did Riot, the Matrix client, get renamed to?
| kgraves wrote:
| "Element". had to look it up, forgotten it already. :/
| IgorPartola wrote:
| It is a really forgettable name, to be fair.
| overcast wrote:
| iMessage? Natively on your phone/macOS and peer to peer
| encrypted. Never really saw a need for yet another messaging
| service. I think I'd trust Apple to do the right thing over any
| of these.
___________________________________________________________________
(page generated 2020-08-02 23:00 UTC)