I spotted some tracking code in a module (code not currently hosted on d.o) today, and it made me wonder. Just an <img> tag sneaked into hook_install().

Are there rules about modules and privacy? Is this a potential security issue? (I know that the update module is opt-in, and anonymises for security reasons.)

What do you think about modules circumventing the update module stats collection to directly track installations?

I'm not personally bothered by it as a module user, but I do think the practice has security concerns (I can explain in detail if you can't picture why).

I guess I can understand the module developer's interest, even though I'd avoid the tactic myself in modules I contribute to Drupal.org - I'd be concerned about issues of trust in the community, and that it might be considered a security issue and thus cause for removal.

Comments

juliangb’s picture

I don't think anything can be done about this if it isn't hosted on drupal.org, but if I was using this module I would almost certainly remove the offending trackers and post a few comments about it.

I believe there are ways to use an update system similar to drupal.org's, but checking a different server, and so that would surely be the recommended way to provide for this.

xurizaemon’s picture

I'm not lighting up any torches or sharpening pitchforks. If it was an issue I thought *should* be resolved, I'd probably just ask the developers.

I guess it's mostly that I haven't seen this in Drupal modules before, and seeing it in one module made me wonder. It might be that it's common practice, or it might be that some other modules have attempted to do similar things in the past and been advised against it.

I simply don't have any past experience of a module doing this particular thing, which made me wonder.

FWIW I'm confident the intentions are not malicious, but I also suspect it's something other people might not take kindly to. Obviously there are modules which allow site admins to perform all kinds of privacy evils, but that's not the same thing as having a module track installations directly.

And there *might* be security questions - well, I think there are (potentially revealing that a specific site is running a specific module version).

I expect that if this issue has been touched on before in the Drupal community, and not found acceptable, that the module maintainer would prefer to know before the tracking code gets into CVS.

WorldFallz’s picture

I'd be more concerned about the fact the developer was doing something ostensibly sneaky. Though the actual infraction maybe be meaningless, the act itself speaks volumes about the type of developer. This time it's harmless, who knows about next time? Maybe they're just testing the waters for something more invasive? The point is, there's no way to know for sure but what you do know for sure is that the developer has no scruples about doing sneaky stuff.

The proper way to do something like that is to let people know about it and let them decide for themselves whether or not it's acceptable. The fact that it wasn't done this way would keep me away from everything that developer produces.

And no, such backhanded code would not be acceptable on drupal.org which is probably why the module isn't available here in the first place.

xurizaemon’s picture

such backhanded code would not be acceptable on drupal.org

I agree based on gut feeling, but I can't find any actual policy forbidding it.

WorldFallz’s picture

I thought I could remember seeing it documented somewhere-- i'll see if I can find it.

xurizaemon’s picture

Thanks! Your .sig virus has infected mine with the "pay it forward" element. I hope you don't mind? :)

WorldFallz’s picture

of course not-- that's the whole point of pay it forward!!! ;-)

Dave Reid’s picture

I want to know which module it is so we can handle it in a public issue to get resolved. Its unacceptable for a module hosted on drupal.org and should be considered a security concern.

xurizaemon’s picture

Understood. When I posted this question, my understanding was that the tracking code was only in the SVN version which was hosted OFF Drupal.org. My aim with this enquiry was to touch base with the developers before the code got to d.o and alert them of d.o policy on tracking.

It wasn't until you raised the issue against the module already in CVS here that I realised the same tracking code was in that branch already (and was reported by dennis_sle more than a year ago). As I'd been focussing my work on their latest code which was off d.o, I hadn't taken the time to check the code already in contrib myself.

Action has since been initiated to have the tracking code removed (#392736: Remove hidden stats iframes), and to clarify Drupal.org policy on such things (#847944: Privacy policy for contributions).

Thanks for engaging.