Merge branch 'develop' into feature/migrate-hub-subscriptions-to-api

Author: tobihagemann

assets/js/hubpricing.js

@@ -6,23 +6,43 @@ class HubPricing {
     this._data = data;
   }
 
-  loadPrice() {
+  loadPrices() {
     $.ajax({
       url: PADDLE_PRICES_URL,
       dataType: 'jsonp',
       data: {
-        product_ids: `${PADDLE_HUB_SELF_HOSTED_YEARLY_PLAN_ID},${PADDLE_HUB_MANAGED_YEARLY_PLAN_ID}`
+        product_ids: `${PADDLE_HUB_SELF_HOSTED_YEARLY_PLAN_ID},${PADDLE_HUB_SELF_HOSTED_MONTHLY_PLAN_ID},${PADDLE_HUB_MANAGED_YEARLY_PLAN_ID},${PADDLE_HUB_MANAGED_MONTHLY_PLAN_ID}`
       },
     }).done(data => {
-      this._data.selfHostedMonthlyPrice = {
-        amount: data.response.products[0].subscription.price.net / 12,
-        currency: data.response.products[0].currency
-      };
-      this._data.managedMonthlyPrice = {
-        amount: data.response.products[1].subscription.price.net / 12,
-        currency: data.response.products[1].currency
-      };
+      const priceMap = {};
+      data.response.products.forEach(p => {
+        priceMap[p.product_id] = {
+          amount: p.subscription.price.net,
+          currency: p.currency
+        };
+      });
+
+      this._assignPrice(priceMap, PADDLE_HUB_SELF_HOSTED_YEARLY_PLAN_ID, 'selfHostedYearlyPrice', 12);
+      this._assignPrice(priceMap, PADDLE_HUB_SELF_HOSTED_MONTHLY_PLAN_ID, 'selfHostedMonthlyPrice', 1);
+      this._assignPrice(priceMap, PADDLE_HUB_MANAGED_YEARLY_PLAN_ID, 'managedYearlyPrice', 12);
+      this._assignPrice(priceMap, PADDLE_HUB_MANAGED_MONTHLY_PLAN_ID, 'managedMonthlyPrice', 1);
+
+      const mYearly = priceMap[PADDLE_HUB_MANAGED_YEARLY_PLAN_ID];
+      const mMonthly = priceMap[PADDLE_HUB_MANAGED_MONTHLY_PLAN_ID];
+      if (mYearly && mMonthly) {
+        this._data.savingsPercent = Math.max(0, Math.round((1 - mYearly.amount / (mMonthly.amount * 12)) * 100));
+      }
     });
   }
 
+  _assignPrice(priceMap, planId, dataKey, divisor) {
+    const price = priceMap[planId];
+    if (price) {
+      this._data[dataKey] = {
+        amount: price.amount / divisor,
+        currency: price.currency
+      };
+    }
+  }
+
 }

assets/js/hubsetup.js

