Drupal.org currently only learns about sites in the wild through Update Status requests: a pseudonymous site_key (an HMAC of the base URL keyed by the site's private key), the list of installed projects, and their versions. That is enough to count projects and not much else, and it can't distinguish between production and pre-production environments either.
#2940737: Add more telemetry to Drupal core has been collecting eight years of ideas for broader telemetry. At DrupalCon Rotterdam 2026 the maintainers asked for the smallest concrete step instead (see comment #56 there): let site owners choose to share their site's domain name and, separately, the site email address, with nothing else added.
This issue proposes an implementation for that incremental step.
localhost, *.ddev.site, *.test, bare IP addresses), which today inflate and blur usage statistics. site_key, which changes whenever the base URL or private key changes..gov, .edu, .ac.uk, country codes) without crawling.(The above two lists may not yet be comprehensive, but are directionally accurate to our intent).
Add two nullable boolean settings to update.settings: data_sharing.domain and data_sharing.site_mail. NULL means the site owner has not yet chosen.
This notice-period behavior would be a new pattern in core - so it probably deserves framework manager attention.
The checkbox defaults and the notice period length are constants in \Drupal\update\DataSharing. Changing the domain choice from opt-out to opt-in is a one-line change; with opt-in defaults the end of the notice period changes nothing.
The choice is presented in two places:
NULL state. They are given a message that the default settings will take effect in 30 days, or on save.Values are sent only to the default Drupal.org update endpoint, never to a server configured through update.settings:fetch.url or an extension's project status url.
| Option | Core side | Drupal.org side | Trade-offs |
|---|---|---|---|
A1. Append domain and site_mail to the existing release-history/drupal/current request |
Extra parameters for the drupal project only |
Extend existing log parsing | No new requests. Mixes non-pseudonymous data into the request stream already parsed; the email lands in CDN and web logs as a query string. |
A2. One extra GET per refresh to a synthetic endpoint, as recipe-applied does in #3489066: Add tracking for when recipes from Drupal.org are applied |
One new fetcher method and call site | Static CDN response plus log analysis | Keeps release-history semantics untouched; one request per cycle; the email is still a query string in logs. |
| B. One POST with a JSON body to a receiving service | Same call site, different method body | A real service with storage, retention and access controls | Keeps the email out of access logs; the service must exist before end-to-end testing. |
The MR implements option A2 as the proposal to review; A1 and B remain alternatives.
SiteConfigureForm.drush cron without --uri (same source as site_key; a known limitation, not a new one).https://updates.drupal.org/site-data, a synthetic 2xx response at the CDN as for recipe-applied) and exempt the path from the bot challenge, before this is committed. The endpoint returns 404 today.New fieldset on the installer's "Configure site" screen, shown only when "Check for updates automatically" is checked. New fieldset on /admin/reports/updates/settings. New status report entry and admin page message while the choice is undecided. Updated wording for the existing "anonymous information" text in the installer and in the Update Status help.
Possibly one new method on \Drupal\update\UpdateFetcherInterface; see the MR. No other API changes.
update.settings gains data_sharing.domain and data_sharing.site_mail, nullable booleans. Both are NULL on existing sites after update and on non-interactive installs. A post-update hook adds the keys.
State key update.data_sharing_notice_start holds the notice period start.
Site owners can now choose whether their site shares its domain name and site email address with Drupal.org and the Drupal Association. Existing sites are asked to review the choice after updating; nothing is shared during a 30-day notice period, after which the recommended settings (share the domain, do not share the email address) apply until a choice is saved.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | update-status-settings-showing-data-sharing-settings.png | 328.47 KB | hestenet |
| #9 | warning-message-to-save-data-sharing-settings.png | 387.64 KB | hestenet |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
hestenetComment #3
hestenetRestating my answers to #2940737: Add more telemetry to Drupal core comments #57 to #65 here and in the issue summary.
What the Drupal Association would do with the data:
localhost,*.ddev.site,*.test, bare IP addresses), which today inflate and blur usage statistics.site_key, which changes whenever the base URL or private key changes..gov,.edu,.ac.uk, country codes) without crawling.What the Drupal Association would NOT do with the data:
(The above two lists may not yet be comprehensive, but are directionally accurate to our intent).
Comment #4
hestenetComment #6
hestenetComment #7
hestenetComment #8
hestenetComment #9
hestenetSome screenshots of what this looks like:
Comment #10
hestenetComment #11
catchNot as a framework manager, just my personal opinion as a long term Drupal contributor: I disagree with opting existing sites into sharing their domain names via a notice period. This is very, very different from a checkbox being checked by default when you install a new site or whatever, and I would imagine many, many people would get annoyed.
As a framework manager: I can't find the issue, but we have one somewhere for 'choose your own adventure' updates - e..g the ability to prompt a site owner during the hook_update_N()/post update whether they want to apply a change or not. With that, it would be possible to add a confirmation step where the site owner makes an explicit (reversible) choice to opt in or out when they update their site. If the config can be true/false/null then that could be added after adding a UI for it - would only need to show the option for sites where it's null.
Comment #12
hestenetIf that's a pattern that exists out there, I'd be very happy to try implementing that instead of the notice period version. Was just wracking my brain for how to handle the existing site use case.
Comment #13
catchCouldn't find an actual issue for what I was talking about, only previous discussions, so opened one: #3633308: Interactive updates.
Comment #14
hestenetCreated an issue for the Drupal.org infrastructure side of the implementation: https://git.drupalcode.org/project/infrastructure/-/work_items/3606961
Comment #15
hestenetComment #16
dwwTrying to be civil. 😅 There's a lot not to like here for me personally:
Re point 1: I'm okay with a status report warning that your value for the new knobs is still NULL and you should go to the settings page to confirm your choice. But NULL should be treated as FALSE, and we should never send anything new until someone explicitly sets the knob to TRUE. Not even after 30 days.
I confess to have only skimmed the summary (wasn't clear if it was slop I'd have to parse or not) and haven't looked at the code at all. But as a subsystem maintainer, I wanted to try to weigh in early on the direction around consent.
Thanks,
-Derek
Comment #17
catchYep this is what I was getting at with #11. Or some kind of explicit opt in/out/later as part of an interactive update. But nothing that leads to it being on due to inaction.
Comment #18
dwwRe: #11 and #17: Yup, that all sounds good. Glad we're in agreement on this much. 😅