Mark Elfsight modules unsupported

+1 to the above opinion. I am just waiting for other's opinion about unpublishing nodes.

+1

I agree that the code is similar across the modules, and could potentially all be a part of one project.

Can the maintainer be contacted and ask what their motivation is?

I feel we should assume positive motivation before removing all the projects

I would like to add that the modules grab the site email address and send it along as querystring parameter to their service, something which is neither disclosed on the module page nor in the module's readme.

It would make sense that this is done to identify the user/site on their system to allow the integration, but none of this is described/disclosed anywhere.

FYI - I've sent an alert through to the Security Team. I have a feeling a decision on this lies there, especially given the points in #5

Agreed that the first step is an issue in the module queue.

Should this one get moved or a new one created?

I'm not sure there is an official policy on this, but it has definitely come up before and definitely a module that does not respect client privacy can and will get marked with a big warning label and/or the code deleted.

marked as postponed until the Security Team have a view

Chatted a bit with with @mlhess about this - my suggestion is that we do the following for these cases:

1. contact the project node owner through contact form and let them know that harvesting site data and/or email addresses without an explicit opt-in on the configuration page is not acceptable use.
2. let them know via an issue on their project as well
3. state that we will unpublish the modules until the issue is resolved
4. offer to republish the modules when they let us know the issue is fixed

Does that sound acceptable - or do people feel we should give them an opportunity to fix the module (a week window maybe) before unpublishing?

Does requiring explicit opt-in actually make sense - or are there some instances where a module would just obviously need to do some of these things in order to be useful at all - and therefore it just needs to disclose that?

When we make a decision on general policy - I suggest we either directly update the Git Contributor Agreement, or create a sub-page for 'policy for modules which collect site configuration data and/or PII'

Okay, marking as Needs Work as we have a way forward!

I've opened this issue directly on the module in the meantime: https://www.drupal.org/project/elfsight_back_to_top/issues/3112841

As we firm up specific policy we can adjust it - but I think the actions we ask of the maintainer there are unlikely to change.

As @drumm noted in conversation:

"Shouldn’t just be unpublish the project, maybe the releases only. Project page needs to actively tell people it is bad if they have it installed."

Here's some history of situations that can inform what to do here:

* #847952: Suspend CVS account for Kaltura (spyware)
* #883176: How is this different from spyware?
* #2145437: Should d.o. adopt a policy for projects that are serving their own ads when installed and if so, what should that policy be?

Based on the ideas and examples set in those I think we're doing the right thing:

* We assume best intent and contact maintainers. As long as they are making progress the module can stay online.
* If the maintainer doesn't respond quickly/favorably then git access should be revoked, the releases should get unpublished, the project page should get a big warning so that any users of the module know what's up.

There seems to be a misconfiguration of the git client for the person doing commits so that the commits are not getting attributed properly. When I look at https://www.drupal.org/node/3112778/commits I can't see who made the commit.

However, if the commits are being done by the "Elfsight" user account then that's a problem with the policy on organization accounts.

@marcvangend - just so you know - I agree with that as well, but in order of triage I'd like to start with sorting the policy for undisclosed data capture - since that's more cut and dry then the marketing vs. useful convo

I added the “Security” issue tag to #3112841: Elfsight ecosystem modules collect site configuration data and site admin email without opt-in, so the issue now shows up in the warning box at https://www.drupal.org/project/elfsight_back_to_top

Since issues don’t cover more than one project, and my understanding is that other modules from the same user account have the same issue, I recommend making sure an issue is filed for every project.

One thing is the undisclosed data capture, and not respecting client privacy – but I think this is far more sinister than that.

As pointed out by several, the Elfsight modules do little more than embed a 3rd party widget (by means of an iframe) into a web page. The payload of said widget is defined by whatever can be found below an url starting with: https://apps.elfsight.com/embed/… at the time the page containing the iframe is loaded into a Drupal website.

