GitHub Pages are moving to imtqy.com

Starting today, all GitHub Pages sites are moving to a new domain: imtqy.com. This security measure aims to prevent CSRF attacks on the main server - github.com. If your site is configured as “yoursite.com” instead of “yoursite.github.com”, the changes will not affect you in any way.
If your site used to be located on the domain “username.github.com”, subsequent requests will redirect to the new domain: “username.imtqy.com”.
From now on, all sites hosted on github.com subdomains can and should be regarded as official GitHub products.

Technical details

Changes in sites and user domains:

• All users, organizations, and project sites configured to work with imtqy.com, instead of github.com.
• All sites * .github.com redirect c code 301 to * .imtqy.com.
• Sites with user domains are not affected.
• IP addresses have not changed, existing A-records point to old IPs.

Changes in GitHub repositories:

• User sites can be called using a new or old convention: username / username.github. [Io / com].
• The existing repositories of sites, named under the old agreement, will continue their work.
• If there are two repositories, named according to the old and new agreement, * .imtqy.com will win.

Security vulnerabilities.

There are two main categories of potential vulnerabilities that led to these changes.

• Session and CSRF change. Since user sites can enable JavaScript, which is stored on github.com subdomains, it becomes possible to write (but not read) cookies from the github.com domain, which allows an attacker to access github.com and launch an attack
• Phishing attacks in which the attacker creates a similar site and prompts the user for confidential information.

We have no evidence that such attacks were, however, we tried to prevent them in advance.
Source: github.com/blog/1452-new-github-pages-domain-imtqy.com
')
UPD : In the comments s01o pointed to the post of Yegor Homakov, it tells how it is possible to conduct an attack. As it turned out, it’s possible in WebKit browsers, since they work with cookies in a special way.

So it is arranged in normal browsers:
Cookie:_gh_sess=ORIGINAL; _gh_sess=HACKED;
You have to understand that _gh_sess are two different cookies, despite the name and they are sent at the same time.
In WebKit, the situation is different, cookies are not sent by domain (the first entry should be Domain = github.com) is exactly the same with httpOnly (obviously, they must also be at the beginning).
In fact, they are ordered according to the time of creation (In this place I must be wrong, but this is how it really is)