Add hop.sh

[Phineas]

• Description of Organization

• Reason for PSL Inclusion

• DNS verification via dig

• Run Syntax Checker (make test)

• Each domain listed in the PRIVATE section has and shall maintain at least two years remaining on registration, and we shall keep the _PSL txt record in place in the respective zone(s) in the affected section

Submitter affirms the following:

• We are listing any third-party limits that we seek to work around in our rationale such as those between IOS 14.5+ and Facebook (see Issue #1245 as a well-documented example)

• This request was not submitted with the objective of working around other third-party limits
• The Guidelines were carefully read and understood, and this request conforms
• The submission follows the guidelines on formatting and sorting

---

For Private section requests that are submitting entries for domains that match their organization website's primary domain, please understand that this can have impacts that may not match the desired outcome and take a long time to rollback, if at all.

To ensure that requested changes are entirely intentional, make sure that you read the affectation and propagation expectations, that you understand them, and confirm this understanding.

PR Rollbacks have lower priority, and the volunteers are unable to control when or if browsers or other parties using the PSL will refresh or update.

(Link: about propagation/expectations)

• Yes, I understand. I could break my organization's website cookies etc. and the rollback timing, etc is acceptable. Proceed.

---

Description of Organization

Hop allows developers to deploy Docker images & applications directly from GitHub. Once deployed, customers can attach a "gateway" to expose their deployment to the internet - when they do this, we assign a free .hop.sh domain to them. Customers can also add custom domains, but for smaller projects, developers often opt to use the free .hop.sh domains instead.

Organization Website:
https://hop.io

Reason for PSL Inclusion

• We issue LetsEncrypt certificates for our customers
• We want our customers' sites to be isolated for other customers (cookies, suffix highlighting, etc)

Number of users this request is being made to serve: 2000+

DNS Verification via dig

dig +short TXT _psl.hop.sh
"https://github.com/publicsuffix/list/pull/1612"

Results of Syntax Checker (make test)

============================================================================
Testsuite summary for libpsl 0.21.1
============================================================================
# TOTAL: 5
# PASS:  5
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================```

[Phineas]

Apologies for the bump, but it's been almost a year. Over 1m users are hitting these domains now. @dnsguru

[Phineas]

The entire .hop.sh domain got flagged by Google Safebrowsing as phishing, in turn flagging thousands of websites which use the hop.sh subdomain. Please could this PR be looked at!

[dnsguru]

The entire .hop.sh domain got flagged by Google Safebrowsing as phishing, in turn flagging thousands of websites which use the hop.sh subdomain. Please could this PR be looked at!

If a browser flags a security issue indicating there is phishing activity, there is likely evidenced phishing activity that earned it being flagged.

If the point is being made that the volunteers processing this sooner would have minimized the impact of the flag to the offending subdomain and avoided the browser determining the submitted base eTLD+ as an unsafe namespace, how is this really a compelling argument for volunteers, who are donating their time to this project, to expedite a PR that enables any phishing?

[Phineas]

The entire .hop.sh domain got flagged by Google Safebrowsing as phishing, in turn flagging thousands of websites which use the hop.sh subdomain. Please could this PR be looked at!

If a browser flags a security issue indicating there is phishing activity, there is likely evidenced phishing activity that earned it being flagged.

If the point is being made that the volunteers processing this sooner would have minimized the impact of the flag to the offending subdomain and avoided the browser determining the submitted base eTLD+ as an unsafe namespace, how is this really a compelling argument for volunteers, who are donating their time to this project, to expedite a PR that enables any phishing?

Fair observation, however...

• Google provided us with a list of subdomains which supposedly contained "phishing"; none of which did
• Google doesn't flag entire TLDs as unsafe. Even if a subdomain of .hop.sh contained phishing, Google would still flag that individual subdomain as risky (if they honor the PSL), so:
• Approving this entry into the PSL wouldn't enable phishing, it'd just protect other entities within this namespace from being incorrectly flagged when there's one bad actor
• ICANN-delegated TLDs also house many bad actors, and the process to report some of those domains are usually long-winded and convoluted. We have a pretty fast (<1 day) turnaround time once we discover bad actors within our platform.

[robertt]

Hop customer here — even though I don't directly use hop.sh for my website, this issue is still affecting my users because my website makes a request to my API, which uses a hop.sh subdomain. The notice pops up for users when the request is made. Frustrating for every party.

[Phineas]

Google Safebrowsing just flagged us again. I don't think it's fair that all of our competitors are gracefully added to the PSL without question while we have to wait over a year and suffer consequences.

(and yes, Google Core libraries use the PSL to parse TLDs: https://github.com/google/guava/wiki/InternetDomainNameExplained)

[dnsguru]

PSL is not intended for use to bypass security safeguards - or to infer any security. it is a catalog. That said, riskier stuff may sometimes take longer to review.

Is there an assertion being made here that hop.sh (now blocked multiple times by google safe browsing due to some cause which is typically abuse) platform is somehow a victim of some form of competitive favoritism? I get you might have feels but that's a message that contains a bit of a microagression.

We're just volunteers and there is a queue ahead of this request. We have flagged this as requiring further security review once you notified us about the prior situation where the domain was similarly flagged by google - and we are awaiting any volunteer in the security community to weigh in and comment that it does not have risks and can proceed.

[simon-friedberger]

• hop.sh expires 2024-06-01
• DNS _psl entries
• Tests pass
• Sorting according to guidelines
• Reasoning/Organization description

[simon-friedberger]

If possible, please provide a non-personal email address.

[dnsguru]

Given the amount of times this namespace has experienced gating by safe browsing, the PR was flagged with security review - the main concern being that abusive activity that earns itself the joy of the red screen seems to be impacted by an entry in the PSL - it seems to alter the computations of bad actor tallies so that an entire domain is not nerfed. The concerns raised by security folk is that with such browser safety initiatives needing to take prompt action to safeguard users, namespaces that get added to the PSL will buy themselves extended operation of campaigns if requested by bad actors.

This is more a meta-coversation - there is no suggestion that the hop.sh namespace is a bad namespace or a good namespace, only that some bad actors found a way to get it onto the safe browsing list.

Even absent the safe browsing friction, requests must have an expiration date at least 2 years from now to approve this pull request.

Registry shows it expires in under three months.
Registry Expiry Date: 2024-06-01T15:32:32Z

[dnsguru]

@simon-friedberger I removed the approval until we see the name is extended out at least 2 years.

[dnsguru]

Just checking with NameCheap - they allow for up to 9 year renewals so this is not a situation whereby the TLD registry or registrar disallows the name to be extended further. Extending the name would provide some indicia of non-ephemoral existence to the requested namespace, especially given its dance with safe browsing

[simon-friedberger]

@Phineas Any updates?