Someone pointed to me to the large number of modules published by user Elfsight (https://www.drupal.org/user/3544810/track). The modules are supposed to be integrations with the Elfsight.com platform (on which I don't have an opinion) but the code looks useless. All modules are 99% the same and merely define a /admin route where an iframe is included. I suspect that the modules are only published here for marketing / SEO purposes, and do not contribute in any way to the quality of our CMS and ecosystem.
The initial version of these modules grabbed the site admin's email address and sent it along as a querystring parameter to their service, something which was neither disclosed on the module page nor in the module's README. As of June 2020, they no longer do this, but instead the user is tricked into clicking on a spam link that takes the user to a registration process where the user must provide pii (i.e. his/her email-address) as consideration for getting access to their service. This process violates the GDPR's notion of consent and also the GDPR Coupling Prohibition.
The word Drupal™ is a trademark owned and controlled by Dries Buytaert, see https://www.drupal.com/trademark
Elfsight branded 25 of its project with a name starting with "Drupal" (see list below). This violates Dries' trademark and is also deceptive marketing, as it gives consumers the false impression that Dries stands behind, or approves of, this software.
There are three major problems with the Elsight projects hosted on Drupal.org:
- Abuse of the Drupal™ trademark.
- Creating an excessive number of near identical projects for the sole purpose of advertising an external business (i.e. spamming the project namespace).
- Privacy violations. I.e. collecting pii without valid consent and also violating GDPR Coupling Prohibition.
Here are those that had names starting with "Drupal". This trademark violation has since been fixed (by one of our webmasters), but we keep their original names in the issue summary as a matter of record.
- Drupal Amazon Reviews
- Drupal Apple App Store Reviews module
- Drupal Audio Player module
- Drupal Background Music module
- Drupal Before and After slider module
- Drupal Click To Call button module
- Drupal Event Calendar module
- Drupal G2 Crowd Reviews
- Drupal Image & Video Slider module
- Drupal Live Chat module
- Drupal Number Counter module
- Drupal Photo Gallery module
- Drupal Podcast Player module
- Drupal Portfolio module
- Drupal Popup module
- Drupal QR Code module
- Drupal Radio Player module
- Drupal Restaurant Menu module
- Drupal Search module
- Drupal Telegram Live Chat module
- Drupal Trustpilot Reviews module
- Drupal Viber Chat module
- Drupal Vimeo Gallery module
- Drupal Visitor Counter module
- Drupal Weather module
Below are a list of the Elfsight projects that did not have names starting with "Drupal".
- Elfsight Age Verification
- Elfsight Airbnb Reviews
- Elfsight Booking Reviews
- Elfsight Back to Top Button
- Elfsight Contact Form
- Elfsight Cookie Consent
- Countdown Timer
- Elfsight Facebook Chat
- Elfsight Facebook Comments
- Elfsight Facebook Feed
- Elfsight Facebook Like Button
- Elfsight Facebook Reviews
- Elfsight Facebook Share Button
- Elfsight FAQ Module
- Elfsight File Embed
- Elfsight Form Builder
- Elfsight Google Maps
- Elfsight Google Reviews
- Elfsight Instagram Feed
- Elfsight Instagram Testimonials
- Elfsight Instagram Widget
- Logo Showcase module for Drupal
- Elfsight PayPal Button
- Elfsight PDF Embed
- Pinterest Feed
- Elfsight Pricing Table
- Elfsight Social Media Icons
- Elfsight Social Share Buttons
- Elfsight Team Showcase
- Elfsight Reviews for TripAdvisor
- Elfsight Testimonials Slider
- Elfsight Twitter Feed
- Elfsight Whatsapp Chat
- Elfsight Yelp Reviews
- Elfsight Youtube Gallery
Comments
Comment #2
rakesh.gectcr+1 to the above opinion. I am just waiting for other's opinion about unpublishing nodes.
Comment #3
rachel_norfolk+1
Comment #4
volkswagenchickI 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
Comment #5
jpoesen CreditAttribution: jpoesen at TrainingCloud commentedI 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.
Comment #6
rachel_norfolkFYI - 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
Comment #7
gregglesAgreed 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.
Comment #8
rachel_norfolkmarked as postponed until the Security Team have a view
Comment #9
hestenetChatted a bit with with @mlhess about this - my suggestion is that we do the following for these cases:
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'
Comment #10
rachel_norfolkOkay, marking as Needs Work as we have a way forward!
Comment #11
hestenetI'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.
Comment #12
hestenetAs @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."
Comment #13
gregglesHere'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.
Comment #14
marcvangendGreat to see lots of activity here. However I do want to point out that for me, it's not just about security and sharing data. I also have a problem with the fact that they seem to use our platform as a marketing tool, not to publish usable modules. That in itself would be reason enough for me to unpublish.
Comment #15
gregglesThere 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.
Comment #16
hestenet@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
Comment #17
drummI 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.
Comment #18
marcvangendFYI I just read something at https://www.drupal.org/project/elfsight_whatsapp_chat that provides some insight into how the module supposedly works:
(Still beats me why someone would use Drupal if copy-pasting 3rd party widgets into templates is their style of web development, but that's a whole different story.)
Comment #19
gisleOne 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.
Comment #20
gregglesThe 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.
Comment #21
gisleThe 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.
Comment #22
gregglesI 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.
Comment #23
drummUnpublishing 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.
Comment #24
gregglesI 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.
Comment #25
apadernoI also find inappropriate that Drupal is included in those project names. Should not they be renamed to include Elfsight instead of Drupal?
Comment #26
gisleThere has been another two weeks since I last complained about nothing happening. Here is a summary of what has been proposed:
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.
Comment #27
gisleUpdated 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.
Comment #28
gisleAdded trademark problem to the issue summary.
Comment #29
gisleThese 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:
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.
Comment #30
gisleAfter 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.
Comment #31
gisleSetting back to "Needs work". The plan I proposed in #26 is no longer doable.
Comment #32
gisleAlso changing title back to the original. As already noted, "repair" is no longer an option.
Comment #33
apadernoI disabled the Git access of that user, and removed Drupal from the project names created from that account.
Comment #34
gisleUpdated summary with more info about the GDPR.
Comment #35
gisle+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.
Comment #36
gisleComment #37
apadernoWe 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.
Comment #38
gisleI 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:
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.
Comment #39
gisleComment #40
hestenetI 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?
Comment #41
gisleI have sufficient permissions.
Comment #42
apadernoComment #43
gisleUpdated issue summary.
Comment #44
gisleComment #45
gisleFixed typo.
Comment #46
gisleAnother typo.
Comment #47
gisleAll 60 Elfsight "modules" listed in the issue summary have been marked "Unsupported" and their releases have been removed from the project pages.
Comment #48
gisleComment #49
gisleMore typos.
Comment #50
marcvangendThank you Gisle, I appreciate your efforts.
Comment #52
gorkagr CreditAttribution: gorkagr commentedHi!
This one still have the releases:
https://www.drupal.org/project/webmasters/issues/3112796Best,
Ups: wrong C&P (thnks @kiamlaluno for the msg)
this is the good one: https://www.drupal.org/project/elfsight_faq
Comment #53
apaderno@gorkagr The link you provided is for this issue.
Comment #54
gorkagr CreditAttribution: gorkagr commentedSorry, wrong c&P. this is the correct one: https://www.drupal.org/project/elfsight_faq
(Thnks again @kiamlaluno)
Comment #55
gislegorkagr,
thanks for the heads-up!
Releases has now been removed from https://www.drupal.org/project/elfsight_faq