The site owner using one of these modules has no control over what that payload is. Yes, it might by benign – for now, but Elfsight can swap it for something malicious at their pleasure – without the site owner being notified.

I think this is bad security by design. The Drupal community should be protected against this type of design.

The feedback in #19 is a valid concern but also true of many other modules (e.g. a youtube iframe field formatter, font modules that use CDNs, modules that add javascript from CDNs). I don't think drupal.org should explicitly rule out modules that use 3rd party resources.

I followed up on #3112841: Elfsight ecosystem modules collect site configuration data and site admin email without opt-in since the issue stalled with a half-question. I tried to answer that half-question explicitly so they know what to do. IMO we need to wait a smidge more.

The issue #3112841: Elfsight ecosystem modules collect site configuration data and site admin email without opt-in has been open with "Critical" priority and it has been more than a month since greggles in that issue (comment #20) reminded Elfsight that action was required ("remove it or propose alternative solutions"). There has been no response or action. I think that we should take action and halt these violations, as the user seems to believe that he/she can do this with impunity.

The violations are still present, e.g.: https://git.drupalcode.org/project/instagramfeed/-/blob/8.x-1.x/src/Cont...

Another puzzling thing about this user is that only a single module project appear on the Elfsight profile page, but a lot more – about 40, all owned by this profile (e.g. Drupal Search module, Drupal Visitor Counter module, …) – are in our repo. They all seem to be nearly identical. I.e. they embed an iframe to collect email addresses.

I think it would be appropriate to disable git access for Elfsight as a first step and email the person. Git access should not be re-enabled on that account since it is an organization account and organizations should not commit code.

Using the name "Drupal..." for these projects is inappropriate. All the projects should probably just be unpublished. At this point it appears this is a marketing strategy and not an engagement, so unpublishing the projects prevents them being abused for marketing.

I would love to be wrong about this, but going weeks without seeing them take action doesn't give me much hope.

Unpublishing will not help anyone who happens to be running these modules. Marking the releases and project as unsupported will be more helpful in update status messaging. And having the project page available with an explanation will give people a path forward.

I just did a spot check of a few modules and the usage is quite low.

I'd be fine if they stayed published but all links pointing off site were removed.

I also find inappropriate that Drupal is included in those project names. Should not they be renamed to include Elfsight instead of Drupal?

There has been another two weeks since I last complained about nothing happening. Here is a summary of what has been proposed:

1. Disable git access for the Elfsight account. As pointed out by greggles in #22, this is is an organization account and organizations should not commit code.
2. Change the long name of all projects and replace "Drupal" with "Elfsight". Incidently, this matches the projects' short name.
3. Edit all the Elfsight projects to remove the link that phone home with pii, and push the change to the repo. This change will not disrupt any existing users.
4. Post a notice on the project page explaining why a new version has been pushed, and that everyone should update. Mark this as an security update.
5. Mark the projects as unsupported.
6. Email Elfsight and explain the steps we have taken. Explain that to get them back to supported status, they need to create (or assign) a human account that will be used for pushing future updates, and they also must come up with a plan to fix the privacy violations that need to be approved by the security team (i.e. either no extraction of pii, or an opt-in scheme that is compliant with the GDPR).

I propose that we follow this plan. Please review.

I regard this (extracting pii without disclosure) a security issue that is handled in public. Maybe an issue should be created with the security team, so that an official advisory can be created when the problem is fixed?

If I'm given the go-ahead, I can do the grunt work of fixing the projects (i.e. items 2-5 in the list above).

As this is a plan, I'm changing the metadata.

