On Sun, Feb 10, 2019 at 01:57:53PM -0000, brian@emwd.com wrote:

"In your settings_local.py copy the whole INSTALLED_APPS section from default settings and add/remove the auth providers you want/don't want. Notice the allauth.socialaccount.providers.<provider> in the list below."

Worked for me. Thanks!

On Sun, Feb 10, 2019, at 6:54 PM, Nick Wynja wrote:

On 02/10/19 at 08:57, brian@emwd.com <brian@emwd.com> wrote:

...

"In your settings_local.py copy the whole INSTALLED_APPS section from default settings and add/remove the auth providers you want/don't want. Notice the allauth.socialaccount.providers.<provider> in the list below."

Another option, which seems more future-proof, is to strictly remove the account providers you don't want from INSTALLED_APPS rather than defining INSTALLED_APPS locally.

First, you have to access INSTALLED_APPS by importing settings into settings_local.py:

from settings import *

Then, you can set INSTALLED_APPS to everything it already is minus the social providers:

INSTALLED_APPS = [a for a in INSTALLED_APPS if not 
a.startswith('allauth.socialaccount.providers') and not 
a.startswith('django_mailman3.lib.auth.fedora')]

This way if Postorius ever adds any apps you won't need to update your local settings. Anyone see any downsides to doing it this way?

Please don't do that, it will create a circular import since settings_local.py is imported by settings.

Postorius (actually, allauth) adding more providers won't affect the INSTALLED_APPS list, which is a static setting defined in the container images. Unless the image changes that list, it won't affect you.

Having the list customized is actually good for you, since there is some extra configuration required for adding a new provider, so you don't want something to just show up without you knowing.

-- thanks, Abhilash Raj (maxking)

Abhilash wrote:

Having the list customized is actually good for you, since there is some extra configuration required for adding a new provider, so you don't want something to just show up without you knowing.

Stephen wrote:

But the general rule for Internet-facing applications is "shut off all access by default, and explicitly open up only the channels you need." I'm not saying your "subtract the social authentication applications" has a downside in all cases. Just that some of us prefer to expend the effort to (a) follow that general rule, and (b) advise others of its existence :-).

Thanks, this is helpful. I'll stick with the configuration as Abhilash suggested.

Hi,

same thing here. A lot of usergroups "accept" social media but in regards to data privacy like to avoid it. Although technical not true people might believe that Facebook & Co have access to the data in a local mailman install.

I would like to disable it to but havent yet the time to dive into it.

+1 for site wide disabling

Regards

Hagen

On 12.02.19 17:11, Stephen J. Turnbull wrote:

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.

...

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.

...

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!)

If you mean in settings_local.py, I suggested something similar earlier. It's not obvious it would be easy to do (sometimes these things are order-dependent, though that's bad practice).

...

And if the admin is setting this to an empty value in the settings_local.py everything is disabled

Because the settings are a Python module, this is the way settings_local.py works anyway. That's why Mark suggested editing INSTALLED_APPS.

---

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/

I am one who uses Mailman to support a closed community.  Social logins are NOT a good thing there.  Besides encouraging spam signups (social media accounts are easy to get - just ask the spammers), they tie your site to the privacy and other policies of the providers.  This includes that when they authenticate, they also track users and sites. Monetizing the data.  Many people find this objectionable.  And not auditable.

When I tried to use MM3, turning off social logins was one of the first things I tried to configure.  It wasn't easy.  First I commented out too much, then too little. The resulting errors were opaque.

I hope things have improved - at present I keep an eye on MM3, but it's not usable for me at this time.  So I may be somewhat behind the times.

The admin interface could use an authentication control panel - per site, and per-list. Click to enable/disable the social (password, 2-factor, and other plugin) providers.

On the whole, MM3 is far to painful to set up - editing hierarchies of config files assumes a technical person runs the list.  Frequently, people who want lists aren't. [X} login with Google [x] login with passwords [x] login with GitHub is comprehensible - the implications may not be, but better to explain policies than how to edit a config file written in a foreign language.

