[HN Gopher] Why federated protocols don't work (2016)
___________________________________________________________________
Why federated protocols don't work (2016)
Author : pcr910303
Score : 83 points
Date : 2022-02-12 17:23 UTC (5 hours ago)
(HTM) web link (signal.org)
(TXT) w3m dump (signal.org)
| danShumway wrote:
| I think my main criticism of this article is that Signal today
| isn't proving that this is true.
|
| Yes, federation makes all of this stuff harder. Of course it
| does. There are problems you have to solve in federated systems
| that you don't have to solve in centralized systems. And it used
| to be easy to point at platforms like Matrix/Element and say that
| they were still struggling to get encrypted chat turned on by
| default, and that was proof that federation didn't work.
|
| But in the years since this article was written things have
| started to change. And now the interesting stuff going on with
| Matrix isn't E2EE chat, it's P2P encrypted chat, it's using
| Matrix as a drop-in securely encrypted data-transfer for web
| apps. It's all of the innovation on how metadata gets encrypted
| that Moxie claimed was going to come out of centralized
| platforms, and never did. Meanwhile, Signal is still trying
| really hard to decide whether or not usernames should exist.
|
| It seems clear to me that federation isn't the entire picture,
| because the federated apps I'm paying attention to are seeing
| more active development and iteration on user-facing privacy
| features than Signal is.
|
| Separately, I think Moxie's argument that switching costs between
| networks aren't an issue has not aged well. And I also think
| Signal itself demonstrates this point; there's a reason why
| Signal falls back to relying on one of the most insecure
| messaging protocols in existence, and there's a reason why Signal
| makes privacy concessions like tying itself to phone numbers and
| announcing to you when other contacts join Signal. It does that
| because actually switching costs are very high, and even Signal
| can't get people off of SMS unless it maintains compatibility
| with that network. Even Signal as a centralized platform hasn't
| been able to get people to switch off of literally the worst
| messaging service we have today on almost every technical level.
|
| So my main criticism of Moxie's take is that I see federated
| systems that are overcoming some of the problems he talks about,
| and I don't see Signal innovating in that space to the same
| degree (not that they're doing nothing, just that they're not
| doing nearly as much). And my secondary criticism is that I think
| he's dismissive of some of the downsides that come from
| centralization, including downsides that have hurt Signal's
| adoption rate among ordinary users.
|
| The main reason I like Signal so much is that it is highly
| audited by security professionals that I trust, that it's been
| around for a while and proven that it is secure, because it is a
| small app with less attack surface, because it's seamless on top
| of SMS, and because I think Moxie is a good, trustworthy coder
| with solid moral principles about privacy (part of why I'm
| disappointed to see him leave the company).
|
| And all of that is still true today, but since this article was
| written I haven't seen the level of supposed innovation that I
| was told was going to happen. It's the federated platforms doing
| the exciting stuff, and meanwhile Signal is good because it
| doesn't change much and it still just kind of reliably works the
| same way it always used to. It's ironically almost the opposite
| of the situation Moxie claimed was going to exist.
| tialaramex wrote:
| When I first installed Signal it didn't have Sealed Sender,
| which means that an adversary in Signal's privileged position
| knows who is sending me messages (today only I know who is
| sending me messages)
|
| I'm pretty sure it didn't have all the badges and other tat I
| don't use but which I'm sure somebody say 30 years younger
| would care about and I believe is on the popular chat apps
|
| It had secret groups back then, but they had to be kept small,
| whereas today much larger (unlimited?) group sizes are
| available thanks to changes in the protocol to facilitate that.
|
| It had secure phone calls, but I don't know if it had video
| calling and certainly not _group_ video calling as it does
| today.
|
| As I understand it (I don't buy Apple devices) they also
| delivered the seamless encrypted upgrade behaviour where you
| buy a new iPhone and transfer everything securely.
|
| I'm sure there's a bunch more.
| danShumway wrote:
| Oh of course! I didn't meant to imply that nothing at all has
| happened, Signal has seen development.
|
| It's just that the list you're bringing up is dwarfed by the
| list of improvements that have happened in protocols like
| Matrix and chat apps like Element over that same time period.
| I don't think anyone would claim that Signal right now is
| evolving faster than the rest of the messaging market -- or
| maybe I'm wrong and people want to try and make that claim?
| kitkat_new wrote:
| > When I first installed Signal it didn't have Sealed Sender,
| which means that an adversary in Signal's privileged position
| knows who is sending me messages (today only I know who is
| sending me messages)
|
| by only looking at the message...
|
| but: you authenticate yourself at the Signal service and you
| use your authentication to drop of a set of messages
|
| How do they not know who sent them (if they want to know)?
| nine_k wrote:
| Why email, DNS,.BGP, etc don't work? One can wonder!
|
| It's good when the clock strikes 13 in the very title of an
| article; saves time :-/
| jshen wrote:
| It's clear you took the time to comment, but didn't take the
| time to click the link and commented purely on the HN title
| which is different than the articles title and point.
| nine_k wrote:
| Exactly, my problem is with the title which is nonsensical in
| a bad way, and discourages from clicking. Anti-clickbait.
| jshen wrote:
| Thanks for clarifying.
| tptacek wrote:
| Hey, once again: you can't editorialize titles like this on HN.
| The title of this post --- and it's an extremely well-known post
| at this point --- is "Reflections: The Ecosystem Is Moving".
| Apreche wrote:
| What if you allowed federation, but you centralize updates?
|
| Make a protocol. Make a server for it. As the central authority
| updates the protocol, they update the official server software.
| If someone installs it, it auto updates by default. If someone
| runs an alternative server software, or doesn't update, then they
| will be broken by everyone else's updates, and that's just too
| bad for them. Keep up, or get left behind.
| hbogert wrote:
| Federation is also about autonomy, which is at least somewhat
| at odds with auto-updating.
|
| If you all are forced to use the same server software, it's not
| federation, it's just a distributed app.
| arka2147483647 wrote:
| What if a bunch of servers decide together to stay on the old
| version?
|
| What if somebody decides to clone the software, and manages to
| keep up?
|
| Who pays for the center, and keeps it running, if you have no
| access to users?
| tommiegannert wrote:
| I like that Matrix has a separate system/acceptance test that
| any implementation can run against to check compatibility:
| https://github.com/matrix-org/sytest
|
| I want any government to help the community set rules, and
| provide transparency. As opposed to encouraging or implementing
| mono/oligopolies.
|
| One way of using an acceptance test could be to centrally name
| and shame/fame the various implementations. (Like caniuse.com
| for web tech.)
| jmbwell wrote:
| He writes "don't work" but he seems to mean "aren't easy to
| monetize."
|
| The protocols "work" just fine. It's making money that seems to
| require centralization, even by his own examples. And if the
| making-money part doesn't happen, the commercialized/centralized
| service goes away. But guess what keeps running. The open
| federated protocols.
|
| I made this point in another thread. The point of openness and
| federation is not to prevent failure, but rather to facilitate
| continuity when central/commercial interests ... lose interest.
|
| Besides. Try building Signal /without/ using IPv4, or HTTP, or
| email, or git. And then maybe /thank/ federated protocols for
| making this little blog post even possible.
| mindslight wrote:
| Moxie jumped the shark when he started arguing for reliance on
| Google Play for better end-user security. He's just got a
| completely different threat model that focuses on getting users
| the first 90% by forgoing the last 10%. I personally am less
| concerned about drive by attackers (oh no, I might have to
| change my credit card number one additional time), and more
| concerned about APTs (advanced persistent threats) like Google.
| baryphonic wrote:
| > Try building Signal /without/ using IPv4, or HTTP, or email,
| or git. And then maybe /thank/ federated protocols for making
| this little blog post even possible.
|
| Extremely underrated point.
|
| The problem is more a prisoner's dilemma w/r/t monetization
| than some intrinsic problem with federation.
| [deleted]
| tptacek wrote:
| The reason you're even making this argument is that the person
| who submitted this story altered the starting conditions of the
| thread by substituting an editorialized title for the author's
| own, and in that sense you're arguing not with Moxie
| Marlinspike, but with the submitter.
| Trombone12 wrote:
| The original title was a bland thing conveying naught but the
| thin idea that the world changes. A better objection is that
| the submitted title does not accurately reflect what is
| clearly Marlinspikes thesis statement:
|
| > "I no longer believe that it is possible to build a
| competitive federated messenger at all"
|
| Personally I think the new titles stays pretty close to the
| thesis statement, but it might be a bit exaggerated as
| clearly Marlinspike doesn't mean "technically impossible" but
| rather something more like "socially unworkable".
| tablespoon wrote:
| > He writes "don't work" but he seems to mean "aren't easy to
| monetize."
|
| > The protocols "work" just fine. It's making money that seems
| to require centralization, even by his own examples.
|
| Why would you say that? I skimmed it, and he wrote very little
| about money at all, and a lot about the stagnation that
| federated protocols experience, e.g.:
|
| > I thought about it. We got to the first production version of
| IP, and have been trying for the past 20 years to switch to a
| second production version of IP with limited success. We got to
| HTTP version 1.1 in 1997, and have been stuck there until now.
| Likewise, SMTP, IRC, DNS, XMPP, are all similarly frozen in
| time circa the late 1990s. To answer his question, that's how
| far the internet got. It got to the late 90s.
|
| > That has taken us pretty far, but it's undeniable that once
| you federate your protocol, it becomes very difficult to make
| changes. And right now, at the application level, things that
| stand still don't fare very well in a world where the ecosystem
| is moving.
|
| It's true: the federated protocol that is email doesn't
| actually have encryption, even though people have been talking
| about it for decades. The need to be interoperable with lowest
| common denominator means that even Phil Zimmerman finds it too
| troublesome to receive anything that's not unencrypted. A
| platform like WhatsApp added it in like a year or two.
|
| Federation seems like it more for an end state where things are
| stable and well-understood enough that it's tolerable that the
| implementations stagnate.
| jasode wrote:
| _> but he seems to mean "aren't easy to monetize."_
|
| Signal is a non-profit entity.[1] E.g. Billionaire Brian Acton
| "donated" (aka 50-year loan at 0%) about $105 million to keep
| Signal running. If Signal has a monetizing agenda, they're
| going about it in a convoluted way.
|
| [1] https://twitter.com/chrisjbakke/status/1348319406028296192
|
| EDIT to reply: _> , and from what i've read, Signal does
| monetize._
|
| In precise terms, how exactly does Signal monetize? Every
| source I found says they're still running on donations:
| https://www.google.com/search?q=signal+technology+monetize+m...
|
| It's worth calling this out specifically so I can evaluate gp
| (jmbwell) accusations of Marlinspike's motives to write the
| essay for commercial gain rather than outline the technical
| pros/cons of federation.
| tomxor wrote:
| non-profit doesn't mean no money, and from what i've read,
| Signal does monetize.
| freeopinion wrote:
| A donation and a loan are not the same thing. Even for a 0%
| loan.
|
| This means Signal has an obligation to come up with $105
| million somehow. So, at the least, they can monetize $105
| million worth, and still be a non-profit. More likely, they
| need to monetize $2 million/year for that loan, plus however
| many $million/year to pay salaries, etc. just to break even
| and be "non-profit." When you pay a single developer
| $200K/year + $20K/year health insurance + $5K/year food, it's
| pretty easy to be a non-profit even when you are trying to be
| high-profit.
| ignoramous wrote:
| IPv4 (cloud), HTTP (cdn), and git (hosting) have all tended
| towards centralisation. Federation is but a mere impl detail.
| Hamcha wrote:
| the centralized part will eventually fail, the federated will
| live on. You could have argued that RSS got centralized with
| Google Reader, but Google Reader died and RSS feeds are still
| alive.
| hiq wrote:
| > RSS feeds are still alive
|
| You're entitled to your opinion, but I don't think you'll
| convince many people with this.
| namecast wrote:
| The subject line doesn't seem to match with the the post it links
| to - perhaps it's been updated since being shared here? The blog
| post right now is titled 'the ecosystem is moving', and in the
| first paragraph states:
|
| "Nothing about any of the protocols we've developed requires
| centralization; it's entirely possible to build a federated
| Signal Protocol-based messenger, but I no longer believe that it
| is possible to build a competitive federated messenger at all."
|
| ...which is is a far cry from "why federated protocols don't
| work". A more accurate headline summary might be "why we believe
| federated protocols are not competitive for this use case", which
| has a different ring to it.
| tedunangst wrote:
| The title hasn't changed. HN just likes to twist things around
| to get worked up about them.
| 6510 wrote:
| users and consumers are different creatures
| Naac wrote:
| @dang please change the title to `Reflections: The ecosystem is
| moving (2016)`
|
| EDIT: Not sure why I am downvoted, editing is against the site
| guidelines: https://news.ycombinator.com/newsguidelines.html
|
| This particular title also feels extremely clickbaity.
| unethical_ban wrote:
| That is far less descriptive.
| Naac wrote:
| Editorializing the title is against the guidelines:
|
| https://news.ycombinator.com/newsguidelines.html
| jlkuester7 wrote:
| Was recently reflecting on this excellent piece comparing and
| contrasting p2p/federated/centralized systems:
| https://changelog.complete.org/archives/10216-the-hidden-dra...
|
| The drawbacks for p2p and centralized systems seem to be mostly
| inherent to the technical requirements necessary for things to
| function.
|
| The downsides of federation are more practical (who/how deploys
| and maintains the servers). Good reminder that organizational
| structures like technical "communes" need more emphasis!
| jsnell wrote:
| (2016) but equally relevant today.
|
| Edit: I originally claimed there was no previous HN discussion,
| but it was on a different URL.
| detaro wrote:
| https://news.ycombinator.com/item?id=11668912
|
| also in talk form some years later:
| https://news.ycombinator.com/item?id=21904041
| [deleted]
| upofadown wrote:
| This doesn't seem all the controversial or even interesting to
| me. It is perfectly true that a standalone project is easier than
| one where you have to communicate and negotiate a specification
| with other people. The idea here was to showcase an approach to
| cryptography. The Signal project has done a good job of that. It
| is up to us to decide if we want to modify any of the existing
| systems based on those ideas.
|
| Moxie was explaining why he was doing what he was doing. I doubt
| it was ever intended as some sort of manifesto.
| AnonC wrote:
| This needs 2016 in the title. Signal can spin stories about why
| federated protocols don't work, but the simple explanation behind
| this is Signal doesn't want to do certain things. Signal's
| unwillingness to avoid doing certain things shouldn't construed
| as "hard to do" or "not worth doing" or "too much hassle". Take
| every position that Signal takes with a pinch of salt. It is,
| after all, a centralized platform that benefits from
| centralization.
| detaro wrote:
| yep. for better or worse (it is security-wise), a federated
| platform has taken over way more of my chatting than Signal
| ever reached, and Signals insistence on "we know what client
| people want" plays a large part in that.
| bogota wrote:
| I have yet to see a federated chat app my tech illiterate
| family can download and use. Sure I have set some up to test
| out but the UX is terrible on all of them. Matrix was the
| most polished but still horrible compared to signal.
|
| Everyone loves to rag on signal here it seems. They would
| rather something be correct in ideals than help the largest
| amount of people. It's a strange and holier than thou stance
| to take in my opinion.
| stormbrew wrote:
| I mean, there was a while there where XMPP-based and
| federated chat clients (particularly google chat, along
| with early facebook messenger) were becoming dominant, and
| were widely used by "normal people" without even knowing it
| was a thing.
|
| So I don't think "it's impossible to make a non-shitty
| federated client" is really a valid argument. That's not to
| dispute real problems with wide-open federation or XMPP,
| because they absolutely exist, just that "the clients are
| hard to use" seems more an artifact of the resources of the
| people making them than anything to do with technical
| merit.
| thfuran wrote:
| >So I don't think "it's impossible to make a non-shitty
| federated client" is really a valid argument.
|
| Perhaps not, but it's definitely a strawman.
| deadlyllama wrote:
| I wonder if some of what went wrong with XMPP was the big
| platforms (Facebook, Gmail) adopting it, then dropping
| it. Coupled with the rise of smartphones and the cloud.
| Previously you ran your chat app on a desktop PC and it
| stored your chat history/etc.
|
| I imagine federated chat means more opportunities for
| your users to avoid seeing ads too... Just use someone
| else's server!
| eximius wrote:
| You managed to not address any point in the article, instead
| insinuating poor motives by the author.
|
| I want federation to work. But this is a fair critique of the
| tradeoff and competition between centralized and federated
| services - and the dynamics of network switching instead of
| host switching.
| [deleted]
| notriddle wrote:
| Please make actual arguments, and not just Bulverism. After
| all, building a centralized system and an organization that can
| run it is the behavior you would expect from someone who
| sincerely thought it was a better way to make a messenger.
| Andrew_nenakhov wrote:
| They absolutely do work, as proven by email.
| notriddle wrote:
| You can use it for communication, and it remains popular by
| first-mover advantage, so I suppose it "works" technically. But
| almost everyone is on a few, huge servers that can dictate the
| standards to everyone else, it's not E2E encrypted and the few
| attempts to add E2E encryption are unusable, the anti-spam
| systems are so strict and flakey that it's a crapshoot if any
| email actually arrives in someone's inbox, and routing emails
| is based on domain names, which are a terrible way to manage
| data portability.
|
| In other words, it didn't accomplish what any pro-Federation
| activist actually wants to accomplish.
| dec0dedab0de wrote:
| A few huge services is still better than one really huge
| service
| Andrew_nenakhov wrote:
| Oh again this obsession with e2ee!! Email can be e2e
| encrypted easily if you want it.
|
| The fact is that you generally don't, because you want to
| access your mail from any device and you want a server-side
| search. All of this is made impossible by a proper e2ee.
|
| Also, proper e2ee _requires_ identity verification of your
| contacts, where you check their key fingerprints using an
| uncompromised channel. If you skip this part, all e2ee you
| use is just a security theater.
| karatinversion wrote:
| How can it be "easily" e2e? The protocol does not allow the
| sender to synchronously communicate with any host the
| receiver influences.
| dane-pgp wrote:
| Probably the best example of easy end-to-end email
| encryption (EoEE2EEE?) is Delta Chat[0] which uses
| Autocrypt[1].
|
| [0] https://delta.chat/en/
|
| [1] https://delta.chat/en/help#which-standards-are-used-
| for-end-...
| hiq wrote:
| > Email can be e2e encrypted easily if you want it.
|
| Not with the same security guarantees, the same usability,
| nor the absence of footguns that apps such as Signal
| provide.
|
| > Also, proper e2ee requires identity verification of your
| contacts, where you check their key fingerprints using an
| uncompromised channel. If you skip this part, all e2ee you
| use is just a security theater.
|
| Even if you don't check fingerprints, you're fully
| protected against passive attackers, as well as attackers
| who started being active only after the key exchange. For
| casual users, Signal is a good protection against dragnet
| surveillance. For advanced users, Signal with key
| fingerprint checks is a good protection against more
| powerful attackers that control the network.
| Andrew_nenakhov wrote:
| > For casual users, Signal is a good protection against
| dragnet surveillance.
|
| It is not a protection, just a security theater. If you
| don't trust your service provider not to spy on you, you
| must not trust it completely. Thus, Signal tells you that
| you are talking to Joe, but it can easily make it so that
| you talk to MitM who talks to Joe, for everyone, dragnet
| style. (those who do indeed verify fingerprints are
| excluded from this program)
|
| _Nobody_ but the slim nerdy minority wants to burden
| themselves with proper e2ee, yet everyone insists on
| having some snake oil too.
|
| Don't want to be spied by your service provider - run you
| own server. That's what federation is for.
| angus-prune wrote:
| I feel like I'm missing something.
|
| If they introduced blanket MitM, it would only take one
| person to verify fingerprints for it to become public.
| You mention that people who verify fingerprints would be
| excluded, but I've no idea how you'd achieve that. My
| understanding is that proper fingerprint confirmation has
| to, by definition, be conducted out of band.
|
| With any FLOSS _everyone_ is trusting that another geek
| somewhere is paying attention to a particular piece of
| software and will raise the alarm if there is something
| wrong. And I do mean everyone. I don 't think its
| conceivable that even the most paranoid, technically
| proficient user could verify the integrity of their
| entire technology stack.
| Andrew_nenakhov wrote:
| No, not really. There are actually ways to go around
| that. One person who does verify a fingerprint will get a
| real fingerprint. Or maybe they'll just show you same
| numbers as to your buddy, because they control both
| server and client software and users have very very
| limited resources to control what code is shipped to them
| via appstores.
|
| You see, this is all a question of trust. The only threat
| against which the e2ee is useful is non-trusted server
| admin. But then signal fans paradoxically don't trust
| Signal to have their unencrypted communications and
| simultaneously trust them to have means to get access to
| their messages.
|
| So in practice a personal/corporate email / xmpp server
| without any e2ee gives you a better level of security
| than using third party service like Signal with e2ww,
| because in that case the attacker will have to somehow
| gain admin access to your server to learn _anything_
| about your communications, while in Signal 's case, even
| if they don't compromise your encryption, they still have
| means to know who you are talking with, when, your IP
| addresses, etc.
|
| (and don't even let me started on that crap where Signal
| supposedly has no ability to know who is sending you a
| message - it all can be logged on server side, and we're
| not trusting the service operator, right?)
|
| Tldr: insisting on e2ee while fully trusting third party
| infrastructure is double-think at its best. If you want
| to be safe, use self-hosted servers. Which brings you to
| federation. :-D
| upofadown wrote:
| Well that means that, Signal (and other instant encrypted
| messengers) bundle the risk up into one huge footgun.
| Very few people know how to verify their identities with
| the "safety numbers" and then keep them verified. As a
| result, you end up trusting the provider not to MITM your
| messages. This is particularly trivial to do in, say,
| some sort of non-federated system where one entity
| controls the entire infrastructure. That is not
| necessarily a bad thing but it would be good if the user
| was made to understand exactly who they are trusting.
| Signal deemphasizes this sort of information these days
| and has made the warnings about changed safety numbers
| easier to ignore. This is a depressingly common
| progression.
|
| At least with encrypted email you are less likely to kid
| yourself. If you do figure it out then the existence of
| identities you treat as objects ("public keys") makes it
| intuitively obvious that you have to get the right one.
| notriddle wrote:
| > Oh again this obsession with e2ee
|
| This is a post on the Signal blog. They are obsessed with
| E2E encryption, and will never be talked down from it.
|
| Also, I presented several problems with email, not just
| poor support for encryption.
|
| > Email can be e2e encrypted easily if you want it.
|
| E2E encryption should have forward secrecy. The way that's
| usually implemented requires "handshake" messages to be
| exchanged before the payload is sent anywhere, which cannot
| be easily retrofitted onto PGP (adding it would be less
| "encrypted email" and more "an entirely different
| communication protocol, tunneled over SMTP"). The Axolotl
| ratchet that Signal uses requires the key for a
| communication channel to change over time, which is also
| pretty far away from what PGP and S/MIME currently do.
|
| > The fact is that you generally don't, because you want to
| access your mail from any device and you want a server-side
| search
|
| Signal and WhatsApp both exist and people use them, so they
| obviously aren't deal-breakers.
|
| > Also, proper e2ee requires identity verification of your
| contacts, where you check their key fingerprints using an
| uncompromised channel
|
| It requires you to verify the identity of one, initial
| contact to bootstrap your social network. From then on, the
| "uncompromised channel" can be the previous E2E encrypted
| channel you already created.
| Andrew_nenakhov wrote:
| > This is a post on the Signal blog.
|
| I'm not responding to a person who writes the Signal
| blog. I'm arguing with a silly statement 'but but email
| doesn't have e2ee'.
|
| Spam problem is big, and can be solved in other federated
| protocol like XMPP by requirement to authenticate sender
| before sending a message.
|
| > E2E encryption should have forward secrecy.
|
| That is an arbitrary requirement imposed by you just now.
| For many people it absolutely SHOULD NOT have forward
| secrecy, and a message signed by a public trusted key
| would be much better.
|
| Regarding that 'axolotl ratched', my developers have
| implemented it on at least 2 platforms, that protocol can
| absolutely be ported to email. But nobody will do it
| because in practice nobody really needs it, just some
| obsessed nerds.
|
| > Signal and WhatsApp both exist and people use them, so
| they obviously aren't deal-breakers.
|
| ... And Telegram CRUSHES them with BY FAR superior user
| experience precisely because they DON'T have e2ee for
| regular chats.
|
| > It requires you to verify the identity of one, initial
| contact to bootstrap your social network.
|
| No, _this_ is a security theater again. If you _need_
| e2ee you should not trust someone else to do a
| verification work for you. Not your contacts, not a
| Signal 's CA, nobody. Imagine you are a gangster in a
| sinister organization. All it would take to compromise
| your communications is just one mole coerced to work with
| the police.
|
| And if you aren't willing to do this work because it is
| too burdensome, you should honestly face the fact that
| nobody is interested in your communications, and that
| your insistence on e2ee does not, in fact, increase your
| privacy, but just makes you feel more safe.
| kitkat_new wrote:
| > E2E encryption should have forward secrecy.
|
| Curios, why? What scenarios does PFS protect you from
| exactly?
| hansel_der wrote:
| imo email proved that strong moderation (black-/whitelist
| oligarchy) is required in a federated messaging system because
| of spam.
| dane-pgp wrote:
| I think email only proved the need for strong moderation in
| the case where the expectation is that you can send any
| message to anyone with only knowing their address.
|
| If there were a standard for strictly formatted
| "introductions", which were the only type of message you
| could send someone unless you were in their address book (and
| had confirmed public keys out of band?), then spam probably
| wouldn't be profitable enough to exist.
| [deleted]
| phkahler wrote:
| >> but it's undeniable that once you federate your protocol, it
| becomes very difficult to make changes.
|
| He opens by talking about how everything keeps changing, the
| denigrates the stuff "stuck in the 1990s" then complains that you
| cant change a federated protocol. Not sure what he's in favor of.
| api wrote:
| He is arguing that decentralized systems are incapable of
| keeping up with the times due to inability to herd the cats.
|
| As evidence I would submit that it's 2022 and we are still
| using IPv4. A centrally managed Internet could have upgraded to
| IPv6 in one day. Send out update. Everything updates. Done.
|
| There is a genuine and IMHO very significant problem here. If
| this problem can be solved it will require a different approach
| from the ones already tried. Pretending the problem doesn't
| exist doesn't help.
| gnufx wrote:
| Someone who wasn't on JANET in the '90s, for instance?
| Plasmoid wrote:
| I like your optimism but even in centrally managed systems
| people won't upgrade.
|
| I've been harassing other employees to move away from our old
| Prometheus instance to our new one and it's been a real
| uphill battle. The only work is (1) copy over the alerts they
| want to keep to the new storage location. By copy, I mean
| literally copy. (2) Change the datasource pointer in grafana
| to the new prometheus location
| Godel_unicode wrote:
| Counterpoint, basically everyone who runs them runs up-to-
| date Chrome and iOS. This is more an argument that some
| centralized systems are poorly (or perhaps weakly?)
| managed.
|
| Could you not copy their alerts and use DNS aliases and/or
| load-balancing to migrate them?
| jerry1979 wrote:
| Moxie also talks about this dynamic in his critique of NFTs.
| The logic kinda goes like this: (Step One) People create
| Federated Services to establish fault tolerant internet
| infrastructure which more-or-less works. (Step Two) People then
| build agile Centralized Services which give users exactly what
| they want. (Step 3) People then attempt to build new, robust
| Federated Services in an attempt to copy the good features of
| the Centralized Services.
|
| The argument says that the last step of copying the Centralized
| Services is a fool's errand, and it makes more sense to build
| better Centralized Services through (Step 2 + SGX) specialized
| hardware.
|
| Time and again Moxie has decided to build the better
| Centralized Services by leveraging Intel's SGX enclaves (the
| specialized hardware). Both Signal and MobileCoin rely entirely
| on these SGX enclaves.
|
| Since I don't trust the enclaves, my hope is for Step 3.
|
| _edit_ that said, I do use signal everyday and I think
| mobilecoin is neat.
| kixiQu wrote:
| See also the response from the people who are working on the
| federated protocols:
|
| https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom
| Edman274 wrote:
| That response is basically "nothing he said is strictly
| speaking wrong, but we value freedom above everything else."
| Well, they're allowed to take that position, but I prioritize
| being able to use a free / open source messaging application
| with as many people as possible over being able to choose
| exactly which federated client I can use to talk to the two
| people I know who go to PGP key exchange parties. Sometimes I
| want to make a video call with two other people on my phone
| without using software written by Google, Apple or Facebook.
| Signal does that. I don't even know how feasible that is with
| Matrix.
| ftyers wrote:
| The Jitsi integration works ok, and isn't worse than Google.
| Others I haven't tried.
| gnufx wrote:
| Hodgson said -- I don't remember where -- something like
| "We'll make it work or die trying".
| godelski wrote:
| The "freedom" vibe was weird. I'm all for freedom and
| maximizing negative rights, but there's some compromises we
| have to make. I don't think this argument is ever going to
| work, just like it hasn't worked in politics. At the end of
| the day people do realize there are some compromises that
| make sense. It's about finding that ground where we maximize
| negative rights while still having those conveniences.
|
| I also found it strange they ignored one of the largest
| arguments that Moxie made. Federation becomes centralization.
| We've seen this happen time and time again. It makes sense by
| pareto distributions. Just the same way one city has way more
| people than most others (e.g. NYC has half the population of
| NY state). This is a natural phenomena. We saw it on the web,
| email, internet providers, telephones, cryptocurrencies,
| everything (we'll see it with web3 too). It's because if
| there isn't an explicit hierarchy there's an implicit one.
| Eventually that implicit one becomes explicit. Moxie's
| argument here isn't "federation sucks" it is "why fight the
| centralization effort? It is better to take control of it
| than let it run wild."
| fsflover wrote:
| > "why fight the centralization effort? It is better to
| take control of it than let it run wild."
|
| Would you also say this about democracy? Why not to become
| a dictator yourself and ride this wave?
| godelski wrote:
| I think you're giving my comment an unfair
| characterization. I'd appreciate it if we discussed in
| good faith with one another. If you read carefully I talk
| about trying to maximize negative rights and a balance.
| The political equivalent is saying that I like democracy
| but a pure democracy is chaos. This does not mean I'm
| remotely in favor of autocracy. There's a spectrum here
| and it isn't a dichotomy.
| dane-pgp wrote:
| And another response from another person who worked on a
| federated protocol (Daniel Gultsch, the main developer of the
| Conversations XMPP client):
|
| https://gultsch.de/objection.html
| tptacek wrote:
| It feels like the steady march of time has convincingly
| refuted this objection.
| dane-pgp wrote:
| I would say it's Marlinspike's position that has aged
| badly.
|
| Despite the supposed innovation benefits of centralised
| control, Signal _still_ requires phone numbers, and its
| main "innovation" has been adding a pump-and-dump crypto-
| coin, which users are forced to have the code for in their
| clients whether they want it or not, because he refuses to
| allow non-official clients to connect to Signal's servers.
|
| In fact he even objects to people installing the official
| client from F-Droid.[0] So it seems that in his mind,
| progress is "whatever direction I decide", and what we call
| freedom is what he would call "dangerous fracturing of my
| ecosystem".
|
| [0] https://old.reddit.com/r/fdroid/comments/q1jnbb/why_isn
| t_sig...
| hiq wrote:
| What do your points have to do with the centralized
| nature of Signal, or the drawbacks of federated networks
| pointed out by the article?
___________________________________________________________________
(page generated 2022-02-12 23:01 UTC)