@@ -428,7 +428,7 @@ EOF`;
         'init-config': {condition: 'service_completed_successfully'},
         'postgres': {condition: 'service_healthy'}
       },
-      image: 'ghcr.io/cryptomator/keycloak:26.5.2',
+      image: 'ghcr.io/cryptomator/keycloak:26.5.4',
       command: startCmd,
       volumes: ['kc-config:/opt/keycloak/data/import'],
       deploy: {
@@ -799,7 +799,7 @@ class KubernetesConfigBuilder extends ConfigBuilder {
             }],
             containers: [{
               name: 'keycloak',
-              image: 'ghcr.io/cryptomator/keycloak:26.5.2',
+              image: 'ghcr.io/cryptomator/keycloak:26.5.4',
               command: startCmd,
               ports: [{containerPort: 8080}],
               resources: {

content/blog/2026-02-01-digital-independence-day-2026.de.md

@@ -2,7 +2,6 @@
 title: "Digital Independence Day: Warum digitale Unabhängigkeit wichtig ist"
 slug: digital-independence-day-2026
 date: 2026-02-01
-notice: 
 tags: [cryptomator, did]
 
 summary: "Der Digital Independence Day zeigt, warum digitale Selbstbestimmung wichtig ist und wie man mit kleinen, alltagstauglichen Schritten – etwa durch bewusste Tool-Wahl und Verschlüsselung – mehr Kontrolle über die eigenen Daten gewinnt."

content/blog/2026-02-01-digital-independence-day-2026.en.md

@@ -2,7 +2,6 @@
 title: "Digital Independence Day: Why Digital Independence Is Important "
 slug: digital-independence-day-2026
 date: 2026-02-01
-notice: 
 tags: [cryptomator, did]
 
 summary: "Digital Independence Day highlights why digital self-determination matters and how small, everyday actions — like choosing privacy-friendly tools and encrypting your data — can help you regain control over your digital life."

content/blog/2026-02-15-bitlocker-fbi-and-the-illusion-of-control.de.md

@@ -0,0 +1,117 @@
+---
+title: "BitLocker, FBI und die Illusion von Kontrolle"
+slug: bitlocker-fbi-und-die-illusion-von-kontrolle
+date: 2026-02-15
+tags: [cryptomator, microsoft, bitlocker]
+
+summary: "Microsoft half dem FBI, BitLocker-verschlüsselte Geräte zu entschlüsseln – nicht durch eine Hintertür, sondern über in der Cloud gesicherte Recovery Keys. Was das über Schlüsselkontrolle, Cloud-Vertrauen und echte Datensouveränität verrät."
+
+ogimage:
+  relsrc: /img/blog/microsoft-bitlocker.png
+  width: 1200
+  height: 675
+---
+
+Als kürzlich bekannt wurde, dass **Microsoft dem FBI dabei geholfen hat, mit BitLocker verschlüsselte Datenträger zu entschlüsseln**, war die Empörung groß. Schnell war von „Hintertüren“ die Rede, von gebrochener Verschlüsselung und davon, dass man sich auf BitLocker offenbar nicht verlassen könne. Doch wie so oft liegt das **eigentliche Problem** weniger in der Technik selbst, sondern darin, **wer die Kontrolle über den Recovery-Key hat.**
+
+Dieser Fall ist ein guter Anlass, genauer hinzusehen: Was ist wirklich passiert? Warum war der Zugriff möglich? Und was sagt das über **unser Verständnis von Verschlüsselung und Cloud-Diensten aus**?
+
+<figure class="text-center">
+  <img class="inline-block rounded-sm" src="/img/blog/microsoft-bitlocker.png" alt="BitLocker, FBI und die Illusion von Kontrolle" />
+</figure>
+
+## Was ist passiert?
+
+In dem bekannt gewordenen Fall ging es um einen **strafrechtlichen Ermittlungsfall**, bei dem das FBI mehrere Laptops sicherstellte. Diese Geräte waren mit **BitLocker** verschlüsselt – **der in Windows integrierten Festplattenverschlüsselung.**
+
+Das FBI konnte die Daten dennoch entschlüsseln, **weil Microsoft die zugehörigen Recovery Keys bereitstellen konnte**. Diese Schlüssel waren im **Microsoft-Account der betroffenen Person gespeichert**. Mit richterlicher Anordnung war Microsoft rechtlich verpflichtet, diese Informationen herauszugeben.
+
+Wichtig ist dabei eine klare Einordnung: **Microsoft hat BitLocker nicht „geknackt“**. Es gab keine Sicherheitslücke, keinen geheimen Generalschlüssel und keinen technischen Hintereingriff in die Verschlüsselung selbst. **Microsoft konnte helfen, weil sie im Besitz der Schlüssel waren.**
+
+## BitLocker ist sicher – aber nicht automatisch privat
+
+BitLocker gilt technisch als **solide Verschlüsselungslösung**. Die Daten auf einem Gerät sind ohne den passenden Schlüssel nicht lesbar. Das Problem entsteht nicht bei der Verschlüsselung, sondern beim **Schlüsselmanagement**.
+
+Standardmäßig bietet Windows an, **den BitLocker-Recovery-Key im Microsoft-Konto zu sichern**. Das ist bequem, denn wenn man das Passwort vergisst oder die Hardware wechselt, kann man den Schlüssel einfach online abrufen.
+
+**Diese Bequemlichkeit hat jedoch eine Konsequenz**: Liegt der Schlüssel bei Microsoft, hat Microsoft auch die Möglichkeit, ihn weiterzugeben – etwa an Strafverfolgungsbehörden mit entsprechendem Beschluss.
+
+Verschlüsselung schützt Daten also nur dann vollständig vor Dritten, wenn der Schlüssel ausschließlich unter der Kontrolle der Nutzer:innen bleibt.
+
+## Das eigentliche Missverständnis: Verschlüsselung ≠ Schlüsselkontrolle
+
+Viele Nutzer:innen setzen Verschlüsselung mit vollständiger Kontrolle gleich. In der Praxis ist das jedoch oft nicht der Fall.
+
+Man kann grob unterscheiden zwischen:
+
+- **Client-seitiger Verschlüsselung mit externer Schlüsselverwaltung**. Das bedeutet, dass der Anbieter Zugriff auf den Schlüssel hat.
+- **Zero-Knowledge-Verschlüsselung**. Hier hat der Anbieter technisch keinen Zugang zum Schlüssel.
+
+BitLocker mit Cloud-gesichertem Recovery-Key fällt klar in die erste Kategorie. **Die Daten sind verschlüsselt, aber nicht ausschließlich für den Eigentümer.**
+
+**Der Microsoft-Fall zeigt damit kein Versagen von BitLocker**, sondern **ein strukturelles Problem moderner Cloud-Ökosysteme**. Komfortfunktionen untergraben oft unbemerkt die eigene Datensouveränität.
+
+## Warum viele überrascht sind
+
+Die starke Reaktion auf den Fall zeigt vor allem eines: **Viele Menschen wissen nicht, wo ihre Verschlüsselungsschlüssel gespeichert sind.**
+
+Cloud-Backups, automatische Synchronisationen und voreingestellte Sicherheitsoptionen sind heute Standard. Sie senken die Einstiegshürde, erhöhen die Benutzerfreundlichkeit und verschieben Verantwortung stillschweigend vom Nutzer zum Anbieter.
+
+Das führt zu einer **trügerischen Annahme**:
+
+> *„Meine Daten sind verschlüsselt, also kann niemand darauf zugreifen.“*
+
+Technisch korrekt wäre eher:
+
+> *„Meine Daten sind verschlüsselt, aber jemand anderes verwahrt den Ersatzschlüssel.“*
+
+## Behördenzugriff ist kein Sonderfall
+
+Ein weiterer wichtiger Punkt: **Der Zugriff durch Behörden ist kein außergewöhnliches Szenario.**
+
+Wenn Anbieter Zugriff auf Schlüssel oder unverschlüsselte Daten haben, sind sie in vielen Ländern **gesetzlich verpflichtet**, diese bei entsprechender Anordnung herauszugeben. **Das betrifft nicht nur Microsoft, sondern ebenso andere große Cloud-Anbieter.**
+
+Die entscheidende Frage lautet daher nicht:
+
+> *„Vertraue ich Microsoft?“*
+
+Sondern:
+
+> *„Will ich einem Anbieter technisch die Möglichkeit geben, meine Daten zu entschlüsseln?“*
+
+## Was Nutzer:innen daraus lernen können
+
+**Der Fall bietet eine wertvolle Lehre** – unabhängig vom konkreten Produkt:
+
+- Verschlüsselung ist nur so stark wie das Key-Management
+- Cloud-Backups von Schlüsseln bedeuten immer einen Kontrollverlust
+- Sicherheit ist keine Standardeinstellung, sondern eine bewusste Entscheidung
+- Wer maximale Privatsphäre möchte, muss auch Verantwortung für Schlüssel übernehmen
+
+**Das bedeutet nicht, dass Cloud-Dienste grundsätzlich unsicher sind**. Aber es bedeutet, dass man verstehen sollte, welches Sicherheitsmodell man nutzt und welche Kompromisse damit einhergehen.
+
+## Wie Cryptomator in solchen Fällen hilft: Zero-Knowledge statt Schlüsselhinterlegung
+
+Genau an diesem Punkt setzen Lösungen wie **Cryptomator und Cryptomator Hub** an. Im Gegensatz zu vielen integrierten Verschlüsselungsfunktionen verfolgt Cryptomator konsequent ein **Zero-Knowledge-Prinzip**.
+
+Das bedeutet, dass die Daten **lokal auf dem Gerät verschlüsselt werden**, bevor sie überhaupt in eine Cloud hochgeladen werden können. Der entscheidende Unterschied liegt dabei im Schlüsselmanagement. **Cryptomator speichert nämlich keine Passwörter, keine Recovery-Keys und keine Master Keys.**
+
+Weder Cloud-Anbieter noch Cryptomator selbst haben technisch Zugriff auf die verschlüsselten Inhalte oder die dafür notwendigen Schlüssel. Selbst wenn ein Cloud-Dienst – etwa Microsoft OneDrive, Google Drive oder Dropbox – zur Herausgabe von Daten verpflichtet wäre, lägen dort **ausschließlich unlesbare, verschlüsselte Dateien**.
+
+Im Kontext des BitLocker-Falls wird **der Unterschied besonders deutlich**:
+
+- Bei BitLocker mit Cloud-gesichertem Recovery-Key kann der Anbieter den Schlüssel herausgeben
+- Bei Cryptomator existiert dieser Schlüssel nur beim Nutzer selbst
+- Ein Zugriff durch Dritte ist technisch ausgeschlossen, nicht nur organisatorisch
+
+Damit **verschiebt sich die Verantwortung bewusst zurück zu den Nutzer:innen**. Das erfordert etwas **mehr Eigenverantwortung** – etwa beim sicheren Umgang mit Passwörtern –, bietet aber im Gegenzug ein **deutlich höheres Maß an Kontrolle und Privatsphäre**.
+
+Gerade für sensible Daten jeglicher Art ist dieses Modell entscheidend. Was man selbst nicht besitzt, kann man auch nicht weitergeben.
+
+## Fazit: Verschlüsselung ist kein Feature, sondern Verantwortung
+
+Der BitLocker-FBI-Fall zeigt **keine heimliche Hintertür und keinen Bruch moderner Kryptografie**. Er zeigt etwas viel Grundsätzlicheres: Wie leicht wir Kontrolle gegen Bequemlichkeit eintauschen – oft ohne es zu merken.
+
+Echte Datensouveränität entsteht nicht allein durch Verschlüsselung, sondern durch exklusive Kontrolle über die Schlüssel. Wer diese Kontrolle abgibt, sollte sich zumindest bewusst sein, was das bedeutet.
+
+Oder anders gefragt: **Weißt du, wer deinen Verschlüsselungsschlüssel besitzt?**

content/blog/2026-02-15-bitlocker-fbi-and-the-illusion-of-control.en.md

@@ -0,0 +1,117 @@
+---
+title: "BitLocker, the FBI, and the Illusion of Control"
+slug: bitlocker-fbi-and-the-illusion-of-control
+date: 2026-02-15
+tags: [cryptomator, microsoft, bitlocker]
+
+summary: "Microsoft helped the FBI decrypt BitLocker-encrypted devices – not through a backdoor, but via recovery keys stored in the cloud. What this reveals about key control, cloud trust, and true data sovereignty."
+
+ogimage:
+  relsrc: /img/blog/microsoft-bitlocker.png
+  width: 1200
+  height: 675
+---
+
+When it recently became known that **Microsoft had helped the FBI decrypt BitLocker-encrypted data carriers**, there was widespread outrage. People were quick to talk about “backdoors,” broken encryption, and how BitLocker was clearly unreliable. But as is so often the case, the real problem lies less in the technology itself than in **who has control over the encryption key**.
+
+This case is a good opportunity to take a closer look: What really happened? Why was access possible? And what does this say about **our understanding of encryption and cloud services**?
+
+<figure class="text-center">
+  <img class="inline-block rounded-sm" src="/img/blog/microsoft-bitlocker.png" alt="BitLocker, the FBI, and the Illusion of Control" />
+</figure>
+
+## What Happened?
+
+The case that came to light involved a **criminal investigation** in which the FBI seized several laptops. These devices were encrypted with **BitLocker**, the **hard disk encryption feature integrated into Windows**.
+
+The FBI was still able to decrypt the data **because Microsoft was able to provide the corresponding recovery keys**. These keys were **stored in the Microsoft account of the person** concerned. Microsoft was legally obliged to disclose this information by court order.
+
+It is important to clarify one thing: **Microsoft did not “crack” BitLocker**. There was no security breach, no secret master key, and no technical backdoor into the encryption itself. **Microsoft was able to help because they had the keys.**
+
+## Bitlocker Is Secure—But Not Automatically Private
+
+BitLocker is technically considered a **robust encryption solution**. The data on a device cannot be read without the appropriate key. The problem does not arise with encryption, but with **key management**.
+
+By default, **Windows offers to save the BitLocker recovery key in your Microsoft account**. This is convenient because if you forget your password or change your hardware, you can simply retrieve the key online.
+
+However, **this convenience has a consequence**: if Microsoft holds the key, Microsoft also has the ability to pass it on—for example, to law enforcement agencies with the appropriate warrant.
+
+Encryption therefore only fully protects data from third parties if the key remains exclusively under the control of the user.
+
+## The Real Misunderstanding: Encryption ≠ Key Control
+
+Many users equate encryption with complete control. In practice, however, this is often not the case.
+
+A rough distinction can be made between:
+
+- **Client-side encryption with external key management**. This means that the provider has access to the key.
+- **Zero-knowledge encryption**. Here, the provider has no technical access to the key.
+
+BitLocker with a cloud-backed recovery key clearly falls into the first category. The **data is encrypted, but not exclusively for the owner.**
+
+**The Microsoft case therefore does not demonstrate a failure of BitLocker**, but rather a **structural problem with modern cloud ecosystems**. Convenience features often undermine data sovereignty without anyone noticing.
+
+## Why Many Are Surprised
+
+The strong reaction to this case shows one thing above all else: **many people do not know where their encryption keys are stored.**
+
+Cloud backups, automatic synchronization, and preset security options are standard today. They lower the barrier to entry, increase user-friendliness, and quietly shift responsibility from the user to the provider.
+
+This leads to a misleading assumption:
+
+> *“My data is encrypted, so no one can access it.”*
+
+Technically correct would be:
+
+> *“My data is encrypted, but someone else has the spare key.”*
+
+## Access by Authorities Is Not a Special Case
+
+Another important point: **Access by authorities is not an unusual scenario.**
+
+If providers have access to keys or unencrypted data, they are **legally obliged** in many countries to hand them over if ordered to do so. **This applies not only to Microsoft, but also to other major cloud providers.**
+
+The crucial question is therefore not:
+
+> *“Do I trust Microsoft?”*
+
+But rather:
+
+> *“Do I want to give a provider the technical ability to decrypt my data?”*
+
+## What Users Can Learn From This
+
+**The case offers a valuable lesson** – regardless of the specific product:
+
+- Encryption is only as strong as key management
+- Cloud backups of keys always mean a loss of control
+- Security is not a default setting, but a conscious decision
+- If you want maximum privacy, you also have to take responsibility for keys
+
+**This does not mean that cloud services are fundamentally insecure**. But it does mean that you should understand which security model you are using and what compromises it entails.
+
+## How Cryptomator Helps in Such Cases: Zero Knowledge Instead of Key Storage
+
+This is precisely where solutions such as **Cryptomator and Cryptomator Hub** come in. Unlike many integrated encryption functions, Cryptomator consistently follows a **zero-knowledge principle**.
+
+This means that **data is encrypted locally on the device** before it can even be uploaded to the cloud. The key difference lies in key management. **Cryptomator does not store passwords, recovery keys, or master keys.**
+
+Neither cloud providers nor Cryptomator itself have technical access to the encrypted content or the keys required to decrypt it. Even if a cloud service—such as Microsoft OneDrive, Google Drive, or Dropbox—were required to disclose data, **it would only contain unreadable, encrypted files**.
+
+The **difference is particularly clear** in the context of the BitLocker case:
+
+- With BitLocker and a cloud-backed recovery key, the provider can issue the key
+- With Cryptomator, this key only exists with the user themselves
+- Access by third parties is technically impossible, not just organizationally
+
+This **deliberately shifts responsibility back to the users**. It requires a little **more personal responsibility**—for example, when it comes to handling passwords securely—but in return **offers a significantly higher degree of control and privacy.**
+
+This model is particularly important for sensitive data of any kind. You can't pass on something you don't own yourself.
+
+## Conclusion: Encryption Is Not a Feature, but a Responsibility
+
+The BitLocker-FBI case **does not reveal a secret backdoor or a breach of modern cryptography**. It reveals something much more fundamental: how easily we trade control for convenience – often without even realizing it.
+
+True data sovereignty does not come from encryption alone, but from exclusive control over the keys. Anyone who relinquishes this control should at least be aware of what that means.
+
+Or to put it another way: **Do you know who has your encryption key?**