Drupal CMS enables Phone Home feature (update manager) without consent

Adding related issue 🌱 [META] Proposal: Track ##: Telemetry Active regarding Drupal CMS and Telemetry in general.

Project browser and automatic updates are enabled out of the box, and at least automatic updates depends on update status. Project browser at a minimum needs to make http requests to d.o even if it doesn't rely on automatic updates (not sure about that bit). Drupal CMS doesn't really exist without project browser because otherwise you can't install recipes and other modules etc., it may end up getting integrated into the installer itself.

So I think this would probably need to be a required checkbox (e.g. you have to click it to continue through the installer), which I normally would not like, but we could include a sentence that this can be changed after install (e.g. you can uninstall those three modules).

What's the point of a required checkbox? It's not consent if you have to consent. All it's gonna do is add confusion and cognitive load.

Also, the Update module is not collecting any kind of identifying information whatsoever, as far as I know.

I would be against this change, personally, unless there's a legal requirement around it.

Also, the Update module is not collecting any kind of identifying information whatsoever, as far as I know.

https://git.drupalcode.org/project/drupal/-/blob/928a5cbd476d536530ba427...

It uses an HMAC’ed copy of the site domain coupled the site salt file.

In other words: a unique identifier that identifies an individual install. Likely equivalent to how a Customer ID is considered PII under various privacy laws.

D.O. Infra has said in the past the ID is recorded to remove duplicates call-in’s from the installed module count reporting so it is known to be recorded.

The identifier breaches some environments security policies on telemetry reporting. Calling home to get an update list can pass review. Once you include a unique ID (especially one that can be used to validate the validity of a leaked secret key) it pushes it over the limit in some security reviews.

Not uncommon in my experience for corporate installs of software to prohibit all telemetry (though by no means would I say it’s universally refused).

This is the original issue that added the checkbox #178581: beta 3 breaker: update.module: opt-in, not opt-out → . Unfortunately it does not go into details about what the WordPress FUD was.

Found it :) https://yro.slashdot.org/story/07/09/25/1632246/wordpress-23-does-not-sp...

Unfortunately it does not go into details about what the WordPress FUD was.

I can’t speak to what it was that long ago, I however note that Wordpress has been involved in more issues around their update module lately being believed to be uploading significantly private details leading to the creation of the WPEngineTracker site.

D.O. too my knowledge couldn’t leak as much details as that system did (I don’t believe we send the plaintext hostnames as part of any headers) however even a unique ID per site is sufficient to create a similar counting system.

See https://duanestorey.com/posts/down-the-rabbit-hole-a-deep-look-at-the-wo... for the recent 2024 issues with their update API.

This will likely be something those migrating from Wordpress will be more sensitive about allowing given the perceived risks.

Drupal CMS doesn't really exist without project browser because otherwise you can't install recipes and other modules etc., it may end up getting integrated into the installer itself.

I'll note that if these services are that critical for Drupal CMS, the project could possibly add a Service Decorator on the update.fetcher service. The decorator could always provide an empty value to the the site_key parameter, that should be sufficient to mitigate the 'phone home' issue allowing Drupal CMS to keep the dependencies.

