<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi George,</p>
<p>You're absolutely right. One of my browsers did not resolve to
the bcg.app site. Another of my browsers did resolve and properly
showed the suspension message: "The Domain Name you’ve entered is
not available. It has been taken down as a result of dispute
resolution proceedings pursuant to the Uniform Rapid Suspension
System (URS) or .us Rapid Suspension System (usRS) Procedure and
Rules." <br>
</p>
<p>I think the policy is pretty clear, but the implementation is
definitely lacking. <br>
</p>
<p><i>Staff, could you kindly add this to the list of issues we
should be considered on the URS? </i>Obviously, if a domain
name is suspended, browsers should know.</p>
Tx you, George!
<p>Best, Kathy<br>
</p>
<br>
<div class="moz-cite-prefix">On 6/4/2018 6:54 PM, George Kirikos
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CALAsOBk+SKmrCgkdXBuFovNKcBNRq0t974zq3riLsdokDJSBPA@mail.gmail.com">
<pre wrap="">The first URS case involving a .app domain was decided (in favour of
the complainant), for bcg.app.
<a class="moz-txt-link-freetext" href="http://www.adrforum.com/domaindecisions/1785973D.htm">http://www.adrforum.com/domaindecisions/1785973D.htm</a>
As I predicted earlier in this thread, the technical bug is evident,
as there's no HTTPS page for bcg.app, i.e.
<a class="moz-txt-link-freetext" href="https://bcg.app/">https://bcg.app/</a>
doesn't serve up the suspension page. If one attempts to load the HTTP
version of the page VIA AN OLDER BROWSER (i.e. one that doesn't
observe the HSTS preload list), one can see the standard suspension
page at:
<a class="moz-txt-link-freetext" href="http://bcg.app/">http://bcg.app/</a>
However, for a modern browser (e.g. the latest version of Chrome) that
is enforcing the HSTS preload list which doesn't permit non-HTTPS
pages for .app, the suspension page isn't loading.
The need for either a better policy (one that more clearly requires
both HTTPS and HTTP versions of the suspension page) and/or better
implementation by the URS providers, is evident.
Sincerely,
George Kirikos
416-588-0269
<a class="moz-txt-link-freetext" href="http://www.leap.com/">http://www.leap.com/</a>
On Wed, May 23, 2018 at 3:17 PM, George Kirikos <a class="moz-txt-link-rfc2396E" href="mailto:icann@leap.com"><icann@leap.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Just to followup, according to the search tool at NAF:
<a class="moz-txt-link-freetext" href="http://www.adrforum.com/SearchDecisions">http://www.adrforum.com/SearchDecisions</a>
there are several URS disputes in progress for .app domains, including:
bcg.app
skx.app
oliverwyman.app
skechers.app
We should know relatively soon whether the suspension pages for these
domains (if decided in favour of the complainants) are served via
HTTPS, to be compatible with the HSTS preload setting that Google has
applied to the entire .app TLD.
Sincerely,
George Kirikos
416-588-0269
<a class="moz-txt-link-freetext" href="http://www.leap.com/">http://www.leap.com/</a>
On Thu, May 17, 2018 at 8:31 AM, George Kirikos <a class="moz-txt-link-rfc2396E" href="mailto:icann@leap.com"><icann@leap.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Six days and no replies.....I'll just post the issue here, in the
hopes it gets to the right people (and to highlight the policy issue).
As members of this PDP are aware, after a complainant wins a URS
dispute, the URS provider is supposed to create a suspension page for
the domain name. For example, at 2 of the 3 URS providers (the 3rd
doesn't seem to have any active suspensions at the moment):
MFSD: <a class="moz-txt-link-freetext" href="http://reima.top">http://reima.top</a>
NAF: <a class="moz-txt-link-freetext" href="http://wikipedia.kim">http://wikipedia.kim</a>
However, Google recently launched .app, which has a unique feature,
namely that the entire TLD is on the HSTS preload list:
<a class="moz-txt-link-freetext" href="https://get.app">https://get.app</a>
"The .app top-level domain is included on the HSTS preload list,
making HTTPS required on all connections to .app websites — no
individual HSTS registration or configuration required."
This means that unless the URS providers launch HTTPS versions of
their suspension pages, the HTTP version won't be accessible for .app
domains. Given the relatively high number of .app domains that were
registered already, one would expect .app URS complaints to be
forthcoming.
One can easily check that the 2 URS providers don't appear to be
serving HTTPS versions of their suspension pages at present, see:
MFSD: <a class="moz-txt-link-freetext" href="https://reima.top">https://reima.top</a> (clicking through the SSL warnings takes ones
to a MFSD page)
NAF: <a class="moz-txt-link-freetext" href="https://wikipedia.kim">https://wikipedia.kim</a> (connection refused; presumably their
webserver isn't listening at that port)
As for ICANN policy, the URS Technical Requirements at:
<a class="moz-txt-link-freetext" href="http://newgtlds.icann.org/en/applicants/urs/tech-requirements-17oct13-en.pdf">http://newgtlds.icann.org/en/applicants/urs/tech-requirements-17oct13-en.pdf</a>
merely say, on page 1:
"A URS Suspended domain name will be redirected to a webpage that
mentions that the domain name has been suspended because of a URS
Complaint."
It didn't specify whether the "webpage" should be delivered via HTTP,
or HTTPS, or both. A clearer set of requirements here would have
avoided the issue.
There are likely still a few weeks before the first .app URS complaint
is decided, so sufficient time for a fix. I figure this issue can be
solved for under $20/month, for those who know what they're doing
technically.
By the way, the implementation of suspension pages seems to differ
across providers. e.g. NAF wildcards (*.example.com) the subdomains,
so that:
<a class="moz-txt-link-freetext" href="http://gjkhjhg.wikipedia.kim">http://gjkhjhg.wikipedia.kim</a>
<a class="moz-txt-link-freetext" href="http://anything.wikipedia.kim">http://anything.wikipedia.kim</a>
deliver the page. MFSD only handles the "www" subdomain (and the naked
domain itself). Neither of the 2 handle "internal" pages beyond the
"home" page, e.g.
<a class="moz-txt-link-freetext" href="http://wikipedia.kim/lalala">http://wikipedia.kim/lalala</a> --- 404 error
<a class="moz-txt-link-freetext" href="http://reima.top/lalala">http://reima.top/lalala</a> -- 404 error
With minor configuration changes, those URLs currently serving up a
404 error could instead serve the suspension notice.
Sincerely,
George Kirikos
416-588-0269
<a class="moz-txt-link-freetext" href="http://www.leap.com/">http://www.leap.com/</a>
On Fri, May 11, 2018 at 10:49 PM, George Kirikos <a class="moz-txt-link-rfc2396E" href="mailto:icann@leap.com"><icann@leap.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi folks,
I believe I've uncovered a technical bug in the URS implementation.
Does anyone here know the best method to report it? It might require a
policy change (due to the ambiguity of the policy's requirements on
providers) or updated documentation, as well as implementation changes
by providers, in order to fix it.
The bug isn't manifesting itself at the moment, but is almost certain
to be visible to others in a short time.
Sincerely,
George Kirikos
416-588-0269
<a class="moz-txt-link-freetext" href="http://www.leap.com/">http://www.leap.com/</a>
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">_______________________________________________
gnso-rpm-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gnso-rpm-wg@icann.org">gnso-rpm-wg@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rpm-wg">https://mm.icann.org/mailman/listinfo/gnso-rpm-wg</a></pre>
</blockquote>
<br>
</body>
</html>