<div dir="ltr">Thank you Andrew, because you have articulated this problem in a much better way than I could have. Reputation systems are a fundamental part of the ability to connect to the Internet.<div><br></div><div>re:Jeremy Malcolm's email:</div><div><br></div><div>You are describing the current patchwork of reputation systems that exist today, and no one disputes that they are optional. However, the optionality here is on the part of the network that the domain owner wants to reach- a network that is a 3rd party to the entire registrar <-> registrant relationship, and the registrant gets no say. Those networks would be, for example corporate networks at banks or large email providers like Gmail. And if you are an operator of Internet infrastructure, you would be very concerned about what those reputation systems think of you. Like so many mean girls in highschool, they can all very quickly decide they don't want to talk to you.</div><div><br></div><div>I'm going to mention some specific examples that anyone here can replicate on their own, and these are all connectivity problems that legitimate users will experience from reputation systems:</div><div><ul><li>Fire up Tor, and try to visit any website. Chances are, it will demand a captcha or block you entirely. </li><li>From Tor, try to register a new Gmail/Twitter/Facebook account. Then, from your home IP, register a new account. One asks for SMS verification, and might just block you, while the other does not. </li><li>Register a new domain, configure everything perfectly to the technical specs, host the mailserver on your own machine, and try to send email from it to any Yahoo, Gmail, or corporate e-mail address.</li><li>Use any e-mail address to try to strike up a conversation relating to male enhancing medications, or certain opiates, and depending on specific phrasing, it won't make it past the spam filter. Especially on gmail.</li><li>Register a new domain on any TLDs widely regarded as malicious, like .XYZ or .science, host a regular website there, and in the first month of that domain's lifespan, see if anyone from different corporate networks can reach your website in their browsers</li><li>Purchase hosting space to host a legitimate website from any hosting provided regarded as a "bad" hoster, like Cyberbunker or Ecatel. See how many people from corporate networks can reach you in their browsers, or receive mail from you</li></ul><div>If you are a domain holder and website administrator, you cannot opt-out of this. Some blacklist operators will allow you to request removal, but they can refuse and often do if the IP or domain is still spamming. Other blacklist operators do not allow you to request removal, because you weren't specifically blocked, but the confluence of datapoints from your infrastructure resulted in the block.</div></div><div><br></div><div>None of this is happening out of a deep seated hatred of privacy, or a bizarre desire to censor discussions about specific medications. They are the direct result of the abuse problem. </div><div><br></div><div>And the abuse problem is so bad, it actually affects the value of these domains and IP ranges. It's part of normal practice to perform due-dilligence on domains or IP ranges under consideration for purchase- specifically reputation due-dilligence. If these reputation systems have a material impact on the value of these goods, and are a significant factor in their connectivity to the Internet, then we should take notice.</div><div><br></div><div>Also, w/r/t your example with Let's Encrypt, some blocking systems use their company name itself in the cert as a negative factor, especially if the domain itself has strings belonging to commonly phished brands. It's Let's Encrypt's prerogative to take that approach, but their reputation is mud now. </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 29, 2017 at 1:47 PM, Jeremy Malcolm <span dir="ltr"><<a href="mailto:jmalcolm@eff.org" target="_blank">jmalcolm@eff.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 29/9/17 10:29 am, Andrew Sullivan wrote:<br>
> So, we can't treat reputation service support as something that's nice<br>
> to have. It's necessary for the functioning of domain names on the<br>
> Internet, and therefore we must provide for it.<br>
<br>
</span>Interesting argument, but not convincing to me. The reputation systems<br>
that I'm aware of *are* optional to support. Some mail providers<br>
subscribe to certain blocklists that others don't, some search engines,<br>
browsers, and browser plugins will flag particular domains that others<br>
don't, and so on. In the similar context of certificate authorities<br>
that issue SSL certificates for domains, Let's Encrypt (which EFF is a<br>
sponsor of) is often asked to refuse to issue certificates for<br>
particular domains based on reputation, but has decided that that's not<br>
part of its job. Consider the domain <a href="http://amazonaws.com" rel="noreferrer" target="_blank">amazonaws.com</a>, which host millions<br>
of Amazon S3 buckets. There's a lot of phishing content stored under<br>
that domain from time to time, but assigning a bad reputation to the<br>
registered owner of <a href="http://amazonaws.com" rel="noreferrer" target="_blank">amazonaws.com</a> would be pointless and cause lots of<br>
collateral damage. It hardly seems that it's an essential part of the<br>
domain name system to be able to do that.<br>
<br>
--<br>
Jeremy Malcolm<br>
Senior Global Policy Analyst<br>
Electronic Frontier Foundation<br>
<a href="https://eff.org" rel="noreferrer" target="_blank">https://eff.org</a><br>
<a href="mailto:jmalcolm@eff.org">jmalcolm@eff.org</a><br>
<br>
Tel: <a href="tel:415.436.9333%20ext%20161" value="+14154369333">415.436.9333 ext 161</a><br>
<br>
:: Defending Your Rights in the Digital World ::<br>
<br>
Public key: <a href="https://www.eff.org/files/2016/11/27/key_jmalcolm.txt" rel="noreferrer" target="_blank">https://www.eff.org/files/<wbr>2016/11/27/key_jmalcolm.txt</a><br>
PGP fingerprint: 75D2 4C0D 35EA EA2F 8CA8 8F79 4911 EC4A EDDF 1122<br>
<br>
<br>
<br>______________________________<wbr>_________________<br>
gnso-rds-pdp-wg mailing list<br>
<a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">_________________________________<br>Note to self: Pillage BEFORE burning.</div>
</div>