Stop redirecting to an expired domain or one that fails verification

[jgneff]

Select Topic Area

Product Feedback

Body

I would like to have a way to instruct GitHub to stop redirecting to a domain name that has expired or that fails verification.

When I die, the custom domains defined for my GitHub Pages repositories will eventually expire or be acquired by someone else. At that point, I would like the websites to revert to the location http(s)://<username>.github.io/<repository> instead of the custom domain. GitHub should be able to detect that the domain has expired or that it no longer passes verification.

The only solution for now is to instruct my account's "successor" to remove the custom domain, but for several reasons, I would prefer to have an automated solution to the problem. (My successor could forget, lose the instructions, or die around the same time as I do.)

Thanks,
John

[yoannchaudet]

This is an interesting take. We have a feature in the work to prevent a site from being associated with a custom domain that has not been verified first. This would do what you want as a side effect. It will likely be available to organizations first, but I'll make a note for the user scenario too.

Semi related, here is our policy regarding deceased user (there is more than Pages to consider) https://docs.github.com/en/site-policy/other-site-policies/github-deceased-user-policy.

[jgneff]

Semi related, here is our policy regarding deceased user ...

In fact, a related issue is being able to define an alternate or contingent successor, or even just more than one successor.

Google lets you define up to ten: "You can choose up to 10 people for us to notify if your Google Account becomes inactive. You can also give them access to some of your data" (https://myaccount.google.com/inactive). Furthermore, all of my financial institutions allow me to define one primary beneficiary and one contingent beneficiary.

The problem with just one is that the single successor is usually a spouse or partner, and if a deadly accident happens while traveling, for example, that person is usually with the account holder (and dead, too). A sibling or other family member makes a great contingent successor, but not a very good primary successor.

Should I create this issue as a separate discussion in another category?

Thanks,
John

[yoannchaudet]

You can define one successor today: https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-access-to-your-personal-repositories/maintaining-ownership-continuity-of-your-personal-accounts-repositories.

The recommended path is to grant explicit access to users instead. But if you cannot, you can then select one successor.

If you have some feature request around that specifically, a dedicated post in the General section should do.

[jgneff]

The recommended path is to grant explicit access to users instead. But if you cannot, you can then select one successor.

Do you mean: add the person as a collaborator of one or more of my repositories? If so, I think that might work.

I could add someone as a collaborator to each of my GitHub Pages repositories to act as the "primary" successor (so the CNAME can be removed), and then add another person as the sole account successor to act as a "contingent" successor in case both myself and my collaborator go at the same time.

All a bit morbid, but just planning ahead. 😄

[yoannchaudet]

Do you mean: add the person as a collaborator of one or more of my repositories? If so, I think that might work.

That's how I personally interpreted the doc, but re-reading I think that was my own take.

Honestly that's how I would do it today to go past the 1 successor limit if I had to. I would also go as far as creating collaborator accounts if needed or if I did not want the person to have access to everything just yet. My password manager does support successors for instance.

Nothing wrong with planning!