Document the communication to 3rd party sites

Created on 17 January 2024, 11 months ago
Updated 19 March 2024, 9 months ago

Describe your bug or feature request.

After the recent upgrade, I was rather surprised to find my customer's site subscribed to your company's feed. I am not aware that anyone gave consent for this, and I can't see an option to turn it off.

I have two significant Data Protection concerns about this which is not something I have seen before on Drupal.org modules.

  1. In terms of data privacy, your company is receiving information about the the sites using the module, for example IP address and some usage pattern based on timing of requests.
  2. This feels like a form of spam, intruding into the user experience of all users with the relevant permission. This feed displays material relating the benefits of your product, which is in effect marketing. There is even a counter/badge on the main menu that makes it difficult to ignore the messages.

.

Secondly there is a security concern. The feed code runs a script fetched from the remote server, which executes in the context of an admin user. This introduces a new attack vector to sites in case there is any compromise of the path of fetching the script (e.g. the remote server is hacked). A secured commerce server could have a policy of not executing any remote scripts.

If a bug, provide steps to reproduce it from a clean install.

No steps as far as I can see - it appears all by itself.

Proposed resolution

The feed should be disabled by default, with a privacy statement displayed accompanying the opt-in form.

๐Ÿ“Œ Task
Status

Active

Version

2.0

Component

Documentation

Created by

๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom adamps

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @adamps
  • Status changed to Closed: works as designed 11 months ago
  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom rachel_norfolk UK

    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!

  • ๐Ÿ‡ต๐Ÿ‡นPortugal introfini

    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;
    
  • Status changed to Active 11 months ago
  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom adamps

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

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom rachel_norfolk UK

    Ah! My apologies.

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom adamps

    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.

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom adamps

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

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States rszrama

    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.

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom adamps

    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.

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom adamps

    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.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States rszrama

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

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom adamps

    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
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States morbus iff

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

  • ๐Ÿ‡น๐Ÿ‡ญThailand AlfTheCat

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

  • ๐Ÿ‡น๐Ÿ‡ญThailand AlfTheCat

    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.

  • ๐Ÿ‡ฎ๐Ÿ‡ฑIsrael jsacksick

    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 โ†’ .

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States morbus iff

    @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;
    }
    
  • ๐Ÿ‡ง๐Ÿ‡ชBelgium swentel

    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.

  • ๐Ÿ‡น๐Ÿ‡ญThailand AlfTheCat

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

Production build 0.71.5 2024