SamyPesse

This is not what we meant. We will be accountable and will post a complete post-mortem. But it’s important to understand that the attack was a lot more developed than what we’ve been used to with humans, especially in terms of pace and adaptability.

We’ll provide details in a long post-mortem. For now, it was important to notify our users as early as possible.

I’m genuinely sorry the end of friendco.de impacted you. It was 12-13 years ago; the service had little usage at the time, and we probably didn’t handle the end perfectly. I don’t recall exactly, but I can assure you that the team today is more experienced.

GitBook’s CTO here

We have been dealing with a security attack since yesterday. Our team has been all hands on deck since the start, and we took a large portion of our services offline to prioritize user security.

Our service is progressively coming back online (most of it already is), and we are actively monitoring the situation.

We’ll continue to actively keep our users updated through emails, Slack, and our status page as we monitor the situation and learn more.

Yes LLMs are an amazing technological breakthrough for knowledge base and document solutions.

You have a good understanding of what we are doing :)

With snippets:

* You can save Slack thread as a new document in GitBook; the document will be generated by a LLM (it's not a plain dump of the messages).

* You can record your work on VS Code (+ audio), and we'll translate it as a document (snippet)

With Insights:

* We analyze content (we have customers with more than 10000 pages in their docs) and identify contradictions or duplicate

* We don't auto-fix them yet, but it's planned ;)

With AI Search:

* We leverage LLM and a vector database to provide complete answers with sources to natural language questions

Today I’m proud to introduce the public alpha of GitBook Lens — a new semantic search tool powered by AI.

Lens indexes the content of documentations hosted on the platform, and provides an interface to ask questions. It’ll scan your documentation and give you a simple, semantic answer using OpenAI — with clickable references if you want to dive deeper.

While Lens is in open alpha, anyone can activate it at no extra cost.

We also provide an API to integrate GitBook Lens in your website / application.

We only remove the domain from Cloudflare when the content is deleted. The main reason is to avoid broken links when users update their domain on GitBook.

Ex: 1. You configure docs.mycompany.com with your GitBook space 2. You share links to docs.mycompany.com on social medias 3. You update the domain to docs.anothercompany.com 4. It's better if the docs.mycompany.com links can continue working until you remove the DNS entry

In summary, we want the users to decide through their DNS config when GitBook should serve the content or not to avoid breaking links without an intentional action from the user.

Unfortunately, because of how Cloudflare doesn't use the DNS configuration to decide where to route the traffic, it causes issues atm. We'll look at what we can do on our side to mitigate this.

GitBook CEO, here.

We use Cloudflare to serve HTTPS traffic for all custom hostnames configured by our users.

When a user configures a custom hostname, they point their DNS via CNAME to one of our domains (which, at the end of the chain points to Cloudflare). We then request Cloudflare (using their Cloudflare for SaaS product) to generate an SSL certificate for this hostname and serve the traffic properly.

When users move away from GitBook, they often don't remove their content from GitBook and only change the DNS on their side. We don't request to remove the hostname from Cloudflare for SaaS until the content is deleted from GitBook, as the goal is to avoid breaking links for URLs that are still pointing to GitBook.

We'd expect Cloudflare to always use the DNS setup of the domain as the primary factor for deciding where to route the traffic.

We don't know the rationale behind why Cloudflare routing continues internally routing the traffic to GitBook when the domain is no longer pointing to the GitBook hostname. But it is not us doing that intentionally.

Our support can help unblock this situation by manually removing this domain from our Cloudflare for SaaS. You can reach out at [email protected].

We don't host user content under the gitbook.com, or at least we've stopped doing it a few years ago.

User content is stored under *.gitbook.io, similar to GitHub.

Google blocked all domains that contained "gitbook" in our account, even ones that are used for some infrastructure and are not accessible by the public. We don't know the exact reason for this, maybe they've blocked gitbook.com because we still have some redirect for content that was hosted under it years ago.

And yes we are going to make changes to host our status page under another domain.