#privacy

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.

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.

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.

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.

#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 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.

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?

@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?

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.

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

Should this issue be moved there?