[gnso-rds-pdp-wg] Principle on Proportionality for "Thin Data"access

[Farell Folly]

+1

All this are interesting...Long away ahead.

Regards
@__f_f__

PhD Candidate, Federal Univsersity of Munich -Germany
Computer Security | Internet of Things
https://www.linkedin.com/in/farellf
________________________________.
Mail sent from my mobile phone. Excuse for brievety.

Le 31 mai 2017 12:43 PM, "allison nixon" <elsakoo at gmail.com> a écrit :

> >>NS information is redundant in "whois", and depending on which whois
> server/system you ask, regularly incorrect
>
> Yes, but the registrar still collects and distributes this data. Defining
> it as PII means that it will not be distributed in any situation, not just
> the unnecessary whois record. Thus completely breaking DNS resolution. If
> attitudes towards privacy are so strong that this is a desired outcome,
> then who am I to get in the way.
>
> the other problems described in your email seem to be more a criticism of
> your registrar than valid reasons why the data needs to be revoked. They
> seem to be a stronger argument for standardizing definitions and forcing
> registrars to adhere. It's also your responsibility to use appropriate
> contact information because spam is going to happen whether you like it or
> not.  This working group is not going to save you from spam. There are
> actual anti-spam people here who have already shared their opinions.
>
> >>If the status is Transfer Prohibited, then yes it does, as they are
> automatically failed by the registry when the gaining registrar sends them.
>
> And something else happens if it is not locked. So this is an option that
> can be inferred by brute force.
>
> >>one-or-more periods of years for most gTLDs, with 2,1,5 being the most
> common at my registrar (in that order)
>
> Again, an easily inferred field. Simply spam the owner every 1 year
> anniversary. Spam costs almost nothing.
>
> On May 31, 2017 2:33 AM, "Rob Golding" <rob.golding at astutium.com> wrote:
>
>> Revoking that data can't stop brute force transfer attempts,
>>>
>>
>> If the status is Transfer Prohibited, then yes it does, as they are
>> automatically failed by the registry when the gaining registrar sends them.
>>
>> It's not about whether a domain needs a status, but whether that status
>> should be "open to the public" rather than restricted to those who need it
>> (registrant via their registrar, authenticated users for specific use
>> cases, etc)
>>
>> Registrars sell domains in precisely 1 year blocks
>>> of time.
>>>
>>
>> one-or-more periods of years for most gTLDs, with 2,1,5 being the most
>> common at my registrar (in that order)
>>
>> Creation date I left off, although it's easy to work out from the changes
>> to the zone files
>>
>> Creation date does (in conjunction with the other data) get abused - I've
>> had over 30 "contacts" from people trying to sell me seo, websites,
>> stationary since registering a variation spelling of a domain on the 19th
>> May (to help those who keep missing out the final "S" when sending an email
>> to me from getting bounces) - 11pm on Monday from an Asian callcentre using
>> a UK voip number (now reported to the TPS) being one of the most intrusive
>> this week.
>>
>> Whilst I can't stop the free pens, adwords vouchers, brochures for
>> radiator valves and other tat coming through the letterbox based on a
>> domain registration, I've even seen _registrars_ doing it :(
>>
>> I didn't forget, but excluded Updated date - in my experience it's wrong
>> at least as much as it's correct -  and my opinion is that data you can't
>> trust does more harm than good
>>
>> From 2 of my domains:
>> 1. Updated Date: 2017-04-11T23:15:07.0Z
>> is correct, as that is when I renewed it
>>
>> 2. Updated Date: 2016-01-09T22:25:53Z
>> is not correct as I changed the nameservers in Dec
>>
>> To me it looks like it only changes the "updated date" when the _dates_
>> on a domain change, not on other types of updates.
>>
>> I actually like the idea of revoking all nameserver data. I like that
>>> idea the more and more I think about it.
>>>
>>
>> NS information is redundant in "whois", and depending on which whois
>> server/system you ask, regularly incorrect - there are a variety of reasons
>> for this, including but not limited to:
>> * registrars don't tidy up
>> * registries aren't realtime
>> * 3rd-party systems cache the data
>> * end-users dont know the difference between whois (service) and "whois"
>> being in the name of a website
>> and so on
>> I've seen domains where Directi WHOIS has said one thing, a Whois website
>> has said another and the actual nameservers were different to both of those
>> on the domain at the registry (plus the actual issue I was diagnosing was
>> that the zone slaved the nameservers off to yet different ns, which is why
>> the A record the client thought should be returned wasn't the IP they were
>> seeing)
>>
>> Use the right tools for the job, and in the case of DNS that's *NOT*
>> whois - we'd be doing a global service to the internet by taking them out
>> of it.
>>
>> SOA data is almost always garbage. 95% of the time I find it useless.
>>>
>>
>> With DNS Zones being mostly automated by hosting control panels, it's
>> "variable" as to what goes in there, and SOAs rarely get updated once
>> created beyond the serial changing, so sadly yes, it's of limited use now
>>
>> Rob
>> _______________________________________________
>> gnso-rds-pdp-wg mailing list
>> gnso-rds-pdp-wg at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170531/96d8d8ed/attachment-0001.html>