Hi Stephen,
thanks for your follow-up and the discussion about ID providers.
Stephen J. Turnbull:
Note: I've changed the order of sentences from Torge's post to fit my responses.
Torge Riedel writes:
I do agree, same here on my side. Lot's of my users are very "sensitive" to social media and don't want see them here.
This is the first I've heard of this. Obviously it's fairly widespread; *please* speak up if anyone have similar issues that we haven't addressed. AFAIK all of the currently active Mailman developers believe that social auth is a GoodThang[tm], so we're unlikely to DTRT as you see it without your help.
As the Mailman3 Debian Maintainers, we decided to disable social auth in the mailman3-web Debian package alltogether.
That's because in general, we try to avoid "calling home" features in software when it's possible. Usually, these "call home" features are abused to track users behaviour. With Mailman3, it's not directly calling home. But still, adding so-called "social" authenticators to the mailman3 django application will expose users to the risk of clicking on those ID provider buttons.
I need to migrate from mailman2 to mailman3 and was wondering why social accounts are enabled by default
By default Mailman 3 is social media: you have a profile, you can be searched in the indicies of the archives, and so on. The large auth providers provide more secure authentication, and a lot of convenience for users who have such accounts already. They also take some administrative burden off the list and site managers when people lose their passwords and forget what their subscription address is, and similar scenarios. Clearly, these are not universally-valued features, but I think that they justify the current defaults.
Personally, I consider it a major privacy issue if one central instance (e.g. Facebook) is able to track on which platforms and services you authenticate.
And to be honstes, I'm a bit irritated that those tracking features from big corporates like Facebook and Google, whose main business model is to aggregate as as much private data points as possible about as much users as possible are enabled by default in Mailman3 upstream.
Besides the privacy concerns raised above, on problem with central authentication services is that they also create new single points of entry/failure. If your Facebook account gets hacked, you now loose control over all other services/platforms, that you used the Facebook authenticator service for.
and are difficult to disable.
They're easy enough to disable (easy to recognize and just add a hash character in front), since you have to edit settings_local.py to install anyway. If you're using a packaged version and the package configuration utility doesn't handle it, there's nothing we can do about it. The distro will have to deal with that.
It should be better documented, I imagine (haven't checked yet).
I propose something like an additional setting listing the enabled social accounts.
Do you mean in the Postorius administration interface? If so, do you want it by-site, by-domain, or by-list? ("You" is everybody who wants to disable social auth, not just Torge!)
I agree with Torge that those social auth providers should be disabled per default. IMHO, A sane default would be to list them in the settings.py but have them commented out.
Cheers jonas