Suspend CVS account for Kaltura (spyware)

block the user from d.o. unpublish the module and cvs rm the code.

Unpublishing the module would negatively affect the 800 or so sites which use this module currently, wouldn't it?

I'm happy to file a patch to resolve the issue, and that should give Kaltura a chance to demonstrate their good faith.

If this is in contravention of existing Drupal.org policy, I can't find it.

I do think we should have a policy on this sort of thing (#847944: Privacy policy for contributions), but as we don't currently have anything I can find to that effect, I don't understand how we can say that Kaltura are "in the wrong".

I'm of the opinion that this sort of privacy thing is not the expectation of the Drupal community. However, commercial organisations producing software needs to know the rules they are playing by in order to avoid breaking them, so we (community) need to state them explicitly.

Notwithstanding the obvious.

At least block cvs access and unpublish the module. I'd be fine with blocking the account too.

Unpublishing the releases is better than unpublishing the project - an unpublished release tells the update module that the release is "revoked".

Has anyone even tried to contact the Kaltura maintainer? This seems pretty full in in such a short period (14:32 - 14:53) only 21 min. 21 min doesn't leave much time... And I am *fully* aware of their previous transgression.

I know that there is a major re-work of the Kaltura module going on in their private SVN network and someone from the Drupal community has a Git repo with the work. Maybe *try* to contact either and see if the IFRAME code has already been removed?

My 2 cents.

Dave: I would suggest, in the future, that IRC +1s be actually logged in here as well OR you get a link to the discussion as an IRC log. We'll obviously need to update hosting policy re: this, but I would also institute a "notify and wait 24 hours" as part of that.

Sounds like process to contact Kaltura is in progress, so let's close this issue and work on #847944: Privacy policy for contributions and see if we can get patch applied at #392736: Remove hidden stats iframes

Myself, chx. grobot and pwolanin were all in irc at the time, but also posted here. #drupal-contribute isn't logged, and pasting from it is discouraged.

I see no need to give an extra 24 hours over the one year and a quarter the original issue sat in the project's issue queue without a response #392736: Remove hidden stats iframes, not to mention the repeat offense.

Guys,

This was unintentionally missed. We will deploy the patch by grobot (thank you for that).
I see no reason to disable the account or take any extreme measures when this was not against any written rules, but merely a bad choice of statistics collection method.

#392736: Remove hidden stats iframes has been open on March 2009; it took too time to resolve the issue, which has been resolved right after the CVS account has been blocked. Saying that it was unintentional is too convenient.

We would have taken the same action, i.e., for module that define a new CCK upload field, and shows random advertising pop ups; there is nothing written about that, but we don't want a module doing that.
Still, the issue has been opened one year and a half ago. The maintainer of the module should have started to ask himself if he was doing something wrong; as there aren't reply from the maintainer, I take he well known what he did (otherwise there would be a question asking where the code is, in example).

kiamlaluno - I understand that you think it was wrong to use the iframe. Nevertheless, as long as it's not written in the rules /guides to be forbidden and there was nothing harmful about it (nor about the intent) - I would like to have the option to fix the trunk according to the patch and release a new version. Blocking the account only leaves the problem as is without a fix or notification for others to get a new release with a fix.

kiamlaluno - I understand that you think it was wrong to use the iframe.

I think I am not the only one to think so; many other reported that as wrong, as I can see.
It doesn't see it has taken any action, since the report opened against the module; there are no replies to that issue, not even to ask where it's written that it's not allowed to do what the module did.

Would you like that CCK (just to make an example) would send your password, or the list of the installed modules to a third-party site?
Such features need to be declared in the project page, and not be hidden features.

Not all that is forbidden is written in some places. In this case, the maintainer was warned with a previous report; I think that should be enough to avoid any repetition of similar mistakes.

Thanks for responding, Zohar.

There are 800 sites (from usage stats) using this module. If we don't speedily resolve the fact that the module has been unpublished, that's 800 sites who will be faced with an alarming "revoked module" notification.

I'm hoping Zohar (or someone else here with cvs superpowers?) is able to commit and release a non-tracking version of this module swiftly, so that those site maintainers don't have additional work created for them unnecessarily. For me as a site maintainer that seems like the most important issue right now, because it'll cause a lot of other people additional work.

...

I've had issues go un-noticed in an issue queue of my own for a long time (because I hadn't activated email notifications on the project). With an organisation of multiple staff, I can imagine how an issue might get missed, or fall into a too-hard basket, or ... whatever.

