feat: reorganise for cloud content

docs/background/_category_.yml

@@ -0,0 +1,5 @@
+---
+label: Background Topics
+position: 30
+link:
+  type: "generated-index"

docs/background/collateral.mdx

@@ -0,0 +1,33 @@
+---
+title: Collateral Freedom
+sidebar_position: 10
+---
+
+Collateral freedom is an anti-censorship strategy that attempts to make it **economically prohibitive** for censors to
+block a resource.
+The diverse needs of businesses to exchange information across international borders makes it impossible to build a
+catalogue of "good" and "bad" networks or websites.
+A censor requires some confidence when they block a resource that it won't be affecting economic activity.
+It’s difficult to achieve accuracy with filtering as most internet traffic is encrypted and must be categorised
+at speed to make blocking decisions.
+As a result, censors will usually err on the side of under-blocking.
+
+One way to exploit this is by deploying solutions in large platforms that are **“too big to block”**, like public cloud
+providers.
+Public cloud providers host large numbers of clients in shared infrastructure to benefit from economies of scale, but
+this sharing also makes it difficult to know what content is being accessed.
+Similarly, large social networks host content from large numbers of publishers but all traffic between the user and the
+social network is typically encrypted and so the censor cannot know what is being read.
+Blocking the cloud provider would have a negative impact on businesses and would hurt state revenue, and blocking the
+social media platform would cause backlash from the people: neither is an attractive option for the censor.
+
+Another approach is to use constantly rotating identifiers, as even where a resource may be easy to block once
+identified, a new resource can be deployed quickly to replace it rendering the blocks ineffective.
+Due to erring on the side of under-blocking, attempts to access previously unseen content usually succeed.
+Even with a procedure for screening or approval, blocking by default would bog down innovation and development to the
+extent that it could cease, certainly falling behind other economies.
+This approach is particularly suited for news media where the majority of readers will be interested in an article for
+only a short time after it is published, and if it is later blocked by the censor then the effect will be minimal.
+
+With collateral freedom on your side **you can have the upper hand** when it comes to making your content accessible to
+your audience.

docs/index.md

@@ -1,10 +1,10 @@
 ---
 sidebar_position: 1
-sidebar_label: Overview
+sidebar_label: Welcome
 ---
 
 # Documentation Overview
 
 :::warning[Under construction]
-This documentation is a work in progress. Please [get in touch with us](mailto:help@cdr.link) if you have any questions.
-:::
+This documentation is a work in progress. Please [get in touch with us](mailto:contact@sr2.uk) if you have any questions.
+:::

docs/link/hosted.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 5
+sidebar_position: 50
 ---
 
 # Hosted CDR Link FAQ

docs/link/index.mdx

@@ -0,0 +1,15 @@
+---
+sidebar_position: 1
+sidebar_label: Link Helpdesk
+---
+
+import DocCardList from '@theme/DocCardList';
+import {useCurrentSidebarCategory} from '@docusaurus/theme-common';
+
+# Documentation Overview
+
+:::warning[Under construction]
+This documentation is a work in progress. Please [get in touch with us](mailto:contact@sr2.uk) if you have any questions.
+:::
+
+<DocCardList items={useCurrentSidebarCategory().items.slice(1)} />

docs/mirrors/index.mdx

@@ -0,0 +1,26 @@
+---
+title: Web Mirrors
+sidebar_position: 20
+---
+
+A web mirror can help users by providing alternate URLs to access censored resources, allowing them to bypass censorship
+and access information that may be otherwise blocked.
+Web mirrors work by forwarding requests to the original website, and providing a different URL to access that content.
+
+Dynamic web mirrors use frequently changing URLs to evade censorship, making it more difficult for censors to maintain
+blocks for the content.
+This assumption of a limited lifetime is built-in to the system, allowing for automated block detection to trigger the
+deployment of new URLs, and for the new URLs to be made available via the portal, the API, and via dead drops.
+
+Named web mirrors use alternative domain names with limited distribution to evade censorship.
+By blending with the "long tail" of web traffic, it may take longer for these mirrors to be discovered.
+
+Web mirrors can be accessed via a normal web browser, making them easily accessible to users without requiring any
+special software or technical knowledge.
+
+<figure style={{"text-align": "center"}}>
+    <img src="/img/mirrors/overview.png" style={{"max-width": "100%", "max-height": "500px"}} />
+    <figcaption style={{"font-weight": "bold"}}>
+        The jasima.app portal overview for web mirrors
+    </figcaption>
+</figure>

docs/mirrors/troubleshooting.mdx

@@ -0,0 +1,32 @@
+---
+title: Troubleshooting
+sidebar_position: 100
+---
+
+We have collected solutions to common issued faced by web mirrors users.
+If you are unable to resolve your issue, please [get in touch](/contact) with us to discuss the options.
+
+## Upstream Rate Limiting
+
+CDNs (Content Delivery Networks) can impose rate limiting or "bot detection" on websites to ensure that the network
+resources are efficiently utilized, to protect the websites from Denial of Service (DoS) attacks, and to
+maintain the quality of service for all the websites using the CDN.
+If you find that mirrors are producing many “Rate Limited Exceeded” or “Access Denied” errors then you may be suffering
+from this problem.
+
+These rate limits will be sized according to the expected rate of requests from an average user, however the mirror
+system is a bottleneck that aggregates requests from multiple users and passes these on to the original CDN.
+When a single system is used to send a large number of requests to a CDN like this, the CDN may interpret this as a
+DoS attack and prevent access to the website.
+
+The optimal approach is to configure the origin to use an alternative host for connections, so that the CDN is bypassed
+and the backend origin (web server) is used directly.
+The mirror will still be the access point for users and this will not reveal the location of the backend origin to your
+users.
+
+If this is not possible, then deploying mirrors for websites hosted on CDNs will require either configuration at, or
+co-operation from, the CDN provider.
+Additional headers can be configured for the origin to authenticate requests that originate from jasima.app, and these
+can be used to bypass the protection mechanisms at your CDN.
+Consult your CDN's documentation or contact their support team to configure using an additional header to disable the
+rate limiting for requests originating from jasima.app.