There's a big difference between "installing" (that can assume some technical knowledge) and "configuring" (that should not).  The former has to do with where you put files, how updates and time-driven events are enabled.  The latter is how one expresses one's site policies/preferences.

Package managers and MaxKing's containers are "good enough" for installing. "configuring" by config files and extensive wiki searches is not.

The persistent echos of issues I raised and appear on the list from others are in the same vein.  Cut and paste is not scalable for bulk subscribing thousands of users.  Neither is API performance.  Or "resent confirmation codes".  or...

I recognize that replacing a mature technology is hard.  MM3 has a lot of potential. It's just not there, for me, yet.

On 12-Feb-19 11:11, Stephen J. Turnbull wrote:

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.

...

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.

...

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!)

If you mean in settings_local.py, I suggested something similar earlier. It's not obvious it would be easy to do (sometimes these things are order-dependent, though that's bad practice).

...

And if the admin is setting this to an empty value in the settings_local.py everything is disabled

Because the settings are a Python module, this is the way settings_local.py works anyway. That's why Mark suggested editing INSTALLED_APPS.

---

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/

-- This communication may not represent my employer's views, if any, on the matters discussed.

This has been a wise decision ! For those adventurous people who still propagate social media, it would be good to mention how to reenable social media in the Readme.Debian

Am 12.02.2019 um 20:44 schrieb Jonas Meurer <jonas@freesources.org>:

As the Mailman3 Debian Maintainers, we decided to disable social auth in the mailman3-web Debian package alltogether.

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/

On 2/14/19 11:10 PM, Stephen J. Turnbull wrote:

Torge Riedel writes:

...

 - 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

This should not be true. If it is, we need to fix that. Will check.

It is more or less true. The issue is that unlike mm_cfg.py and Defaults.py in Mailman 2.1, the recommended way to set up Django in Mailman 3 is to point Django at settings.py for the default config, and the last thing in settings.py is

try: from settings_local import * except ImportError: pass

Thus,the only way settings_local.py can change something like INSTALLED_APPS is to redefine INSTALLED_APPS in it's entirety which leads to the possibility of INSTALLED_APPS changing in settings.py and those changes not being picked up in settings_local.py.

The way around this is to remove the import of settings_local from settings.py and then put

from settings import *

at the beginning of settings_local.py and then point Django at settings_local rather than settings.

Then you can do things like

try: INSTALLED_APPS.remove('allauth.socialaccount.providers.google') except ValueError: pass

in settings_local.py except there are still issues because, e.g., INSTALLED_APPS is defined as a tuple (immutable) and not a list in settings.py.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Am 16.02.19 um 13:50 schrieb Stephen J. Turnbull:

Mark Sapiro writes:

...

On 2/14/19 11:10 PM, Stephen J. Turnbull wrote:

...

Torge Riedel writes:

...

 - 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

This should not be true. If it is, we need to fix that. Will check.

It is more or less true [...] the only way settings_local.py can change something like INSTALLED_APPS is to redefine INSTALLED_APPS in it's entirety which leads to the possibility of INSTALLED_APPS changing in settings.py and those changes not being picked up in settings_local.py.

That's a different issue from the one I believe Torge is worried about, which is an update overwriting settings_local.py. But it's not good.

Well, Mark got it what I was meaning. Maybe my explanation was not precise enough.

Hopefully an update is not overwriting settings_local.py in any case. Is it part of delivery and then changed afterwards? Haven't checked that yet.

I personally like the way other services are importing custom settings by including all config files from a given directory. Maybe it is not worth for mailman cause custom settings will not grow very big - so no need to split it in tiny files.

...

The way around this is to remove the import of settings_local from settings.py and then put

from settings import *

at the beginning of settings_local.py and then point Django at settings_local rather than settings.

I don't understand the ramifications of making this change (presumably Barry or somebody had a reason for the change from Mailman 2's method), but at first glance it looks like a big step in the right direction.