I'm not making excuses for Kaltura. I can't speak for them, but I can see how I might make similar mistakes, and I'm a believer in Hanlon's razor. (Zohar, I'm not calling your team stupid, I'm just saying that honest mistakes sometimes look like malicious ones.).

I feel we could be unfair both to Kaltura and to our own users of the module in shutting down a contrib project with such short notice. Yes, they should have responded earlier; yes, there was an earlier offense; yes, the issue should have been dealt with before today.

But the escalation from no warning to full klaxons blaring has been swift, and there was no explicit policy against this behaviour before the issue was raised, and I think some level of lenience is sensible - especially considering the needs of those Drupal users who have this module installed. (Who also have a right to "no spyware", but actually getting them to uninstall will trigger said spyware, and getting them an upgrade path won't, so ...)

I feel totally out of my depth here; I'm arguing with people who I have huge respect for, and I don't feel like I have the depth of Drupal community experience to dispute these things with you Big Name Folks. But I'm saying this because I think it's true, and you lot won't be afraid to tell me I'm wrong if I am :)

kiamlaluno - You're right, we should have fix this issue - however we missed it. Now that it has brought to our attention, we should fix it and close the matter.
What will be the procedure of releasing the CVS account so that we'll be able to patch and release a new version?

Give me a break-- spyware is unacceptable and if you claim you need a policy to understand that your being disingenuous. You're also posting your code in the wrong place. I agree with chx, but never the less, just so we can have a place to point to: http://drupal.org/node/103704#spyware.

The mere fact there was such an uproar over the first bit of code that had to be removed should have been enough. The fact that an issue sat open, unattended for more than a year, just seals the deal.

WorldFallz - no spyware was done, it was merely a way to collect anonymously installation stats to make the module better. the module did not send any information nor did it do (or even meant to) any harm.
Nevertheless, it should be fixed. We care about the module and its users and it is in our best interest to fix every issue immediately.
We all have issues unattended, sometimes things go unnoticed and sometimes you just don't get to it fast enough - deleting a module will not make anything better.
There are many who use the module today - and blocking the CVS account only stands in the way of patching the issue and releasing a new version ignoring all the current users of the module.

Collecting installation statistics surreptitiously is exactly what spyware is, lol. unbelievable. chx was soooooo right.

I agree with #21. I'm firmly against restoring cvs access after the response here, I'm fine with grobot or another maintainer not connected to Kaltura being given either permanent or temporary cvs access to apply that patch, review for more spyware/spam and push out a new release.

From the usage stats, it appears that some 800 sites are using this code, and a good percentage of them are likely unaware that they are running spyware.

Is it possible to send a message to that effect via Update Status, with instructions to these users about how to get updated code?

As a Drupal community member and developer, I appreciate your concern and have learned from this discussion.

If a message was given last night instead of immediately (20min middle of the night!) disabling the access we would have fixed the issue - taking such extreme steps without a notice does not provide the module developer with much time to respond and remedy.

