worik writes:
People are starting to realise that you always (in the general case) are paying for a service.
Please, send me my checks!
The people I follow on Twitter (around half are infosec or natsec professionals, the great majority of the rest are open source software developers) frequently do point out or complain about this kind of "payment". But most "ordinary people" I know (generally Americans and Asians) think that on balance they're well-served by the SNSes they subscribe to and by retailers like Amazon. They *like* the sacrifice of privacy. Especially the Chinese, since the government is already collecting "social credit information" on each and every one of them., they figure they might get the benefit of personalized service.
tl;dr The choice for or against using the big bad corporation services needs to be clear and usable.
It can't get clearer than big colorful buttons that do nothing if you don't click them. (Caveat: I need to check that those buttons' labels are local images or HTTPS URLs that go directly to the auth service.)
IMO use of social auth *should* be a subscriber choice. Activists want to take that choice away by default, and impose the burden of providing it on all site administrators, possibly even all list administrators. In some cases, we might consider even providing that choice too much of a risk (canonical example: support list for DV -- domestic violence -- victims). But for most lists providing the choice should be the default IMO.
We could provide a warning that "We believe that this authentication provider sells information about what sites you log in to to third parties" or something like that. That wouldn't bother me (as long as it didn't invite anybody to sue *us*, and was configurable by site admins in case they worry about getting sued).
The ship has not sailed. We can get back what we have lost.
A huge quantity of data is already out there. Perhaps in Europe you can protect privacy in the future and even claw back PII collected in the past, but not for a decade (or several) in the US, and China and other authoritarian countries (including NATO and EU members!) are already moving fast in the *wrong* direction.
> The new generation of web developers are, in my experience, too > enamoured with the cool stuff they can do, and ignore old grey > beards (like myself) talk of "attack surfaces" and "chains of > trust"
Sure, I talk about those things frequently, too. But in this case concentrating on the privacy attack misses the fact social auth can reduce the hacking attack surface for many user-service combinations.
Same thing if you use a weak password.
Attack surfaces. "Whataboutism" is not a valid argument against the argument that you should decrease your attack surface.
Valid arguments are not "whataboutism."
The weak password -- which *Mailman* does nothing to prevent and *Mailman developers* do not know how to prevent -- *is a relevant attack surface* for an attack you are ignoring. Attacks on reused passwords are impossible for a single site to prevent. There's also the attack on the password store itself. The big auth providers seem to be relatively good (compared to random Mom and Pop services) at protecting credentials and are getting better at it.
It is not clear to me which attacks are more likely to succeed, and even less clear which ones are of concern to admins and subscribers.
But social authentication is enabled are the trackers are not loaded too.
Which trackers? I'm sure the social auth services do track which of their ids are requesting auth tokens from which services (I guess you could use TOR to obfuscate your server's address? not my pidgen). But that is all they get; stock Mailman doesn't allow any other conversation with the auth provider.
What is required is a configuration option in the interface not in the text configuration files. The former is for list administrators the latter is for site administrators. Currently list administrators do not have that choice.
That's right. In fact, domain admins don't have the choice, either. I guess we could give them the choice at the expense of code complexity.
List administrators currently *can't* have the choice, by the nature of the URL for the login interface. In theory you could have a subdomain per list, or use the query parameter to identify a list that you want to log in to. The subdomain approach is a large burden on the domain administrator, and current Mailman can't easily handle it. The query parameter would be easier to implement, but users would probably forget it or get it wrong, which would be messy.
In any case I think that would be very confusing if different lists on the same domain made the different choices, and the user subscribes to both lists. I'll think about whether the DV case is important enough to cater specially to, but I suspect that users are likely to go to the wrong login page rather often, and the additional complexity increases the attack surface slightly (at least in the subdomain approach, any MITM knows that you're logging in to a protected list, and perhaps so does the auth provider). We could also make this a subscriber choice, by allowing them to set a query parameter or cookie that identifies them or specifically requests no social auth. But that seems fragile and potentially infringes on privacy in a different way.
This stuff is hard....
Steve