Some people wouldn't like it because the installation wouldn't be completely automated anymore
Including 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.
;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print