I'll do a top post to sum things a bit up (from my point of view and requirements):
- no need to disable social logins by default, there are and will be setups where this is required and wanted, but: - allow disable of social logins either by config file or admin web UI in a stable way, means: after update of mailman nothing gets broken if default configuration has changed - there is a way to do this now via settings_local.py, but feels a little bit risky if default configuration changes on update of mailman
Maybe there is a possibility for a simple approach via config file:
EXTRA_LOGINS = no
or
ENABLED_EXTRA_LOGINS = []
(maybe not valid py code, but just to show how it might look like)
Best regards Torge
Am 14.02.19 um 03:42 schrieb Stephen J. Turnbull:
Jonas Meurer writes:
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 can see this point for Debian users. I suspect Ubuntu users are somewhat less paranoid. :-)
Since that risk holds even for sites that enable explicitly (assuming we adopt the same policy) I will take a look at making that risk hard to realize (more distance from anything else clickable, smaller buttons with visible and accurate boundaries.
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.
Sure, but that ship has pretty well sailed AFAICT. Most users use unconfigured versions of IE (or Edge) and Safari, which means they're subject to all manner of webbugs. My employer just asked me to stop using Firefox because it's too pedantic for their website development vendors. :-( GDPR enforcement seems to primarily be an arm of the EU trade offensive against large American services (that's the Economist's recent opinion, not mine), while Europe-based globals are undoubtedly doing the same crap.
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.
Your irritation is not our problem, though, since you can use Debian's version, and as I mentioned earlier, as far as I know most of our sites are happy to have social auth. I will be paying attention to the list to see what others think.
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.
Same thing if you use a weak password. Effective and secure authentication is not something we're good at, and we can't really afford the effort to be good at it. These things are tradeoffs, and the default should be something that most of our users (ie, site and list admins, NOT subscribers) want. Hopefully their preferences in this respect reflect those of *their* users (== subscribers).
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.
"Those" social auth providers? Are there social auth providers who provide what you consider acceptable privacy guarantees (a la Duck-Duck-Go in search engines)? If so, we could make those higher in the list/easier to use.
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/