ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [gnso-ff-pdp-may08] Another example why due process is important

  • To: Fast Flux Workgroup <gnso-ff-pdp-May08@xxxxxxxxx>
  • Subject: Re: [gnso-ff-pdp-may08] Another example why due process is important
  • From: George Kirikos <fastflux@xxxxxxxx>
  • Date: Sat, 31 Jan 2009 14:17:05 -0500

Hi Rod,

On Sat, Jan 31, 2009 at 1:33 PM, Rod Rasmussen wrote:
> Substitute GOOD for due and I would agree with you.  Do you seriously think
> Google would * all search results as malware intentionally?  I wonder how
> much money they just lost in missed ad revenue alone.  This is a
> systems/software issue, not a policy problem.

>From what I understand, only the free organic search results were
marked as malware -- the paid results were not. So, they might have
made some extra money during that brief period! :)

No one creates false positives intentionally, that's the entire point.
The policy problem remains that if false positives do occur (and a
domain is taken down that shouldn't be by a registry or other actor)
for fast flux or for the broader issue of alleged "abuse", there needs
to be financial repercussions on that actor, besides an "oops" or
"we're sorry." The damages should not be borne by the innocent victim,
namely the registrant. That's why I don't like the whole "takedown"
idea, as it's reactive, instead of being proactive and reducing the
problem at the registration time.

If we look at guns, for example, guns can be used to defend oneself,
or to commit murder. Gun registration laws and waiting periods have
been one policy choice to limit access to guns for "bad actors". One
of the comments on the report used that example:

http://forum.icann.org/lists/fast-flux-initial-report/msg00003.html

although registering in person, photo ID and biometric data are
probably overkill (the verified WHOIS approach through PINs sent by
physical mail that I've suggested in the past should be sufficient and
be inexpensive to implement while maintaining the benefits of being
proactive). What "bad" things can happen under such a system?

a) the cost to send out PINs (say $1 per verification, which can be
spread out over multiple domains sharing the same WHOIS)
b) new registrant who is "innocent" who doesn't get their PIN code has
to wait a few days before their site resolves (no big loss)
c) new registrant who has malevolent intent has to supply a physical
address -- great tool for law enforcement to help track them down if
they commit a crime (not bad at all, except for the bad guys)
d) repeat registrant who did bad things in (c) is blacklisted and
can't register a new domain (unless he supplies another physical
address/identity) -- bad for him, not bad for the rest of us; in any
event, he is slowed down, and it's more costly for him to run his
scams

>From signalling economics:

http://en.wikipedia.org/wiki/Signalling_(economics)

it's less costly for the good guys to signal via accurate verified
WHOIS credentials than it is for the bad guys. Just like it's less
costly for smart people to get a higher education, providing a signal
of their higher quality, even though that education in itself might be
completely useless to their job.

All the people modelling abuse (or fast flux) are providing a
statistical model based on observed variables, and making a
probabilistic assessment that A is a good site or B is a bad site. How
would those models change if they had one more "observed variable",
namely that Site A had verified WHOIS, whereas Site B did not? I would
posit that adding that single variable alone would shift the
predictions of their models greatly, and reduce false positives.
Without a doubt, the models would be improved. Right now, all those
models lack that variable (except in certain ccTLDs), and a legitimate
domain registrant who has the *desire* to strongly signal their
superior quality or behaviour doesn't have a means to whitelist
themselves via that signal or some other signal.

Sincerely,

George Kirikos
http://www.leap.com/



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy