← Back to context

Comment by anon7000

2 days ago

I mean, yeah, tracking prevention features basically completely break cross-domain authentication. There are a surprising number of valid use cases that need cross-domain auth (or make the user experience a lot easier). While there are workarounds these days, sometimes it does require deep changes in how auth works

> There are a surprising number of valid use cases that need cross-domain auth

I am not a web developer, but I would disagree with that.

Either web standards respect privacy or they don't, but I would not sacrifice privacy for anything.

Firefox was right to prevent tracking, it highlights how webstandards are just not good. I something doesn't work properly in a firefox private window, to me it should not exist.

  • Authentication requires the opposite of privacy. If you don't want to be identified, you can't restrict anything to your identity.

    • If I'm authenticating with server A. I shouldn't have to carry ephemera from server B. A can interact with B on its own if necessary.

      Bubbling up these architectural details to the front end is a symptom of the webdev cargo cult coming up with broken ideas that get fossilized as the status quo.

      1 reply →

  • The status quo appears to involve handing over your account password to your chosen client. That's worse than this.

    • If you don't trust your matrix client, why use it at all?

      It's also a bit disheartening to see Matrix putting all that "Log in with Google", Apple, Facebook etc so prominently on their login page. The whole idea of decentralised services was getting out of those walled gardens.

      1 reply →

    • But you already trust your client with all the private keys and message plaintexts for your account.

      I struggle to see why I should trust it with those things but not the account password.

      2 replies →