Move project telemetry reporting from the update module into core

This sounds like a good idea. More accurate usage data is a good thing.

Decide if it should be opt-in or opt-out.

My default position is opt-in, but we should definitely encourage sites to opt-in, highlighting the benefits of doing so, linking to a privacy statement, etc.

Having said that, I personally wouldn't object to an opt-out strategy, as long as it was very clear to users that they can opt-out and the implications of staying "in" are clearly communicated.

At the end of the day I think it comes down to how we communicate it and where we choose to place the option.

Indeed, there's no explicit telemetry as part of update.module. d.o "just" notices that a site has requested available update data for a specific project, which is how we "know" that project is in use.

I'd be in favor of changing this, but it's not really a feature request for update.module and more a "build a whole new telemetry feature". Moving to base system for now, since there's not yet a better component for this request.

Opining from the other side of this:

I don't enable the update module because of the telemetry reporting. This also prohibits project browser from being deployed.

If the update module only requested a list of modules I would be more likely to allow it to be enabled.

Polar opposite reason as to the original request, however equally tied to the same problem, mixing two different functionalities into the same code.

Re opt-in/opt-out: I'm very much a fan of 'opt-in', we need to have consent for the data collection, opt-out does not give that consent.

There is various configuration in update.module like which server to contact, how frequently etc. that would need to move to system.module if this was in core, which is the opposite of what we've been trying to do for years of moving things out of core/system into dedicated modules (path aliases, page cache etc.). So -1 to baking it in.

We could have a 'telemetry' module that does the phone home, this would require removing the config from update.module and into the telemetry module (and adding a dependency), or duplicating the URL config (which could be confusing/go wrong). And the telemetry module wouldn't do anything except phone home so there is not really any reason to enable it. And a reasonable amount of work to move things around.

On the other hand, we've got #3319030: Drupal Core Roadmap for Package Manager and Update Manager and #3316151: Roadmap to experimental Project Browser in Drupal Core - those two modules depend on update module, and at some point might completely replace the UI of the existing update module.

If we have 'update manager' and 'project browser' as two new modules, and 'update module' retains the phone home functionality but no longer provides the update status report UI and notification e-mails, then that could end up holding all the phone home code, that the other modules depend on, but without an extra step of moving things around compared to what will happen anyway.

Locale also depends on update module (because it depends on the project listing API).

So I think we should postpone this on update manager/automatic updates + project browser in core, and the UX consolidation that needs to happen around that, and see if we end up with an update API module by default, called update.module, which already exists. And then we can look at providing an option in update.module to send requests weekly even if the other modules aren't installed and that would allow sites to opt-in to telemetry if they want.

Marking postponed and adding those two issues as related.

Note: thanks to #3491731: [META] Remove the ability to update modules and themes via authorize.php and #3417136: Remove adding an extension via a URL we're back to update.module only being "Update Status", providing the "Available updates" report at admin/reports/updates, email notifications, and the telemetry aspect (basically as a side effect of querying for new available releases).