Updated the issue summary to mention the problem with grabbing pii without disclosure (see comment #5).
Changed title to allow for "repair" rather than "removal" in the way we go ahead to resolve this, based upon comment #23 from drumm.

Added trademark problem to the issue summary.

These are not Drupal modules as I understand the term. What each and every one of them do is to embed a spam link in a Drupal website which is activated when the user clicks on the text "Elfsight .... settings" in the admin UI. When clicked, the spam link takes the user to the Elfsight website where the user, after registering and choosing a "plan", can interact with their site to generate some Javascript. A typical example of the end result looks like this:

<script src="https://apps.elfsight.com/p/platform.js" defer></script>
<div class="elfsight-app-9f6e875b-9d7a-44d3-82b3-3caca31c746c"></div>

The user is instructed to copypaste the script into his/her own website, thus giving Elfsight a back door to the user's site.

This is IMHO a total waste of diskspace. The 40+ Elfsight projects here all do exactly the same thing: They trick the user to visit their website, where the user must first register an account, and then interact with it to generate the script. All these 40+ projects can be replaced with a single pulldown menu with 40+ elements that append a query-string to the URL to identify the "thing" requested.

Another thing is that their registration process is not compliant with the GDPR. Essentially, their signup process violates the GDPRs notion of consent and also the GDPR Coupling Prohibition.

After the latest changes by Elfsight the privacy violations are no longer fixable. Basically they've moved the entire pii extraction to a registration process on their own website, and there is nothing we can do about it except to remove all their modules.

Since these are not real Drupal modules, just some ploy to market their services, we can remove their modules wthout causing any disruption. The back doors people already have embedded in their Drupal websites will continue to function, even if the "module" is removed from our repo and from the end user's website.

And even if we delete all these "modules", Elfsite will be able to continue to market and provide their services to Drupal users. They just have to find another ploy to get people to visit their website than pretending this spam link is a Drupal module.

Setting back to "Needs work". The plan I proposed in #26 is no longer doable.

Also changing title back to the original. As already noted, "repair" is no longer an option.

I disabled the Git access of that user, and removed Drupal from the project names created from that account.

Updated summary with more info about the GDPR.

I disabled the Git access of that user, and removed Drupal from the project names created from that account.

+1

I also think the "modules" themselves should be removed from the repo. IMHO, these are not modules, just spam cleverly disguised as Drupal modules.

We usually don't delete projects with committed code. (Webmasters cannot actually delete projects, even if they don't have committed code).

Looking at the number of sites using those modules (https://www.drupal.org/project/usage?page=60&sort=asc&order=Project and following page), I wonder if there are real sites using the modules.

I probably wasn't thinking when I called for their removal in #35, so please forget I said that. While these are not modules, but spam, removal is still not the right thing do.

I think the the correct solution has already given by drumm in #23, he said:

Unpublishing will not help anyone who happens to be running these modules. Marking the releases and project as unsupported will be more helpful in update status messaging. And having the project page available with an explanation will give people a path forward.

I fully support this. Marking them unsupported will put up a big red flag in the status report of everyone using them, which will get existing users (very few, it looks like) aware of the problem. But we should prepare a text to put on those project pages, explaining why the project has become unsupported.

Incidentally, marking all these modules "Unsupported" will not disrupt any existing users. They can get rid of the red flag on the status page by disabling the Elfscript module, and there will be no loss of functionality. The script works independently of the "module". If they like what the Elfsight script does, and trust Elfscript not to abuse the back door, they can keep the script embedded in the site.

I think this has had enough discussion. Let's proceed with marking unsupported and close this out. @Gisle - do your webmaster permissions allow that, or will one of us on the DA side need to make that change?

I have sufficient permissions.

Updated issue summary.

Fixed typo.

Another typo.

All 60 Elfsight "modules" listed in the issue summary have been marked "Unsupported" and their releases have been removed from the project pages.

More typos.

Hi!

This one still have the releases: https://www.drupal.org/project/webmasters/issues/3112796
Best,

Ups: wrong C&P (thnks @kiamlaluno for the msg)
this is the good one: https://www.drupal.org/project/elfsight_faq

@gorkagr The link you provided is for this issue.

Sorry, wrong c&P. this is the correct one: https://www.drupal.org/project/elfsight_faq

(Thnks again @kiamlaluno)

gorkagr,
thanks for the heads-up!

Releases has now been removed from https://www.drupal.org/project/elfsight_faq