Thanks to grobot there is already a patch (http://drupal.org/node/392736) available for the issue and we should release a new version of the module asap. We heard the feedback and will make sure it is attended in future releases.

bonobo - the iframe is only present during installation of the module.

Re #22, I'm prepared to accept CVS access for Kaltura module in order to have the issue speedily resolved in the interests of its userbase. I'll review the codebase now for other stats harvesting.

I am concerned about the lack of response, and what appears to be a lack of concern, from the Kaltura team about communicating with their userbase about the fact that they included spyware with their module.

The fact that the Kaltura team used the d.o infrastructure to distribute spyware is a related, but separate issue.

The fact that they used the d.o infrastructure to distribute spyware after repeated warnings about spam links, spam communications, and that they sat on an issue about removing the spyware for over a year, is an additional factor to consider.

And I wonder: how many of these extensions also contain spam links and/or spyware?

So, in response to

the iframe is only present during installation of the module

This response, and other responses in the thread, show a lack of caring about your userbase, and how you harvest information from them. Why not just be honest, and disclose that you want to collect information about how people use the module? Make it an opt-in system.

Unsure if it's required, but re #22/25 above, I've opened #848826: Release co-ordination issue: 6.x-1.5.

FFS, sorry! That should have been #848818: Add grobot as a co-maintainer for Kaltura.

I completely agree with bonobo. It should have been easy to report in the project page that the module is sending information or statistics about the installation of the module, and to add an option in the project settings page to disable that feature.

It doesn't seem a news that many applications or utilities can send statistics about their use, but they allow the user to disable such behavior, and they always warn the user when they are sending such data. Even some OS have a similar functionality that is used when an application crashes (I know of Windows, and Mac OS X, but there could be many more OS); also in this case the user is able to avoid the information are sent each single time, or globally.

yep, bonobo is exactly right. And I don't buy any of these 'whoops, sorry it was an oversight' claims from the developers. There's simply no justifiable reason for these spyware tactics in a gpl module released on drupal.org and no reason drupal.org should be required provide notice, give warnings, or anything of the sort. Drupal and drupal.org will take a reputation hit for distributing spyware and that's unacceptable.

That you could claim you weren't given enough warning after an issue sat in the issue queue for over a year is absurd. More likely is that you were ignoring it hoping to fly under the radar as long as possible.

We're very happy with grobot co-maintaining and are appreciative for your efforts & support, grobot.

In contrary to where this discussion was lead, we are very open to listen and better the project in every way possible.
That said, we have set up a better process for ourselves to monitor the the issue tracker and respond faster.
We've also taken a note and better understanding of everyone consideration in this discussion on the matter of spam and spyware.

We would like to continue maintain the project and release new versions (6.2 is also ready and is just waiting for release).

I am re-enabling Zohar's account temporarily so that Kaltura can help with any fixes that Grobot hasn't already applied in fixing this.

I am going to ask Kaltura to publicly commit to following guidelines and not add these hidden information gathering techniques in the future. I don't think it's the community's interest to see this module not maintained to it's fullest, or to fork.

Re-enabling for 7 day period while we work to a full resolution.

Kieran

I am also going to try and meet with Kaltura at OSCON, next week, and would welcome Bonobo and others to attend so we can discuss this in person and work to a full resolution.

Kieran

I'm curious why the action to restore cvs access was taken with no discussion in this issue? A unanimous community decision was made and to have it overturned like this seems totally arbitrary.

I see two resolutions. Either this arbitrary and outrageous decision is overturned and ASAP or we ask EVERY webmaster to resign in protest and Kieran can find other fools to police the waters.

I just removed all my d.o permissions, I have no interest in doing any work as a d.o webmaster if decisions get overturned in this arbitrary fashion, this is not the first time. Amazon isn't the only person who can change d.o permissions without consulting anyone.

Seriously-- this was no minor infraction or conflict of personalities. A community member with commit access committed spyware to the drupal.org CVS repository. Moreover, it's was multiple infractions for which they have demonstrated a complete lack of understanding or concern for what they have done. It's the persistent attitude of 'oops, sorry, it was no big deal' that speaks volumes-- even more than the spyware itself. IMO the drupal community has no need for developers like this.

This doesn't just reflect badly on them, it reflects badly on the entire community.

I've blocked Kaltura's account so we can reach agreement how to proceed.

Kieran

I thought that a solution has been already found.

If Kaltura wanted to keep maintaining the project, then they should have acted more responsibly. It doesn't sound news that contacting a site without that is even declared as feature of the module, or it's an expected feature of the module, is not considered good practice.
Mac OS X asks me permission to send information about the crashed application; I don't see why Kaltura thought to have the right to do what Apple doesn't do.

I don't take the developers didn't know what kind of code they were adding, nor that they forgot that particular piece of code.
About the fact the module is not sending data to the site, that is clearly not true; it is at least sending the IP of the site where the module is installed, among other things.

I am re-enabling Zohar's account temporarily so that Kaltura can help with any fixes that Grobot hasn't already applied in fixing this.

I'm not aware of any fixes lacking from Grobot's commits. Are there any open issues for the module discussing these? If that's the case how long was grobot given to review and commit these before re-granting access? (certainly less than a year...) Did you discuss specific code changes with Zohar before re-enabling the account?

I am going to ask Kaltura to publicly commit to following guidelines and not add these hidden information gathering techniques in the future.

Let's compare this to the response Kaltura gave to the original issue:

Due to some additional internal discussions and feedback from within the community, we have updated the module to allow an opt-out option regarding the links discussed above. Specifically, site-owners will be able to opt-out and remove the links from within the module settings (without having to change any code, as was the case before).

We have left two links that are geared towards promoting the open source video movement and Kaltura's efforts in this area - including the Kaltura Directory of content, the world's largest repository of legally remixable content, which is in the making. Seeing as the links are highly relevant and do not harm any of our publishers or Kaltura itself, we hope that the majority of the community will join us in this effort and leave the links in.

Additional feedback is welcome, of course!

Lisa
Kaltura

First of all, the hidden links were made opt-out, not opt-in - that means any existing installs would have continued to have had the spammy links unless the site administrator made a visit to the settings page, noticed the new setting, then disabled it. Not exactly encouraging, nor were the responses to this issue, so I see no reason they should have been given the benefit of the doubt.

I don't think it's the community's interest to see this module not maintained to it's fullest, or to fork.

My definition of a module that's not well maintained would include one where issues requesting that spyware be removed languish for months or years in the issue queue without any response.

First of all, the hidden links were made opt-out, not opt-in - that means any existing installs would have continued to have had the spammy links unless the site administrator made a visit to the settings page, noticed the new setting, then disabled it.

As the settings page is not available before the module is installed, nobody will be able to avoid the hidden links are followed during the installation.
catch makes a good point: the option should be to opt-in the hidden links, not to opt-out them; that is what is done in similar cases, where the purpose is much more important than commercial purposes.
Such option should be then made public by reporting it in the project page; if you are not reporting it, many users will not know it exist such option, nor can they decide if to not install the module.

No such links, forms etc should be present on any module hosted on drupal.org. Drupal.org already collects usage statistics which are made available to everybody (and there's a proper select box on install to not provide this info).

Kieran's summary -- he needed to run for a meeting

I met with many of the people in this issue in #drupal-contribute to discuss.

The consensus and final agreement was that this behavior was deliberate, unresponded to for over a year, and continued to be an issue since they have not updated their public SVN repository. The decision is to block Kaltura's CVS account permanently.

I asked about a half dozen people if they thought this issue could be resolved but everyone felt that this couldn't be resolved given how extensive the actions were and the time period in which they were not addressed.

I am re-enabling Zohar's account temporarily so that Kaltura can help with any fixes that Grobot hasn't already applied in fixing this.

I've been in touch with Zohar directly as well, but as yet have not heard of any such issues. Nor can I find any in the issue queues.

Catch has already asked above in #40 if there are specific issues remaining which relate to this in Kaltura module - I'd definitely appreciate Amazon (or Zohar) answering his question so I can engage any such issues.

I'd also be curious why, as Dave Reid points out above in #34, the module under development in Kaltura's internal repo appears to still have the spyware in place.

This creates the appearance that folks from Kaltura are saying one thing here, and doing another thing in their own space. This is definitely their right, but it undercuts the statements that they have listened to the concerns voiced in this thread.

I also propose that we place a link on the Kaltura module project page linking to this thread. It seems appropriate that people considering the use of this module be apprised of the concerns raised in this thread.

I've opened a ticket for this in the Kaltura module issue queue: #856784: Inform users about the use of spyware/spam links in older versions of the Kaltura module

I also propose that we place a link on the Kaltura module project page linking to this thread.

What has proposed in IRC is that the project page contains a warning about the spyware link that was present in previous versions; it was also suggested another way to let users know of the issue, which involves a SA.

As a user who stopped using Kaltura because of problems (perhaps related to this, but mostly due to some other bugs AND lack of attention to the module) what was the result of this discussion? And what is the current status of the Kaltura module and service and the maintainers on this site?

Examining the module, it looks as though the module was updated two days after this discussion but there is no reference to this exchange in the module description. Further, the "beta" version of the module was last updated in mid-2011, unless the updates are being done only on D7 and the dev version of 6.

So it would be great if the community maintainers could update this or at least show how this was resolved versus just a system message that this issue is now closed. Please don't misunderstand; we users of Drupal are deeply indebted to folks like those on this string who make the software to powerful to use and so accessible to nonprofit organizations like ours, but so often we do run into important strings like this that are left hanging. This discussion raises some serious issues about Kaltura, about the module and about best practices. Yet I can find no continuation of this. If, in fact, there is another thread/string somewhere that continues this, please direct me and sorry for taking up your time.

Thanks, in advance.

geoff

This two year old issue shouldn't be repurposed to ask questions about the status of the module today. For that use the normal module issue queue http://drupal.org/project/issues/kaltura