Drupal CMS would still want to disclose it makes web connections either as part of its quick start guide or the installer (I've worked in several environments that an unexpected network request from a server will result in the Network Access Control killing the network port) however it would not need to receive telemetry consent since the unique identifier is removed.

Drupal CMS would need to keep an eye on core to be sure it does not add any other telemetry data which could necessitate adding a consent form.

possibly add a Service Decorator on the update.fetcher service. The decorator could always provide an empty value to the the site_key parameter,

I have not published a release yet, however there is now https://www.drupal.org/project/site_key_mutator → which will (by default) empty out the site id removing the Unique Identifier (phone home) portion of the update checker.

✨ Moving project telemetry reporting from the update module into core Active would have been the better issue however its postponed and unlikely to see resolution anytime soon.

Drupal CMS installs the https://www.drupal.org/project/automatic_updates → which enables core's updates module.

Should this issue be moved there?

Should this issue be moved there?

I don't see why it should be.

The code is available in standard drupal/core however there is a prompt to reject the tracking while Drupal CMS removed the prompt and disclosure.

Users download Drupal CMS, Drupal CMS enable the modules in its default install without user consent. It follows Drupal CMS (and the Drupal.org/Drupal Association as the collectors of the tracking data and sponsors of Drupal CMS) holds the responsibility for the feature being enabled.

Linking a few issues related to discussion of undisclosed trackers being considered a breach of trust. While these discussed contrib and were more significant in how they were implemented I would maintain Starshot is required to be held to the same , or even higher, standard.

@cmlara We can't really get rid of Update Manager, it's a hard dependency of Package Manager and therefore Automatic Updates (and Project Browser). That's a mission-critical set of modules.

If you're willing to roll a stable release of https://www.drupal.org/project/site_key_mutator → , could we not just include that with Drupal CMS (maybe as part of the basic privacy recipe)? Would that mitigate the concerns here until core can fix the problem more fully?

As another option: what about a post-install message that discloses the necessary information, and offers a link to opt out?

That sounds similar to the required checkbox in #3, personally I think something along those lines ought to be enough. The actual data sent to d.o is not really the problem here except for extreme use-cases, it's very minimal, it's the lack of disclosure.

Wouldn't 📌 Use the packagist endpoint instead of update XML to determine which updates are supported/installable Postponed remove the strict update status dependency from package manager?

The code is available in standard drupal/core however there is a prompt to reject the tracking while Drupal CMS removed the prompt and disclosure.

Could you point out where this prompt is and how Drupal CMS is removing it? That may help with some options to solve this.

#15: https://git.drupalcode.org/project/drupal_cms/-/blob/1.x/project_templat...

/**
 * Implements hook_form_alter() for install_configure_form.
 */
function drupal_cms_installer_form_install_configure_form_alter(array &$form): void {
  // We always install Automatic Updates, so we don't need to expose the update
  // notification settings.
  $form['update_notifications']['#access'] = FALSE;
}

The prompt is part of core's installer: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...

Drupal CMS suppresses it entirely with a form_alter hook: https://git.drupalcode.org/project/drupal_cms/-/blob/1.x/project_templat...

We suppress it because, as has been pointed out, we always enable Automatic Updates and Project Browser, which have a dependency on Package Manager, which in turns depends on Update Manager.

We could surely adjust it so that we don't expose the checkbox -- which would have no effect anyway -- but we do keep the disclosure, or some re-worded version of it. Not sure that it would suffice, though, since the truth is that there's no real way to opt-out unless you also are willing to remove Automatic Updates along with Project Browser's "install from the UI" functionality.

since the truth is that there's no real way to opt-out unless you also are willing to remove Automatic Updates along with Project Browser's "install from the UI" functionality.

This is true but it gives you the option of not continuing with the install in the first place if it was an actual dealbreaker,, and a hint that it's possible to uninstall things later.

We could surely adjust it so that we don't expose the checkbox -- which would have no effect anyway -- but we do keep the disclosure, or some re-worded version of it.

I like this idea. It provides the message and the user can stop the installation if they don't agree. And we don't have to rely on another package or core to make any changes.

This is true but it gives you the option of not continuing with the install in the first place if it was an actual dealbreaker,, and a hint that it's possible to uninstall things later.

This seems like it could be the best method, if the owner does not consent throw an error that advises them it is required.

The checkbox could be removed making it a non-option, however does that actually fill the role of consent? (the user will be warned, however if they were not compelled to agree did they actually knowingly consent?)

If you're willing to roll a stable release of https://www.drupal.org/project/site_key_mutator → , could we not just include that with Drupal CMS

I can do this if it ends up being the route that is needed/useful.