...

Then you can do things like

try: INSTALLED_APPS.remove('allauth.socialaccount.providers.google') except ValueError: pass

in settings_local.py except there are still issues because, e.g., INSTALLED_APPS is defined as a tuple (immutable) and not a list in settings.py.

Given the concerns of privacy advocates, I would say that it would be better to have a separate

 AUTH_PROVIDERS = ['allauth.socialaccount.providers.google', ...]

in settings_local.py, and merge that in to INSTALLED_APPS. Of course removing specific providers would be OK too, but I think that this is a place where "deny all / accept what you want" is appropriate.

Steve

This is kind of a top-post, because I am not sure which message should my reply quote. Please excuse that part.

My thinking on this topic resonates with what Steve said, I don't think we should be forcing the Mailman Administrators to handle username passwords. Dare I say that most social auth providers have more incentive and money to keep their database secure than Mailman Administrators.

Having said that, it doesn't have to be either or between "social logins enabled by default" and "I don't want to see a Facebook button". I have actually thought about this before, but never have been able to get to it. I opened an issue too but can't find it right now.

Anyway, so the idea is that most social providers need some soft of configuration from the Admin. Today, we enable them by default, but they don't work by default. I think we could make both sides happy if we were to just not show the social providers that aren't configured. What do others think?

Only two providers that I know of in Mailman's default list, which don't need any configuration, are Fedora and OpenID. I am happy to remove OpenID from default since I have never been able to actually get that to work. I am okay with removing Fedora too, which is a special case in Mailman 3 because of fedoralists.org being the first customer for Mailman 3 and Hyperkitty.

I don't have cycles to do that myself right now, so I would encourage people to step up to tackle this. I would obviously help them out with any Python, Mailman or Django related questions they might have.

Now, about the ease of being able to disable social logins, I think it should be possible to disable social logins with just a boolean flag in settings. Why haven't we done it yet? We didn't need to. What we provided was a **sample configuration**, with a huge emphasis on sample. We weren't maintaining it as an official set of configurations, but just something that one could use as a starting point. But that obviously didn't happen since people just downloaded and used it, some of which is ofc my own fault since the official docs doesn't say that what precisely you should be worried about changing from the sample.

The beauty (and ugliness) of Django's settings.py is that it is Python. We can disable social login if your CPU heats up1, or if the stock price of the company goes below (or above? :P) a threshold, or heck, if the network firewall detects a packet heading out to their servers.

How Django's configuration works has been left kind-of open by the Django devs themselves, making every downstream project handle their own use case separately. We chose to just go with what was provided out of box, but that doesn't mean we can't do any better. We can do ini-style configs, it gets a tad bit complicated when there are unknown Python data structures that can't easily be represented in ini-style. We could do YAML, which supports more complicated data structures (nested maps and lists). OR, we could do JSON, but I find that less human readable.

Next topic, people worrying about customizing settings in settings_local.py and worrying about not getting newer updates. Isn't this how rest of the packaging and configuration world works? If you customize the /etc/postfix/main.cf you don't get the updates to default config (apt asks you, but you will choose not to update with your custom settings, right?) when you upgrade your postfix package from Debian and you need to pull in any new settings that package supports manually.

I have been (silently) working2 on making the mailman_suite project a Python package (mailman3-web), like the Debian Maintainers did. That would be the right place to put whatever configuration logic we want to expose to our users. We can move to a model where you'd import all the settings from mailman3_web.settings.base and then customize all the fields that you do care about. But there will be downsides to it, like us updating a setting that changes the behavior of an already working site, and we can sure document those changes in release notes in big bold letters, but I still worry there will be people running pip install -U without thinking what does that even mean.

I don't know what should we do? What do other people managing configurations do? Maybe Debian Maintainers can chime in here?

On Fri, Feb 15, 2019, at 8:43 AM, Mark Sapiro wrote:

On 2/14/19 11:10 PM, Stephen J. Turnbull wrote:

