Add domains from afraid.org (ddns) to PSL

[josmers]

As discussed for other ddns providers (https://github.com/publicsuffix/list/pull/64) please add the domains listed by http://freedns.afraid.org/domain/registry/. As the raw list contains over 85000 entries, this is a much greater effort than adding the fewer noip domains. Hopefully this serves the purpose of the PSL and taking the automation discussion further.

Cheers, Jan

[gerv]

@josmers : I assume you are an official representative of afraid.org?

[josmers]

@gerv , I'm sorry I'm not an official representative. I'm just an ordinary user of the services offered. If I can help somehow please let me know. I'm happy to support in this case if possible.

[ghost]

I sent a mail to the owner of afraid.org, hopefully he will stop by and do what's necessary.

Afraid.org hosts dns many public domains that are not owned by him, but hopefully he can add at least the ones he owns.

[ghost]

I talked to the owner and admin of afraid.org. He mentioned but there's a automated list of all domain hosted on afraid.org that are public 1 but he is not interested in helping any further.

So unless PSL owners are willing to make an exception and add the public domain list without the site owner's verification (which would also require scraping the page, because there's no API or export, AFAIK), the 84,884 public dynamic dns domains hosted by afraid.org will never get added to PSL and thus never be available for Let's Encrypt certificates.

EDIT: adding at least the first ten most popular dynamic DNS domains would be really nice, because they count for 1,067,751 public hosts / subdomains.

[nistvan86]

Any chance of moving this forward? Maybe if someone writes a scraper to extract the domains? I would really love to use my homenet.org address with letsencrypt.

[weppos]

Unfortunately, I have to close this issue as for the others that were opened. As per our guidelines, only the owner can request the inclusion.

Moreover, as the intent is to get into Let's Encrypt, this is not the right channel. You should use https://letsencrypt.org/docs/rate-limits/

[josmers]

Sadly to hear you closed this issue. For me this is the remarkable issue along several others that all has been closed, too. Actually the other linked issues just requested to add a few domains. This one is more general.

I understand you guidelines. The point is totally valid. Second, Let's Encrypt is off topic of cause. Their "Rate-Limit" has nothing to do with this issue. Moreover it is not even a workaround as the described procedures are for domain owners only.

When I wrote "Hopefully this serves the purpose of the PSL and taking the automation discussion further." I was talking about the process of adding domains in general. As we see the PSL guidelines does not work for ddns providers. This limit PSL growth. It renders the project unusable for most users of ddns services. We are talking about figures with five to six trailing zeros just in the case of afraid.org not including all other ddns providers. And be sure there are some around. Is this not your scope? @ghost proposal mitigates the problem but offers no solution. Don't you have to rework your guidlines as you want something from domain owners that are never involved in this process?

[weppos]

@josmers the domain owner is the sole responsible for the domain and its uses, from the POV of the PSL. It could not be otherwise.

There are implications on being on the list, and someone needs to understand them and grant an explicit authorization for the domain. That entity can only be the domain owner.

This is a very common model in several other services, such as requesting an SSL certificate, authorizing a domain transfer, etc. Users can't be authorized to take decisions on behalf of a domain owner, no matter how many users the domain/service has. It's like asking us to include (for eg.) facebook.com only because you are a user of the service and you need it to be in the list.

If the service you are using doesn't satisfy your needs, simply change service, instead of pretending to have us to consider unauthorized requests. I'm sorry, but we are not going to change this decision.

[kirviq]

@weppos how do I trigger a discussion about the guidelines?

The PSL is used for security critical stuff like third party cookies or ssl certificate granting. So there are also implications for not being on the list.

Imagine someone had a subdomain called veryprivatestuff.chickenkiller.com (everybody can register it at afraid.org) and uses tomcat. The sessionid will be stored in a cookie called JSESSIONID. Someone else has a subdomain somephonyclickbaiting.chickenkiller.com that tracks all JSESSIONID cookies and does bad things at veryprivatestuff.chickenkiller.com.

I argue that having a suffix too few is worse than having a suffix too much. Everyone should be able to request adding a public suffix by showing a way how to register a subdomain of it. The owner-privilege should only be needed for registering an exception. Especially because the disadvantages of having one too few are on the side of the users that can't do anything about it and the disadvantages of having too many are on the side of the owners that can prove ovnership and request an exception.

[weppos]

@kirviq I'm very aware of the implications of what could happen if the domain is not in the list. However, as I already mentioned, you are missing a fundamental point: if you don't want to have that problem, simply use a service that is not affected.

As I already explained, only the owner is granted the privilege of this decision. This is a conscious choice.

Again, let me emphasize it one more time: if you are concerned about the security implications of using one of these domains, simply use a different service where the domain owner asked to be included in the list.

[kirviq]

@weppos well, that doesn't exactly answer my question. But I assume the answer is "you can't".

The problem I have with this is, that this deals a serious blow to free, innovative services. The service provider (who built it in his free time and does not earn any money) has no clue if the free domain service he's using has registered is suffix. The end-user who uses a browser to access this service has even less clue if his service provider was willing to pay for a domain provider that registered his public suffix.

If this is intentional, I would love to have this stated somewhere on https://publicsuffix.org/ instead of 'Avoid privacy-damaging "supercookies"' and 'Highlight the most important part of a domain name'.

[sleevi]

It's prominently documented in https://publicsuffix.org/submit/

[kirviq]

"prominently"

Let's be honest, we can count ourselves lucky if the service provider I mentioned finds https://publicsuffix.org, much less the link to submit. We can be sure no end-user will ever read it and even more sure that no end-user will understand the security risk this imposes for him.

That's why I'm asking why the policy is as it is and where the reasoning for it is documented.

[sleevi]

@kirviq For sake of discussion, no, the policy requiring domain owners authorization will not change. As @weppos mentioned, if your domain owner has not requested addition to the PSL, you should consider migrating to another service.

At this point, there's nothing further to be had with discussion. The "Why" is largely irrelevant, because it's clear your goal with the "why" is not to understand, but to change the "why". The "why" could be as simple as "This is what we decided, so that's that" - and you'd no doubt be unhappy, but it'd be an answer. The "Why" could be extremely nuanced and detailed, but at the end of the day, you'd still be unhappy if the policy would not change.

The policy of requiring the domain owner to authorize the request is the policy we've decided for managing the PSL in a way that is open, vendor-neutral, and respect the rights of the domain holders, and it's not going to change. If you're unhappy with that, you should contact your domain provider or find a new one.

[kirviq]

it's clear your goal with the "why" is not to understand, but to change the "why"

Yes. That was my goal. Because I think the internet would be better that way.

as simple as "This is what we decided, so that's that" - and you'd no doubt be unhappy

I accept that. And I am.

extremely nuanced and detailed, but at the end of the day, you'd still be unhappy

I like to think of myself as being open to reason. I can't guarantee that the reasons would convince me. After all I failed to imagine a reasoning with this outcome.

But that is your choice. My consequence is that I need a better authority when it comes to privacy. Not only about my domain provider, but also about my policy as an end-user. (meaning my plugin to block third-party-content)