Document the communication to 3rd party sites

I also raised #3415209: Data protection in Drupal.org modules →

Drupal.org has received that data for many years. You can see how it is used in the statistic data on module usage section on project pages.

You can opt not to send the data by disabling the update module. But I’d prefer if you didn’t - good quality data on usage improves the quality of contribution.

For the announcements feed, if that is not something you want, disable the announcements module. The feed will go away.

The announcements module is only enabled by default on newly installed sites, not upgrades.

As it happens, the inclusion of the announcements module as a default in new sites was announced in https://www.drupal.org/blog/drupal-10-2-0 → — always a good reason to follow the feed!

I also believe that it should have been set to disabled as the default configuration. Meanwhile, you can add the following to the settings.php file:

# Disable Commerce Inbox
$settings['commerce_dashboard_show_toolbar_link'] = FALSE;
$settings['commerce_dashboard_fetch_inbox_messages'] = FALSE;

@rachel_norfolk Thanks for the reply. From reading #3 I believe there must be significant confusion. I am not referring to the Core upgrade module, the Core announcements module or the Drupal blog.

This is all about a feature on the Commerce Core contrib module, which is of course hosted on Drupal.org. I raised #3415209: Data protection in Drupal.org modules → to initiate a discussion from the Drupal.org management on the policy for what is acceptable for contrib modules.

Ah! My apologies.

I also believe that it should have been set to disabled as the default configuration.

Thanks. I have searched the codebase for the settings that you refer to, and the only reference I can find is like this

Settings::get('commerce_dashboard_fetch_inbox_messages', TRUE)

So it apparently defaults to TRUE. You are right, I can disable it using settings.php. Unfortunately this setting is not apparently widely advertised and requires developer-level knowledge to search the code base then alter the PHP file.

After reading the code in more detail I added a security concern.