...

Torge Riedel writes:

...

 - 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

This should not be true. If it is, we need to fix that. Will check.

It is more or less true. The issue is that unlike mm_cfg.py and Defaults.py in Mailman 2.1, the recommended way to set up Django in Mailman 3 is to point Django at settings.py for the default config, and the last thing in settings.py is

try: from settings_local import * except ImportError: pass

Thus,the only way settings_local.py can change something like INSTALLED_APPS is to redefine INSTALLED_APPS in it's entirety which leads to the possibility of INSTALLED_APPS changing in settings.py and those changes not being picked up in settings_local.py.

The way around this is to remove the import of settings_local from settings.py and then put

from settings import *

at the beginning of settings_local.py and then point Django at settings_local rather than settings.

Then you can do things like

try: INSTALLED_APPS.remove('allauth.socialaccount.providers.google') except ValueError: pass

in settings_local.py except there are still issues because, e.g., INSTALLED_APPS is defined as a tuple (immutable) and not a list in settings.py.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

---

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/

-- thanks, Abhilash Raj (maxking)

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

Jonas Meurer writes:

But in my eyes, software developers, package maintainers and system administrators all should do their best to protect their users from privacy and/or security threats.

Me too. Passwords are a well-known vulnerability, providing a large attack surface. I'd rather not burden Mailman providers with protecting their users' credentials, other things being equal. They're not, so we have to decide (individually and as a project) which vulnerabilities are more frightening, and how much configurability to provide, and how.

Probably we have a different opinion on whether providing usage of authentication providers which earn their money by collecting users' data exposes users to privacy threats.

We do not. We differ on the importance of those vulnerabilities to the users.

I have a different opinion on this. You're correct that most users know next to nothing about protecting themselves against all kinds of threats on the internet. But to me this shows even more, that we as those who build the tools have a responsibility to protect our users against shooting themselves in their foot.

See my reply to Worik on this.

But that doesn't mean that we as independent and free software developers have to agree on the dangerous interfaces and standards those corporates develop (for their business!).

Sure. This is a valuable service which for most users reveals very little information: the domain and IP that the user wants to authenticate to. If I were the type to visit porn or RWNJ sites, I wouldn't use GMail as my auth provider, and I'd probably use Tor as my ISP. I have no problem with using Gmail as my auth provider to Google Summer of Code (!) and Github.

Why do you think it's a problem to allow users to make the choice? As I mentioned to Worik, I wouldn't mind allowing customization of the interface, with a warning displayed about social auth. I do not see any argument for preventing them from making the choice.

My irritation was mainly about what I wrote above: that the privacy concerns against authentication providers from big corporates seem to be of low priority when deciding about defaults in Mailman3 upstream.

Then you misunderstand. We explicitly made the decision to emphasize social auth *in part* because *as authentication* is far more secure than (1) passwords and (2) most mom and pop sites. I'll grant that the "coolness" and user demand factors matter, too. And the privacy implications generally seem minor with a few exceptions (see the mentions of "DV" in my message to Worik).

To be honest, I've never evaluated the privacy implications of OpenID. From a first glance, it looks *way* better.

AFAICS (first glance in several years), OpenID is no better: the on- the-wire information is provided in basically the same way, and it looks like the content is arbitrary. The FAPI (financial information) and HEART (health information) protocols look especially tasty to big data users/privacy invaders The question is what do the providers provide (account identifier, real name, address, gender orientation, where you buy your illegal drugs ...) and what the client asks for (Mailman asks if user credentials are valid).

But for sure, Github, Google, Facebook, Stackexchange and Twitter all rely on collecting users data for their business model. So it's probably not a good idea to share with them the information which platforms and services you authenticate against, *if* you care about privacy.

I'm far more worried about the video cameras that are everywhere nowadays, hacks of government databases, people who record "private" conversations in person and otherwise, and which of my passwords are going to show up on haveibeenpwned.com next week.

Steve