[Gnso-ppsai-pdp-wg] For review - updated templates Cat B, questions 1 and 2
Volker Greimann
vgreimann at key-systems.net
Fri Feb 28 19:37:39 UTC 2014
Hi John,
> Sure, happy to clarify, and also provide a few comments in response to
> yours. I think re-verification actually does serve a purpose.
>
> One of the questions before the group is whether "ICANN-accredited
> privacy/proxy service providers (should) be required to conduct
> periodic checks to ensure accuracy of customer contact information;
> and if so, how?" There has been some argument that criminals always
> falsify their Whois information, and therefore re-verification in
> general is pointless because criminals would lie anyway. My first
> point is that that isn't true: rather, it depends on the type of
> criminal activity in question. So, to the extent that's being used as
> an argument against re-verification (or, for that matter, against
> verification), it shouldn't be.
This may very well be the case but I do not follow how re-verification
of already verified data will help anyone. The result will in all
likelyhood be the same.
>
> My second point is that there is value in re-verification or periodic
> checks. Let me offer some thoughts on the value of re-verification at
> some intervals.
>
> * First -- and certainly let me know if I'm wrong on this, since I
> think you helped negotiate the 2013 RAA and surely are more
> familiar with it than I am! -- I think it's fair to say that the
> Registrar's verification requirement as specified in the *Whois
> Accuracy Program Specification
> <http://www.icann.org/en/resources/registrars/raa/approved-with-specs-27jun13-en.htm#whois-accuracy>*
> doesn't constitute comprehensive verification of all fields. That
> is, most of the verification requirements pertain to the format of
> the data, with additional verification that the email and
> telephone numbers are responsive correlated with the registrant.
> One of the questions before the group is whether P/P entities
> should engage in the same level of verification, or some different
> level. Reasonable minds can differ on this, but some members of
> this group have suggested an additional level of verification.
>
First of all, it is: email _or_ telephone! This mistake is often made
when quoting the obligation, so I feel I have to correct it to prevent
this from spreading. ;-).
Second, there is no real difference between the underlying data of the
registrant with a p/p service and the public data with a registrar. If
anything the quality of the hidden data is usually better than the
public data. I fail to see why it would need to be treated differently.
> * Second, addresses can change over time: people and businesses
> move, and they may forget to update their registration data.
> Re-verification serves to highlight cases where the contact
> information has changed and, even if not malicious, is no longer
> accurate. (So, although data can't become "more accurate" as you
> point out, it can certainly become "more inaccurate" over time.)
>
Not updating outdated data is a violation of the registration agreement
and can lead to the suspension or deletion of the domain name. For this
reason, registrars are required to inform registrants annually about the
data they have on file and request the data is checked. And I would
suggest that enforcement of such "outdated whois" violations usually
hits legitimate registrants more than illegitimate ones.
> * Third, I would also assume (as you do) that verification and
> re-verification will need to be heavily automated, and to the
> extent that external data sets (for example, here in the US,
> postal data) are used to help highlight -- for example --
> non-existent addresses or inaccurate correlations, those external
> data sets are likely being improved or updated over time. So, if
> errors or inaccurate data aren't caught in the first round,
> re-verification may catch them simply due to the verification
> tools being improved, or the underlying data being updated, over
> time.
>
Currently, all that is required under the RAA is sanity checks of
address data (is the format correct) and trigger-response verification
of either email or phone address. ICANN has not provided access to any
international database that could be used for data checks. But even
then, such checks would not ever be able to differentiate between stolen
data and accurate data.
> * Fourth, in an ideal world, the verification process used by
> Registrars would catch 100% of inaccuracies, but that probably
> won't be the real-world result. Additional and periodic
> re-verification by P/P providers provides another layer of assurance.
>
Actually, the checks that return false positives worry me more, because
those cause real work, customer confusion, etc. Any "solution" resulting
in a significant amount of false positives is simply unacceptable.
>
> * Fifth, as to the problem of inaccurate correlations with real data
> (what you correctly refer to as "the data is accurate, but
> stolen") I would concur that this might present more of a
> challenge, but I don't think I'd agree that the inaccurate
> correlation wouldn't ever be uncovered, depending upon the
> verification algorithm and approach. We actually do look for this
> in our ongoing monitoring and have seen instances of inaccurate
> correlations but with real data.
>
The only way it can be uncovered it the good old "hey, what is my data
doing there" complaint (and we get one of those from time to time). And
that requires no verification whatsoever, that only requires someone
googling his name and finding the whois record.
>
> I think that those are some arguments in favor of why re-verification
> by the P/P provider has merit at periodic intervals. I think there's a
> reasonable question of whether the Registrar's verification of the
> email and phone number should be sufficient for those portions of the
> P/P service provider's verification process within a limited time
> frame after the Registrar's verification occurs. (Perhaps that
> eliminates some redundancy.)
I do not follow these arguments. Re-verification will just add costs,
confusion and annoyance to an already cumbersome process and will bring
no benefits. Please note that I am specifically excluding from the term
re-verification those cases where the registrar is compelled to recheck
because of notifications or positive knowledge of incorrect or outdated
data.
Volker
>
> On Fri, Feb 28, 2014 at 3:29 AM, Volker Greimann
> <vgreimann at key-systems.net <mailto:vgreimann at key-systems.net>> wrote:
>
> Hi John,
>
> I am having a bit of a hard time understanding your point here.
>
> You are describing three different cases here, two of which will
> not benefit from verification in the least bit and one might, but
> only in some cases:
>
> a) The data is accurate, but stolen: Here verification would not
> uncover any issues with the data as it is essentially correct and
> will most likely be identified as accurate.
> b) The data is false: Here, depending on the methods used, the
> inaccuracy may be uncovered and would lead to an automated request
> to provide updated data or deactivation after a set time.
> Remember, in order to keep providing services in a sensible
> manner, this needs to be automated in some form, i.e. no
> individual record would likely see any manual review.
> c) The data is already accurate: If the data is already correct,
> what purpose does verification fulfill? The data cannot become
> more accurate. Verification in this case seems like an exercise in
> self-gratification.
>
> That said, even if there is a benefit to be derived from
> verification, such benefits are achieved once verification
> concludes. Re-verification of already verified data fulfills no
> purpose whatsoever. So if a set of data has already been verified
> by the registrar, there is no need for the p/p provider to again
> verify the same data. Only if no verification is or can be
> performed on the registrar level does verification by providers
> come into play.
>
> Volker
>
> Am 28.02.2014 00:32, schrieb John Horton:
>> Thanks, Marika. I also wanted to provide a comment pertaining to
>> Question 2 in the attachments (relating to periodic checks).
>>
>> In a few of the recent discussions, there's been some reference
>> to criminals always or nearly always being untruthful in their
>> Whois records (even if privacy-protected), leading to the
>> conclusion that there is little purpose in having a registrar or
>> any third party have to verify or re-verify the information
>> (especially if it is difficult to prove that the data is
>> falsified). I wanted to share our experience and observations on
>> that point, in the hope that it's relevant to future discussion
>> regarding Question 2.
>>
>> Our consistent observation has been that when it comes to a
>> particular sub-category of criminal activity, spam, phishing,
>> malware, and so forth, it's probably safe to say that that
>> statement is true -- the registrant's Whois information is nearly
>> always inaccurate. Even in cases, such as some where we've worked
>> with law enforcement, when the Whois record for a domain name
>> involved in spam, phishing or malware is privacy-protected and is
>> subsequently unmasked, the Whois record is still not accurate
>> behind the privacy curtain. There are probably exceptions, but
>> that's what we've seen well over 95% of the time. On occasion,
>> it's a real address and phone number, just not one genuinely
>> connected to the registrant.
>>
>> But there are other types of criminal activity where the Whois
>> record is not so regularly obfuscated. For example, we
>> investigate a lot of websites selling tainted dietary supplements
>> that end up containing some toxin or adulterant that harms
>> people. In those cases, we've overwhelmingly seen that even if
>> the Whois record is privacy-protected, the trend is that the
>> underlying Whois record is accurate. The same has been true for
>> illegal or counterfeit medical device websites that we've
>> researched. On illegal Internet pharmacies not engaged in spam,
>> it's probably 50-50. (It might be a shell corporation, but that's
>> still valuable information.)
>>
>> One important point to consider is that the Whois registration
>> can be relevant information from a banking perspective for
>> commercial entities. That is, some banks are going to look at an
>> online merchant's domain name registration record and if it's
>> either inaccurate or protected, they may require disclosure, or
>> ask about any discrepancy, which can be an incentive for
>> criminals selling products online who nevertheless want to get
>> paid via credit card to have an accurate Whois. Hackers, malware
>> providers and spammers will find a way around that, but they
>> don't necessarily constitute "most" criminal activity.
>>
>> The point here is, I think verification can still be a useful and
>> necessary tool in either scenario, even if it doesn't uncover
>> useful information a portion of the time. I realize that only
>> pertains to a portion of the issues related to Question 2, but I
>> hope that our observations on that are relevant.
>>
>> Thanks,
>>
>> John Horton
>> President, LegitScript
>>
>>
>> *FollowLegitScript*: LinkedIn
>> <http://www.linkedin.com/company/legitscript-com> | Facebook
>> <https://www.facebook.com/LegitScript> | Twitter
>> <https://twitter.com/legitscript> | YouTube
>> <https://www.youtube.com/user/LegitScript> | _Blog
>> <http://blog.legitscript.com>_ |Google+
>> <https://plus.google.com/112436813474708014933/posts>
>>
>>
>>
>> On Wed, Feb 26, 2014 at 2:39 AM, Marika Konings
>> <marika.konings at icann.org <mailto:marika.konings at icann.org>> wrote:
>>
>> Dear All,
>>
>> Following our call yesterday, please find attached the
>> updated templates for Category B -- questions 1 & 2. Please
>> review these templates to make sure the WG discussions have
>> been accurately reflected and feel free to share any comments
>> / edits you may have with the mailing list. We've created a
>> page on the wiki where we'll post the templates that have
>> been finalised for now (noting that for some of these the WG
>> will need to come back to the template at a later date), see
>> https://community.icann.org/x/ihLRAg.
>>
>> The WG will continue its deliberations on Category B --
>> Question 2 next week. Some of the questions that came up
>> during the conversation yesterday and which you are
>> encouraged to share your views on (and/or add additional
>> questions that need to be considered in this context) are:
>>
>> * What would be the arguments for not using the same
>> standards / requirements for validation and verification
>> as per the 2013 RAA?
>> * Should there be a requirement for re-verification, and if
>> so, what instances would trigger such re-verification?
>> * In case of affliction between the P/P service and the
>> registrar, if the registration information has already
>> been verified by the registrar, should this exempt the
>> P/P provider from doing so?
>> * Should the same requirements apply to privacy and proxy
>> services or is there a reason to distinguish between the two?
>>
>> Best regards,
>>
>> Marika
>>
>> _______________________________________________
>> Gnso-ppsai-pdp-wg mailing list
>> Gnso-ppsai-pdp-wg at icann.org <mailto:Gnso-ppsai-pdp-wg at icann.org>
>> https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg
>>
>>
>>
>>
>> _______________________________________________
>> Gnso-ppsai-pdp-wg mailing list
>> Gnso-ppsai-pdp-wg at icann.org <mailto:Gnso-ppsai-pdp-wg at icann.org>
>> https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg
>
> --
> Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
>
> Mit freundlichen Grüßen,
>
> Volker A. Greimann
> - Rechtsabteilung -
>
> Key-Systems GmbH
> Im Oberen Werk 1
> 66386 St. Ingbert
> Tel.:+49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
> Fax.:+49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
> Email:vgreimann at key-systems.net <mailto:vgreimann at key-systems.net>
>
> Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net>
> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
>
> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
> www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
>
> Geschäftsführer: Alexander Siffrin
> Handelsregister Nr.: HR B 18835 - Saarbruecken
> Umsatzsteuer ID.: DE211006534
>
> Member of the KEYDRIVE GROUP
> www.keydrive.lu <http://www.keydrive.lu>
>
> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
>
> --------------------------------------------
>
> Should you have any further questions, please do not hesitate to contact us.
>
> Best regards,
>
> Volker A. Greimann
> - legal department -
>
> Key-Systems GmbH
> Im Oberen Werk 1
> 66386 St. Ingbert
> Tel.:+49 (0) 6894 - 9396 901 <tel:%2B49%20%280%29%206894%20-%209396%20901>
> Fax.:+49 (0) 6894 - 9396 851 <tel:%2B49%20%280%29%206894%20-%209396%20851>
> Email:vgreimann at key-systems.net <mailto:vgreimann at key-systems.net>
>
> Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net>
> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
>
> Follow us on Twitter or join our fan community on Facebook and stay updated:
> www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
>
> CEO: Alexander Siffrin
> Registration No.: HR B 18835 - Saarbruecken
> V.A.T. ID.: DE211006534
>
> Member of the KEYDRIVE GROUP
> www.keydrive.lu <http://www.keydrive.lu>
>
> This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
>
>
>
>
> _______________________________________________
> Gnso-ppsai-pdp-wg mailing list
> Gnso-ppsai-pdp-wg at icann.org <mailto:Gnso-ppsai-pdp-wg at icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg
>
>
--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann at key-systems.net
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems
www.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann at key-systems.net
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems
www.twitter.com/key_systems
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/attachments/20140228/bfdc76c8/attachment-0001.html>
More information about the Gnso-ppsai-pdp-wg
mailing list