GitHub Pages move to github.io

Starting today, all GitHub Pages sites are moving to the new domain: github.io. 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.
If your site was previously located on the domain "username.github.com", subsequent requests will be redirected to the new domain: "username.github.io".
From now on, all sites hosted on the github.com subdomains can and should be regarded as official GitHub products.

Technical details

Changes to sites and user domains:

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

Changes in GitHub repositories:

• User sites can be called using the new or old agreement: username / username.github. [Io / com].
• Existing site repositories named after the old agreement will continue their work.
• If there are two repositories named by the old and the new agreement - * .github.io will win.

Security vulnerabilities.

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

• Change Sessions and CSRF. Since user sites can attach JavaScript stored on the github.com subdomains, it is possible to write (but not read) cookies from the github.com domain, which allows an attacker to access github.com and carry out an attack
• Phishing attacks in which an attacker creates a similar site and requests confidential information from the user.

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-github-io

UPD : In the comments s01o pointed to the post of Yegor Khomakov, it tells how all the same you can carry out an attack. As it turned out, it’s possible in WebKit browsers, since they work with cookies in a special way.

So it works 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) exactly the same with httpOnly (obviously, they should also be at the beginning).
In fact, they are ordered by creation time (In this place I should be wrong, but this is how it really is)