PSL's affect on root domain cookies

[Kyle Drake]

Hello! I'm considering doing something unusual with PSL and wanted to chime in and see if there was any feedback about the idea.

I run Neocities (a static web site hosting platform), where we do all of the backend/front site stuff on the root domain (neocities.org), and then host sites on the subdomains (https://distantskies.neocities.org/). The www is a redirect to the root domain that we never expect to use directly, it should forever just be a simple redirect.

I've been considering inclusion into the PSL, because the root domain will -never- require cookies with the subdomains, and I think the additional security would be nice to have.

The concern I have is that I have never seen anyone use the PSL in this way to date, and I'm concerned about cookies not working on the root domain. A cursory inspection of similar hosting services suggests that most choose to operate their own special domain instead of allowing subdomains (github.com using github.io for example), so I've yet to find anyone trying to do this in the wild. With local testing using /etc/hosts, it seems that browsers allow cookies to be set for the root domain when it's a domain in the PSL, but it's possible that there could be unforeseen issues here I'm not aware of.

I've gotten a suggestion to use the www instead of the root domain, but I'd rather not do that, we like to maintain the root / subdomain design, also it's simple to describe to users that we don't manage any of the subdomain sites. I would also not want to change the domain for the users to something like neocities.io, I like the way things are as is. Moving to the www would be preferable to having an io domain, if i was to make a compromise to our arrangement.

Any feedback is welcome here, even if it's just "yes, cookies should work fine go for it".

Cheers,

-Kyle

[Jothan Frakes]

Please read the algorithm and the wiki docs - we're not really set up or resourced to support questions.  If you can in any way avoid requesting an entry, it is preferred, as it is taking this anemic-resourced volunteer-maintained project months - sometimes many of them - to turn around requests.

--
You received this message because you are subscribed to the Google Groups "psl-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to publicsuffix-dis...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/publicsuffix-discuss/42daf1fb-c491-449a-a095-087be8896f8cn%40googlegroups.com.

[Kyle Drake]

Thanks for the feedback, I will read those documents again.

RE resourcing - have there been any discussions on implementing a fee structure to make changes to the list? Most of the organizations that would need entries on this list will have the means to pay for changes to it and would be happy to help resource this important project, reduce the backlog, and throttle the number of junk/spam/scam entry requests. I would love to be the first person to be charged this fee, should we decide to go ahead with an entry request. Thanks

[Jothan Frakes]

We have kept money out of the conversation because payment leads to expectations, and we often have to decline pull requests - so dealing with punitive chargebacks and all the payment hassle stuff was an extra overhead for a number of reasons, not the least of which was dealing with the accounting stuff.

On the one hand, you're willing to throw some money at this, but wouldn't sentiment change if that were related to the review and not the guarantee of being added?  

-J

Jothan Frakes
Tel: +1.206-355-0230

To view this discussion on the web, visit https://groups.google.com/d/msgid/publicsuffix-discuss/bf49af4f-6f7c-4e02-96ca-453ec03683e9n%40googlegroups.com.

[Jothan Frakes]

I am not sure the fee should be refundable - the review work is not trivial and often the heaviest work comes from the ones that likely may not pass - back and forth dialog from inexperience, entitlement/challenging personalities, non-responsive etc.

All your comments are appreciated.

On Tue, Jan 30, 2024 at 7:59 AM Kyle Drake <kyle...@gmail.com> wrote:

If the fee was sufficiently high (one time $250-500?), I think it would be a sufficient filter that most non-serious proposals would go away, and the orgs that really need to be on this list would get on it. It would be pretty easy to just refund the amount if the proposal was rejected, and I don't think it would have to happen very often. Could be as simple as a Stripe form and a single member LLC that files as a schedule c with a 1099-k every year if one person wanted to own that maintenance.

I'm sure someone will gawk at this idea/amount but look at the legitimate users of the PSL.. Google, Github, root domains that fork over $500k to ICANN, governments that spend $25k on hammers, web hosting services for third parties (Neocities, Netlify, etc), cloud hosting proxies for consumer NAS, et cetera, which more often than not will be running their own BGP and IPs to deal with abuse complaints (our ARIN annual renewal alone is $600/yr). Let's be honest here, any organization that can't afford a Valentine's Day dinner for 2 probably shouldn't be hosting content for untrustable third parties, and probably shouldn't be on this list. Users of this list are going to be high value orgs that have the means to pay for its maintenance, and I do think it is a privilege to be added to this list that comes with at least the responsibility of supporting its maintenance.

There's a lot of low grade junk and dead sites on the list as-is, which may also need to be dealt with after their domains expire and the new domain owners discover their subdomain cookies don't work, and every single browser on the planet gets a performance hit sifting through that extra junk every time a request is made. Then you get the opportunists coming in and trying to use PSL to scam something (I'm going to avoid reading how that works this morning because it sounds headache inducing to me)

Aside from just being a really nice filter to keep maintenance time reasonable and reduce junk, the maintainer(s?) of this list are hard working professionals that deserve to be compensated for their time spent on it. I've long been an advocate for removing the "free beer" component of free software, especially when dealing almost exclusively with organizations that have the means to support that.

There is certainly a possibility that the browser people will push back on the idea, but I think given the alternative of having to maintain the list themselves with overworked staff and deal with all the crap just so they can punch down on an OSS maintainer, they would instead appreciate the increase in speed and quality and go along with the change, rather than fork it into an unmaintainable mess. But if they did do that, I also think it would be fine for y'all to just say "you know what forget it, I'm done sacrificing my valuable time" and move on. It would be nice if browser orgs contributed to maintenance here too, but I don't see an easy way to incentivize that for them, it seems easiest to just schedule fees for changes to the list itself.

Not trying to start a revolution here or tell anyone what to do, just adding my thoughts, and of course it's easier to write an email than actually implement any of this, but I hope this at least lays some support down and some arguments here for that support. Cheers!

[Kyle Drake]

I did not realize the extent of the extra work involved and my proposal was mostly just for "click merge button" workflow, so my opinion on fees is doubly so now. I would say then to just charge up front for the labor of doing those reviews, and I still think this will reduce the amount of "may not pass" requests. In my experience, chargebacks are rare and the consequences of them are low (a $20 fine at worst, which would be more than covered by legit entries, of which there would probably be more). They are also able to be challenged, so if someone does issue one you can submit ample evidence that they are paying for the labor of the review, not necessarily the inclusion into a list, and you will probably win those disputes. RE attitudes, you'd be surprised how much more friendly, engaged and professional people are when they have to pay for things vs getting them for "free". I'll leave the hypothesizing on that one to the psychologists.

Fraud risk I think would be low too.. not worth a fraudster's time to use a stolen card to pay for entry of a scam site if inclusion time is months or years in the future.. you could remove their entry long before it would be added to any browsers, and after a few months payments can no longer be charged back.

[Kyle Drake]

If the fee was sufficiently high (one time $250-500?), I think it would be a sufficient filter that most non-serious proposals would go away, and the orgs that really need to be on this list would get on it. It would be pretty easy to just refund the amount if the proposal was rejected, and I don't think it would have to happen very often. Could be as simple as a Stripe form and a single member LLC that files as a schedule c with a 1099-k every year if one person wanted to own that maintenance.

I'm sure someone will gawk at this idea/amount but look at the legitimate users of the PSL.. Google, Github, root domains that fork over $500k to ICANN, governments that spend $25k on hammers, web hosting services for third parties (Neocities, Netlify, etc), cloud hosting proxies for consumer NAS, et cetera, which more often than not will be running their own BGP and IPs to deal with abuse complaints (our ARIN annual renewal alone is $600/yr). Let's be honest here, any organization that can't afford a Valentine's Day dinner for 2 probably shouldn't be hosting content for untrustable third parties, and probably shouldn't be on this list. Users of this list are going to be high value orgs that have the means to pay for its maintenance, and I do think it is a privilege to be added to this list that comes with at least the responsibility of supporting its maintenance.

There's a lot of low grade junk and dead sites on the list as-is, which may also need to be dealt with after their domains expire and the new domain owners discover their subdomain cookies don't work, and every single browser on the planet gets a performance hit sifting through that extra junk every time a request is made. Then you get the opportunists coming in and trying to use PSL to scam something (I'm going to avoid reading how that works this morning because it sounds headache inducing to me)

Aside from just being a really nice filter to keep maintenance time reasonable and reduce junk, the maintainer(s?) of this list are hard working professionals that deserve to be compensated for their time spent on it. I've long been an advocate for removing the "free beer" component of free software, especially when dealing almost exclusively with organizations that have the means to support that.

There is certainly a possibility that the browser people will push back on the idea, but I think given the alternative of having to maintain the list themselves with overworked staff and deal with all the crap just so they can punch down on an OSS maintainer, they would instead appreciate the increase in speed and quality and go along with the change, rather than fork it into an unmaintainable mess. But if they did do that, I also think it would be fine for y'all to just say "you know what forget it, I'm done sacrificing my valuable time" and move on. It would be nice if browser orgs contributed to maintenance here too, but I don't see an easy way to incentivize that for them, it seems easiest to just schedule fees for changes to the list itself.

Not trying to start a revolution here or tell anyone what to do, just adding my thoughts, and of course it's easier to write an email than actually implement any of this, but I hope this at least lays some support down and some arguments here for that support. Cheers!

On Tue, Jan 30, 2024 at 8:13 AM Jothan Frakes <jot...@jothan.com> wrote:

[Jothan Frakes]

On Tue, Jan 30, 2024 at 8:59 AM Kyle Drake <kyle...@gmail.com> wrote:

I did not realize the extent of the extra work involved and my proposal was mostly just for "click merge button" workflow,

to god's ears were it that simple

 

so my opinion on fees is doubly so now. I would say then to just charge up front for the labor of doing those reviews, and I still think this will reduce the amount of "may not pass" requests. In my experience, chargebacks are rare and the consequences of them are low (a $20 fine at worst, which would be more than covered by legit entries, of which there would probably be more). They are also able to be challenged, so if someone does issue one you can submit ample evidence that they are paying for the labor of the review, not necessarily the inclusion into a list, and you will probably win those disputes. RE attitudes, you'd be surprised how much more friendly, engaged and professional people are when they have to pay for things vs getting them for "free". I'll leave the hypothesizing on that one to the psychologists.

Fraud risk I think would be low too.. not worth a fraudster's time to use a stolen card to pay for entry of a scam site if inclusion time is months or years in the future.. you could remove their entry long before it would be added to any browsers, and after a few months payments can no longer be charged back.

Blue skies where you live, I see.   Fraudsters gonna fraud... and unless the payment is connected to the entry, it is likely that the use of stolen card to request some illegitimate entries to bypass google safe or other things that might consider slower action in situations of phishing - the more delayed takedown happens the longer the perp's criminal acts nourish them.  

This is where 'registry' type system would be beneficial - connecting the payment to the ongoing listing - if fraud is reported after the fact on a card used to include one or more strings, those strings just get removed automagically vs us having to yet again do a manual review process to pluck their entries.

The situation of chargebacks can occur at any point after a successful purchase - it is designed so that someone reviewing their credit card statement at a later point in time, perhaps 60 to even 90 days after their statement, can challenge a line item.  

[Frank Dana (FeRD)]

On Tuesday, January 30, 2024 at 9:13:11 AM UTC-5 Jothan Frakes wrote:

We have kept money out of the conversation because payment leads to expectations,

I think that's the most important point. The moment you start charging a fee for something, you're no longer working on a project, you're running a business — with all of the complexities and requirements that implies. Even if the fee is a one-time token amount, the equation doesn't really change.

There's payment processing to put in place; fee structures to define, product/service descriptions to write (when someone pays for something, you're expected to tell them exactly what they'll receive in exchange for their money, and customers — you have customers now, not users! — can be expected to get litigious if they feel they've been underserved); you likely need to incorporate, so that there's an entity which can hold the funds collected and protect the individuals involved; that leads to a need for things like corporate governance and financial statements to document where it goes; etc, etc, etc...

Oh, and of course there's the most vexing aspect — the shift in relationship. As soon as someone is paying for something, they're no longer prepared to take "no" for an answer. Being told they're "not allowed" to have what they ask for, or having their submission "denied"/"rejected", goes over much worse with many people if it was accompanied by a payment. (Even if it's refundable. When you tell someone you won't take their money to do what they want, they're liable to start throwing around accusations like "discrimination!" and "unfair business practices!". Because you're running a business.)

[Jothan Frakes]

Difficult balance; in a perfect world, all things internet would not have cost, but the equipment and people etc layers around keeping it all going should not be presumed to have zero cost to support that 

In other fora, there are request fees or filing fees, and then application fees - so regardless of outcome, the filing/request costs can be covered, because in a lot of cases, this is where a large amount of the work is - there are a lot of people that submit deficient or non-complying requests that require people time and iterative dialog.  There are also a lot of people that set/forget or are just experimenting vs those that have bonafide need for entries.

There are areas where automation is possible to help reduce human time costs, but the internet seems to always deliver and stay two steps ahead of automation in re-inventing improved novices and edge-cases in response to automation, which then requires humans once more to untangle it.

-Jothan

--
You received this message because you are subscribed to the Google Groups "psl-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to publicsuffix-dis...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/publicsuffix-discuss/600206cb-5970-455d-a366-0ae444640e4bn%40googlegroups.com.

[Simon Friedberger]

I assume you found it by now, but cookies will indeed not work on a public suffix. I don't immediately see why it couldn't be handled as a separate domain but that's not how browsers currently work.