Hey Adam, sorry for the lack of formal documentation on the settings. We shared about them in other forums (e.g., Slack and post comment threads) but should've added them to the release notes. They're there now. (I also wanted to put them in the official project docs, but we're in the middle of a migration to ReadTheDocs.io, complicating things there.) That said, I disagree that this is a data protection issue or security concern.

Re: data protection, there are any number of calls to 3rd party websites in an eCommerce application. Fetching a cached content feed from a server controlled by a project maintainer (that is not logging IPs) is as benign as it gets. We could move this to drupalcommerce.org, which we also control, I suppose. But the utility of communicating news about the project that isn't dependent on a module update / installation remains as evidenced by the update lag → amongst Commerce users (i.e., only 50% of sites are on one of the 2 most recent versions).

For folks that have concerns, we made sure to include the setting with the release, and we've even made use of the alter hook on our own client sites. (Note: the inbox remains even if the ability to fetch messages from the project feed is disabled, because we anticipate Commerce Core and contributed modules using the inbox to communicate project updates or configuration steps on installation.)

Re: security concerns, if fetching content from a remote feed violates a security policy, it should be disabled. To be clear, though, this is a glorified RSS feed, only formatted as JSON to be able to structure the content vs. sending a title and body. If the concern is a compromise in our server, what would alleviate that concern for you?

All that said, the support block on the dashboard does advertise the fact that there is a company maintaining Drupal Commerce that is happy to support end users should they need it. This is already apparent in all of our project messaging on d.o and our own websites, and yet we still regularly encounter end users through our outbound activity who are prepared to leave Drupal Commerce because they don't know where to turn to for support. This shouldn't be - it's bad for the platform, and it's bad for us as a company.

There's no harm at all in folks building stores with Drupal Commerce altering the support block out of the dashboard, but our goal is to ensure those who don't have developers / agencies know what their options are. At the end of the day, as a company, we do actually need paying customers to stay in business, and I'd rather find those opportunities before being called to help someone migrate away to another platform.

Thanks @rszrama.

Apologies, I should have a better job of raising the issue. I was frustrated with the surprising appearance of this communication on a live customer site without any obvious way to remove it.

Re: data protection, there are any number of calls to 3rd party websites in an eCommerce application.

For a simple site, I would say there are not so many 3rd party services. I believe they are all ones that I have chosen to engage with according to their documented terms and privacy policies.

what would alleviate that concern for you?

I would like to be informed in advance please, exactly as the other 3rd party services do.

There are many different modules installed on sites that I maintain and I don't have time to "follow" them on social platforms. Given the module is hosted on Drupal.org, then let's put the essential information there. Maybe even the Drupal.org platform could be extended to provide a standard way to do this??

• What sites are contacted?
• What information is transmitted?
• How can I control this?

IMHO It should be possible to disable the feed from the GUI.

How about this?

On the project page https://www.drupal.org/project/commerce → , after documentation put a section called "privacy policy". Explain that there is this connection out, but no data is stored or logged. Link to the documentation page for how to disable it.

Good thought re: a privacy policy on the project page, and sorry for not doing something like that in advance of the release.

We were torn about a full on configuration form for the various dashboard components, to be honest. But looking at Webform now, I see that it does offer checkboxes for all manner of things that appear in the UI advertising support / development services.

(And I'll add this to the discussion in the governance queue, but we should consider the potential for referer URI logging of clicks on outbound links, whether to a module maintainer resource or even third party resources. I wonder if there's some way to prevent that?)

Thanks, I appreciate the way that you are responsive to feedback. I understand that companies need income to fund key development. If we all work together I feel that we can make commercialisation on Drupal.org work in a practical non-intrusive way.

I feel that respecting the freedom of site owners means:

1. Inform; you've responded thanks
2. Allow choice (it's their site😃) with config options

(A small wrinkle that I hesitate to mention because it sounds like I'm angry or annoyed and I'm not:) The first inbox fetch is in commerce_install(), which makes it difficult to stop from happening before "it's too late". That is: if you're concerned about sending data to Centarro, the "commerce_dashboard_fetch_inbox_messages" setting doesn't help very much (especially if you're installing Commerce as part of an enterprise installation profile like we are, where settings.php doesn't exist until AFTER the installation profile has finished). By the time you have a chance to disable it (after the installation profile is finished, after you enable the module "just to try it out", etc., etc.), you've already pinged them.

Hi guys, I'm also running into issues with unwanted ads in my commerce installs.
I added the
# Disable Commerce Inbox

$settings['commerce_dashboard_show_toolbar_link'] = FALSE;
$settings['commerce_dashboard_fetch_inbox_messages'] = FALSE;

to my settings.php but because it was an existing install it does not remove the content. I also just got served shipping provider ads when I was setting up shipping methods.

Is there any documentation or guidance on how to remove all of the ads from the commerce-related user interfaces and prevent new ones from coming in?

I would vote for a new boolean configuration option in the GUI to allow ads, with a default setting of "off".

One additional thought/ observation: as I'm now using CSS rules to remove the ads from the GUI, I noticed that CSS can't be used to hide the column that contains the "commerce inbox" widget. So using

.commerce-dashboard--inbox {
  display: none;

does degrade the look and feel of the interface a bit. It would perhaps look nicer if it were possible to have the commerce-dashboard__metrics card widget span the full width of the page after the inbox is removed via CSS.

Instructions were added to the release notes on how to disable "partner ads", See https://www.drupal.org/project/commerce/releases/8.x-2.38 → .

@AlfTheCat, #16, you're almost there. This is what we use:

/**
 * Hide third-party messaging from the Commerce dashboard.
 * Example URL: admin/commerce
 */
.commerce-dashboard {
  display: block;
}
.commerce-dashboard--inbox {
  display: none;
}
.commerce-order-dashboard-metrics-form {
  margin-top: 2rem;
}

I agree with the sentiment that there should be a UI option for this as well. Secondly, it should default to false when you upgrade sites, so therey should be an upgrade path, meaning this really needs to live in config. Spent way to much time on customer sites now having to alter the settings.php everywhere which is simply annoying.

@morbus_Iff, thanks very much! Added to my spamfilter.css :)