Live data from Hacker News

Google Domains blocking all Gitbook URLS: post-mortem

blog.gitbook.com

111–120 of 189 posts

Re: Google Domains blocking all Gitbook URLS: post-mortem

#111

Earlier quoted context omitted.

In the postmortem it states that they are moving to Cloudflare

ahh yes, the more ethical choice to move to well known hosters of DDoS protection for white supremacist sites and literal nazis. Why not move to a company that is just a domain registrar.

I thought Cloudflare was more about saying "we were wrong to try to be the world's speech police, and will never again bow to public pressure and take away DDOS from literal Nazis" and then taking down 8chan and other literal Nazis anyway because of public pressure.

Re: Google Domains blocking all Gitbook URLS: post-mortem

#112
post #86

Earlier quoted context omitted.

Why not stick to the topic at hand, rather than trying to hijack the discussion?

The topic at hand is where to move a domain out to, and whether said company is one that can be relied upon to act ethically and responsibly. I don't see the difference.

[deleted]

Re: Google Domains blocking all Gitbook URLS: post-mortem

#113
> sent to an e-mail address on a domain they had just suspended...

I've always assumed that:

1. When creating your account at the registrar you should use an email address that is not at any domain you will be registering through or transferring to them,

2. The contact information you give for your WHOIS records (or if using a WHOIS privacy guard service, the contact information you give them to forward to) should use an email address at a different domain,

3. If you use a DNS provider other than your registrar the contact email address they have for you should not be a domain using them for DNS, and

4. Same for whatever hosts your email.

The general principle is that the contact method that a service provider will use to contact you if there is a problem with your account or service with them should not depend on the account being in good standing and the service working.

Re: Google Domains blocking all Gitbook URLS: post-mortem

#114
Aside from the Google domain issue (which is obviously a problem) -- why on earth would GitBook be hosting user-generated content under their corporate gitbook.com domain?

The registrar issue is one problem here -- but I don't see this addressed in their post-mortem. I thought this was a well-known issue. You don't host user-generated content on the same domain that handles your corporate email. Because things like this can and do happen, so you want to make sure that your company isn't also down while you're busy fixing a problem with your customers.

I know the exposure risks are different, but isn't this is one of the reasons why Github moved hosting Github Pages content to github.io from their primary github.com site? Or why raw data is hosted from githubusercontent.com (in addition to mitigating cookie security issues).

The registrar was an issue that was largely out of their hands. But this was something that they could control. And I think it's something that is missing from their post-mortem. If they had split their domains, then while serving user-content was disrupted, accepting users to gitbook.com and their email (!?!?) would have still been working. Also, depending on if they had a 3rd domain for hosting their CDN, users that had custom domains would also have been protected.This goes along with the idea that you don't use email from your primary domain (cto@gitbook.com) to register your domain (gitbook.com). Or host your status page on the same infrastructure as your site.

If I were them, after migrating registrars, this would be the next engineering change I'd make.

(Maybe they do this, I don't know enough about GitBook to know. But based on the thread here, I don't think they do, or at least it isn't mentioned in their post-mortem that I saw.)

Re: Google Domains blocking all Gitbook URLS: post-mortem

#116

Aside from the Google domain issue (which is obviously a problem) -- why on earth would GitBook be hosting user-generated content under their corporate gitbook.com domain? The registrar issue is one problem here -- but I don't see this addressed in their post-mortem. I thought this was a well-known issue. You don't host user-generated content on the same domain that handles your corporate email. Because things like t…

Where do you draw the line? I mean github.com is the corporate email domain of the GitHub company, it also hosts repositories (user generated content)

Re: Google Domains blocking all Gitbook URLS: post-mortem

#117
post #116

Aside from the Google domain issue (which is obviously a problem) -- why on earth would GitBook be hosting user-generated content under their corporate gitbook.com domain? The registrar issue is one problem here -- but I don't see this addressed in their post-mortem. I thought this was a well-known issue. You don't host user-generated content on the same domain that handles your corporate email. Because things like t…

Where do you draw the line? I mean github.com is the corporate email domain of the GitHub company, it also hosts repositories (user generated content)

But not for any binary content as uploaded by the user, that's served from raw.githubusercontent.com.

Re: Google Domains blocking all Gitbook URLS: post-mortem

#118
post #116

Aside from the Google domain issue (which is obviously a problem) -- why on earth would GitBook be hosting user-generated content under their corporate gitbook.com domain? The registrar issue is one problem here -- but I don't see this addressed in their post-mortem. I thought this was a well-known issue. You don't host user-generated content on the same domain that handles your corporate email. Because things like t…

Where do you draw the line? I mean github.com is the corporate email domain of the GitHub company, it also hosts repositories (user generated content)

But it isn't... directly.

Github.com is their corporate site, hosts their application, and is how we all interact with repositories (via https or git://). But, the only data you get from that site has been processed through their application and sanitized.

The only way to get access to the raw user-generated data is through raw.githubusercontent.com or Github Pages which hosted on github.io. And the data from raw.githubusercontent.com has the MIME types set so that you don't get HTML rendered -- only the raw plaintext (I think).

So, in this specific example, if there was someone hosting a phishing site in a github account, it would have been active only through github.io, not the main github.com site. (You could have likely seen the source code from the main site, but it would not have actually generated an HTML form).

For historical views, here is the Github blog post that details the change (2013): https://github.blog/2013-04-05-new-github-pages-domain-githu...

Re: Google Domains blocking all Gitbook URLS: post-mortem

#119

Aside from the Google domain issue (which is obviously a problem) -- why on earth would GitBook be hosting user-generated content under their corporate gitbook.com domain? The registrar issue is one problem here -- but I don't see this addressed in their post-mortem. I thought this was a well-known issue. You don't host user-generated content on the same domain that handles your corporate email. Because things like t…

Assumingly because GitBook didn't expect Google to be so reckless and tone-deaf.

Re: Google Domains blocking all Gitbook URLS: post-mortem

#120
post #116

Earlier quoted context omitted.

Where do you draw the line? I mean github.com is the corporate email domain of the GitHub company, it also hosts repositories (user generated content)

But not for any binary content as uploaded by the user, that's served from raw.githubusercontent.com.

I'm aware, but I could just as easily see a lesser registrar getting confused by an abuse report and suspending github.com because it embeds content from githubusercontent.com.
Post reply on HN