Some people wouldn't like it because the installation wouldn't be completely automated anymoreIncluding myself.
[Raises hand] Indeed. If your module phones home with OS and Perl version, I have no objection. If it requires user intervention during install, I won't use it. I don't need that hassle. The only exception I make to this is for stuff included in Bundle::CPAN, because that's so vital and because it installs first and then I can walk away while everything else gets installed.
As it happens I don't use your module, but if I did, I wouldn't get counted with the opt-in plan. Just so you know. I almost never sit and babysit CPAN while it's installing modules. Especially not on desktop systems. Sometimes I position the window where I can see the bottom of it peeking out behind some other window I'm working in, but just as often I start CPAN going in a screen session and detach, especially when I'm sshing into a headless or remote system. Is there a security risk? Sure. There'd be a security risk even if I monitored the install closely. I could mitigate that risk by reading the source of every module before I install it, but that would consume a lot of my time; there's a tradeoff involved here, and to date the worst fashion in which I've been "bitten" by a module from the CPAN was when I discovered that a certain module I rely on heavily won't run out of the box under Taint checking. (The module in question is a dependency for DateTime::Format and as such is worth enough to me that I investigated this problem and figured out how to resolve it, rather than dropping the module. Most modules I'd just discontinue using in this situation.)
As for privacy concerns, there are different kinds of privacy. Information privacy (protecting things like my OS, Perl version, address, ...) is of little concern to me, except for _sensitive_ information (passwords, social security number, and such). I'm not a tinfoil-hat kind of guy, really. But the other kind of privacy, the freedom to not be continually needlessly bothered, is more important to me. I filter spam to the largest extent possible (as long as I don't get false positives; I did away with naive Bayesian filtering because it got false positives, which makes it worse than useless to me; as far as keeping my address private, that would prevent real people from being able to contact me for legitimate reasons, an unacceptable tradeoff), use a browser that suppresses popup windows, don't have a voice phone in my living quarters, and won't use Perl modules that require a lot of babysitting during installation (except, as noted, for really vital things like Bundle::CPAN).
I'm not comfortable with allowing everything to phone home, as I want to see what information they will send before I agree.
If a global setting such as you propose were ever implemented, it should have an option for "Don't ask, just do it." That's how I'd set it, but if that option weren't available I'd set it to "Don't ask" and screw your statistics, because I don't want to be hassled. I specifically want to be able to install Bundle::CPAN, reload CPAN, and then set Bundle::Jonadab going and go do something else while another sixty or eighty modules are installed. (Most of those are dependencies, either directly, or through the test suites.) It wouldn't be right to make me sit and watch the scrolling text so I can monkeybang the keyboard every little bit for two hours every time I install a new system or a new Perl version or whatever. That would be far more invasive than sending my OS and Perl version to the module author. It's bad enough I have to configure CPAN and LWP each time; once I get that done, I want the rest to be interruption-free.
As far as not being comfortable letting "just anything" phone home, a malicious program wouldn't respect my phone-home preference anyway, so if there's code that I don't trust, I shouldn't be installing it at all; if I'm installing your module, that implies that I decided the utility it provides is worth more to me than the security tradeoff of trusting it. So that implies I trust it to be sensible about what data it sends and where it sends it. At some point I'll probably make the mistake of trusting a module I shouldn't, but when that happens I'll deal with it; I choose not to go through life agonizing over such things when the agonizing is fundamentally not even going to significantly mitigate, much less solve, the problem.
There are things I wouldn't want a module doing at install time; one example has recently come up. But phoning home with statistical data for the author of the module isn't anywhere near that category, as far as I'm concerned. It's nice that you're going to have your module ask for permission, because we know there are some people who object, but as far as I'm concerned, it's fine. As you point out, the risk these data pose is much smaller than the risk I've already accepted by running your code on my systems without personally inspecting every line of it first.
I'm not saying everyone should be comfortable setting the variable that way in every situation; I'm just saying that if someone were to go to all the trouble to institute a standardized global way to express a preference on this issue, it should provide for the basic standard three options, "Yes", "No", and "Ask"; if a user such as yourself is "not comfortable" with one of these options, then he won't set it that way, will he? "Ask" should probably be the default. It would be nice if there were a way to say "Yes, and set the pref so I'm not asked again" or "No, and set the pref so I'm not asked again", but that would require the existence of a global preference that all software would be expected to know about.
In reply to Re: Gathering module usage statistics - a compromise solution?
by jonadab
in thread Gathering module usage statistics
by Juerd
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |