cwtch.im
/
docs.cwtch.im
4
0
Fork 3
Code Issues 2 Pull Requests Projects Releases Wiki Activity

update translations + full german

This commit is contained in:
Dan Ballard 2023-03-19 12:56:29 -05:00
parent afec776cce
commit 941041c692
134 changed files with 3128 additions and 77 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
i18n/de/docusaurus-plugin-content-blog/options.json
View File

@ -1,14 +1,14 @@
{
"title": {
"message": "Blog",
"message": "Entwicklungsprotokoll",
"description": "The title for the blog used in SEO"
},
"description": {
"message": "Blog",
"message": "Die neuste Aktualisierung der Cwtch Entwicklung.",
"description": "The description for the blog used in SEO"
},
"sidebar.title": {
"message": "Kürzliche Beiträge",
"message": "Neueste Logs",
"description": "The label for the left sidebar"
}
}

12
i18n/de/docusaurus-plugin-content-docs/current/chat/add-contact.md
View File

@ -2,10 +2,16 @@
sidebar_position: 1.5
---
# Neuen Kontakt hinzufügen
# Neues Gespräch beginnen
1. Ein Profil auswählen
2. Klicke auf den Hinzufügen Button
3. Wähle 'Kontakt hinzufügen'
5. Eine Cwtch-Adresse einfügen
6. Der Kontakt wird zu deiner Kontaktliste hinzugefügt
4. Eine Cwtch-Adresse einfügen
5. Der Kontakt wird zu deiner Kontaktliste hinzugefügt
:::info
Diese Dokumentationsseite ist ein Muster. Du kannst helfen, indem [du es mit vergrößerst](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

6
i18n/de/docusaurus-plugin-content-docs/current/chat/block-contact.md
View File

@ -8,3 +8,9 @@ sidebar_position: 7
2. Zu Einstellungen gehen
3. Scrolle nach unten zum Kontakt blockieren
4. Verschiebe den Schalter auf Kontakt blockieren
:::info
Diese Dokumentationsseite ist ein Muster. Du kannst helfen, indem [du es mit vergrößerst](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

11
i18n/de/docusaurus-plugin-content-docs/current/chat/delete-contact.md Normal file
View File

@ -0,0 +1,11 @@
---
sidebar_position: 10
---
# Entfernen einer Konversation
:::info
Diese Dokumentationsseite ist ein Muster. Du kannst helfen, indem [du es mit vergrößerst](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

19
i18n/de/docusaurus-plugin-content-docs/current/chat/share-address-with-friends.md
View File

@ -2,11 +2,26 @@
sidebar_position: 3
---
# Teile eine Cwtch Adresse
# Teilen von Cwtch Adressen
Es gibt viele Möglichkeiten, eine Cwtch Adresse zu teilen.
## Teilen deiner Cwtch Adresse
1. Zu deinem Profil gehen
2. Klicke auf das Kopiere-Adresse-Symbol
Du kannst diese Adresse nun teilen. Personen mit dieser Adresse können dich als Cwtch Kontakt hinzufügen.
Für Informationen zum Blockieren von Verbindungen von Personen, die du nicht kennst, lies bitte [Einstellungen: Unbekannte Verbindungen blockieren](/docs/settings/behaviour/block-unknown-connections)
Für Informationen zum Blockieren von Verbindungen von Personen, die du nicht kennst, lies bitte [Einstellungen: Unbekannte Verbindungen blockieren](/docs/settings/behaviour/block-unknown-connections)
# Teilen der Cwtch Adresse von Freunden
Innerhalb von Cwtch gibt es einen weiteren Mechanismus zum Austausch von Cwtch-Adressen.
:::info
Diese Dokumentationsseite ist ein Muster. Du kannst helfen, indem [du es mit vergrößerst](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

9
i18n/de/docusaurus-plugin-content-docs/current/chat/unblock-contact.md
View File

@ -7,4 +7,11 @@ sidebar_position: 8
1. Wähle den Kontakt in Ihrer Konversationsliste aus. Gesperrte Kontakte werden an das Ende der Liste verschoben.
2. Gehe zu den Konversationseinstellungen
3. Scrolle nach unten zum Kontakt sperren
4. Verschiebe den Schalter auf Kontakt entsperren
4. Verschiebe den Schalter auf Kontakt entsperren
:::info
Diese Dokumentationsseite ist ein Muster. Du kannst helfen, indem [du es mit vergrößerst](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

51
i18n/de/docusaurus-plugin-content-docs/current/contribute/developing.md Normal file
View File

@ -0,0 +1,51 @@
---
sidebar_position: 1
---
# Entwicklung von Cwtch
Dieser Abschnitt dokumentiert einige Möglichkeiten, um mit der Cwtch-Entwicklung zu beginnen.
## Cwtch-Fehlerverfolgungsprozess
Alle Cwtch-Probleme werden aus dem [cwtch-ui git Repository](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues)verfolgt, auch wenn der Fehler / das Feature in einer Upstream-Bibliothek entsteht. Dies erlaubt uns, alles an einem Ort zu halten.
Probleme sind in 4 verschiedene Kategorien unterteilt:
- **Unbearbeitete** - Dies sind neue Probleme, die vom Cwtch Team nicht diskutiert wurden.
- [**Geplant**](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues?q=&type=all&state=open&labels=195&milestone=0&assignee=0&poster=0) - Diese Probleme wurden für eine kommende Veröffentlichung eingeplant. Normalerweise werden sie mit der Release Version getaggt, in der sie voraussichtlich in `cwtch-1.11` behoben werden. Ein Kern-Cwtch-Team-Mitglied arbeitet wahrscheinlich an diesem Problem oder wird in den nächsten Wochen an diesem Thema arbeiten.
- [**Gewünscht**](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues?q=&type=all&state=open&labels=153&milestone=0&assignee=0&poster=0) - Dies sind Probleme, die wir gerne beheben würden, aber aus irgendeinem Grund können wir diese nicht planen. Dies könnte daran liegen, dass die Funktion groß ist und viel Aufwand erfordert, oder weil es einen Blocker gibt (z.B. Eine fehlende Funktion in Flutter oder einer anderen Bibliothek), die die Arbeit an der Funktion verhindert.
- [**Hilfe gesucht**](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues?q=&type=all&state=open&labels=136&milestone=0&assignee=0&poster=0) - Dies sind in der Regel kleine Probleme, die wir gerne beheben würden, die aber als geringe Priorität eingestuft wurden. Dies sind ideale erste Probleme für Freiwillige.
Wenn du an einem offenen Fehler/Feature arbeiten möchtest, bitte kommentiere das Problem und ein Mitglied des Cwtch Teams wird dir Ratschläge geben, wohin du von dort gehen solltest. Dies hilft uns, den Überblick zu behalten, wer an welchen Problemen arbeitet, und reduziert den Umfang der doppelten Arbeit. Wir sind bestrebt, die meisten Anfragen innerhalb von 24 Stunden zu beantworten, fühle dich frei, an ein Problem zu "erinnern", wenn es länger als diese Zeit dauert.
:::note Hinweis
Aufgrund eines Problems mit unserem E-Mail-Provider sind wir derzeit nicht in der Lage, E-Mails von unserer gitea-Instanz zu versenden. Bitte überprüfe regelmäßig offene Probleme / Pull-Requests auf Updates (oder abonniere die RSS-Feeds des Projektarchivs)
:::
## Cwtch Pull-Request Prozess
Alle Pull-Requests müssen von einem Kernmitglied des Cwtch Teams überprüft und genehmigt werden, bevor das Zusammenführen erfolgt. Sarah prüft alle neuen und aktiven Pull-Anfragen mehrmals in der Woche.
### Bot bauen
Alle Cwtch Projekte werden mit automatisierten Builds und Tests eingerichtet. Es wird erwartet, dass jeder Pull-Request diese Pipelines durchlaufen kann, bevor er zusammengeführt wird. Wenn buildbot einen Fehler meldet, dann wird Sarah mit dir zusammenarbeiten, um das Problem und alle notwendigen Korrekturen zu ermitteln.
Der Buildbot kann aus Gründen, die außerhalb deiner Kontrolle liegen, fehlschlagen, z.B. viele unserer Integrationstests sind auf das Einrichten von Tor-Verbindungen angewiesen, diese können gelegentlich spröde sein und zu Timeouts und Fehlern führen. Bestätige immer die Hauptursache für einen Testfehler, bevor du entscheidest, was als nächstes zu tun ist.
## Nützliche Ressourcen
- [Cwtch Ecosystem Übersicht](/security/components/ecosystem-overview) - eine Zusammenfassung der aktiven Cwtch Repositories aus dem Cwtch Secure Development Handbuch.
- [Beitragen zur Dokumentation](/docs/contribute/documentation) - Ratschläge zum Beitragen zur Cwtch-Dokumentation.
- [Beitragen zum Testen](/docs/contribute/testing) - Ratschläge zum Beitragen durch das Testen von Cwtch.
- [Beitragen zu Übersetzungen](/docs/contribute/translate) - Ratschläge zum Beitragen von Übersetzungen in Cwtch.
:::note Hinweis
Alle Beiträge sind [berechtigt für Aufkleber](/docs/contribute/stickers)
:::

46
i18n/de/docusaurus-plugin-content-docs/current/contribute/documentation.md Normal file
View File

@ -0,0 +1,46 @@
---
sidebar_position: 6
---
# Stilregeln der Dokumentation
Dieser Abschnitt dokumentiert die erwartete Struktur und Qualität der Cwtch-Dokumentation.
## Screenshots und Übertragung von Zeichen
Die meisten Cwtch-Dokumentationen sollte mindestens einen Screenshot oder ein animiertes Bild enthalten. Screenshots der Cwtch-Anwendung sollten sich auf die in der Dokumentation beschriebene Funktion konzentrieren.
Um die Konsistenz zwischen Screenshots zu gewährleisten, schlagen wir vor, dass das betreffende Profil besonderen, konstanten und Rollen dienen sollte.
- **Alice** - wird verwendet, um das primäre Profil zu repräsentieren.
- **Bob** - der primäre Kontakt, nützlich bei der Darstellung von Peer-to-Peer-Funktionen
- **Carol** - ein sekundärer Kontakt, nützlich bei der Darstellung von Gruppenfunktionen
- **Mallory** - stellt einen böswilligen Partner dar (welcher verwendet wird, um die Blockierfunktionalität zu demonstrieren)
## Dialog und Inhalt
Wo Screenshots und Demonstrationen Dialog, Gespräche und/oder Bilder zeigen, halte bitte die Gespräche kurz zu einem lässigen Thema. Beispiele dafür sind:
- Organisieren eines Picknicks
- Teilen von Fotos aus einem Urlaub
- Senden des Dokuments zur Prüfung
## Experimente
Alle Funktionen, die auf die Aktivierung eines Experiments angewiesen sind, sollten dies alles oben auf der Seite hervorheben z. B.:
:::caution Experimentelle Funktionen erforderlich
Diese Funktion erfordert, dass [Experimente aktiviert](https://docs.cwtch.im/docs/settings/introduction#experiments) und das [Beispiel Experiment](https://docs.cwtch.im/docs/settings/experiments/server-hosting) eingeschaltet ist.
:::
## Risiko
Wenn eine Funktion zur Zerstörung des Schlüsselmaterials oder zur dauerhaften Löschung des Status führen könnte dann sollten diese auch oben in der Dokumentation aufgerufen werden, z. B.:
:::warning Warnung
Diese Funktion wird das Schlüsselmaterial **unwiderruflich** löschen. Dieses **kann nicht rückgängig gemacht werden**.
:::

10
i18n/de/docusaurus-plugin-content-docs/current/contribute/stickers.md Normal file
View File

@ -0,0 +1,10 @@
---
sidebar_position: 10
---
# Aufkleber
Alle Beiträge sind für Aufkleber berechtigt. Wenn du zu Bugs, Features, Testen oder Sprache beiträgst oder in der Vergangenheit einen wesentlichen Beitrag geleistet hast, schreibe bitte eine E-Mail an erinn@openprivacy. mit Details und einer Adresse für uns, damit wir die Aufkleber dir schicken können.
![Ein Foto von Cwtch-Aufklebern](/img/stickers-new.jpg)

8
i18n/de/docusaurus-plugin-content-docs/current/contribute/testing.md
View File

@ -28,4 +28,10 @@ Cwtch Nightly Builds sind Entwicklungs-Builds, die neue Features enthalten, die
Die aktuellsten Entwicklungsversionen von Cwtch sind auf unserem [Build-Server](https://build.openprivacy.ca/files/) verfügbar.
Wir empfehlen **nicht**, dass Tester immer auf die neueste Nightly aktualisieren, sondern wir werden eine Nachricht an die Cwtch Release Candidate Testers Gruppe schicken, wenn eine bedeutsame Nightly verfügbar wird. Eine Nightly wird als bedeutsam angesehen, wenn sie eine neue Funktion oder eine größere Fehlerbehebung enthält.
Wir empfehlen **nicht**, dass Tester immer auf die neueste Nightly aktualisieren, sondern wir werden eine Nachricht an die Cwtch Release Candidate Testers Gruppe schicken, wenn eine bedeutsame Nightly verfügbar wird. Eine Nightly wird als bedeutsam angesehen, wenn sie eine neue Funktion oder eine größere Fehlerbehebung enthält.
:::note Hinweis
Alle Beiträge sind [berechtigt für Aufkleber](/docs/contribute/stickers)
:::

36
i18n/de/docusaurus-plugin-content-docs/current/contribute/translate.md
View File

@ -6,14 +6,36 @@ sidebar_position: 2
Wenn du Übersetzungen zu Cwtch beitragen möchtest, entweder zur App oder zu diesem Handbuch, kommt hier wie dies möglich ist.
## Cwtch-Anwendung
## Übersetzungen zur Cwtch-Anwendung beitragen
Die Anwendung wird über [Lokalise](https://lokalise.com) übersetzt.
1. Registriere dich für ein Konto auf der Lokalise Website
2. Sende eine E-Mail an [team@cwtch.im](mailto:team@cwtch.im) mit der Information, dass du gerne bei der Übersetzung mithelfen möchtest und teile die E-Mail-Adresse mit, mit der du dich angemeldet hast. Wir werden dich dann zum Projekt hinzufügen.
Es gibt zwei Möglichkeiten, zu Cwtch Anwendungen beizutragen.
### Trete unserem Lokalise-Team bei
Wir verwenden [Lokalise](https://lokalise.com) für die Verwaltung von Übersetzungen für die Cwtch-Anwendung.
1. Registriere dich für ein Lokalise-Konto
2. Sende eine E-Mail an [team@cwtch.im](mailto:team@cwtch.im) mit der Sprache, die du übersetzen möchtest und einer E-Mail-Adresse, mit der wir dich in unser Lokalise-Team einladen können.
### Direkt über Git
Für neue Übersetzungen, kannst du eine Kopie von [https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/branch/trunk/lib/l10n/intl_en.arb](https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/branch/trunk/lib/l10n/intl_en.arb) erstellen und übersetzen - Du kannst dann entweder [Pull-Requests einreichen oder direkt](/docs/contribute/developing#cwtch-pull-request-process) Aktualisierungen an uns senden (team@cwtch.im) und wir werden sie zusammenführen.
Um zu existierenden Übersetzungen hinzuzufügen, kannst du Pull-Requests direkt auf jede Datei in [https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/branch/trunk/lib/l10n/](https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/branch/trunk/lib/l10n/) einstellen und wir werden sie überprüfen und zusammenführen.
## Cwtch-Benutzerhandbuch
Das Handbuch wird über [Crowdin](https://crowdin.com) übersetzt.
1. Registriere dich für ein Konto auf der Crowdin Website.
2. Gehe zum [cwtch-users-handbuch](https://crowdin.com/project/cwtch-users-handbook) Projekt und trete bei.
Dieses Handbuch wird über [Crowdin](https://crowdin.com) übersetzt.
Um unserem Crowdin-Projekt beizutreten:
1. Registrieren dich für ein Konto bei [Crowdin](https://crowdin.com).
2. Treten dem [cwtch-users-handbook Projekt](https://crowdin.com/project/cwtch-users-handbook) bei.
Wir bündeln Änderungen an der Dokumentation in Batches und synchronisieren sie regelmäßig mit dem Crowdin-Projekt.
:::note Hinweis
Alle Beiträge sind [berechtigt für Aufkleber](/docs/contribute/stickers)
:::

7
i18n/de/docusaurus-plugin-content-docs/current/getting-started/_category_.json Normal file
View File

@ -0,0 +1,7 @@
{
"label": "Erste Schritte",
"position": 2,
"link": {
"type": "generierter Index"
}
}

39
i18n/de/docusaurus-plugin-content-docs/current/getting-started/supported_platforms.md Normal file
View File

@ -0,0 +1,39 @@
# Unterstützte Platformen
Die folgende Tabelle stellt unser aktuelles Verständnis von Cwtch-Unterstützung auf verschiedenen Betriebssystemen und Architekturen dar (Stand Cwtch 1.10 und Januar 2023).
In vielen Fällen suchen wir nach Testern, die bestätigen, dass verschiedene Funktionen funktionieren. Wenn du daran interessiert bist, Cwtch auf einer bestimmten Plattform zu testen oder als freiwilliger Helfer bei der offiziellen Unterstützung einer hier nicht aufgelisteten Plattform helfen möchtest, dann schaue dir [Beitragen zu Cwtch](/docs/category/contribute) an.
**Legende:**
- ✅: **Offiziell unterstützt**. Cwtch sollte auf diesen Plattformen ohne Probleme funktionieren. Regressionen werden als hohe Priorität behandelt.
- 🟡: **Beste Anstrengung zur Unterstützung**. Cwtch sollte auf diesen Plattformen funktionieren, aber es kann dokumentierte oder unbekannte Probleme geben. Es kann notwendig sein, Tests durchzuführen. Einige Funktionen erfordern möglicherweise zusätzliche Arbeit. Freiwilligenarbeit wird gewürdigt.
- ❌: **Nicht unterstützt**. Cwtch wird wahrscheinlich nicht auf diesen Systemen funktionieren. Wir werden vermutlich keine Fehlerberichte für diese Systeme akzeptieren.
| Plattform | Offizielle Cwtch Builds | Quellencode-Unterstützung | Anmerkungen |
| ----------------------------- | ----------------------- | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Windows 11 | ✅ | ✅ | Nur 64-Bit amd64. |
| Windows 10 | ✅ | ✅ | Nur 64-Bit amd64. Nicht offiziell unterstützt, aber offizielle Builds könnten funktionieren. |
| Windows 8 und darunter | ❌ | 🟡 | Nicht unterstützt. Dedizierte Builds aus dem Quellcode könnten funktionieren. Testen erforderlich. |
| OSX 10 und darunter | ❌ | 🟡 | Nur 64-Bit. Offizielle Builds sollen auf Catalina funktionieren, aber nicht auf High Sierra |
| OSX 11 | ✅ | ✅ | Nur 64-Bit. Offizielle Builds unterstützen sowohl arm64 als auch x86 Architekturen. |
| OSX 12 | ✅ | ✅ | Nur 64-Bit. Offizielle Builds unterstützen sowohl arm64 als auch x86 Architekturen. |
| OSX 13 | ✅ | ✅ | Nur 64-Bit. Offizielle Builds unterstützen sowohl arm64 als auch x86 Architekturen. |
| Debian 11 | ✅ | ✅ | Nur 64-Bit amd64. |
| Debian 10 | 🟡 | ✅ | Nur 64-Bit amd64. |
| Debian 9 und darunter | 🟡 | ✅ | Nur 64-Bit amd64. Builds aus dem Quellcode sollten funktionieren, aber offizielle Builds könnten mit installierten Abhängigkeiten inkompatibel sein. |
| Ubuntu 22.04 | ✅ | ✅ | Nur 64-Bit amd64. |
| Andere Ubuntu | 🟡 | ✅ | Nur 64-Bit. Testen erforderlich. Builds aus dem Quellcode sollten funktionieren, aber offizielle Builds könnten mit installierten Abhängigkeiten inkompatibel sein. |
| CentOS | 🟡 | 🟡 | Testen erforderlich. |
| Gentoo | 🟡 | 🟡 | Testen erforderlich. |
| Arch | 🟡 | 🟡 | Testen erforderlich. |
| Whonix | 🟡 | 🟡 | [Bekannte Probleme. Für die Unterstützung sind spezielle Änderungen an Cwtch erforderlich. ](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues/550) |
| Raspian (arm64) | 🟡 | ✅ | Builds aus dem Quellcode erstellt, funktionieren. |
| Andere Linux-Distributionen | 🟡 | 🟡 | Testen erforderlich. |
| Android 9 und darunter | 🟡 | 🟡 | Offizielle Builds könnten funktionieren. |
| Android 10 | ✅ | ✅ | Offizielle SDK unterstützen arm, arm64 und amd64 Architekturen. |
| Android 11 | ✅ | ✅ | Offizielle SDK unterstützen arm, arm64 und amd64 Architekturen. |
| Android 12 | ✅ | ✅ | Offizielle SDK unterstützen arm, arm64 und amd64 Architekturen. |
| Android 13 | ✅ | ✅ | Offizielle SDK unterstützen arm, arm64 und amd64 Architekturen. |
| LineageOS | 🟡 | 🟡 | [Bekannte Probleme. Für die Unterstützung sind spezielle Änderungen an Cwtch erforderlich.](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues/607) |
| Andere Android Distributionen | 🟡 | 🟡 | Testen erforderlich. |

2
i18n/de/docusaurus-plugin-content-docs/current/profiles/create-a-profile.md
View File

@ -16,6 +16,6 @@ sidebar_position: 1.5
Die Profile werden lokal auf der Festplatte gespeichert und mittels eines Schlüssels verschlüsselt, der von einem Benutzer bekannten Passwort abgeleitet wird (via pbkdf2).
Beachte, dass einmal verschlüsselt und auf der Festplatte gespeichert die einzige Möglichkeit, ein Profil wiederherzustellen, ist das erneute Ableiten des Passworts - so ist es nicht möglich, eine vollständige Liste der Profile anzugeben, auf die ein Benutzer Zugriff haben könnte, bis er ein Passwort eingegeben hat.
Beachte, dass einmal verschlüsselt und auf der Festplatte gespeichert die einzige Möglichkeit, ein Profil wiederherzustellen, ist das erneute Ableiten des Schlüssels aus dem Passwort - so ist es nicht möglich, eine vollständige Liste der Profile anzugeben, auf die ein Benutzer Zugriff haben könnte, bis er ein Passwort eingegeben hat.
Siehe auch: [Cwtch Sicherheits-Handbuch: Profil Verschlüsselung & Speicher](https://docs.openprivacy.ca/cwtch-security-handbook/profile_encryption_and_storage.html)

8
i18n/de/docusaurus-plugin-content-docs/current/settings/experiments/file-sharing.md
View File

@ -2,4 +2,10 @@
sidebar_position: 3
---
# Dateifreigabe
# Dateifreigabe
:::info Info
Diese Dokumentationsseite ist ein Muster. Du kannst helfen, indem [du es mit vergrößerst](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

10
i18n/de/docusaurus-plugin-content-docs/current/settings/experiments/group-experiment.md
View File

@ -4,6 +4,14 @@ sidebar_position: 1
# Gruppen-Experiment aktivieren
:::info Info
Diese Dokumentationsseite ist ein Muster. Du kannst helfen, indem [du es mit vergrößerst](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::
1. Zu den Einstellungen
2. Experimente aktivieren
3. Gruppen-Experiment aktivieren
3. Gruppen-Experiment aktivieren

8
i18n/de/docusaurus-plugin-content-docs/current/settings/experiments/image-previews-and-profile-pictures.md
View File

@ -2,4 +2,10 @@
sidebar_position: 4
---
# Bildvorschau und Profilbilder
# Bildvorschau und Profilbilder
:::info Info
Diese Dokumentationsseite ist ein Muster. Du kannst helfen, indem [du es mit vergrößerst](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

6
i18n/de/docusaurus-plugin-content-docs/current/settings/experiments/message-formatting.md
View File

@ -3,3 +3,9 @@ sidebar_position: 6
---
# Nachrichtenformatierung
:::info Info
Diese Dokumentationsseite ist ein Muster. Du kannst helfen, indem [du es mit vergrößerst](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

11
i18n/de/docusaurus-plugin-content-docs/current/settings/experiments/qrcodes.md Normal file
View File

@ -0,0 +1,11 @@
---
sidebar_position: 9
---
# QR Codes
:::info Info
Diese Dokumentationsseite ist ein Muster. Du kannst helfen, indem [du es mit vergrößerst](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

7
i18n/de/docusaurus-plugin-content-security/current/components/_category_.json Normal file
View File

@ -0,0 +1,7 @@
{
"label": "Cwtch Komponenten",
"position": 4,
"link": {
"type": "generierter Index"
}
}

7
i18n/de/docusaurus-plugin-content-security/current/components/connectivity/_category_.json Normal file
View File

@ -0,0 +1,7 @@
{
"label": "Verbindung & Tor",
"position": 4,
"link": {
"type": "generierter Index"
}
}

43
i18n/de/docusaurus-plugin-content-security/current/components/connectivity/intro.md Normal file
View File

@ -0,0 +1,43 @@
---
sidebar_position: 3
---
# Verbindung
Cwtch nutzt Tor Onion Services (v3) für die Kommunikation zwischen Knoten.
Wir stellen das [openprivacy/connectivity](https://git.openprivacy.ca/openprivacy/connectivity) Paket zur Verfügung, um den Tor-Daemon zu verwalten und Onion Dienste durch Tor einzurichten und abzubauen.
## Bekannte Risiken
### Privater Schlüssel dem Tor Prozess ausgesetzt
**Status: Teilweise gemildert** (Erfordert physischen Zugriff oder Privilegierte Eskalation zum ausnutzen)
Wir müssen den privaten Schlüssel eines Onion Dienstes an die Konnektivitätsbibliothek übergeben über die `Listen` Schnittstelle (und damit zum Tor Prozess). Dies ist einer der kritischsten Bereiche, der außerhalb unserer Kontrolle liegt. Jede Bindung an einen Rogue-Tor-Prozess oder ein Binary führt zur Kompromittierung des privaten Schlüssels von Onion führen.
### Eindämmung
Verbindungsversuche als Standard an den vom System bereitgestellten Tor-Prozess zu binden, *nur* wenn ihm ein Authentifizierungs-Token zur Verfügung gestellt wurde.
Andernfalls versucht die Konnektivität immer einen eigenen Tor-Prozess mit einem bekannten guten Binärpaket, das mit dem System gepackt wurde (außerhalb des Geltungsbereichs des Konnektivitäts-Paketes)
Langfristig hoffen wir, dass eine integrierte Bibliothek verfügbar sein wird und die direkte Verwaltung über eine In-Prozessoberfläche ermöglicht, um zu verhindern, dass der private Schlüssel die Prozessgrenze verlässt (oder andere alternative Pfade, die es uns erlauben, die volle Kontrolle über den privaten Schlüssel im Speicher zu erhalten.)
### Tor-Prozess-Management
**Status: Teilweise gemildert** (Erfordert physischen Zugriff oder Privilegierte Eskalation zum ausnutzen)
Viele Probleme können sich aus der Verwaltung eines separaten Prozesses ergeben, einschließlich der Notwendigkeit, neu zu starten, zu beenden und anderweitig eine angemessene Verwaltung zu gewährleisten.
Die [ACN](https://git.openprivacy.ca/openprivacy/connectivity/src/branch/master/acn.go) Schnittstelle bietet `Restart`, `Close` und `GetBootstrapStatus` Schnittstellen die es Anwendungen erlauben, den zugrunde liegenden Tor-Prozess zu verwalten. Zusätzlich kann die `SetStatusCallback` Methode verwendet werden, um eine Anwendung zu benachrichtigen, wenn der Status des Tor-Prozesses sich ändert.
Wenn jedoch genügend privilegierte Benutzer es wünschen, können sie diesen Mechanismus stören, und als solches ist der Tor-Prozess eine zerbrechlichere Komponente in der Interaktion als andere.
## Teststatus
Die aktuelle Konnektivität hat begrenzte Test Möglichkeiten keine davon wird während Pull-Requests oder Zusammenschlüssen ausgeführt. Es gibt keine Integrationstests.
Es ist anzumerken, dass die Konnektivität sowohl von Tapir als auch von Cwtch in ihren Integrationstests verwendet wird (und dies trotz fehlender Tests auf Paketebene ist systemweiten Prüfbedingungen ausgesetzt)

7
i18n/de/docusaurus-plugin-content-security/current/components/cwtch/_category_.json Normal file
View File

@ -0,0 +1,7 @@
{
"label": "Cwtch",
"position": 5,
"link": {
"type": "generierter Index"
}
}

41
i18n/de/docusaurus-plugin-content-security/current/components/cwtch/groups.md Normal file
View File

@ -0,0 +1,41 @@
---
sidebar_position: 4
---
# Gruppen
Das Cwtch Risikomodell für Gruppen ist größtenteils in zwei unterschiedliche Profile aufgeteilt:
* Gruppen aus gegenseitig vertrauenswürdigen Teilnehmern, in denen Peers als ehrlich angenommen werden.
* Gruppen, die aus Fremden bestehen, in denen von Peers angenommen wird, dass sie potenziell bösartig sind.
Die meisten der in diesem Abschnitt beschriebenen Eindämmungen beziehen sich auf den letztgenannten Fall, aber wirken sich natürlich auch auf den Ersteren aus. Selbst wenn angenommen wird, dass ehrliche Peers später böswillig werden, gibt es Mechanismen, die solches Böse erkennen und verhindern können, dass es in der Zukunft passiert.
## Überblick über die Risiken: Schlüssel-Ableitung
Im Idealfall würden wir ein Protokoll wie OTR verwenden, die Einschränkungen, die uns im Moment daran hindern, sind:
* Offline-Nachrichten sind nicht garantiert, dass sie alle Peers erreichen, und als solche können alle Metadaten in Bezug auf Schlüsselmaterial verloren gehen. Wir benötigen einen Schlüsselableitungs-Prozess, der robust ist für fehlende Nachrichten oder unvollständige Übertragungen.
## Risiko: Schädlicher Peer- verrät Gruppenschlüssel und/oder Unterhaltung
**Status: Teilweise gemildert (aber unmöglich vollständig zu mildern)**
Ob mit vertrauenswürdigen kleineren Gruppen oder partiell öffentliche größeren Gruppen, es gibt *immer * die Möglichkeit, dass ein böswilliger Akteur Gruppe Nachrichten verraten kann.
Wir planen, es den Peers zu erleichtern, [Gruppen zu fork](#fork), den gleichen Schlüssel zu entschärfen, der zur Verschlüsselung vieler sensibler Informationen verwendet wird und ein gewisses Maß an Weiterleitungsgeheimhaltung für frühere Gruppengespräche bereitzustellen.
## Risiko: Aktive Angriffe von Gruppenmitgliedern
**Status: Teilweise gemildert**
Gruppenmitglieder, die Zugang zum Schlüsselmaterial der Gruppe haben, können sich mit einem Server oder anderen Gruppenmitgliedern verschwören, um die Konsistenz des Transkripts zu unterbrechen.
Während wir die Zensur angesichts dieser aktiven Absprachen nicht direkt verhindern können, so verfügen wir doch über eine Reihe von Mechanismen, die ehrlichen Gruppen-Mitgliedern das Vorhandensein einer Zensur offenbaren sollten.
### Eindämmung:
* Weil jede Nachricht vom öffentlichen Schlüssel der Peers signiert ist, es sollte nicht möglich sein (innerhalb der kryptographischen Annahmen der zugrunde liegenden Kryptographie) für ein Gruppenmitglied ein anderes nachzuahmen.
* Jede Nachricht enthält eine eindeutige Identifikation, die aus dem Inhalt abgeleitet wird und den vorherigen Hash der Nachrichten - wodurch es Kollaborateuren unmöglich gemacht wird, Nachrichten von nicht geheimen Mitgliedern einzufügen, ohne eine implizite Meldungs-Kette zu enthüllen (die wenn sie versuchen andere Nachrichten zu zensieren würde eine solche Zensur offenbaren)
Abschließend: Wir arbeiten aktiv daran, den Cwtch-Servern eine Nichtabstreitbarkeit hinzuzufügen, so dass dass sie selbst in dem, was sie effizient zensieren können, eingeschränkt sind.

28
i18n/de/docusaurus-plugin-content-security/current/components/cwtch/key_bundles.md Normal file
View File

@ -0,0 +1,28 @@
---
sidebar_position: 3
---
# Schlüsselbündel
Cwtch-Server identifizieren sich mit signierten Schlüsselbündeln. Diese Schlüsselbündel enthalten eine Liste der benötigten Schlüssel, um die Kommunikation der Cwtch-Gruppe sicher zu machen und Metadaten widerstandsfähig zu machen.
Zum Zeitpunkt des Schreibens wird erwartet, dass Schlüsselbündel 3 Schlüssel enthalten:
1. Ein öffentlicher Tor v3 Onion Service Public Key für das Token Board (ed25519)- verwendet um sich über Tor mit dem Dienst zu verbinden und Nachrichten zu empfangen.
2. Ein öffentlicher Schlüssel des Tor-v3-Onion Service für den Token Service (ed25519) - der verwendet wird, um Tokens zu erwerben, um über eine kleine Proof-Work-Übung auf den Dienst zu posten.
3. Ein Public Key für den Privacy-Pass - verwendet im Token-Akquisitionsprozess (ein ristretto Kurvenpunkt) . Siehe: [OPTR2019-01](https://openprivacy.ca/research/OPTR2019-01/)
Das Schlüsselbündel ist signiert und kann über den ersten v3-Onion Service Schlüssel verifiziert werden, so dass es an die onion-Adresse gebunden wird.
## Überprüfe Schlüsselbündel
Profile, die Server-Schlüsselpakete importieren, überprüfen sie anhand des folgenden "trust-on-first-use"-Algorithmus (TOFU):
1. Überprüfung der angehängten Signatur mit der v3-Onion Adresse des Servers. (Wenn dies fehlschlägt, wird der Importprozess gestoppt)
2. Überprüfung, ob jeder Schlüsseltyp existiert. (Wenn dies fehlschlägt, wird der Importprozess gestoppt)
3. Wenn das Profil zuvor das Server-Schlüsselbündel importiert hat, Sicherstellung, dass alle Schlüssel gleich sind. (Wenn dies fehlschlägt, wird der Importprozess gestoppt)
4. Speichern der Schlüssel im Kontakt-Eintrag des Servers.
In Zukunft wird dieser Algorithmus wahrscheinlich so geändert, dass neue öffentliche Schlüssel hinzugefügt werden können (z.B. um Tokens über eine Zcash Adresse zu erwerben.)
Technisch gesehen kann der Server in den Schritten (2) und (3() als bösartig angesehen werden, weil er ein gültiges Schlüsselbündel unterzeichnet hat, das nicht den Spezifikationen entspricht. Wenn Gruppen von "experimentell" in "stable" verschoben werden, führt eine solche Aktion dazu, dass eine Warnung an das Profil kommuniziert wird.

57
i18n/de/docusaurus-plugin-content-security/current/components/cwtch/message_formats.md Normal file
View File

@ -0,0 +1,57 @@
---
sidebar_position: 2
---
# Nachrichtenformate
## Peer-to-Peer Nachrichten
PeerMessage {
ID string // A unique Message ID (primarily used for acknowledgments)
Context string // A unique context identifier i.e. im.cwtch.chat
Data []byte // The context-dependent serialized data packet.
}
### Kontext-Bezeichner
* `im.cwtch.raw` - Daten enthalten eine Klartext-Chat-Nachricht (siehe: [Overlays](../ui/overlays.md) für weitere Informationen)
* `im.cwtch.acknowledgement` - Daten sind leer und ID verweist auf eine zuvor gesendete Nachricht
* `im.cwtch.getVal` und `im.cwtch.retVal` - Wird für die Abfrage / Rückgabe spezifischer Informationen über einen Peer verwendet. Daten enthalten eine serialisierte `peerGetVal` und `peerRetVal` Struktur.
peerGetVal struct {
Scope string
Path string
}
type peerRetVal struct {
Val string // Serialized path-dependent value
Exists bool
}
## Klartext / Entschlüsselte Gruppennachrichten
type DecryptedGroupMessage struct {
Text string // plaintext of the message
Onion string // The Cwtch address of the sender
Timestamp uint64 // A user specified timestamp
// NOTE: SignedGroupID is now a misnomer, the only way this is signed is indirectly via the signed encrypted group messages
// We now treat GroupID as binding to a server/key rather than an "owner" - additional validation logic (to e.g.
// respect particular group constitutions) can be built on top of group messages, but the underlying groups are
// now agnostic to those models.
SignedGroupID []byte
PreviousMessageSig []byte // A reference to a previous message
Padding []byte // random bytes of length = 1800 - len(Text)
}
Entschlüsselte Gruppennachrichten enthalten zufällige Füllung zu einer festen Größe, die der Länge aller Felder mit fester Länge + 1800 entspricht. Dies stellt sicher, dass alle verschlüsselten Gruppen-Nachrichten gleich lang sind.
## Verschlüsselte Gruppennachrichten
// EncryptedGroupMessage provides an encapsulation of the encrypted group message stored on the server
type EncryptedGroupMessage struct {
Ciphertext []byte
Signature []byte // Sign(groupID + group.GroupServer + base64(decrypted group message)) using the senders Cwtch key
}
Die Berechnung der Signatur erfordert das Wissen über die Gruppen-Id der Nachricht, des Servers, mit dem die Gruppe verbunden ist und der entschlüsselten Gruppennachricht (und damit der Gruppenschlüssel). Es ist vom Absender der Nachricht (ed25519) signiert und kann mit ihrem öffentlichen Cwtch-Adressschlüssel verifiziert werden.

60
i18n/de/docusaurus-plugin-content-security/current/components/cwtch/server.md Normal file
View File

@ -0,0 +1,60 @@
# Cwtch Server
Ziel des Cwtch-Protokolls ist es, die Gruppenkommunikation über **Nicht vertrauenswürdige Infrastruktur** zu aktivieren.
Im Gegensatz zu Relay basierten Schemata, bei denen die Gruppen einen Führer, einen Satz von Führern, oder ein vertrauenswürdiger Server von Drittanbietern zuweisen, um sicherzustellen, dass jedes Mitglied der Gruppe Nachrichten zeitnah senden und empfangen kann (selbst wenn Mitglieder offline sind) - hat die nicht vertrauenswürdige Infrastruktur das Ziel, diese Eigenschaften zu realisieren ohne Vertrauen anzunehmen.
Das ursprüngliche Cwtch-Papier hat eine Reihe von Eigenschaften definiert, die Cwtch-Server erwartbar zur Verfügung stellen sollten:
* Cwtch Server kann von mehreren Gruppen oder nur einer verwendet werden.
* Ein Cwtch Server, ohne Zusammenarbeit mit einem Gruppenmitglied, sollte niemals die Identität der Teilnehmer innerhalb einer Gruppe erlernen.
* Ein Cwtch Server sollte niemals den Inhalt einer Kommunikation erlernen.
* Ein Cwtch-Server sollte niemals in der Lage sein, Nachrichten als einer bestimmten Gruppe zugehörig unterscheiden zu können.
Wir stellen hier fest, dass diese Eigenschaften ein Superset der Designziele der privaten Informationsabfrage sind.
## Bösartige Server
Wir erwarten das Vorhandensein bösartiger Entitäten innerhalb des Cwtch-Ökosystems.
Wir legen auch Wert auf Dezentralisierung und erlaubnisfreien Zugang zum Ökosystem und stützen daher keine Sicherheitsansprüche auf die folgenden Punkte:
* Jede Nicht-Kollusionsannahme zwischen einer Reihe von Cwtch-Servern
* Jedes von Dritten definierte Prüfverfahren
Die Peers selbst werden ermutigt, Cwtch-Server einzurichten und zu betreiben, wo sie effizientere Eigenschaften garantieren können, indem sie die Vertrauens- und Sicherheits Annahmen voraussetzen - standardmäßig ist das Protokoll jedoch so konzipiert, dass es auch ohne diese Annahmen sicher ist - auf Kosten der Effizienz, wo es nötig ist.
### Erkennbare Fehler
* Wenn ein Cwtch-Server eine bestimmte Nachricht nicht an eine Gruppe von Gruppenmitgliedern weiterleitet, wird es eine erkennbare Lücke im Nachrichtenbaum einiger Peers geben, die durch Peer-to-Peer Klatsch entdeckt werden kann.
* Ein Cwtch-Server kann keine Nachricht ohne das Schlüsselmaterial, das der Gruppe bekannt ist, ändern (jeder Versuch, dies für eine Teilmenge von Gruppenmitgliedern zu tun, führt dazu, dass es das gleiche Verhalten hat, wie wenn keine Nachricht weitergeleitet wird).
* Während ein Server Nachrichten duplizieren *kann*, haben diese keine Auswirkungen auf den Gruppen-Nachrichtenbaum (aufgrund der Verschlüsselung, Nonces und Nachrichtenidentitäten) - die Quelle der Vervielfältigung ist für einen Peer nicht bekannt.
## Effizienz
Zum Zeitpunkt des Schreibens dieser Seite ist nur ein Protokoll für das Erreichen der gewünschten Eigenschaften bekannt, naive PIR oder "der Server sendet alles, und die Peers sichten es".
Dies hat einen offensichtlichen Einfluss auf die Effizienz der Bandbreite, insbesondere für Peers mit mobilen Geräten, als solche entwickeln wir aktiv neue Protokolle, in denen die Datenschutz- und Effizienzgarantien auf unterschiedliche Weise ausgehandelt werden können.
Beim Zeitpunkt des Schreibens dieser Seite erlauben die Server sowohl einen vollständigen Download aller gespeicherten Nachrichten, und eine Anfrage, um Nachrichten von einer bestimmten Nachricht herunterzuladen.
Alle Peers, wenn sie einer Gruppe auf einem neuen Server beitreten, laden alle Nachrichten vom Server herunter und von dann an laden sie nur neue Nachrichten.
*Hinweis*: Dieses Verhalten erlaubt eine milde Form der Metadatenanalyse. Der Server kann neue Nachrichten für jedes verdächtige eindeutige Profil anzeigen und dann diese eindeutigen Signaturen benutzen um eindeutige Sitzungen im Laufe der Zeit zu verfolgen (über Anfragen für neue Nachrichten).
Dies wird durch 2 Verwirrungsfaktoren gemildert:
1. Profile können ihre Verbindungen jederzeit aktualisieren - was zu einer neuen Serversitzung führt.
2. Profile können jederzeit von einem Server "synchronisieren" - was zu einem neuen Aufruf führt, um alle Nachrichten herunterzuladen. Die am meisten verbreitete Benutzungsgrundlage für dieses Verhalten ist das Abrufen älterer Nachrichten aus einer Gruppe.
In Kombination setzen diese 2 Abschwächungen Grenzen auf das, was der Server herausfinden kann, aber wir können noch keine vollständige Metadatenresistenz bieten.
Für mögliche zukünftige Lösungen für dieses Problem siehe [Niwl](https://git.openprivacy.ca/openprivacy/niwl)
# Den Server wird vor böswilligen Peers schützen
Das Hauptrisiko für Server besteht in Form von Spam, der von Peers erzeugt wird. Im Prototyp von Cwtch wurde ein Spamschutzmechanismus eingeführt, der von anderen Peers verlangte, einen willkürlichen Nachweis der Arbeit mit einem server-spezifizierten Parameter durchzuführen.
Dies ist keine robuste Lösung in Anwesenheit eines bestimmten Gegners mit einer beträchtlichen Menge an Ressourcen und damit wird eines der wichtigsten externen Risiken für das Cwtch-System wird Zensur-Via-Ressourcen-Erschöpfung.
Wir haben eine mögliche Lösung dafür in [Token basierten Diensten](https://openprivacy.ca/research/OPTR2019-01/) skizziert, aber beachte, dass dies ebenfalls weiterentwickelt werden muss.

70
i18n/de/docusaurus-plugin-content-security/current/components/ecosystem-overview.md Normal file
View File

@ -0,0 +1,70 @@
---
sidebar_position: 1.5
---
# Komponenten Ecosystem Übersicht
Cwtch besteht aus mehreren kleineren Komponenten-Bibliotheken. Dieses Kapitel gibt einen kurzen Überblick über jede Komponente und wie sie sich auf das größere Cwtch-Ökosystem bezieht.
## [offene Privatsphäre/Konnektivität](https://git.openprivacy.ca/openprivacy/connectivity)
Zusammenfassung: Eine Bibliothek, die eine ACN (Anonymous Communication Network ) Netzwerkabstraktion zur Verfügung stellt.
Das Ziel der Konnektivität ist es, die zugrunde liegenden Bibliotheken/Software zu abstrahieren, die für die Kommunikation mit einer spezifischen ACN benötigt wird. Zurzeit unterstützen wir nur Tor und deshalb ist die Aufgabe der Verbindung folgendes:
* Start und Stopp des Tor Prozesses
* Bereitstellen der Konfiguration des Tor-Prozesses
* Erlaube unveränderte Verbindungen zu Endpunkten über den Tor-Prozess (z.B. Verbindung mit Onion-Diensten)
* Endpunkte über den Tor-Prozess zur Verfügung stellen (z.B. Host-Onion-Dienste)
* Statusaktualisierungen über den zugrunde liegenden Tor-Prozess bereitstellen
Für weitere Informationen siehe [Konnektivität](/security/components/connectivity/intro)
## [cwtch.im/tapir](https://git.openprivacy.ca/cwtch.im/tapir)
Zusammenfassung: Tapir ist eine kleine Bibliothek für das Erstellen von p2p Anwendungen über anonyme Kommunikationssysteme.
Das Ziel von Tapir ist es, **Anwendungen** über eine bestimmte ACN zu abstrahieren. Tapir unterstützt:
* Erstellen einer kryptographischen Identität (einschließlich kurzlebiger Identitäten)
* Wartung eines Verbindungspools von eingehenden und ausgehenden Verbindungen zu Diensten
* Behandlung verschiedener Anwendungsschichten, einschließlich kryptographischer Transkripte, [Authentifizierungs- und Autorisierungsprotokolle](/security/components/tapir/authentication_protocol)und [Token-basierte Dienste über PrivacyPass](https://openprivacy.ca/research/OPTR2019-01/),
Für weitere Informationen siehe [Tapir](/security/components/tapir/authentication_protocol)
## [cwtch.im/cwtch](https://git.openprivacy.ca/cwtch.im/cwtch)
Zusammenfassung: Cwtch ist die Hauptbibliothek für die Implementierung des Cwtch-Protokolls / System.
Das Ziel von Cwtch ist die Bereitstellung von Implementierungen für cwtch-spezifische Anwendungen wie z.B. Nachrichtensendung, Gruppen und Dateifreigabe (implementiert als Tapir Anwendungen), Schnittstellen zur Verwaltung und Speicherung von Cwtch Profilen, bietet neben der Verwaltung anderer Kernfunktionen auch einen Eventbus für Subsystem Splitting und das Erstellen von Plugins mit neuen Funktionen.
Die Cwtch Bibliothek ist auch für die Pflege kanonischer Modelldarstellungen für Formate und Overlays zuständig.
## [cwtch.im/libcwtch-go](https://git.openprivacy.ca/cwtch.im/libcwtch-go)
Zusammenfassung: libcwtch-go stellt C (auch für Android) Bindungen für Cwtch bereit für die Benutzung in UI Implementierungen.
Das Ziel von libcwtch-go ist es, die Lücke zwischen der Backend Cwtch Bibliothek und allen Frontend-Systemen zu überbrücken, die in einer anderen Sprache geschrieben werden können.
Die von libcwtch bereitgestellte API ist wesentlich eingeschränkter als die von Cwtch direkt bereitgestellte API, jede libcwtch API paketiert normalerweise mehrere Aufrufe an Cwtch.
libcwtch-go ist auch für die Verwaltung der UI-Einstellungen und des experimentellen Gateways zuständig. Es wird auch oft als Staging-Boden für experimentelle Funktionen und Code verwendet, die möglicherweise am Ende in Cwtch enden.
## [cwtch-ui](https://git.openprivacy.ca/cwtch.im/cwtch-ui)
Zusammenfassung: Eine flutterbasierte Oberfläche (UI) für Cwtch.
Cwtch UI verwendet libcwtch-go um ein vollständiges UI für Cwtch bereitzustellen, das es Leuten ermöglicht, Profile zu erstellen und zu verwalten, Kontakte und Gruppen hinzuzufügen, Nachrichten zu versenden, Dateien freizugeben (bald) und vieles mehr.
Das UI ist auch für die Verwaltung von Lokalisierung und Übersetzungen zuständig.
Für weitere Informationen siehe [Cwtch UI](/security/category/cwtch-ui)
## Zusätzliche Komponenten
Gelegentlich wird Open Privacy Teile von Cwtch in eigenständige Bibliotheken einbeziehen, die nicht Cwtch spezifisch sind. Diese werden hier kurz zusammengefasst:
### [openprivacy/log](https://git.openprivacy.ca/openprivacy/log)
Ein Open Privacy spezifisches Logging-Framework, das in allen Cwtch Paketen verwendet wird.

49
i18n/de/docusaurus-plugin-content-security/current/components/intro.md Normal file
View File

@ -0,0 +1,49 @@
---
sidebar_position: 1
---
# Cwtch technische Grundlagen
Diese Seite bietet einen kurzen technischen Überblick über das Cwtch-Protokoll.
## Ein Cwtch Profil
Benutzer können eines von mehreren Cwtch Profilen erstellen. Jedes Profil erzeugt ein zufälliges ed25519 Schlüsselpaar, welches kompatibel mit Tor ist.
Zusätzlich zum kryptographischen Material enthält ein Profil auch eine Liste von Kontakten (öffentliche Schlüssel für das Cwtch-Profil + zugeordnete Daten über dieses Profil wie Nickname und (optional) historische Nachrichten), eine Liste von Gruppen (mit kryptographischem Gruppenmaterial zusätzlich zu anderen zugehörigen Daten wie dem Gruppennickname und historischen Nachrichten).
## 2-Parteien-Konversionen: Peer to Peer
![](/img/BASE_3.png)
Damit 2 Parteien ein Peer-to-Peer-Gespräch führen können, müssen beide online sein, aber nur eine Partei muss über ihren Onion-Dienst erreichbar sein. Um der Klarheit willen kennzeichnen wir oft eine Partei als den "eingehenden Peer" (die Person, die den Onion-Dienst beherbergt) und die andere Partei den "ausgehenden Peer" (der sich mit dem Onion-Dienst verbindet).
Nach einer Verbindung beteiligen sich beide Seiten an einem -Authentifizierungsprotokoll von:
* Behauptet, dass jede Partei Zugriff auf den privaten Schlüssel hat, der mit ihrer öffentlichen Identität verbunden ist.
* Erzeugt einen kurzlebigen Sitzungs-Schlüssel, der zur Verschlüsselung aller weiteren Kommunikation während der Sitzung verwendet wird.
Dieser Austausch (detailliert im [-Authentifizierungsprotokoll](tapir/authentication_protocol.md)dokumentiert) ist *offline verweigerbar* d. h. es ist möglich für jede Seite Transkripte dieses Protokoll-Austausches zu fälschen und daher ist es unmöglich definitiv zu beweisen, dass der Austausch überhaupt stattgefunden hat.
Nach dem Authentifizierungsprotokoll können beide Parteien frei miteinander kommunizieren.
## Mehrparteien-Unterhaltungen: Gruppen und Kommunikation zwischen Peer to Server
**Hinweis: Metadaten resistente Kommunikation ist noch ein aktives Entwicklungsfeld und was hier dokumentiert ist wird sehr wahrscheinlich in der Zukunft sich ändern.**
Wenn eine Person eine Gruppendiskussion starten möchte, generiert sie einen zufälligen geheimen `Gruppenschlüssel`. Alle Gruppenkommunikation wird mit diesem Schlüssel verschlüsselt.
Zusammen mit dem `Gruppenschlüssel` entscheidet der Gruppenersteller sich auch für einen **Cwtch Server** als Host der Gruppe zu verwenden. Weitere Informationen darüber, wie Server sich selbst authentifizieren, findest du unter [Schlüsselbündel](cwtch/key_bundles.md).
Ein `Gruppen Identifikator` wird mit dem Gruppenschlüssel und dem Gruppenserver generiert und diese drei Elemente sind in einer Einladung verpackt, die an potenzielle Gruppenmitglieder gesendet werden kann (z.B. über existierende Peer-to-Peer-Verbindungen).
Um eine Nachricht an die Gruppe zu senden, verbindet sich ein Profil mit dem Server, der die Gruppe beherbergt (siehe unten), und verschlüsselt deine Nachricht mit dem `Gruppenschlüssel` und erzeugt eine kryptographische Signatur über die `Gruppen-Id`, `Gruppen Server` und die entschlüsselte Nachricht (siehe: [Nachrichtenformate](cwtch/message_formats.md) für weitere Informationen).
Um Nachrichten von der Gruppe zu erhalten, verbindet sich ein Profil mit dem Server, der die Gruppe beherbergt und lädt *alle* Nachrichten (seit seiner vorherigen Verbindung) herunter. Die Profile versuchen dann jede Nachricht mit dem `Gruppenschlüssel` zu entschlüsseln und wenn dies erfolgreich war, dann die Signatur zu verifizieren (siehe [Cwtch Server](cwtch/server.md) [Cwtch Gruppen](./cwtch/groups.md) für einen Überblick über Attacken und Abschwächungen).
### Server sind Peers
In vielerlei Hinsicht ist die Kommunikation mit einem Server identisch mit einer regulären Cwtch Gegenstelle, die gleichen Schritte oben werden durchgeführt, aber der Server fungiert immer als eingehender Peer, und der ausgehende Peer verwendet immer neu generierte **kurzlebige Schlüsselpaare** als "Langfristige Identität".
Somit unterscheidet sich die Peer zu Server Konversation nur in der *Art* der Nachrichten, die zwischen zwei Seiten gesendet werden, mit dem Server, der alle Nachrichten, die er erhält, weiterleitet und außerdem den Clients erlaubt den Server nach älteren Nachrichten abzufragen.

7
i18n/de/docusaurus-plugin-content-security/current/components/tapir/_category_.json Normal file
View File

@ -0,0 +1,7 @@
{
"label": "Tapir",
"position": 4,
"link": {
"type": "generierter Index"
}
}

34
i18n/de/docusaurus-plugin-content-security/current/components/tapir/authentication_protocol.md Normal file
View File

@ -0,0 +1,34 @@
---
sidebar_position: 2
---
# Authentifizierungsprotokoll
Jeder Peer erhält eine offene Verbindung $C$:
$$ I = \mathrm{InitializeIdentity()} \\
I_e = \mathrm{InitializeEphemeralIdentity()} \\ I,I_e \rightarrow C \\
P, _e \leftarrow C \\ k = \mathrm{KDF}({P_e}^{i} + {P}^{i_e} + {P_e}^{i_e}) \\
c = \mathrm{E}(k, transkript. ommit()) \\ c \rightarrow C \\
c_p \leftarrow C\\ \mathrm{D}(k, c_p) \stackrel{?}{=} transcript.LatestCommit() $$
Das obige stellt ein Skizzenprotokoll dar, in Wirklichkeit gibt es ein paar Implementierungsdetails die es zu erwähnen gilt:
Einmal von der Schlüssel-Ableitungsfunktion ($\mathrm{KDF}$) abgeleitet, wird der Schlüssel ($k$) auf *an* gesetzt. Dies bedeutet, dass die Authentifizierungs-App die Verschlüsselung oder Entschlüsselung nicht explizit durchführt.
Die Verkettung von Teilen des 3DH Austauschs ist streng geregelt:
* DH der langfristigen Identität der ausgehenden Verbindung durch den flüchtigen Schlüssel der eingehenden Verbindung.
* DH der langfristigen Identität der eingehenden Verbindung durch den flüchtigen Schlüssel der ausgehenden Verbindung.
* DH der beiden ephemeren Identitäten der eingehenden und ausgehenden Verbindungen.
Diese strikte Reihenfolge stellt sicher, dass beide Seiten der Verbindung den *gleichen* Sitzungsschlüssel ableiten.
### Kryptographische Eigenschaften
Während einer Online-Sitzung können alle mit dem Sitzungsschlüssel verschlüsselten Nachrichten von den Peers als von ihrem Peers kommend authentifiziert werden (oder zumindest jemand, der über einen geheimen Schlüssel der Peers verfügt, da dies mit der Onion Adresse in Verbindung steht).
Sobald die Sitzung beendet ist, ein Transkript mit den langfristigen und kurzlebigen öffentlichen Schlüsseln, ein abgeleiteter Session-Schlüssel und alle verschlüsselten Nachrichten in der Sitzung können nicht als authentisch bewiesen werden. dieses Protokoll bietet die Nachricht & Teilnehmer Zurückweisung (offline verweigerbar) zusätzlich zur Nachrichtenunverlinkbarkeit (offline verweigerbar) für den Fall, dass jemand damit zufrieden ist, dass eine einzelne Nachricht im Transkript von einem Peer stammt, es gibt keine Möglichkeit, eine andere Nachricht mit zu verknüpfen.
Intuition für die obigen Ausführungen: Das einzige kryptographische Material, das mit dem Transkript zusammenhängt, ist der abgeleitete Sitzungsschlüssel - wenn der Sitzungsschlüssel veröffentlicht wird, kann er verwendet werden, um neue Nachrichten im Transkript zu schmieden - und als solche unterliegt jede eigenständige Transkription der Möglichkeit einer Fälschung und kann daher nicht verwendet werden, um einen Peer kryptographisch an eine Unterhaltung zu binden.

15
i18n/de/docusaurus-plugin-content-security/current/components/tapir/packet_format.md Normal file
View File

@ -0,0 +1,15 @@
---
sidebar_position: 1
---
# Paketformat
Alle Tapir-Pakete haben eine feste Länge (8192 Bytes) und die ersten 2 Bytes zeigen die tatsächliche Länge der Nachricht, `len` Bytes an Daten und der Rest mit null aufgefüllt:
| len (2 bytes) | data (len bytes) | paddding (8190-len bytes)|
Einmal verschlüsselt, ist das gesamte 8192-Byte-Datenpaket mit [libsodium secretbox](https://libsodium.gitbook.io/doc/secret-key_cryptography/secretbox) verschlüsselt unter Verwendung der Standardstruktur ( beachte in diesem Fall die tatsächlich benutzbare Größe des Datenpakets ist 8190-14, um die Nonce in der Geheimbox zu unterbringen)
Informationen darüber, wie der geheime Schlüssel abgeleitet wird, findest du im [Authentifizierungsprotokoll](authentication_protocol.md)

7
i18n/de/docusaurus-plugin-content-security/current/components/ui/_category_.json Normal file
View File

@ -0,0 +1,7 @@
{
"label": "Cwtch-UI",
"position": 7,
"link": {
"type": "generierter Index"
}
}

28
i18n/de/docusaurus-plugin-content-security/current/components/ui/android.md Normal file
View File

@ -0,0 +1,28 @@
# Android Dienst
[Angepasst von: Discreet Log #11: Integration von FFI-Prozessen mit Android-Diensten](https://openprivacy.ca/discreet-log/11-android-ffi-service-integration/)
Zusätzlich zu der Notwendigkeit, einfache Methodenaufrufe in die Cwtch-Bibliothek zu machen, müssen wir auch in der Lage sein, mit langlaufenden Cwtch-Go-Routinen zu kommunizieren (und Ereignisse von ihnen zu empfangen), die den Tor-Prozess im Hintergrund laufen lassen, den Verbindungs- und Gesprächsstatus für alle deine Kontakte verwalten und einige andere Überwachungs- und Wartungsaufgaben erledigen. Auf herkömmlichen Multitasking-Desktop-Betriebssystemen ist dies kein wirkliches Problem, aber auf mobilen Geräten mit Android müssen wir mit kürzeren Sitzungen, häufigen Entladevorgängen sowie Netzwerk- und Energiebeschränkungen zurechtkommen, die sich im Laufe der Zeit ändern können. Da Cwtch metadatenresistent und datenschutzorientiert sein soll, wollen wir auch Benachrichtigungen bereitstellen, ohne den Google-Push-Benachrichtigungsdienst zu nutzen.
Die Lösung für langlaufende Netzwerkanwendungen wie Cwtch besteht darin, unseren FFI-Code in einen Android Foreground Service zu integrieren. (Und nein, es ist mir nicht entgangen, dass der Code für unser Backend in einem sogenannten ForegroundService untergebracht ist) Die WorkManager-API ermöglicht es uns, mit ein wenig Fingerspitzengefühl verschiedene Arten von Diensten zu erstellen und zu verwalten, darunter auch ForegroundServices. Dies erwies sich als eine gute Wahl für uns, da unser gomobile FFI-Handler bereits in Kotlin geschrieben war und WorkManager uns erlaubt, eine Kotlin-Coroutine zu spezifizieren, die als Dienst aufgerufen wird.
Wenn Sie uns folgen wollen, unsere WorkManager-Spezifikationen werden in der handleCwtch()-Methode von [MainActivity.kt](https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/branch/trunk/android/app/src/main/kotlin/im/cwtch/flwtch/MainActivity.kt) erstellt, und die Worker selbst sind in [FlwtchWorker.kt](https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/branch/trunk/android/app/src/main/kotlin/im/cwtch/flwtch/FlwtchWorker.kt) definiert.
Unsere einfachen Methodenaufrufe an FFI-Routinen werden auch als WorkManager-Arbeitsanforderungen aktualisiert, so dass wir die Rückgabewerte bequem über den Ergebnis-Callback zurückgeben können.
Ein erster Aufruf (passenderweise Start genannt) wird von FlwtchWorker gekapert, um unsere Eventbus-Schleife zu werden. Da es sich bei FlwtchWorker um eine Co-Routine handelt, ist es für sie ein Leichtes, bei Bedarf aufzugeben und fortzufahren, während sie darauf wartet, dass Ereignisse erzeugt werden. Die Goroutinen von Cwtch können dann Ereignisse ausgeben, die von FlwtchWorker aufgegriffen und entsprechend weitergeleitet werden.
Die Eventbus-Schleife von FlwtchWorker ist nicht nur ein langweiliger Forwarder. Es muss auf bestimmte Nachrichtentypen geprüft werden, die den Android-Status beeinflussen. So sollten beispielsweise bei neuen Nachrichtenereignissen normalerweise Benachrichtigungen angezeigt werden, auf die der Benutzer klicken kann, um das entsprechende Konversationsfenster aufzurufen, auch wenn die App nicht im Vordergrund läuft. Wenn es an der Zeit ist, das Ereignis an die Anwendung weiterzuleiten, verwenden wir LocalBroadcastManager, um die Benachrichtigung an MainActivity.onIntent zu erhalten. Von dort aus verwenden wir wiederum Flutter MethodChannels, um die Ereignisdaten von Kotlin an die Flutter-Engine des Frontends weiterzuleiten, wo das Ereignis schließlich von Dart-Code geparst wird, der die Benutzeroberfläche nach Bedarf aktualisiert.
Nachrichten und andere permanente Zustände werden vom Dienst auf der Festplatte gespeichert, so dass das Frontend nicht aktualisiert werden muss, wenn die Anwendung nicht geöffnet ist. Einige Dinge (wie z. B. Daten und ungelesene Nachrichten) können dann jedoch zu Desynchronisationen zwischen Front- und Backend führen, so dass wir dies beim Starten/Fortsetzen der Anwendung überprüfen, um zu sehen, ob wir Cwtch neu initialisieren und/oder den UI-Status neu synchronisieren müssen.
Schließlich haben wir bei der Implementierung dieser Dienste unter Android festgestellt, dass WorkManager sehr gut darin ist, alte Warteschlangen aufrechtzuerhalten, und zwar so gut, dass alte Worker sogar nach einer Neuinstallation der Anwendung wieder aufgenommen wurden! Das Hinzufügen von Aufrufen zu pruneWork() hilft, dies abzumildern, solange die Anwendung ordnungsgemäß heruntergefahren wurde und alte Aufträge ordnungsgemäß abgebrochen wurden. Dies ist unter Android jedoch häufig nicht der Fall, so dass wir es als zusätzliche Abschwächung für sinnvoll erachten, die Arbeit mit dem Namen des nativen Bibliotheksverzeichnisses zu kennzeichnen:
private fun getNativeLibDir(): String {
val ainfo = this.applicationContext.packageManager.getApplicationInfo(
"im.cwtch.flwtch", // Must be app name
PackageManager.GET_SHARED_LIBRARY_FILES)
return ainfo.nativeLibraryDir
}
... dann brechen wir bei jedem Start der Anwendung alle Aufträge ab, die nicht mit dem richtigen aktuellen Bibliotheksverzeichnis gekennzeichnet sind. Da sich der Name dieses Verzeichnisses bei jeder Installation der Anwendung ändert, verhindert diese Technik, dass wir versehentlich mit einem veralteten Service Worker fortfahren.

29
i18n/de/docusaurus-plugin-content-security/current/components/ui/image_previews.md Normal file
View File

@ -0,0 +1,29 @@
# Bildervorschau
Basierend auf dem Filesharing in Cwtch 1.3 werden die Bildvorschauen durch die Erweiterung des vorgeschlagenen Dateinamens (und nein, wir sind nicht daran interessiert, MIME-Typen oder magische Zahlen zu verwenden) und die angezeigte Größe bestimmt. Wenn diese Option aktiviert ist, lädt das Vorschausystem automatisch freigegebene Bilder in einen konfigurierten Download-Ordner herunter und zeigt sie als Teil der Nachricht selbst an. (Aufgrund von Beschränkungen auf Android werden sie im privaten Cache der App gespeichert und Sie haben die Möglichkeit, sie später an anderer Stelle zu speichern) Die Dateigrößenbeschränkung ist noch nicht festgelegt, wird aber deutlich niedriger sein als die allgemeine Größenbeschränkung für die gemeinsame Nutzung von Dateien, die derzeit bei 10 Gigabyte liegt.
Im Moment unterstützen wir nur Einzelbildnachrichten und jede Bildbearbeitung/jeder Bildausschnitt muss in einer separaten Anwendung erfolgen. Wie in den FAQ zum Filesharing erwähnt, enthalten Bilddateien häufig auch wichtige versteckte Metadaten und du solltest sie nur mit Personen teilen, denen du vertraust.
## Bekannte Risiken
## Andere Anwendungen und/oder das Betriebssystem, die Informationen aus Bildern ableiten
Bilder müssen irgendwo gespeichert werden und wir haben uns dafür entschieden, sie zunächst unverschlüsselt im Dateisystem zu speichern. Wir haben dies aus 2 Gründen gemacht:
1. Um leistungsfähigere Dateifreigabeverfahren wie Rehosting zu unterstützen, müssen wir in der Lage sein, Dateien effizient zu scannen und Chunks zu liefern - dies über eine verschlüsselte Datenbankschicht zu tun, würde die Leistung beeinträchtigen.
2. Diese Informationen müssen immer die Anwendungsgrenze passieren (entweder über Anzeigetreiber oder durch Speichern und Anzeigen der Datei in einer externen Anwendung) - es gibt nichts, was Cwtch nach diesem Punkt tun kann.
## Bösartige Bilder, die Cwtch zum Absturz bringen oder anderweitig kompromittieren
Flutter verwendet Skia, um Bilder zu rendern. Der zugrundeliegende Code ist zwar speicherunsicher, wird aber im Rahmen der regulären Entwicklung [ausführlich zerfusselt](https://github.com/google/skia/tree/main/fuzz).
Wir führen auch unsere eigenen Fuzz-Tests von Cwtch-Komponenten durch. Bei dieser Analyse haben wir einen einzigen Absturzfehler gefunden, der mit einer fehlerhaften GIF-Datei, die den Renderer dazu veranlasste, eine lächerliche Menge an Speicher zuzuweisen (und schließlich vom Kernel abgelehnt wurde). Um zu verhindern, dass sich dies auf Cwtch auswirkt, haben wir die Richtlinie eingeführt, immer eine maximale `cacheWidth` und/oder `cacheHeight` für Bild-Widgets.
## Bösartige Bilder werden auf verschiedenen Plattformen unterschiedlich gerendert, was zur Offenlegung von Metadaten führen kann
Vor kurzem wurde [ein Fehler in Apples png-Parser](https://www.da.vidbuchanan.co.uk/widgets/pngdiff/) gefunden, der dazu führte, dass ein Bild auf Apple-Geräten anders dargestellt wurde als auf Nicht-Apple-Geräten.
Wir haben einige Tests mit unseren Mac-Builds durchgeführt und konnten dieses Problem für Flutter nicht replizieren (da alle Flutter-Builds Skia für das Rendering verwenden), aber wir werden solche Fälle weiterhin in unseren Testkorpus aufnehmen.
Die Bildvorschau bleibt vorerst experimentell und auf freiwilliger Basis.

18
i18n/de/docusaurus-plugin-content-security/current/components/ui/input.md Normal file
View File

@ -0,0 +1,18 @@
# Eingabe
## Risiko: Abfangen von Cwtch-Inhalten oder Metadaten durch eine IME auf mobilen Geräten
**Status: Teilweise gemildert**
Jede Komponente, die die Möglichkeit hat, Daten zwischen einer Person und der Cwtch-App abzufangen, stellt ein potenzielles Sicherheitsrisiko.
Einer der wahrscheinlichsten Abfangjäger ist ein IME (Input Method Editor) eines Drittanbieters, der häufig um Zeichen zu erzeugen, die von ihrem Gerät nicht unterstützt werden.
Selbst gutartige und standardmäßige IME-Anwendungen können unbeabsichtigt Informationen über den Inhalt einer Person preisgeben, z. B. durch Cloud-Synchronisierung, Cloud-Übersetzung oder persönliche Wörterbücher.
Letztlich kann dieses Problem nicht von Cwtch allein gelöst werden, sondern stellt ein größeres Risiko dar, welches auf das gesamte mobile Ökosystem auswirkt.
Ein ähnliches Risiko besteht auf dem Desktop durch die Verwendung ähnlicher Eingabeanwendungen (zusätzlich zu den Software-Keyloggern), Wir sind jedoch der Ansicht, dass dies völlig außerhalb des Rahmens der Cwtch-Risikobewertung liegt (in Übereinstimmung mit anderen Angriffen auf die Sicherheit des zugrunde liegenden Betriebssystems selbst).
Dies wird in Cwtch 1.2 teilweise durch die Verwendung von `enableIMEPersonalizedLearning: false` entschärft. Siehe [diesen PR](https://git.openprivacy.ca/cwtch.im/cwtch-ui/pulls/142) für weitere Informationen.

72
i18n/de/docusaurus-plugin-content-security/current/components/ui/overlays.md Normal file
View File

@ -0,0 +1,72 @@
# Nachrichten Overlays
[Angepasst von: Discreet Log #8: Anmerkungen zur Cwtch Chat API](https://openprivacy.ca/discreet-log/08-chatapi/)
**Hinweis: Dieser Abschnitt behandelt Overlay-Protokolle, die auf das Cwtch-Protokoll aufsetzen. Für Informationen über das Cwtch-Protokoll Nachrichten selbst schaue unter [Nachrichtenformate](../cwtch/message_formats.md)**
Wir sehen Cwtch als eine Plattform für die Bereitstellung einer authentifizierten Transportschicht für Anwendungen auf höherer Ebene. Es steht den Entwicklern frei, selbst zu entscheiden, welche Protokolle der Anwendungsschicht sie verwenden wollen, ob sie maßgeschneiderte binäre Nachrichtenformate wünschen oder einfach nur eine HTTP-Bibliothek aufsetzen und die Sache abhaken wollen. Cwtch kann neue Schlüsselpaare für Sie generieren (die zu Onion-Adressen werden; es sind keine DNS-Registrierungen erforderlich!) und du kannst mit REST sicher sein, dass alle Daten, die deine Anwendung vom (anonymen Kommunikations-) Netz empfängt, bereits authentifiziert wurden.
In unserem aktuellen Stack sind die Nachrichten in einen minimalen JSON-Rahmen verpackt, der einige kontextbezogene Informationen über den Nachrichtentyp hinzufügt. Und da es sich bei serialisierten JSON-Objekten nur um Wörterbücher handelt, können wir später bei Bedarf problemlos weitere Metadaten hinzufügen.
## Chat-Overlays, Listen und Bulletins
Das ursprüngliche Cwtch alpha zeigte "Overlays": verschiedene Arten, denselben Datenkanal zu interpretieren, abhängig von der Struktur der atomaren Daten selbst. Wir haben einfache Checklisten und BBS/Klassifizierungsanzeigen als Overlays eingefügt, die mit jedem Cwtch-Kontakt angeschaut und geteilt werden konnten, sei es mit einem einzelnen Peer oder einer Gruppe. Das Übertragungsformat sah wie folgt aus:
```
{o:1,d:"hey there!"}
{o:2,d:"bread",l:"groceries"}
{o:3,d:"garage sale",p:"[parent message signature]"}
```
Overlay-Feld `o` bestimmt, ob es ein Chat (1), Liste (2), oder Bulletin (3) Nachricht war. Das Datenfeld `d` ist überladen und Listen/Bulletins benötigen zusätzliche Informationen darüber, welcher Gruppe/Beitrag sie angehören. (Wir verwenden Nachrichtensignaturen anstelle von IDs, um Probleme wie Ordnungsprobleme und böswillig erstellte IDs zu vermeiden. Auf diese Weise teilt auch das Cwtch-Protokoll dem Frontend mit, welche Nachricht abgeholt wird)
## Datenstruktur
Die Implementierung von baumstrukturierten Daten auf einem sequentiellen Nachrichtenspeicher hat offensichtliche Leistungsnachteile. Betrachte z. B. die Nachrichtenansicht, die die neuesten Nachrichten zuerst lädt und nur so weit zurückgeht, dass sie das aktuelle Ansichtsfenster ausfüllt, im Vergleich zu einem (etwas pathologischen) Forum, in dem fast jede Nachricht ein Kind der allerersten Nachricht in der Historie ist, die Gigabytes an Daten enthalten kann. Wenn die Benutzeroberfläche nur Beiträge der obersten Ebene anzeigt, bis der Benutzer sie erweitert, müssen wir den gesamten Verlauf analysieren, bevor wir genügend Informationen erhalten, um überhaupt etwas anzuzeigen.
Ein weiteres Problem besteht darin, dass das Multiplexen all dieser Überlagerungen in einem Datenspeicher "Löcher" in den Daten erzeugt, die [lazy-loaded listviews](https://api.flutter.dev/flutter/widgets/ListView/ListView.builder.html) und Scrollbars verwirren. Die Anzahl der Nachrichten kann darauf hinweisen, dass es eine Menge weiterer Informationen gibt, die angezeigt werden können, wenn der Benutzer einfach scrollt, aber wenn sie tatsächlich abgerufen und geparst werden, könnten wir feststellen, dass nichts davon für das aktuelle Overlay relevant ist.
Keines dieser Probleme ist unüberwindbar, aber sie zeigen einen Fehler in unseren ursprünglichen Annahmen über die Art des kollaborativen Nachrichtenflusses und die Art und Weise, wie wir mit diesen Daten umgehen sollten.
# Overlay Typen
Wie oben erwähnt, werden Overlays in einem sehr einfachen JSON-Format mit der folgenden Struktur angegeben:
type ChatMessage struct {
O int `json:"o"`
D string `json:"d"`
}
Wo O für `Overlay` mit den unten dokumentierten unterstützten Overlays steht:
1: data is a chat string
2: data is a list state/delta
3: data is a bulletin state/delta
100: contact suggestion; data is a peer onion address
101: contact suggestion; data is a group invite string
## Chat-Nachrichten (Overlay 1)
Die einfachste Variante ist eine Chat-Nachricht, die einfach nur rohe, unverarbeitete Informationen über die Chat-Nachricht enthält.
```
{o:1,d:"got milk?"}
```
## Einladungen (Overlays 100 und 101)
Anstatt die Einladung als eingehende Kontaktanfrage auf Profilebene zu erhalten, werden neue Inline-Einladungen mit einem bestimmten Kontakt/einer bestimmten Gruppe geteilt, wo sie später eingesehen und/oder angenommen werden können, auch wenn sie zunächst (möglicherweise versehentlich) abgelehnt wurden.
Das Format ist für diese gleichermaßen einfach:
```
{o:100,d:"u4ypg7yyyrrvf2aceeclq5dgwtkirzletltbqofnb6km7u542qqk4jyd"}
{o:101,d:"torv3eyJHcm91cElEIjoiOWY3MWExYmFhNDkzNTAzMzAyZDFmODRhMzI2ODY2OWUiLCJHcm91cE5hbWUiOiI5ZjcxYTFiYWE0OTM1MDMzMDJkMWY4NGEzMjY4NjY5ZSIsIlNpZ25lZEdyb3VwSUQiOiJyVGY0dlJKRkQ2LzFDZjFwb2JQR0xHYzdMNXBKTGJTelBLRnRvc3lvWkx6R2ZUd2Jld0phWllLUWR5SGNqcnlmdXVRcjk3ckJ2RE9od0NpYndKbCtCZz09IiwiVGltZXN0YW1wIjowLCJTaGFyZWRLZXkiOiJmZVVVQS9OaEM3bHNzSE9lSm5zdDVjNFRBYThvMVJVOStPall2UzI1WUpJPSIsIlNlcnZlckhvc3QiOiJ1cjMzZWRid3ZiZXZjbHM1dWU2anBrb3ViZHB0Z2tnbDViZWR6ZnlhdTJpYmY1Mjc2bHlwNHVpZCJ9"}
```
Dies stellt eine Abkehr von unserem ursprünglichen "Overlays"-Denken hin zu einer stärker handlungsorientierten Darstellung dar. Das Chat-"Overlay" kann mitteilen, dass jemand etwas *getan* hat, selbst wenn es auf "ein Element zu einer Liste hinzugefügt" umschrieben wird, und die Listen und Bulletins und andere schön chaotische Daten können ihren Zustand vorberechnet und separat gespeichert haben.
## Listen / Bulletin Boards
**Hinweis: Wird voraussichtlich in Cwtch Beta 1.5 definiert werden**

14
i18n/de/docusaurus-plugin-content-security/current/deployment.md Normal file
View File

@ -0,0 +1,14 @@
# Veröffentlichung
## Risiko: Binärdateien werden auf der Website durch böswillige Versionen ersetzt
**Status: Teilweise gemildert**
Während dieser Prozess jetzt größtenteils automatisiert ist, sollte diese Automatisierung jemals kompromittiert sein, dann gibt es in unserem aktuellen Prozess nichts, was dies erkennen würde.
Wir benötigen:
* Reproduzierbare Builds - derzeit verwenden wir öffentliche Docker-Container für alle Builds, was jedem erlauben sollte, verteilte Builds mit denen aus dem Quellcode zu vergleichen.
* Signierte Veröffentlichungen - Open Privacy verwaltet noch keinen öffentlichen Datensatz von Mitarbeitern öffentlichen Schlüsseln. Dies ist wahrscheinlich eine Notwendigkeit um veröffentlichte Builds zu signieren und eine Audit-Kette zu erstellen, die von der Organisation unterstützt wird. Dieser Prozess muss per Definition manuell sein.

28
i18n/de/docusaurus-plugin-content-security/current/development.md Normal file
View File

@ -0,0 +1,28 @@
# Entwicklung
Der Hauptprozess gegen böswillige Akteure bei der Entwicklung von Cwtch ist die Offenheit des Prozesses.
Um diese Offenheit zu verstärken, werden automatisierte buidls, Tests und Paketierungen als Teil der Repositories definiert - Verbesserung der Robustheit der Codebasis in jeder Phase.
![](https://docs.openprivacy.ca/cwtch-security-handbook/1.png)
Während die einzelnen Tests nicht perfekt sind und alle Prozesse Lücken haben, sollten wir verpflichtet sein, es so einfach wie möglich machen, etwas zu Cwtch beizutragen und gleichzeitig Pipelines und Prozesse so erstellen, dass Fehler (unabsichtlich oder bösartig) so früh wie möglich abgefangen werden.
### Risiko: Entwickler liefert bösartigen Code direkt aus
**Status: Gemildert**
`trunk` ist derzeit gesperrt und nur 3 Open Privacy Mitarbeiter haben die Berechtigung um es zu überschreiben und darüber hinaus die Verantwortung für die Überwachung der Änderungen.
Darüber hinaus löst jeder neue Pull-Request und Merge automatisierte Builds & Tests aus, die E-Mails und Audit Protokolle auslösen.
Der Code ist auch Open Source und von jedem überprüfbar.
### Risiko: Code Regressionen
**Status: Teilweise gemildert** (Siehe einzelne Projekteinträge in diesem Handbuch für weitere Informationen)
Unsere automatisierten Pipelines haben die Möglichkeit, Regressionen zu erfassen, wenn dieses Verhalten erkennbar ist.
Die größte Herausforderung besteht darin, festzulegen, wie solche Regressionen für die [UI](/security/category/cwtch-ui) erkannt werden - wo das Verhalten nicht so streng definiert ist wie für die einzelnen Bibliotheken.

48
i18n/de/docusaurus-plugin-content-security/current/intro.md Normal file
View File

@ -0,0 +1,48 @@
---
sidebar_position: 1
---
# Cwtch Sicherheitshandbuch
Willkommen im Cwtch Sicherheitshandbuch! Der Zweck dieses Handbuchs ist es, eine Anleitung für die verschiedenen Komponenten des Cwtch Ökosystems zu liefern um die bekannten Risiken und Abschwächungen zu dokumentieren und Diskussionen über Verbesserungen und Aktualisierungen für Cwtch sichere Entwicklungsprozesse zu ermöglichen.
![](https://docs.openprivacy.ca/cwtch-security-handbook/2.png)
## Was ist Cwtch?
Cwtch (/kʊtʃ/ - ein walisisches Wort, das in etwa mit "eine Umarmung, die einen sicheren Ort schafft" übersetzt werden kann) ist ein dezentralisiertes, datenschutzfreundliches Mehrparteien-Nachrichtenprotokoll, das zum Aufbau metadatenresistenter Anwendungen verwendet werden kann.
* **Dezentralisiert und offen**: Es gibt keinen „Cwtch-Dienst“ oder „Cwtch-Netzwerk“. Die Cwtch Teilnehmer können ihre eigenen sicheren Räume hosten oder ihre Infrastruktur anderen anbieten, die auf der Suche nach einem sicheren Raum sind. Das Cwtch-Protokoll ist offen und jeder kann Bots, Dienste und Benutzeroberflächen erstellen und in Cwtch integrieren und interagieren.
* **Datenschutz wahrend**: Alle Kommunikation in Cwtch ist Ende-zu-Ende verschlüsselt und findet über Tor v3 onion Dienste statt.
* **Metadaten resistent**: Cwtch wurde so konzipiert, dass ohne deine ausdrückliche Zustimmung keine Informationen ausgetauscht oder zugänglich sind einschließlich On-the-wire Nachrichten und Protokoll-Metadaten.
## Eine (kurze) Geschichte des metadatenresistenten Chats
In den letzten Jahren ist das öffentliche Bewusstsein für die Notwendigkeit und Vorteile von Ende-zu-Ende-verschlüsselten Lösungen mit Anwendungen wie [Signal](https://signalapp.org), [Whatsapp](https://whatsapp.com) und [Wire](https://wire.org) gestiegen. Diese bieten Benutzern jetzt sichere Kommunikation.
Diese Werkzeuge benötigen jedoch verschiedene Ebenen von Metadaten, um zu funktionieren und viele dieser Metadaten können verwendet werden, um Details darüber zu erfahren, wie und warum eine Person ein Kommunikationstool nutzt. [[rottermanner2015privacy]](https://www.researchgate.net/profile/Peter_Kieseberg/publication/299984940_Privacy_and_data_protection_in_smartphone_messengers/links/5a1a9c29a6fdcc50adeb1335/Privacy-and-data-protection-in-smartphone-messengers.pdf).
Ein Werkzeug, das versucht hat, Metadaten zu reduzieren, ist [Ricochet](https://ricochet.im) welches 2014 zum ersten Mal veröffentlicht wurde. Ricochet nutzte die Onion-Dienste von Tor v2, um eine sichere Ende-zu-Ende-verschlüsselte Kommunikation zu gewährleisten und die Metadaten der Kommunikation zu schützen.
Es gab keine zentralisierten Server, die beim Routen von Ricochet Unterhaltungen helfen. Keine andere als die an einem Gespräch beteiligten Parteien konnte wissen, dass ein solches Gespräch stattfindet.
Ricochet war nicht ohne Einschränkungen, es gab weder eine Multidevice Unterstützung noch einen Mechanismus zur Unterstützung der Gruppenkommunikation oder eine Unterstützung zum Senden von Nachrichten, während ein Kontakt offline ist.
Dies machte die Annahme von Ricochet zu einer schwierigen Angelegenheit. selbst diejenigen in Umgebungen, die am besten von Metadatenresistenz profitieren würden, wissen nicht, dass es [[ermoshina2017can]](https://www.academia.edu/download/53192589/ermoshina-12.pdf) gibt [[renaud2014doesn]](https://eprints.gla.ac.uk/116203/1/116203.pdf).
Darüber hinaus ist jede Lösung für dezentralisierte, metadatenresistente Kommunikation mit [grundlegenden Problemen](https://code.briarproject.org/briar/briar/-/wikis/Fundamental-Problems) konfrontiert, wenn es um Effizienz, Datenschutz und Gruppensicherheit geht (wie von [Konsens und Konsistenz der Transkription](https://code.briarproject.org/briar/briar/-/wikis/Fundamental-Problems) definiert).
Moderne Alternativen zu Ricochet sind [Briar](https://briarproject.org), [Zbay](https://www.zbay.app/) und [Ricochet Refresh](https://www.ricochetrefresh.net/) - Jedes Tool versucht, für eine andere Reihe von Kompromissen zu optimieren, z. Briar möchte es Menschen ermöglichen, [auch dann zu kommunizieren, wenn die zugrunde liegende Netzwerkinfrastruktur ausgefallen ist](https://briarproject.org/how-it-works/), und bietet gleichzeitig Schutz vor Metadatenüberwachung.
<hr />
Das Cwtch-Projekt begann 2017 als ein Erweiterungsprotokoll für Ricochet, das Gruppengespräche über nicht vertrauenswürdige Server, um dezentrale, metadatenresistente Anwendungen zu ermöglichen (wie gemeinsame Listen und Bulletin Board)
Eine Alpha-Version von Cwtch wurde [im Februar 2019 gestartet](https://openprivacy.ca/blog/2019/02/14/cwtch-alpha/) und seitdem hat das Cwtch-Team ( betrieben von der [Open Privacy Research Society](https://openprivacy.ca)) Forschung und Entwicklung zu Cwtch und den zugrunde liegenden Protokollen und Bibliotheken und Problembereichen durchgeführt.

28
i18n/de/docusaurus-plugin-content-security/current/references.md Normal file
View File

@ -0,0 +1,28 @@
# Referenzen
* Atwater, Erinn und Sarah Jamie Lewis. "Token Based Services-Differences from Privacy Pass."
* Brooks, John. Ricochet: Anonymous instant messaging for real privacy. https://ricochet.im . Zugriffen: 2018-03-10
* Ermoshina K, Halpin H, Musiani F. Can johnny build a protocol? co-ordinating developer and user intentions for privacy-enhanced secure messaging protocols. In European Workshop on Usable Security 2017.
* Ermoshina, K., Musiani, F. and Halpin, H., 2016, September. End-to-end encrypted messaging protocols: An overview. In International Conference on Internet Science (pp. 244-254). Springer, Cham.
* Farb, M., Lin, Y.H., Kim, T.H.J., McCune, J. and Perrig, A., 2013, September. Safeslinger: easy-to-use and secure public-key exchange. In Proceedings of the 19th annual international conference on Mobile computing & networking (pp. 417-428).
* Greschbach, B., Kreitz, G. and Buchegger, S., 2012, March. The devil is in the metadata—New privacy challenges in Decentralised Online Social Networks. In 2012 IEEE international conference on pervasive computing and communications workshops (pp. 333-339). IEEE.
* Langley, Adam. Pond. https://github.com/agl/pond. Zugriffen: 2018-05-21.
* Le Blond, S., Zhang, C., Legout, A., Ross, K. and Dabbous, W., 2011, November. I know where you are and what you are sharing: exploiting p2p communications to invade users' privacy. In Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conference (pp. 45-60).
* Lewis, Sarah Jamie. "Cwtch: Privacy Preserving Infrastructure for Asynchronous, Decentralized, Multi-Party and Metadata Resistant Applications." (2018).
* Kalysch, A., Bove, D. and Müller, T., 2018, November. How Android's UI Security is Undermined by Accessibility. In Proceedings of the 2nd Reversing and Offensive-oriented Trends Symposium (pp. 1-10).
* Renaud, K., Volkamer, M. and Renkema-Padmos, A., 2014, July. Why doesn’t Jane protect her privacy?. In International Symposium on Privacy Enhancing Technologies Symposium (pp. 244-262). Springer, Cham.
* Rottermanner, C., Kieseberg, P., Huber, M., Schmiedecker, M. and Schrittwieser, S., 2015, December. Privacy and data protection in smartphone messengers. In Proceedings of the 17th International Conference on Information Integration and Web-based Applications & Services (pp. 1-10).
* Unger, Nik et al. “SoK: secure messaging”. In: Security and Privacy (SP), 2015 IEEE Sympo-sium on. IEEE. 2015, pp. 232–249 [link](http://cacr.uwaterloo.ca/techreports/2015/cacr2015-02.pdf)

57
i18n/de/docusaurus-plugin-content-security/current/risk.md Normal file
View File

@ -0,0 +1,57 @@
---
sidebar_position: 2
---
# Risiko-Modell
Es ist bekannt, dass Kommunikationsmetadaten von verschiedenen Gegnern ausgenutzt werden, um die Sicherheit von Systemen zu untergraben, Opfer zu verfolgen und groß angelegte Analysen sozialer Netzwerke durchzuführen, um die Massenüberwachung zu unterstützen. Metadaten-resistente Tools stecken noch in den Kinderschuhen und es fehlt an Forschung zur Konstruktion und Benutzererfahrung solcher Tools.
![](/img/4.png)
Cwtch wurde ursprünglich als Erweiterung des Metadaten-resistenten Protokolls Ricochet konzipiert, um die asynchrone Multi-Peer-Gruppenkommunikation durch die Verwendung einer verwerfbaren, nicht vertrauenswürdigen, anonymen Infrastruktur zu unterstützen.
Seitdem hat sich Cwtch zu einem eigenständigen Protokoll entwickelt. In diesem Abschnitt werden die verschiedenen bekannten Risiken beschrieben, die Cwtch zu mindern versucht, und es wird im Rest des Dokuments stark darauf verwiesen, wenn die verschiedenen Unterkomponenten der Cwtch-Architektur erörtert werden.
## Bedrohungsmodell
Es ist wichtig zu erkennen und zu verstehen, dass Metadaten in Kommunikationsprotokollen allgegenwärtig sind, es ist in der Tat notwendig, dass solche Protokolle effizient und in großem Umfang funktionieren. Informationen, die für die Unterstützung von Peers und Servern nützlich sind, sind jedoch auch für Gegner, die solche Informationen ausnutzen möchten, von großer Bedeutung.
Für unsere Problemstellung gehen wir davon aus, dass der Inhalt einer Kommunikation so verschlüsselt ist, dass ein Angreifer sie praktisch nicht knacken kann (siehe [tapir](/security/category/tapir) und < a href="security/category/cwtch">cwtch</a> für Details zu der von uns verwendeten Verschlüsselung) und daher konzentrieren wir uns auf den Kontext der Kommunikationsmetadaten.
Wir bemühen uns, die folgenden Kommunikationskontexte zu schützen:
* Wer ist an einer Kommunikation beteiligt? Es kann möglich sein, Personen oder einfach Geräte- oder Netzwerkkennungen zu identifizieren. Beispiel: „An dieser Kommunikation sind Alice, eine Journalistin, und Bob, ein Regierungsangestellter, beteiligt.“.
* Wo sind die Gesprächsteilnehmer? Beispiel: „Während dieser Kommunikation war Alice in Frankreich und Bob in Kanada.“
* Wann hat ein Gespräch stattgefunden? Der Zeitpunkt und die Länge der Kommunikation können viel über die Art eines Anrufs verraten, z. B. „Bob, ein Regierungsangestellter, hat gestern Abend eine Stunde lang mit Alice telefoniert. Dies ist das erste Mal, dass sie kommuniziert haben.“ *Wie wurde das Gespräch vermittelt? Ob eine Konversation über eine verschlüsselte oder unverschlüsselte E-Mail stattgefunden hat, kann nützliche Informationen liefern. Beispiel: „Alice hat gestern eine verschlüsselte E-Mail an Bob gesendet, während sie normalerweise nur Klartext-E-Mails aneinander senden.“
* Worum geht es in dem Gespräch? Selbst wenn der Inhalt der Kommunikation verschlüsselt ist, ist es manchmal möglich, einen wahrscheinlichen Kontext eines Gesprächs abzuleiten, ohne genau zu wissen, was gesagt wird, z. „Eine Person hat zum Abendessen in einem Pizzaladen angerufen“ oder „Jemand hat um 3 Uhr morgens eine bekannte Selbstmord-Hotline angerufen.“
Über einzelne Konversationen hinaus versuchen wir auch, uns gegen Kontextkorrelationsangriffe zu verteidigen, wobei mehrere Konversationen analysiert werden, um Informationen auf höherer Ebene abzuleiten:
* Beziehungen: Entdeckung sozialer Beziehungen zwischen zwei Entitäten durch Analyse der Häufigkeit und Länge ihrer Kommunikation über einen bestimmten Zeitraum. z.B. Carol und Eve telefonieren jeden Tag mehrere Stunden am Stück.
* Cliquen: Entdeckung sozialer Beziehungen zwischen einer Gruppe von Einheiten, die alle miteinander interagieren. z.B. Alice, Bob und Eve kommunizieren alle miteinander.
* Lose verbundene Cliquen und Brücken-Individuen: Entdeckung von Gruppen, die über Vermittler miteinander kommunizieren, indem Kommunikationsketten analysiert werden (z. B. jedes Mal, wenn Alice mit Bob spricht, spricht sie fast unmittelbar danach mit Carol; Bob und Carol kommunizieren nie.)
* Muster des Lebens: Entdecken, welche Kommunikation zyklisch und vorhersehbar ist. z.B. Alice ruft Eve jeden Montagabend etwa eine Stunde lang an.
### Aktive Angriffe
#### Falschdarstellungsangriffe
Cwtch bietet keine globale Anzeigenamenregistrierung und daher sind Personen, die Cwtch verwenden, anfälliger für Angriffe, die auf falscher Darstellung beruhen, d. h. Personen, die vorgeben, andere Personen zu sein:
Ein grundlegender Ablauf eines dieser Angriffe sieht wie folgt aus, obwohl auch andere Abläufe existieren:
- Alice hat einen Freund namens Bob und einen anderen namens Eve
- Eve findet heraus, dass Alice einen Freund namens Bob hat
- Eve erstellt Tausende neuer Konten, um eines zu finden, das ein ähnliches Bild / einen ähnlichen öffentlichen Schlüssel wie Bob hat (wird nicht identisch sein, könnte aber jemanden für ein paar Minuten täuschen)
- Eve nennt dieses neue Konto "Eve Neues Konto" und fügt Alice als Freundin hinzu.
- Eve ändert dann ihren Namen auf "Eve Neues Konto" in "Bob"
- Alice sendet Nachrichten, die für „Bob“ bestimmt sind, an Eves gefälschtes Bob-Konto
Da es bei Angriffen mit falscher Darstellung an sich um Vertrauen und Verifizierung geht, besteht die einzige absolute Möglichkeit, sie zu verhindern, darin, dass Benutzer den öffentlichen Schlüssel absolut validieren. Das ist offensichtlich nicht ideal und wird in vielen Fällen einfach *nicht passieren*.
Daher möchten wir einige Hinweise zur Benutzererfahrung in der [ui](/security/category/cwtch-ui) bereitstellen, um Menschen bei der Entscheidung zu helfen, Konten zu vertrauen und/oder Konten zu unterscheiden die möglicherweise versuchen, sich als andere Benutzer auszugeben.
## Eine Anmerkung zu physischen Angriffen
Cwtch betrachtet Angriffe, die physischen Zugriff (oder gleichwertigen Zugriff) auf den Computer des Benutzers erfordern, nicht als praktisch verteidigbar. Im Interesse einer guten Sicherheitstechnik werden wir jedoch in diesem Dokument immer noch auf Angriffe oder Bedingungen verweisen, die ein solches Privileg erfordern und darauf hinweisen, wo von uns eingerichtete Minderungsmaßnahmen fehlschlagen.

6
i18n/es/docusaurus-plugin-content-blog/options.json
View File

@ -1,14 +1,14 @@
{
"title": {
"message": "Blog",
"message": "Development Log",
"description": "The title for the blog used in SEO"
},
"description": {
"message": "Blog",
"message": "The latest updated on Cwtch development.",
"description": "The description for the blog used in SEO"
},
"sidebar.title": {
"message": "Publicaciones recientes",
"message": "Recent Logs",
"description": "The label for the left sidebar"
}
}

12
i18n/es/docusaurus-plugin-content-docs/current/chat/add-contact.md
View File

@ -2,10 +2,16 @@
sidebar_position: 1.5
---
# Añadir un nuevo contacto
# Starting a New Conversation
1. Selecciona un perfil
2. Haz clic en el botón Añadir
3. Selecciona 'Agregar contacto'
5. Pega una dirección de Cwtch
6. El contacto se añadirá a tu lista de contactos
4. Pega una dirección de Cwtch
5. El contacto se añadirá a tu lista de contactos
:::info
This documentation page is a stub. You can help by [expanding it](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

6
i18n/es/docusaurus-plugin-content-docs/current/chat/block-contact.md
View File

@ -8,3 +8,9 @@ sidebar_position: 7
2. Ir a la Configuración
3. Desplázate hacia abajo hasta bloquear contacto
4. Mueve el interruptor para bloquear un contacto
:::info
This documentation page is a stub. You can help by [expanding it](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

11
i18n/es/docusaurus-plugin-content-docs/current/chat/delete-contact.md Normal file
View File

@ -0,0 +1,11 @@
---
sidebar_position: 10
---
# Removing a Conversation
:::info
This documentation page is a stub. You can help by [expanding it](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

19
i18n/es/docusaurus-plugin-content-docs/current/chat/share-address-with-friends.md
View File

@ -2,11 +2,26 @@
sidebar_position: 3
---
# Compartir una dirección de Cwtch
# Sharing Cwtch Addresses
There are many ways to share a Cwtch address.
## Sharing Your Cwtch Address
1. Ve a tu perfil
2. Haz clic en el icono de copiar dirección
Ahora puedes compartir esta dirección. Las personas con esta dirección podrán añadirte como un contacto de Cwtch.
Para obtener información sobre cómo bloquear conexiones de personas que no conoces, por favor consulta [Configuración: Bloquear Conexiones Desconocidas](/docs/settings/behaviour/block-unknown-connections)
Para obtener información sobre cómo bloquear conexiones de personas que no conoces, por favor consulta [Configuración: Bloquear Conexiones Desconocidas](/docs/settings/behaviour/block-unknown-connections)
# Sharing A Friends Cwtch Address
Inside of Cwtch there is another mechanism for exchanging Cwtch addresses.
:::info
This documentation page is a stub. You can help by [expanding it](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

9
i18n/es/docusaurus-plugin-content-docs/current/chat/unblock-contact.md
View File

@ -7,4 +7,11 @@ sidebar_position: 8
1. Selecciona el contacto en tu lista de conversaciónes. Los contactos bloqueados se mueven al final de la lista.
2. Ve a la configuración de conversación
3. Desplázate hacia abajo para bloquear contacto
4. Mueve el interruptor para desbloquear contacto
4. Mueve el interruptor para desbloquear contacto
:::info
This documentation page is a stub. You can help by [expanding it](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

51
i18n/es/docusaurus-plugin-content-docs/current/contribute/developing.md Normal file
View File

@ -0,0 +1,51 @@
---
sidebar_position: 1
---
# Developing Cwtch
This section documents some ways to get started with Cwtch Development.
## Cwtch Issues Tracking Process
All Cwtch issues are tracked from the [cwtch-ui git repository](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues), even if the bug/feature originates in an upstream library. This allows us to keep everything in one place.
Issues are generally divided into 4 distinct categories:
- **Unprocessed** - These are new issues that have not been discussed by the Cwtch team.
- [**Scheduled**](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues?q=&type=all&state=open&labels=195&milestone=0&assignee=0&poster=0) - These issues have been planned for an upcoming release. They are usually tagged with the release they are expected to be fixed in e.g. `cwtch-1.11`. A core Cwtch team member is likely working on the issue, or is expecting to work on the issue in the coming weeks.
- [**Desired**](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues?q=&type=all&state=open&labels=153&milestone=0&assignee=0&poster=0) - These are issues that we would like to fix but for some reason we are unable to schedule. This might be because the feature is large and requires a lot of effort, or because there is some blocker (e.g. a missing feature in Flutter or some other library) that prevents work on the feature.
- [**Help Wanted**](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues?q=&type=all&state=open&labels=136&milestone=0&assignee=0&poster=0) - These are generally small issues that we would like to fix but that have been designated low priority. These are ideal first issues for volunteers.
If you would like to work on an open bug/feature, please comment on the issue and a member of the Cwtch team will follow up with advice on where to go from there. This helps us keep track of who is working on what problems, and reduces the amount of duplicate work. We aim to answer most queries within 24 hours, feel free to "bump" an issue if it takes longer than that.
:::note
Due to an issue with our email provider, we are currently unable to consistently send email from our gitea instance. Please regularly check open issues / pull-requests for updates (or subscribe to the repository's RSS feeds)
:::
## Cwtch Pull-Request Process
All pull-requests must be reviewed and approved by a core Cwtch team member prior to merging. Sarah reviews all new and active pull requests multiple times a week.
### Build Bot
All Cwtch projects are set up with automated builds and testing. Every pull request is expected to be able to pass through these pipelines prior to being merged. If buildbot reports a failure then Sarah will work with you to determine the issue, and any necessary fixes.
Buildbot can fail for reasons beyond your control e.g. many of our integration tests rely setting up Tor connections, these can be brittle on occasion and result in timeouts and failures. Always confirm the root cause of a test failure before deciding what to do next.
## Useful Resources
- [Cwtch Ecosystem Overview](/security/components/ecosystem-overview) - a summary of active Cwtch repositories from the Cwtch Secure Development Handbook.
- [Contributing Documentation](/docs/contribute/documentation) - advice on contributing Cwtch documentation.
- [Contributing Testing](/docs/contribute/testing) - advice on contributing by testing Cwtch.
- [Contributing Translations](/docs/contribute/translate) - advice on contributing translations to Cwtch.
:::note
All contributions are [eligible for stickers](/docs/contribute/stickers)
:::

46
i18n/es/docusaurus-plugin-content-docs/current/contribute/documentation.md Normal file
View File

@ -0,0 +1,46 @@
---
sidebar_position: 6
---
# Documentation Style Guide
This section documents the expected structure and quality of Cwtch documentation.
## Screenshots and Cast of Characters
Most Cwtch documentation should feature at least one screenshot or animated image. Screenshots of the Cwtch application should be focused on the feature being described by the documentation.
To ensure consistency between screenshots we suggest that the profile involved should serve particular, constant, roles.
- **Alice** - used to represent the primary profile.
- **Bob** - the primary contact, useful when demonstrating peer-to-peer features
- **Carol** - a secondary contact, useful when demonstrating group features
- **Mallory** - representing a malicious peer (to be used when demonstrating blocking functionality)
## Dialogue and Content
Where screenshots and demonstrations show dialogue, conversations, and/or images please keep the conversations short, on a casual topic. Examples include:
- Organizing a picnic
- Sharing photos from a vacation
- Sending a document for review
## Experiments
All features that rely on an experiment being enabled should all this out prominently at the top of the page e.g.:
:::caution Experiments Required
This feature requires [Experiments Enabled](https://docs.cwtch.im/docs/settings/introduction#experiments) and the [Example Experiment](https://docs.cwtch.im/docs/settings/experiments/server-hosting) turned on.
:::
## Risks
If a feature might result in destruction of key material or permanent deletion of state, then these should also be called out at the top of the documentation e.g.:
:::warning
This feature will result in **irreversible** deletion of key material. This **cannot be undone**.
:::

10
i18n/es/docusaurus-plugin-content-docs/current/contribute/stickers.md Normal file
View File

@ -0,0 +1,10 @@
---
sidebar_position: 10
---
# Stickers
All contributions are eligible for stickers. If you are contributing to bug, feature, testing, or language, or have contributed significantly in the past then please email erinn@openprivacy.ca with details and an address for us to mail stickers to.
![A Photo of Cwtch Stickers](/img/stickers-new.jpg)

8
i18n/es/docusaurus-plugin-content-docs/current/contribute/testing.md
View File

@ -28,4 +28,10 @@ Las construcciones de Cwtch Nightly son construcciones de desarrollo que contien
Las versiones más recientes de desarrollo de Cwtch están disponibles en nuestro [servidor de compilación](https://build.openprivacy.ca/files/).
Nosotros **no** recomendamos que los testers se actualicen siempre a los últimos Nightlies. En su lugar publicaremos un mensaje en el Grupo de Pruebas de Candidatos de Lanzamientos de Cwtch cuando un Nightlie significativo se encuentre disponible. Un Nightly se considera significativo si contiene una nueva característica o una corrección importante de errores.
Nosotros **no** recomendamos que los testers se actualicen siempre a los últimos Nightlies. En su lugar publicaremos un mensaje en el Grupo de Pruebas de Candidatos de Lanzamientos de Cwtch cuando un Nightlie significativo se encuentre disponible. Un Nightly se considera significativo si contiene una nueva característica o una corrección importante de errores.
:::note
All contributions are [eligible for stickers](/docs/contribute/stickers)
:::

38
i18n/es/docusaurus-plugin-content-docs/current/contribute/translate.md
View File

@ -2,18 +2,40 @@
sidebar_position: 2
---
# Traducir Cwtch
# Translating Cwtch
Si quieres contribuir a la traducción de Cwtch o de este manual puedes aprender cómo aquí
## Aplicación de Cwtch
## Contributing Translations to the Cwtch Application
La aplicación se traduce a través de [Lokalize](https://lokalise.com).
1. Regístrate para obtener una cuenta en el sitio
2. Envía un correo electrónico a [team@cwtch.im](mailto:team@cwtch.im) diciendo que deseas traducir y la dirección de correo electrónico con la que te registraste. Te agregaremos al proyecto
There are two ways to contribute to Cwtch applications.
### Join our Lokalise Team
We use [Lokalise](https://lokalise.com) for managing translations for the Cwtch application.
1. Sign up for a Lokalise account
2. Email [team@cwtch.im](mailto:team@cwtch.im) with the language you are interested in translating and an email we can use to invite you to our Lokalise team.
### Directly via Git
For new translations, you can make a copy of [https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/branch/trunk/lib/l10n/intl_en.arb](https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/branch/trunk/lib/l10n/intl_en.arb) and begin translating - you can then either [submit pull requests or directly](/docs/contribute/developing#cwtch-pull-request-process) send updates to us (team@cwtch.im) and we will merge them in.
For adding to existing translations you can make pull requests directly on any file in [https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/branch/trunk/lib/l10n/](https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/branch/trunk/lib/l10n/) and we will review and merge them in.
## Manual del usuario de Cwtch
El manual se traduce a través de [Crowdin](https://crowdin.com).
1. Regístrate en el sitio.
2. Ve al proyecto [cwtch-users-handbook](https://crowdin.com/project/cwtch-users-handbook) y únete.
This handbook is translated through [Crowdin](https://crowdin.com).
To join our Crowdin project:
1. Sign up for an account on [Crowdin](https://crowdin.com).
2. Join the [cwtch-users-handbook project](https://crowdin.com/project/cwtch-users-handbook).
We bundle up changes to the documentation in batches and sync them with the Crowdin project on a regular basis.
:::note
All contributions are [eligible for stickers](/docs/contribute/stickers)
:::

7
i18n/es/docusaurus-plugin-content-docs/current/getting-started/_category_.json Normal file
View File

@ -0,0 +1,7 @@
{
"label": "Getting started",
"position": 2,
"link": {
"type": "generated-index"
}
}

39
i18n/es/docusaurus-plugin-content-docs/current/getting-started/supported_platforms.md Normal file
View File

@ -0,0 +1,39 @@
# Supported Platforms
The table below represents our current understanding of Cwtch support across various operating systems and architectures (as of Cwtch 1.10 and January 2023).
In many cases we are looking for testers to confirm that various functionality works. If you are interested in testing Cwtch on a specific platform, or want to volunteer to help us official support a platform not listed here, then check out [Contibuting to Cwtch](/docs/category/contribute).
**Legend:**
- ✅: **Officially Supported**. Cwtch should work on these platforms without issue. Regressions are treated as high priority.
- 🟡: **Best Effort Support**. Cwtch should work on these platforms but there may be documented or unknown issues. Testing may be needed. Some features may require additional work. Volunteer effort is appreciated.
- ❌: **Not Supported**. Cwtch is unlikely to work on these systems. We will probably not accept bug reports for these systems.
| Platform | Official Cwtch Builds | Source Support | Notes |
| --------------------------- | --------------------- | -------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| Windows 11 | ✅ | ✅ | 64-bit amd64 only. |
| Windows 10 | ✅ | ✅ | 64-bit amd64 only. Not officially supported, but official builds may work. |
| Windows 8 and below | ❌ | 🟡 | Not supported. Dedicated builds from source may work. Testing Needed. |
| OSX 10 and below | ❌ | 🟡 | 64-bit Only. Official builds have been reported to work on Catalina but not High Sierra |
| OSX 11 | ✅ | ✅ | 64-bit Only. Official builds supports both arm64 and x86 architectures. |
| OSX 12 | ✅ | ✅ | 64-bit Only. Official builds supports both arm64 and x86 architectures. |
| OSX 13 | ✅ | ✅ | 64-bit Only. Official builds supports both arm64 and x86 architectures. |
| Debian 11 | ✅ | ✅ | 64-bit amd64 Only. |
| Debian 10 | 🟡 | ✅ | 64-bit amd64 Only. |
| Debian 9 and below | 🟡 | ✅ | 64-bit amd64 Only. Builds from source should work, but official builds may be incompatible with installed dependencies. |
| Ubuntu 22.04 | ✅ | ✅ | 64-bit amd64 Only. |
| Other Ubuntu | 🟡 | ✅ | 64-bit Only. Testing needed. Builds from source should work, but official builds may be incompatible with installed dependencies. |
| CentOS | 🟡 | 🟡 | Testing Needed. |
| Gentoo | 🟡 | 🟡 | Testing Needed. |
| Arch | 🟡 | 🟡 | Testing Needed. |
| Whonix | 🟡 | 🟡 | [Known Issues. Specific changes to Cwtch are required for support. ](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues/550) |
| Raspian (arm64) | 🟡 | ✅ | Builds from source work. |
| Other Linux Distributions | 🟡 | 🟡 | Testing Needed. |
| Android 9 and below | 🟡 | 🟡 | Official builds may work. |
| Android 10 | ✅ | ✅ | Official SDK supprts arm, arm64, and amd64 architectures. |
| Android 11 | ✅ | ✅ | Official SDK supprts arm, arm64, and amd64 architectures. |
| Android 12 | ✅ | ✅ | Official SDK supprts arm, arm64, and amd64 architectures. |
| Android 13 | ✅ | ✅ | Official SDK supprts arm, arm64, and amd64 architectures. |
| LineageOS | 🟡 | 🟡 | [Known Issues. Specific changes to Cwtch are required for support.](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues/607) |
| Other Android Distributions | 🟡 | 🟡 | Testing Needed. |

2
i18n/es/docusaurus-plugin-content-docs/current/groups/introduction.md
View File

@ -20,7 +20,7 @@ En muchos sentidos, la comunicación con un servidor es idéntica a la comunicac
Como tal, las conversaciones entre pares y servidores solo difieren en los *tipos* de mensajes que se envían entre las dos partes, con el servidor guardando todos los mensajes que recibe y permitiendo así que cualquier cliente busque mensajes antiguos.
El modelo de riesgo asociado con los servidores es más complicado que la comunicación entre pares. Como tal actualmente requerimos que las personas que quieren usar servidores dentro de Cwtch [habiliten el experimento de Chat de Grupos](/docs/settings/experiments/group-experiment) para añadir, administrar y crear grupos en servidores no confiables.
The risk model associated with servers is more complicated that peer-to-peer communication, as such we currently require people who want to use servers within Cwtch to [opt-in to the Group Chat experiment](/docs/settings/experiments/group-experiment) in order to add, manage and create groups on untrusted servers.
## Cómo funcionan los Grupos en profundidad

2
i18n/es/docusaurus-plugin-content-docs/current/profiles/create-a-profile.md
View File

@ -16,6 +16,6 @@ sidebar_position: 1.5
Los perfiles se almacenan localmente en el disco y se cifran usando una clave derivada de la contraseña conocida por el usuario (a través de pbkdf2).
Ten en cuenta que una vez cifrado, y almacenado en el disco, la única forma de recuperar un perfil es rederivando la contraseña - por lo que no es posible proporcionar una lista completa de perfiles a los que un usuario podría tener acceso hasta que introduzca una contraseña.
Note that, once encrypted and stored on disk, the only way to recover a profile is by rederiving the key from the password - as such it isn't possible to provide a full list of profiles a user might have access to until they enter a password.
Consultar: [Manual de seguridad de Cwtch.: Encriptación del perfil & Almacenamiento](https://docs.openprivacy.ca/cwtch-security-handbook/profile_encryption_and_storage.html)

2
i18n/es/docusaurus-plugin-content-docs/current/settings/appearance/streamer-mode.md
View File

@ -4,7 +4,7 @@ sidebar_position: 4
# Modo de streaming/presentación
El modo de streaming / presentación hace la aplicación más visualmente privada. En este modo, Cwtch no mostrará información auxiliar, como las direcciones de Cwtch y otra información confidencial en las pantallas principales.
El modo de streaming / presentación hace la aplicación más visualmente privada. In this mode, Cwtch will not display auxiliary information like Cwtch addresses and other sensitive information on the main screens.
Esto es útil cuando se toman capturas de pantalla o cuando se muestra Cwtch de una manera más pública.

4
i18n/es/docusaurus-plugin-content-docs/current/settings/behaviour/block-unknown-connections.md
View File

@ -4,9 +4,9 @@ sidebar_position: 1
# Bloquear Conexiones Desconocidas
De forma predeterminada, Cwtch interpreta las conexiones de direcciones Cwtch desconocidas como [Solicitudes de contacto](https://docs.cwtch.im/docs/chat/accept-deny-new-conversation). Puede cambiar este comportamiento a través de la configuración de Bloquear Conexiones Desconocidas.
By default, Cwtch interprets connections from unknown Cwtch addresses as [Contact Requests](https://docs.cwtch.im/docs/chat/accept-deny-new-conversation). Puede cambiar este comportamiento a través de la configuración de Bloquear Conexiones Desconocidas.
Si está activado, Cwtch cerrará automáticamente todas las conexiones de las direcciones de Cwtch que no has añadido a tu lista de contactos. Esto evitará que la gente que tenga su dirección cwtch se ponga en contacto contigo a menos que tu también los añadas.
Si está activado, Cwtch cerrará automáticamente todas las conexiones de las direcciones de Cwtch que no has añadido a tu lista de contactos. This will prevent people who have your Cwtch address from contacting you unless you also add them.
Para habilitar:

8
i18n/es/docusaurus-plugin-content-docs/current/settings/experiments/file-sharing.md
View File

@ -2,4 +2,10 @@
sidebar_position: 3
---
# Compartir Archivos
# Compartir Archivos
:::info
This documentation page is a stub. You can help by [expanding it](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

10
i18n/es/docusaurus-plugin-content-docs/current/settings/experiments/group-experiment.md
View File

@ -4,6 +4,14 @@ sidebar_position: 1
# Habilitar el Experimento de Grupos
:::info
This documentation page is a stub. You can help by [expanding it](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::
1. Ir a Configuración
2. Habilitar Experimentos
3. Habilitar el Experimento de Grupos
3. Habilitar el Experimento de Grupos

8
i18n/es/docusaurus-plugin-content-docs/current/settings/experiments/image-previews-and-profile-pictures.md
View File

@ -2,4 +2,10 @@
sidebar_position: 4
---
# Vista previa de imágenes y fotos de perfil
# Vista previa de imágenes y fotos de perfil
:::info
This documentation page is a stub. You can help by [expanding it](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

6
i18n/es/docusaurus-plugin-content-docs/current/settings/experiments/message-formatting.md
View File

@ -3,3 +3,9 @@ sidebar_position: 6
---
# Formato de mensajes
:::info
This documentation page is a stub. You can help by [expanding it](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

11
i18n/es/docusaurus-plugin-content-docs/current/settings/experiments/qrcodes.md Normal file
View File

@ -0,0 +1,11 @@
---
sidebar_position: 9
---
# QR Codes
:::info
This documentation page is a stub. You can help by [expanding it](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

4
i18n/es/docusaurus-plugin-content-docs/current/settings/introduction.md
View File

@ -6,11 +6,11 @@ sidebar_position: 1
## Apariencia
Estos son los ajustes que afectan cómo se ve cwtch, incluyendo temas y localización.
These are settings which effect how Cwtch looks, including themes and localization.
## Comportamiento
Estos ajustes impactan la respuesta de cwtch a ciertos eventos, por ejemplo, notificaciones de nuevos mensajes, o solicitudes de direcciones públicas desconocidas.
These settings impact how Cwtch responds to certain events e.g. notifications for new messages, or requests from unknown public addresses.
## Experimentos

7
i18n/es/docusaurus-plugin-content-security/current/components/_category_.json Normal file
View File

@ -0,0 +1,7 @@
{
"label": "Cwtch Components",
"position": 4,
"link": {
"type": "generated-index"
}
}

7
i18n/es/docusaurus-plugin-content-security/current/components/connectivity/_category_.json Normal file
View File

@ -0,0 +1,7 @@
{
"label": "Connectivity & Tor",
"position": 4,
"link": {
"type": "generated-index"
}
}

43
i18n/es/docusaurus-plugin-content-security/current/components/connectivity/intro.md Normal file
View File

@ -0,0 +1,43 @@
---
sidebar_position: 3
---
# Connectivity
Cwtch makes use of Tor Onion Services (v3) for all inter-node communication.
We provide the [openprivacy/connectivity](https://git.openprivacy.ca/openprivacy/connectivity) package for managing the Tor daemon and setting up and tearing down onion services through Tor.
## Known Risks
### Private Key Exposure to the Tor Process
**Status: Partially Mitigated** (Requires Physical Access or Privilege Escalation to exploit)
We must pass the private key of any onion service we wish to set up to the connectivity library, through the `Listen` interface (and thus to the Tor process). This is one of the most critical areas that is outside of our control. Any binding to a rouge tor process or binary will result in compromise of the Onion private key.
### Mitigations
Connectivity attempt to bind to the system-provided Tor process as the default, *only* when it has been provided with an authentication token.
Otherwise connectivity always attempts to deploy its own Tor process using a known good binary packaged with the system (outside of the scope of the connectivity package)
In the long term we hope an integrated library will become available and allow direct management through an in-process interface to prevent the private key from leaving the process boundary (or other alternative paths that allow us to maintain full control over the private key in-memory.)
### Tor Process Management
**Status: Partially Mitigated** (Requires Physical Access or Privilege Escalation to exploit)
Many issues can arise from the management of a separate process, including the need to restart, exit and otherwise ensure appropriate management.
The [ACN](https://git.openprivacy.ca/openprivacy/connectivity/src/branch/master/acn.go) interface provides `Restart`, `Close` and `GetBootstrapStatus` interfaces to allow applications to manage the underlying Tor process. In addition the `SetStatusCallback` method can be used to allow an application to be notified when the status of the Tor process changes.
However, if sufficiently-privileged users wish they can interfere with this mechanism, and as such the Tor process is a more brittle component interaction than others.
## Testing Status
Current connectivity has limited unit testing capabilities and none of these are run during pull requests or merges. There is no integration testing.
It is worth noting that connectivity is used by both Tapir and Cwtch in their integration tests (and so despite the lack of package level testing, it is exposed to system-wide test conditions)

7
i18n/es/docusaurus-plugin-content-security/current/components/cwtch/_category_.json Normal file
View File

@ -0,0 +1,7 @@
{
"label": "Cwtch",
"position": 5,
"link": {
"type": "generated-index"
}
}

41
i18n/es/docusaurus-plugin-content-security/current/components/cwtch/groups.md Normal file
View File

@ -0,0 +1,41 @@
---
sidebar_position: 4
---
# Groups
For the most part the Cwtch risk model for groups is split into two distinct profiles:
* Groups made up of mutually trusted participants where peers are assumed honest.
* Groups consisting of strangers where peers are assumed to be potentially malicious.
Most of the mitigations described in this section relate to the latter case, but naturally also impact the former. Even if assumed honest peers later turn malicious there are mechanisms that can detect such malice and prevent it from happening in the future.
## Risk Overview: Key Derivation
In the ideal case we would use a protocol like OTR, the limitations preventing us from doing so right now are:
* Offline messages are not guaranteed to reach all peers, and as such any metadata relating to key material might get lost. We need a key derivation process which is robust to missing messages or incomplete broadcast.
## Risk: Malicious Peer Leaks Group Key and/or Conversation
**Status: Partially Mitigated (but impossible to mitigate fully)**
Whether dealing with trusted smaller groups or partially-public larger groups there is *always* the possibility that a malicious actor will leak group messages.
We plan to make it easy for peers to [fork](#fork) groups to mitigate the same key being used to encrypt lots of sensitive information and provide some level of forward secrecy for past group conversations.
## Risk: Active Attacks by Group Members
**Status: Partially Mitigated**
Group members, who have access to the key material of the group, can conspire with a server or other group members to break transcript consistency.
While we cannot directly prevent censorship given this kind of active collusion, we have a number of mechanisms in place that should reveal the presence of censorship to honest members of the group.
### Mitigations:
* Because each message is signed by the peers public key, it should not be possible (within the cryptographic assumptions of the underlying cryptography) for one group member to imitate another.
* Each message contains a unique identifier derived from the contents and the previous message hash - making it impossible for collaborators to include messages from non-colluding members without revealing an implicit message chain (which if they were attempting to censor other messages would reveal such censorship)
Finally: We are actively working on adding non-repudiation to Cwtch servers such that they themselves are restricted in what they can censor efficiently.

28
i18n/es/docusaurus-plugin-content-security/current/components/cwtch/key_bundles.md Normal file
View File

@ -0,0 +1,28 @@
---
sidebar_position: 3
---
# Key Bundles
Cwtch servers identify themselves through signed key bundles. These key bundles contain a list of keys necessary to make Cwtch group communication secure and metadata resistant.
At the time of writing, key bundles are expected to contain 3 keys:
1. A Tor v3 Onion Service Public Key for the Token Board (ed25519)- used to connect to the service over Tor to post and receive messages.
2. A Tor v3 Onion Service Public Key for the Token Service (ed25519) - used to acquire tokens to post on the service via a small proof-of-work exercise.
3. A Privacy Pass Public Key - used in the token acquisition process (a ristretto curve point) . See: [OPTR2019-01](https://openprivacy.ca/research/OPTR2019-01/)
The key bundle is signed and can be verified via the first v3 onion service key, thus binding it to that particular oninon address.
## Verifying Key Bundles
Profiles who import server key bundles verify them using the following trust-on-first-use (TOFU) algorithm:
1. Verify the attached signature using the v3 onion address of the server. (If this fails, the import process is halted)
2. Check that every key type exists. (If this fails, the import process is halted)
3. If the profile has imported the server key bundle previously, assert that all the keys are the same. (If this fails, the import process is halted)
4. Save the keys to the servers contact entry.
In the future this algorithm will likely be altered to allow the addition of new public keys (e.g. to allow tokens to be acquired via a Zcash address.)
Technically, at steps (2) and (3() the server can be assumed to be malicious, having signed a valid key bundle that does not conform to the specifications. When groups are moved from "experimental" to "stable" such an action will result in a warning being communicated to the profile.

57
i18n/es/docusaurus-plugin-content-security/current/components/cwtch/message_formats.md Normal file
View File

@ -0,0 +1,57 @@
---
sidebar_position: 2
---
# Message Formats
## Peer to Peer Messages
PeerMessage {
ID string // A unique Message ID (primarily used for acknowledgments)
Context string // A unique context identifier i.e. im.cwtch.chat
Data []byte // The context-dependent serialized data packet.
}
### Context Identifiers
* `im.cwtch.raw` - Data contains a plain text chat message (see: [overlays](../ui/overlays.md) for more information)
* `im.cwtch.acknowledgement` - Data is empty and ID references a previously sent message
* `im.cwtch.getVal` and `im.cwtch.retVal` - Used for requesting / returning specific information about a peer. Data contains a serialized `peerGetVal` structure and `peerRetVal` respectively.
peerGetVal struct {
Scope string
Path string
}
type peerRetVal struct {
Val string // Serialized path-dependent value
Exists bool
}
## Plaintext / Decrypted Group Messages
type DecryptedGroupMessage struct {
Text string // plaintext of the message
Onion string // The Cwtch address of the sender
Timestamp uint64 // A user specified timestamp
// NOTE: SignedGroupID is now a misnomer, the only way this is signed is indirectly via the signed encrypted group messages
// We now treat GroupID as binding to a server/key rather than an "owner" - additional validation logic (to e.g.
// respect particular group constitutions) can be built on top of group messages, but the underlying groups are
// now agnostic to those models.
SignedGroupID []byte
PreviousMessageSig []byte // A reference to a previous message
Padding []byte // random bytes of length = 1800 - len(Text)
}
DecryptedGroupMessage contains random padding to a fixed size that is equal to the length of all fixed length fields + 1800. This ensures that all encrypted group messages are equal length.
## Encrypted Group Messages
// EncryptedGroupMessage provides an encapsulation of the encrypted group message stored on the server
type EncryptedGroupMessage struct {
Ciphertext []byte
Signature []byte // Sign(groupID + group.GroupServer + base64(decrypted group message)) using the senders Cwtch key
}
Calculating the signature requires knowing the groupID of the message, the server the group is associated with and the decrypted group message (and thus, the Group Key). It is (ed25519) signed by the sender of the message, and can be verified using their public Cwtch address key.

60
i18n/es/docusaurus-plugin-content-security/current/components/cwtch/server.md Normal file
View File

@ -0,0 +1,60 @@
# Cwtch Server
The goal of the Cwtch protocol is to enable group communication through **Untrusted Infrastructure**.
Unlike in relay-based schemes where the groups assign a leader, set of leaders, or a trusted third party server to ensure that every member of the group can send and receive messages in a timely manner (even if members are offline) - untrusted infrastructure has a goal of realizing those properties without the assumption of trust.
The original Cwtch paper defined a set of properties that Cwtch Servers were expected to provide:
* Cwtch Server may be used by multiple groups or just one.
* A Cwtch Server, without collaboration of a group member, should never learn the identity of participants within a group.
* A Cwtch Server should never learn the content of any communication.
* A Cwtch Server should never be able to distinguish messages as belonging to a particular group.
We note here that these properties are a superset of the design aims of Private Information Retrieval structures.
## Malicious Servers
We expect the presence of malicious entities within the Cwtch ecosystem.
We also prioritize decentralization and permissionless entry into the ecosystem and as such we do not base any security claims on the following:
* Any non-collusion assumptions between a set of Cwtch servers
* Any third-party defined verification process
Peers themselves are encouraged to set up and run Cwtch servers where they can guarantee more efficient properties by relaxing trust and security assumptions - however, by default, we design the protocol to be secure without these assumptions - sacrificing efficiency where necessary.
### Detectable Faults
* If a Cwtch server fails to relay a specific message to a subset of group members then there will be a detectable gap in the message tree of certain peers that can be discovered through peer-to-peer gossip.
* A Cwtch server cannot modify any message without the key material known to the group (any attempt to do so for a subset of group members will result in identical behavior to failing to relay a message).
* While a server *can* duplicate messages, these will have no impact on the group message tree (because of encryption, nonces and message identities) - the source of the duplication is not knowable to a peer.
## Efficiency
As of writing, only 1 protocol is known for achieving the desired properties, naive PIR or "the server sends everything, and the peers sift through it".
This has an obvious impact on bandwidth efficiency, especially for peers using mobile devices, as such we are actively developing new protocols in which the privacy and efficiency guarantees can be traded-off in different ways.
As of writing, the servers allow both a complete download of all stored messages, and a request to download messages from a certain specified message.
All peers when they first join a group on a new server download all messages from the server, and from then on download only new messages.
*Note*: This behaviour does permit a mild form of metadata analysis. The server can new messages for each suspected unique profile, and then use these unique message signatures to track unique sessions over time ( via requests for new messages).
This is mitigated by 2 confounding factors:
1. Profiles can refresh their connections at any time - resulting in fresh server session.
2. Profiles can "resync" from a server at any time - resulting in a new call to download all messages. The most common usecase for this behaviour is to fetch older messages from a group.
In combination, these 2 mitigations place bounds on what the server is able to infer however we still cannot provide full metadata-resistance.
For potential future solutions to this problem see [Niwl](https://git.openprivacy.ca/openprivacy/niwl)
# Protecting the Server from Malicious Peers
The main risk to servers come in the form of spam generated by peers. In the prototype of Cwtch a spamguard mechanism was put in place that required peers to conduct some arbitrary proof of work given a server-specified parameter.
This is not a robust solution in the presence of a determined adversary with a significant amount of resources, and thus one of the main external risks to the Cwtch system becomes censorship-via-resource exhaustion.
We have outlined a potential solution to this in [token based services](https://openprivacy.ca/research/OPTR2019-01/) but note that this also requires further development.

70
i18n/es/docusaurus-plugin-content-security/current/components/ecosystem-overview.md Normal file
View File

@ -0,0 +1,70 @@
---
sidebar_position: 1.5
---
# Component Ecosystem Overview
Cwtch is made up of several smaller component libraries. This chapter will provide a brief overview of each component and how it relates to the wider Cwtch ecosystem.
## [openprivacy/connectivity](https://git.openprivacy.ca/openprivacy/connectivity)
Summary: A library providing an ACN (Anonymous Communication Network ) networking abstraction.
The goal of connectivity is to abstract away the underlying libraries/software needed to communicate with a specific ACN. Right now we only support Tor and so the job of connectivity is to:
* Start and Stop the Tor Process
* Provide configuration to the Tor process
* Allow raw connections to endpoints via the Tor process (e.g. connect to onion services)
* Host endpoints via the Tor process (e.g. host onion services)
* Provide status updates about the underlying Tor process
For more information see [connectivity](/security/components/connectivity/intro)
## [cwtch.im/tapir](https://git.openprivacy.ca/cwtch.im/tapir)
Summary: Tapir is a small library for building p2p applications over anonymous communication systems.
The goal of tapir is to abstract away **applications** over a particular ACN. Tapir supports:
* Creating a cryptographic identity (including ephemeral identities)
* Maintaining a connection pool of inbound and outbound connections to services
* Handling various application-layers including cryptographic transcripts, [authentication and authorization protocols](/security/components/tapir/authentication_protocol), and [token-based services via PrivacyPass](https://openprivacy.ca/research/OPTR2019-01/),
For more information see [tapir](/security/components/tapir/authentication_protocol)
## [cwtch.im/cwtch](https://git.openprivacy.ca/cwtch.im/cwtch)
Summary: Cwtch is the main library for implementing the Cwtch protocol / system.
The goal of Cwtch is to provide implementations for cwtch-specific applications e.g. message sending, groups, and file sharing(implemented as Tapir applications), provide interfaces for managing and storing Cwtch profiles, provide an event bus for subsystem splutting and building plugins with new functionality, in addition to managing other core functionality.
The Cwtch library is also responsible for maintaining canonical model representations for wire formats and overlays.
## [cwtch.im/libcwtch-go](https://git.openprivacy.ca/cwtch.im/libcwtch-go)
Summary: libcwtch-go provides C (including Android) bindings for Cwtch for use in UI implementations.
The goal of libcwtch-go is to bridge the gap between the backend Cwtch library and any front end systems which may be written in a different language.
The API provided by libcwtch is much more restricted than the one provided by Cwtch directly, each libcwtch API typically packages up several calls to Cwtch.
libcwtch-go is also responsible for managing UI settings and experimental gating. It is also often used as a staging ground for experimental features and code that may eventually end up in Cwtch.
## [cwtch-ui](https://git.openprivacy.ca/cwtch.im/cwtch-ui)
Summary: A flutter based UI for Cwtch.
Cwtch UI uses libcwtch-go to provide a complete UI for Cwtch, allowing people to create and manage profiles, add contacts and groups, message people, share files (coming soon) and more.
The UI is also responsible for managing localization and translations.
For more information see [Cwtch UI](/security/category/cwtch-ui)
## Auxiliary Components
Occasionally, Open Privacy will factor out parts of Cwtch into standalone libraries that are not Cwtch specific. These are briefly summarized here:
### [openprivacy/log](https://git.openprivacy.ca/openprivacy/log)
An Open Privacy specific logging framework that is used throughout Cwtch packages.

49
i18n/es/docusaurus-plugin-content-security/current/components/intro.md Normal file
View File

@ -0,0 +1,49 @@
---
sidebar_position: 1
---
# Cwtch Technical Basics
This page presents a brief technical overview of the Cwtch protocol.
## A Cwtch Profile
Users can create one of more Cwtch Profiles. Each profile generates a random ed25519 keypair compatible with Tor.
In addition to the cryptographic material, a profile also contains a list of Contacts (other Cwtch profile public keys + associated data about that profile like nickname and (optionally) historical messages), a list of Groups (containing the group cryptographic material in addition to other associated data like the group nickname and historical messages).
## 2-party conversions: Peer to Peer
![](/img/BASE_3.png)
For 2 parties to engage in a peer-to-peer conversation both must be online, but only one needs to be reachable via their onion service. For the sake of clarity we often label one party the "inbound peer" (the one who hosts the onion service) and the other party the "outbound peer" (the one that connects to the onion service).
After connection both parties engage in an authentication protocol which:
* Asserts that each party has access to the private key associated with their public identity.
* Generates an ephemeral session key used to encrypt all further communication during the session.
This exchange (documented in further detail in [authentication protocol](tapir/authentication_protocol.md)) is *offline deniable* i.e. it is possible for any party to forge transcripts of this protocol exchange after the fact, and as such - after the fact - it is impossible to definitely prove that the exchange happened at all.
After, the authentication protocol the two parties may exchange messages with each other freely.
## Multi-party conversations: Groups and Peer to Server Communication
**Note: Metadata Resistant Group Communication is still an active research area and what is documented here will likely change in the future.**
When a person wants to start a group conversation they first randomly generate a secret `Group Key`. All group communication will be encrypted using this key.
Along with the `Group Key`, the group creator also decides on a **Cwtch Server** to use as the host of the group. For more information on how Servers authenticate themselves see [key bundles](cwtch/key_bundles.md).
A `Group Identifier` is generated using the group key and the group server and these three elements are packaged up into an invite that can be sent to potential group members (e.g. over existing peer-to-peer connections).
To send a message to the group, a profile connects to the server hosting the group (see below), and encrypts their message using the `Group Key` and generates a cryptographic signature over the `Group Id`, `Group Server` and the decrypted message (see: [wire formats](cwtch/message_formats.md) for more information).
To receive message from the group, a profile connected to the server hosting the group and downloads *all* messages (since their previous connection). Profiles then attempt to decrypt each message using the `Group Key` and if successful attempt to verify the signature (see [Cwtch Servers](cwtch/server.md) [Cwtch Groups](./cwtch/groups.md) for an overview of attacks and mitigations).
### Servers are Peers
In many respects communication with a server is identical to communication with a regular Cwtch peer, all the same steps above are taken however the server always acts as the inbound peer, and the outbound peer always uses newly generated **ephemeral keypair** as their "longterm identity".
As such peer-server conversations only differ in the *kinds* of messages that are sent between the two parties, with the server relaying all messages that it receives and also allowing any client to query for older messages.

7
i18n/es/docusaurus-plugin-content-security/current/components/tapir/_category_.json Normal file
View File

@ -0,0 +1,7 @@
{
"label": "Tapir",
"position": 4,
"link": {
"type": "generated-index"
}
}

34
i18n/es/docusaurus-plugin-content-security/current/components/tapir/authentication_protocol.md Normal file
View File

@ -0,0 +1,34 @@
---
sidebar_position: 2
---
# Authentication Protocol
Each peer, given an open connection $C$:
$$ I = \mathrm{InitializeIdentity()} \\
I_e = \mathrm{InitializeEphemeralIdentity()} \\ I,I_e \rightarrow C \\
P,P_e \leftarrow C \\ k = \mathrm{KDF}({P_e}^{i} + {P}^{i_e} + {P_e}^{i_e}) \\
c = \mathrm{E}(k, transcript.Commit()) \\ c \rightarrow C \\
c_p \leftarrow C\\ \mathrm{D}(k, c_p) \stackrel{?}{=} transcript.LatestCommit() $$
The above represents a sketch protocol, in reality there are a few implementation details worth pointing out:
Once derived from the key derivation function ($\mathrm{KDF}$) the key ($k$) is set *on* the connection, meaning the authentication app doesn't do the encryption or decryption explicitly.
The concatenation of parts of the 3DH exchange is strictly ordered:
* DH of the Long term identity of the outbound connection by the ephemeral key of the inbound connection.
* DH of the Long term identity of the inbound connection by the ephemeral key of the outbound connection.
* DH of the two ephemeral identities of the inbound and outbound connections.
This strict ordering ensures both sides of the connection derive the *same* session key.
### Cryptographic Properties
During an online-session, all messages encrypted with the session key can be authenticated by the peers as having come from their peer (or at least, someone with possession of their peers secret key as it related to their onion address).
Once the session has ended, a transcript containing the long term and ephemeral public keys, a derived session key and all encrypted messages in the session cannot be proven to be authentic i.e. this protocol provides message & participant repudiation (offline deniable) in addition to message unlinkability (offline deniable) in the case where someone is satisfied that a single message in the transcript must have originated from a peer, there is no way of linking any other message to the session.
Intuition for the above: the only cryptographic material related to the transcript is the derived session key - if the session key is made public it can be used to forge new messages in the transcript - and as such, any standalone transcript is subject to forgery and thus cannot be used to cryptographically tie a peer to a conversation.

15
i18n/es/docusaurus-plugin-content-security/current/components/tapir/packet_format.md Normal file
View File

@ -0,0 +1,15 @@
---
sidebar_position: 1
---
# Packet Format
All tapir packets are fixed length (8192 bytes) with the first 2 bytes indicated the actual length of the message, `len` bytes of data, and the rest zero padded:
| len (2 bytes) | data (len bytes) | paddding (8190-len bytes)|
Once encrypted, the entire 8192 byte data packet is encrypted using [libsodium secretbox](https://libsodium.gitbook.io/doc/secret-key_cryptography/secretbox) using the standard structure ( note in this case the actual usable size of the data packet is 8190-14 to accommodate the nonce included by secret box)
For information on how the secret key is derived see the [authentication protocol](authentication_protocol.md)

7
i18n/es/docusaurus-plugin-content-security/current/components/ui/_category_.json Normal file
View File

@ -0,0 +1,7 @@
{
"label": "Cwtch UI",
"position": 7,
"link": {
"type": "generated-index"
}
}

28
i18n/es/docusaurus-plugin-content-security/current/components/ui/android.md Normal file
View File

@ -0,0 +1,28 @@
# Android Service
[Adapted from: Discreet Log #11: Integrating FFI processes with Android services](https://openprivacy.ca/discreet-log/11-android-ffi-service-integration/)
In addition to needing to make plain ol’ method calls into the Cwtch library, we also need to be able to communicate with (and receive events from) long-running Cwtch goroutines that keep the Tor process running in the background, manage connection and conversation state for all your contacts, and handle a few other monitoring and upkeep tasks as well. This isn’t really a problem on traditionally multitasking desktop operating systems, but on mobile devices running Android we have to contend with shorter sessions, frequent unloads, and network and power restrictions that can vary over time. As Cwtch is intended to be metadata resistant and privacy-centric, we also want to provide notifications without using the Google push notification service.
The solution for long-running network apps like Cwtch is to put our FFI code into an Android Foreground Service. (And no, it’s not lost on me that the code for our backend is placed in something called a ForegroundService.) With a big of finagling, the WorkManager API allows us to create and manage various types of services including ForegroundServices. This turned out to be a great choice for us, as our gomobile FFI handler happened to already be written in Kotlin, and WorkManager allows us to specify a Kotlin coroutine to be invoked as the service.
If you’d like to follow along, our WorkManager specifications are created in the handleCwtch() method of [MainActivity.kt](https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/branch/trunk/android/app/src/main/kotlin/im/cwtch/flwtch/MainActivity.kt), and the workers themselves are defined in [FlwtchWorker.kt](https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/branch/trunk/android/app/src/main/kotlin/im/cwtch/flwtch/FlwtchWorker.kt).
Our plain ol’ method calls to FFI routines are also upgraded to be made as WorkManager work requests, which allows us to conveniently pass the return values back via the result callback.
One initial call (aptly named Start) gets hijacked by FlwtchWorker to become our eventbus loop. Since FlwtchWorker is a coroutine, it’s easy for it to yield and resume as necessary while waiting for events to be generated. Cwtch’s goroutines can then emit events, which will be picked up by FlwtchWorker and dispatched appropriately.
FlwtchWorker’s eventbus loop is not just a boring forwarder. It needs to check for certain message types that affect the Android state; for example, new message events should typically display notifications that the user can click to go to the appropriate conversation window, even when the app isn’t running in the foreground. When the time does come to forward the event to the app, we use LocalBroadcastManager to get the notification to MainActivity.onIntent. From there, we in turn use Flutter MethodChannels to forward the event data from Kotlin into the frontend’s Flutter engine, where the event finally gets parsed by Dart code that updates the UI as necessary.
Messages and other permanent state are stored on disk by the service, so the frontend doesn’t need to be updated if the app isnt open. However, some things (like dates and unread messages) can then lead to desyncs between the front and back ends, so we check for this at app launch/resume to see if we need to reinitialize Cwtch and/or resync the UI state.
Finally, while implementing these services on Android we observed that WorkManager is very good at persisting old enqueued work, to the point that old workers were even being resumed after app reinstalls! Adding calls to pruneWork() helps mitigate this, as long as the app was shut down gracefully and old jobs were properly canceled. This frequently isn’t the case on Android, however, so as an additional mitigation we found it useful to tag the work with the native library directory name:
private fun getNativeLibDir(): String {
val ainfo = this.applicationContext.packageManager.getApplicationInfo(
"im.cwtch.flwtch", // Must be app name
PackageManager.GET_SHARED_LIBRARY_FILES)
return ainfo.nativeLibraryDir
}
…then, whenever the app is launched, we cancel any jobs that aren’t tagged with the correct current library directory. Since this directory name changes between app installs, this technique prevents us from accidentally resuming with an outdated service worker.

29
i18n/es/docusaurus-plugin-content-security/current/components/ui/image_previews.md Normal file
View File

@ -0,0 +1,29 @@
# Image Previews
Built on the back of filesharing in Cwtch 1.3, image previews are keyed by the suggested filename’s extension (and no, we’re not interested in using MIME types or magic numbers) and advertised size. If enabled, the preview system will automatically download shared images to a configured downloads folder and display them as part of the message itself. (Due to limitations on Android, they’ll go to the app’s private storage cache, and give you the option to save them elsewhere later instead.) The file size limit is TBD but will obviously be much lower than the overall filesharing size limit, which is currently 10 gigabytes.
For now, we only support single-image messages, and any image editing/cropping will have to be done in a separate application. As we mention in the filesharing FAQ, image files also frequently contain significant hidden metadata, and you should only share them with people you trust.
## KnownRisks
## Other Applications and/or the OS Inferring Information from Images
Images must be stored somewhere, and for now we have chosen to store them unencrypted on the file system. We have done this for 2 reasons:
1. In order to support more powerful file sharing schemes like rehosting we require the ability to efficiently scan files and deliver chunks - doing this through an encrypted database layer would harm performance.
2. This information always has to transit the application boundary (either via display drivers, or storing and viewing the file in an external application) - there is nothing that Cwtch can do after that point in any case.
## Malicious Images Crashing or otherwise Compromising Cwtch
Flutter uses Skia to render Images. While the underlying code is memory unsafe, it is [extensively fuzzed](https://github.com/google/skia/tree/main/fuzz) as part of regular development.
We also conduct our own fuzz testing of Cwtch components. In that analysis we found a single crash bug related to a malformed GIF file that caused the renderer to allocate a ridiculous amount of memory (and eventually be refused by the kernel). To prevent this from impacting Cwtch we have adopted the policy of always enabling a maximum `cacheWidth` and/or `cacheHeight` for Image widgets.
## Malicious Images Rendering Differently on Different Platforms, Potentially Exposing Metadata
Recently [a bug was found in Apple's png parser](https://www.da.vidbuchanan.co.uk/widgets/pngdiff/) which would cause an image to render differently on Apple devices as it would on non-Apple devices.
We conducted a few tests on our Mac builds and could not replicate this issue for Flutter (because all Flutter builds use Skia for rendering), however we will continue to include such cases in our testing corpus.
For now image previews will remain experimental and opt-in.

18
i18n/es/docusaurus-plugin-content-security/current/components/ui/input.md Normal file
View File

@ -0,0 +1,18 @@
# Input
## Risk: Interception of Cwtch content or metadata through an IME on Mobile Devices
**Status: Partially Mitigated**
Any component that has the potential to intercept data between a person, and the Cwtch app is a potential security risk.
One of the most likely interceptors is a 3rd party IME (Input Method Editor) commonly used by people to generate characters not natively supported by their device.
Even benign and stock IME apps may unintentionally leak information about the contents of a persons message e.g. through cloud synchronization, cloud translation or personal dictionaries.
Ultimately, this problem cannot be solved by Cwtch alone, and is a wider risk impacting the entire mobile ecosystem.
A similar risk exists on desktop through the use of similar input applications (in addition to software keyloggers), however we consider that fully outside the scope of Cwtch risk assessment (in line with other attacks on the security of the underlying operating system itself).
This is partially mitigated in Cwtch 1.2 through the use of `enableIMEPersonalizedLearning: false`. See [this PR](https://git.openprivacy.ca/cwtch.im/cwtch-ui/pulls/142) for more information.

72
i18n/es/docusaurus-plugin-content-security/current/components/ui/overlays.md Normal file
View File

@ -0,0 +1,72 @@
# Message Overlays
[Adapted from: Discreet Log #8: Notes on the Cwtch Chat API](https://openprivacy.ca/discreet-log/08-chatapi/)
**Note: This section covers overlay protocols on-top of the Cwtch protcol. For information on the Cwtch Protocol messages themselves please see [Message Formats](../cwtch/message_formats.md)**
We envision Cwtch as a platform for providing an authenticated transport layer to higher-level applications. Developers are free to make their own choices about what application layer protocols to use, whether they want bespoke binary message formats or just want to throw an HTTP library on top and call it a day. Cwtch can generate new keypairs for you (which become onion addresses; no need for any DNS registrations!) and you can REST assured that any data your application receives from the (anonymous communication) network has been authenticated already.
For our current stack, messages are wrapped in a minimal JSON frame that adds some contextual information about the message type. And because serialised JSON objects are just dictionaries, we can easily add more metadata later on as needed.
## Chat overlays, lists, and bulletins
The original Cwtch alpha demoed "overlays": different ways of interpreting the same data channel, depending on the structure of the atomic data itself. We included simple checklists and BBS/classified ads as overlays that could be viewed and shared with any Cwtch contact, be it a single peer or a group. The wire format looked like this:
```
{o:1,d:"hey there!"}
{o:2,d:"bread",l:"groceries"}
{o:3,d:"garage sale",p:"[parent message signature]"}
```
Overlay field `o` determined if it was a chat (1), list (2), or bulletin (3) message. The data field `d` is overloaded, and lists/bulletins need additional information about what group/post they belong to. (We use message signatures in place of IDs to avoid things like message ordering problems and maliciously crafted IDs. This is also how the Cwtch protocol communicates to the front end which message is being acked.)
## Data structure
Implementing tree-structured data on top of a sequential message store comes with obvious performance disadvantages. For example, consider the message view, which loads most-recent-messages first and only goes back far enough to fetch enough messages to fill the current viewport, in comparison with a (somewhat pathological) forum where almost every message is a child of the very first message in the history, which could have been gigs and gigs of data-ago. If the UI only displays top-level posts until the user expands them, we have to parse the entire history before we get enough info to display anything at all.
Another problem is that multiplexing all these overlays into one data store creates "holes" in the data that confuse [lazy-loaded listviews](https://api.flutter.dev/flutter/widgets/ListView/ListView.builder.html) and scrollbars. The message count may indicate there is a ton more information to display if the user simply scrolls, but when it actually gets fetched and parsed we might realize that none of it is relevant to the current overlay.
None of these problems are insurmountable, but they demonstrate a flaw in our initial assumptions about the nature of collaborative message flows and how we should be handling that data.
# Overlay Types
As stated above, overlays are specified in a very simple JSON format with the following structure:
type ChatMessage struct {
O int `json:"o"`
D string `json:"d"`
}
Where O stands for `Overlay` with the current supported overlays documented below:
1: data is a chat string
2: data is a list state/delta
3: data is a bulletin state/delta
100: contact suggestion; data is a peer onion address
101: contact suggestion; data is a group invite string
## Chat Messages (Overlay 1)
The most simple over is a chat message which simply contains raw, unprocessed chat message information.
```
{o:1,d:"got milk?"}
```
## Invitations (Overlays 100 and 101)
Instead of receiving the invite as an incoming contact request at the profile level, new inline invites are shared with a particular contact/group, where they can be viewed and/or accepted later, even if they were initially rejected (potentially by accident).
The wire format for these are equally simple:
```
{o:100,d:"u4ypg7yyyrrvf2aceeclq5dgwtkirzletltbqofnb6km7u542qqk4jyd"}
{o:101,d:"torv3eyJHcm91cElEIjoiOWY3MWExYmFhNDkzNTAzMzAyZDFmODRhMzI2ODY2OWUiLCJHcm91cE5hbWUiOiI5ZjcxYTFiYWE0OTM1MDMzMDJkMWY4NGEzMjY4NjY5ZSIsIlNpZ25lZEdyb3VwSUQiOiJyVGY0dlJKRkQ2LzFDZjFwb2JQR0xHYzdMNXBKTGJTelBLRnRvc3lvWkx6R2ZUd2Jld0phWllLUWR5SGNqcnlmdXVRcjk3ckJ2RE9od0NpYndKbCtCZz09IiwiVGltZXN0YW1wIjowLCJTaGFyZWRLZXkiOiJmZVVVQS9OaEM3bHNzSE9lSm5zdDVjNFRBYThvMVJVOStPall2UzI1WUpJPSIsIlNlcnZlckhvc3QiOiJ1cjMzZWRid3ZiZXZjbHM1dWU2anBrb3ViZHB0Z2tnbDViZWR6ZnlhdTJpYmY1Mjc2bHlwNHVpZCJ9"}
```
This represents a departure from our original "overlays" thinking to a more action-oriented representation. The chat "overlay" can communicate that someone *did* something, even if it's paraphrased down to "added an item to a list," and the lists and bulletins and other beautifully chaotic data can have their state precomputed and stored separately.
## Lists / Bulletin Boards
**Note: Expected to be Defined in Cwtch Beta 1.5**

14
i18n/es/docusaurus-plugin-content-security/current/deployment.md Normal file
View File

@ -0,0 +1,14 @@
# Deployment
## Risk: Binaries are replaced on the website with malicious ones
**Status: Partially-mitigated**
While this process is now mostly automated, should this automation ever be compromised then there is nothing in our current process that would detect this.
We need:
* Reproducible Builds - we currently use public docker containers for all builds which should allow anyone to compare distributed builds with ones built from source.
* Signed Releases - Open Privacy does not yet maintain a public record of staff public keys. This is likely a necessity for signing released builds and creating an audit chain backed by the organization. This process must be manual by definition.

28
i18n/es/docusaurus-plugin-content-security/current/development.md Normal file
View File

@ -0,0 +1,28 @@
# Development
The main process to counter malicious actors in development of Cwtch is the openness of the process.
To enhance this openness, automated builds, testing and packaging are defined as part of the repositories - improving te robustness of the code base at every stage.
![](https://docs.openprivacy.ca/cwtch-security-handbook/1.png)
While individual tests aren't perfect, and all processes have gaps, we should be committed to make it as easy as possible to contribute to Cwtch while also building pipelines and processes that catch errors (unintential or malicious) as soon as possible.
### Risk: Developer Directly Pushes Malicious Code
**Status: Mitigated**
`trunk` is currently locked and only 3 Open Privacy staff members have permission to override it, in addition the responsibility of monitoring changes.
Further every new pull request and merge triggered automated builds & tests which trigger emails and audit logs.
The code is also open source and inspectable by anyone.
### Risk: Code Regressions
**Status: Partially Mitigated** (See individual project entries in this handbook for more information)
Our automated pipelines have the ability to catch regressions when that behaviour is detectable.
The greatest challenge is in defining how such regressions are detected for the [ui](/security/category/cwtch-ui) - where behaviour isn't as strictly defined as it is for the individual libraries.

48
i18n/es/docusaurus-plugin-content-security/current/intro.md Normal file
View File

@ -0,0 +1,48 @@
---
sidebar_position: 1
---
# Cwtch Security Handbook
Welcome to the Cwtch Secure Development Handbook! The purpose of this handbook is to provide a guide to the various components of the Cwtch ecosystem, to document the known risks and mitigations, and to enable discussion about improvements and updates to Cwtch secure development processes.
![](https://docs.openprivacy.ca/cwtch-security-handbook/2.png)
## What is Cwtch?
Cwtch (/kʊtʃ/ - a Welsh word roughly translating to “a hug that creates a safe place”) is a decentralized, privacy-preserving, multi-party messaging protocol that can be used to build metadata resistant applications.
* **Decentralized and Open**: There is no “Cwtch service” or “Cwtch network”. Participants in Cwtch can host their own safe spaces, or lend their infrastructure to others seeking a safe space. The Cwtch protocol is open, and anyone is free to build bots, services and user interfaces and integrate and interact with Cwtch.
* **Privacy Preserving**: All communication in Cwtch is end-to-end encrypted and takes place over Tor v3 onion services.
* **Metadata Resistant**: Cwtch has been designed such that no information is exchanged or available to anyone without their explicit consent, including on-the-wire messages and protocol metadata.
## A (Brief) History of Metadata Resistant Chat
In recent years, public awareness of the need and benefits of end-to-end encrypted solutions has increased with applications like [Signal](https://signalapp.org), [Whatsapp](https://whatsapp.com) and [Wire](https://wire.org) now providing users with secure communications.
However, these tools require various levels of metadata exposure to function, and much of this metadata can be used to gain details about how and why a person is using a tool to communicate. [[rottermanner2015privacy]](https://www.researchgate.net/profile/Peter_Kieseberg/publication/299984940_Privacy_and_data_protection_in_smartphone_messengers/links/5a1a9c29a6fdcc50adeb1335/Privacy-and-data-protection-in-smartphone-messengers.pdf).
One tool that did seek to reduce metadata is [Ricochet](https://ricochet.im) first released in 2014. Ricochet used Tor v2 onion services to provide secure end-to-end encrypted communication, and to protect the metadata of communications.
There were no centralized servers that assist in routing Ricochet conversations. No one other than the parties involved in a conversation could know that such a conversation is taking place.
Ricochet wasn't without limitations; there was no multi-device support, nor is there a mechanism for supporting group communication or for a user to send messages while a contact is offline.
This made adoption of Ricochet a difficult proposition; with even those in environments that would be served best by metadata resistance unaware that it exists [[ermoshina2017can]](https://www.academia.edu/download/53192589/ermoshina-12.pdf) [[renaud2014doesn]](https://eprints.gla.ac.uk/116203/1/116203.pdf).
Additionally, any solution to decentralized, metadata resistant communication faces [fundamental problems](https://code.briarproject.org/briar/briar/-/wikis/Fundamental-Problems) when it comes to efficiency, privacy and group security (as defined by [transcript consensus and consistency](https://code.briarproject.org/briar/briar/-/wikis/Fundamental-Problems)).
Modern alternatives to Ricochet include [Briar](https://briarproject.org), [Zbay](https://www.zbay.app/) and [Ricochet Refresh](https://www.ricochetrefresh.net/) - each tool seeks to optimize for a different set of trade-offs e.g. Briar seeks to allow people to communicate [even when underlying network infrastructure is down](https://briarproject.org/how-it-works/) while providing resistant to metadata surveillance.
<hr />
The Cwtch project began in 2017 as an extension protocol for Ricochet providing group conversations via untrusted servers, with an eye to enabling decentralized, metadata resistant applications (like shared lists and bulletin board)
An alpha version of Cwtch was [was launched in February 2019](https://openprivacy.ca/blog/2019/02/14/cwtch-alpha/), and since then the Cwtch team (run by the [Open Privacy Research Society](https://openprivacy.ca)) has conducted research and development into Cwtch and the underlying protocols and libraries and problem spaces.

28
i18n/es/docusaurus-plugin-content-security/current/references.md Normal file
View File

@ -0,0 +1,28 @@
# References
* Atwater, Erinn, and Sarah Jamie Lewis. "Token Based Services-Differences from Privacy Pass."
* Brooks, John. Ricochet: Anonymous instant messaging for real privacy. https://ricochet.im. Accessed: 2018-03-10
* Ermoshina K, Halpin H, Musiani F. Can johnny build a protocol? co-ordinating developer and user intentions for privacy-enhanced secure messaging protocols. In European Workshop on Usable Security 2017.
* Ermoshina, K., Musiani, F. and Halpin, H., 2016, September. End-to-end encrypted messaging protocols: An overview. In International Conference on Internet Science (pp. 244-254). Springer, Cham.
* Farb, M., Lin, Y.H., Kim, T.H.J., McCune, J. and Perrig, A., 2013, September. Safeslinger: easy-to-use and secure public-key exchange. In Proceedings of the 19th annual international conference on Mobile computing & networking (pp. 417-428).
* Greschbach, B., Kreitz, G. and Buchegger, S., 2012, March. The devil is in the metadata—New privacy challenges in Decentralised Online Social Networks. In 2012 IEEE international conference on pervasive computing and communications workshops (pp. 333-339). IEEE.
* Langley, Adam. Pond. https://github.com/agl/pond. Accessed: 2018-05-21.
* Le Blond, S., Zhang, C., Legout, A., Ross, K. and Dabbous, W., 2011, November. I know where you are and what you are sharing: exploiting p2p communications to invade users' privacy. In Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conference (pp. 45-60).
* Lewis, Sarah Jamie. "Cwtch: Privacy Preserving Infrastructure for Asynchronous, Decentralized, Multi-Party and Metadata Resistant Applications." (2018).
* Kalysch, A., Bove, D. and Müller, T., 2018, November. How Android's UI Security is Undermined by Accessibility. In Proceedings of the 2nd Reversing and Offensive-oriented Trends Symposium (pp. 1-10).
* Renaud, K., Volkamer, M. and Renkema-Padmos, A., 2014, July. Why doesn’t Jane protect her privacy?. In International Symposium on Privacy Enhancing Technologies Symposium (pp. 244-262). Springer, Cham.
* Rottermanner, C., Kieseberg, P., Huber, M., Schmiedecker, M. and Schrittwieser, S., 2015, December. Privacy and data protection in smartphone messengers. In Proceedings of the 17th International Conference on Information Integration and Web-based Applications & Services (pp. 1-10).
* Unger, Nik et al. “SoK: secure messaging”. In: Security and Privacy (SP ), 2015 IEEE Sympo-sium on. IEEE. 2015, pp. 232–249 [link](http://cacr.uwaterloo.ca/techreports/2015/cacr2015-02.pdf)

57
i18n/es/docusaurus-plugin-content-security/current/risk.md Normal file
View File

@ -0,0 +1,57 @@
---
sidebar_position: 2
---
# Risk Model
Communications metadata is known to be exploited by various adversaries to undermine the security of systems, to track victims and to conduct large scale social network analysis to feed mass surveillance. Metadata resistant tools are in their infancy and research into the construction and user experience of such tools is lacking.
![](/img/4.png)
Cwtch was originally conceived as an extension of the metadata resistant protocol Ricochet to support asynchronous, multi-peer group communications through the use of discardable, untrusted, anonymous infrastructure.
Since then, Cwtch has evolved into a protocol in its own right, this section will outline the various known risks that Cwtch attempts to mitigate and will be heavily referenced throughout the rest of the document when discussing the various sub-components of the Cwtch Architecture.
## Threat Model
It is important to identify and understand that metadata is ubiquitous in communication protocols, it is indeed necessary for such protocols to function efficiently and at scale. However, information that is useful to facilitating peers and servers is also highly relevant to adversaries wishing to exploit such information.
For our problem definition, we will assume that the content of a communication is encrypted in such a way that an adversary is practically unable to break (see [tapir](/security/category/tapir) and [cwtch](security/category/cwtch) for details on the encryption that we use, a and as such we will focus to the context to the communication metadata.
We seek to protect the following communication contexts:
* Who is involved in a communication? It may be possible to identify people or simply device or network identifiers. E.g., “this communication involves Alice, a journalist, and Bob a government employee.”.
* Where are the participants of the conversation? E.g., “during this communication Alice was in France and Bob was in Canada.”
* When did a conversation take place? The timing and length of communication can reveal a large amount about the nature of a call, e.g., “Bob a government employee, talked to Alice on the phone for an hour yesterday evening. This is the first time they have communicated.” *How was the conversation mediated? Whether a conversation took place over an encrypted or unencrypted email can provide useful intelligence. E.g., “Alice sent an encrypted email to Bob yesterday, whereas they usually only send plaintext emails to each other.”
* What is the conversation about? Even if the content of the communication is encrypted it is sometimes possible to derive a probable context of a conversation without knowing exactly what is said, e.g. “a person called a pizza store at dinner time” or “someone called a known suicide hotline number at 3am.”
Beyond individual conversations, we also seek to defend against context correlation attacks, whereby multiple conversations are analyzed to derive higher level information:
* Relationships: Discovering social relationships between a pair of entities by analyzing the frequency and length of their communications over a period of time. E.g. Carol and Eve call each other every single day for multiple hours at a time.
* Cliques: Discovering social relationships between a group of entities that all interact with each other. E.g. Alice, Bob and Eve all communicate with each other.
* Loosely Connected Cliques and Bridge Individuals: Discovering groups that communicate to each other through intermediaries by analyzing communication chains (e.g. everytime Alice talks to Bob she talks to Carol almost immediately after; Bob and Carol never communicate.)
* Pattern of Life: Discovering which communications are cyclical and predictable. E.g. Alice calls Eve every Monday evening for around an hour.
### Active Attacks
#### Misrepresentation Attacks
Cwtch provides no global display name registry, and as such people using Cwtch are more vulnerable to attacks based around misrepresentation i.e. people pretending to be other people:
A basic flow of one of these attacks is as follows, although other flows also exist:
- Alice has a friend named Bob and another called Eve
- Eve finds out Alice has a friend named Bob
- Eve creates thousands of new accounts to find one that has a similar picture / public key to Bob (won't be identical but might fool someone for a few minutes)
- Eve calls this new account "Eve New Account" and adds Alice as a friend.
- Eve then changes her name on "Eve New Account" to "Bob"
- Alice sends messages intended for "Bob" to Eve's fake Bob account
Because misrepresentation attacks are inherently about trust and verification the only absolute way of preventing them is for users to absolutely validate the public key. This is obviously not-ideal and in many cases simply *won't-happen*.
As such we aim to provide some user-experience hints in the [ui](/security/category/cwtch-ui) to guide people in making choices around whether to trust accounts and/or to distinguish accounts that may be attempting to represent themselves as other users.
## A note on Physical Attacks
Cwtch does not consider attacks that require physical access (or equivalent) to the users machine as practically defendable. However, in the interests of good security engineering, throughout this document we will still refer to attacks or conditions that require such privilege and point out where any mitigations we have put in place will fail.

6
i18n/it/docusaurus-plugin-content-blog/options.json
View File

@ -1,14 +1,14 @@
{
"title": {
"message": "Blog",
"message": "Development Log",
"description": "The title for the blog used in SEO"
},
"description": {
"message": "Blog",
"message": "The latest updated on Cwtch development.",
"description": "The description for the blog used in SEO"
},
"sidebar.title": {
"message": "Post recenti",
"message": "Recent Logs",
"description": "The label for the left sidebar"
}
}

12
i18n/it/docusaurus-plugin-content-docs/current/chat/add-contact.md
View File

@ -2,10 +2,16 @@
sidebar_position: 1.5
---
# Aggiungere un nuovo contatto
# Starting a New Conversation
1. Seleziona un profilo
2. Clicca sul pulsante "Aggiungi"
3. Scegli "Aggiungi contatto"
5. Incolla un indirizzo Cwtch
6. Il contatto verrà aggiunto alla tua lista contatti
4. Incolla un indirizzo Cwtch
5. Il contatto verrà aggiunto alla tua lista contatti
:::info
This documentation page is a stub. You can help by [expanding it](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

6
i18n/it/docusaurus-plugin-content-docs/current/chat/block-contact.md
View File

@ -8,3 +8,9 @@ sidebar_position: 7
2. Vai su "Impostazioni"
3. Scorri verso il basso fino a "Blocca il contatto"
4. Sposta l'interruttore su "Blocca contatto"
:::info
This documentation page is a stub. You can help by [expanding it](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

11
i18n/it/docusaurus-plugin-content-docs/current/chat/delete-contact.md Normal file
View File

@ -0,0 +1,11 @@
---
sidebar_position: 10
---
# Removing a Conversation
:::info
This documentation page is a stub. You can help by [expanding it](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

19
i18n/it/docusaurus-plugin-content-docs/current/chat/share-address-with-friends.md
View File

@ -2,11 +2,26 @@
sidebar_position: 3
---
# Condividere un indirizzo Cwtch
# Sharing Cwtch Addresses
There are many ways to share a Cwtch address.
## Sharing Your Cwtch Address
1. Vai al tuo profilo
2. Fare clic sull'icona della copia indirizzo
Ora è possibile condividere questo indirizzo. Le persone con questo indirizzo saranno in grado di aggiungerti come un contatto Cwtch.
Per informazioni su come bloccare connessioni da persone che non conosci vedi [Impostazioni: Blocca connessioni sconosciute](/docs/settings/behaviour/block-unknown-connections)
Per informazioni su come bloccare connessioni da persone che non conosci vedi [Impostazioni: Blocca connessioni sconosciute](/docs/settings/behaviour/block-unknown-connections)
# Sharing A Friends Cwtch Address
Inside of Cwtch there is another mechanism for exchanging Cwtch addresses.
:::info
This documentation page is a stub. You can help by [expanding it](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

9
i18n/it/docusaurus-plugin-content-docs/current/chat/unblock-contact.md
View File

@ -7,4 +7,11 @@ sidebar_position: 8
1. Seleziona il contatto nella tua lista conversazioni. I contatti bloccati vengono spostati in fondo alla lista.
2. Vai alle Impostazioni della conversazione
3. Scorri verso il basso fino a "Blocca il contatto"
4. Sposta l'interruttore su "Sblocca il contatto"
4. Sposta l'interruttore su "Sblocca il contatto"
:::info
This documentation page is a stub. You can help by [expanding it](https://git.openprivacy.ca/cwtch.im/docs.cwtch.im).
:::

51
i18n/it/docusaurus-plugin-content-docs/current/contribute/developing.md Normal file
View File

@ -0,0 +1,51 @@
---
sidebar_position: 1
---
# Developing Cwtch
This section documents some ways to get started with Cwtch Development.
## Cwtch Issues Tracking Process
All Cwtch issues are tracked from the [cwtch-ui git repository](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues), even if the bug/feature originates in an upstream library. This allows us to keep everything in one place.
Issues are generally divided into 4 distinct categories:
- **Unprocessed** - These are new issues that have not been discussed by the Cwtch team.
- [**Scheduled**](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues?q=&type=all&state=open&labels=195&milestone=0&assignee=0&poster=0) - These issues have been planned for an upcoming release. They are usually tagged with the release they are expected to be fixed in e.g. `cwtch-1.11`. A core Cwtch team member is likely working on the issue, or is expecting to work on the issue in the coming weeks.
- [**Desired**](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues?q=&type=all&state=open&labels=153&milestone=0&assignee=0&poster=0) - These are issues that we would like to fix but for some reason we are unable to schedule. This might be because the feature is large and requires a lot of effort, or because there is some blocker (e.g. a missing feature in Flutter or some other library) that prevents work on the feature.
- [**Help Wanted**](https://git.openprivacy.ca/cwtch.im/cwtch-ui/issues?q=&type=all&state=open&labels=136&milestone=0&assignee=0&poster=0) - These are generally small issues that we would like to fix but that have been designated low priority. These are ideal first issues for volunteers.
If you would like to work on an open bug/feature, please comment on the issue and a member of the Cwtch team will follow up with advice on where to go from there. This helps us keep track of who is working on what problems, and reduces the amount of duplicate work. We aim to answer most queries within 24 hours, feel free to "bump" an issue if it takes longer than that.
:::note
Due to an issue with our email provider, we are currently unable to consistently send email from our gitea instance. Please regularly check open issues / pull-requests for updates (or subscribe to the repository's RSS feeds)
:::
## Cwtch Pull-Request Process
All pull-requests must be reviewed and approved by a core Cwtch team member prior to merging. Sarah reviews all new and active pull requests multiple times a week.
### Build Bot
All Cwtch projects are set up with automated builds and testing. Every pull request is expected to be able to pass through these pipelines prior to being merged. If buildbot reports a failure then Sarah will work with you to determine the issue, and any necessary fixes.
Buildbot can fail for reasons beyond your control e.g. many of our integration tests rely setting up Tor connections, these can be brittle on occasion and result in timeouts and failures. Always confirm the root cause of a test failure before deciding what to do next.
## Useful Resources
- [Cwtch Ecosystem Overview](/security/components/ecosystem-overview) - a summary of active Cwtch repositories from the Cwtch Secure Development Handbook.
- [Contributing Documentation](/docs/contribute/documentation) - advice on contributing Cwtch documentation.
- [Contributing Testing](/docs/contribute/testing) - advice on contributing by testing Cwtch.
- [Contributing Translations](/docs/contribute/translate) - advice on contributing translations to Cwtch.
:::note
All contributions are [eligible for stickers](/docs/contribute/stickers)
:::

46
i18n/it/docusaurus-plugin-content-docs/current/contribute/documentation.md Normal file
View File

@ -0,0 +1,46 @@
---
sidebar_position: 6
---
# Documentation Style Guide
This section documents the expected structure and quality of Cwtch documentation.
## Screenshots and Cast of Characters
Most Cwtch documentation should feature at least one screenshot or animated image. Screenshots of the Cwtch application should be focused on the feature being described by the documentation.
To ensure consistency between screenshots we suggest that the profile involved should serve particular, constant, roles.
- **Alice** - used to represent the primary profile.
- **Bob** - the primary contact, useful when demonstrating peer-to-peer features
- **Carol** - a secondary contact, useful when demonstrating group features
- **Mallory** - representing a malicious peer (to be used when demonstrating blocking functionality)
## Dialogue and Content
Where screenshots and demonstrations show dialogue, conversations, and/or images please keep the conversations short, on a casual topic. Examples include:
- Organizing a picnic
- Sharing photos from a vacation
- Sending a document for review
## Experiments
All features that rely on an experiment being enabled should all this out prominently at the top of the page e.g.:
:::caution Experiments Required
This feature requires [Experiments Enabled](https://docs.cwtch.im/docs/settings/introduction#experiments) and the [Example Experiment](https://docs.cwtch.im/docs/settings/experiments/server-hosting) turned on.
:::
## Risks
If a feature might result in destruction of key material or permanent deletion of state, then these should also be called out at the top of the documentation e.g.:
:::warning
This feature will result in **irreversible** deletion of key material. This **cannot be undone**.
:::

10
i18n/it/docusaurus-plugin-content-docs/current/contribute/stickers.md Normal file
View File

@ -0,0 +1,10 @@
---
sidebar_position: 10
---
# Stickers
All contributions are eligible for stickers. If you are contributing to bug, feature, testing, or language, or have contributed significantly in the past then please email erinn@openprivacy.ca with details and an address for us to mail stickers to.
![A Photo of Cwtch Stickers](/img/stickers-new.jpg)

8
i18n/it/docusaurus-plugin-content-docs/current/contribute/testing.md
View File

@ -28,4 +28,10 @@ Cwtch Nightly build sono build di sviluppo che contengono nuove funzionalità ch
Le versioni di sviluppo più recenti di Cwtch sono disponibili dal nostro [build server](https://build.openprivacy.ca/files/).
**Non** raccomandiamo che i tester si tengano sempre aggiornati con l'ultimo nightly build. Invece, pubblicheremo un messaggio sul gruppo Tester di versioni di Cwtch candidate al rilascio quando sarà disponibile un nightly build significativa. Un nightly build è considerato significativo se contiene una nuova funzione o un fix a un bug serio.
**Non** raccomandiamo che i tester si tengano sempre aggiornati con l'ultimo nightly build. Invece, pubblicheremo un messaggio sul gruppo Tester di versioni di Cwtch candidate al rilascio quando sarà disponibile un nightly build significativa. Un nightly build è considerato significativo se contiene una nuova funzione o un fix a un bug serio.
:::note
All contributions are [eligible for stickers](/docs/contribute/stickers)
:::

38
i18n/it/docusaurus-plugin-content-docs/current/contribute/translate.md
View File

@ -2,18 +2,40 @@
sidebar_position: 2
---
# Traduci Cwtch
# Translating Cwtch
Se vuoi contribuire con delle traduzioni all'applicazione di Cwtch o a questo manuale, ecco come fare
## Applicazione di Cwtch
## Contributing Translations to the Cwtch Application
L'applicazione è tradotta attraverso [Lokalise](https://lokalise.com).
1. Registra un account sul sito
2. Manda una email a [team@cwtch.im](mailto:team@cwtch.im) dicendo che vorresti tradurre e specifica l'indirizzo email con cui hai effettuato la registrazione a Lokalise. Ti aggiungeremo al progetto.
There are two ways to contribute to Cwtch applications.
### Join our Lokalise Team
We use [Lokalise](https://lokalise.com) for managing translations for the Cwtch application.
1. Sign up for a Lokalise account
2. Email [team@cwtch.im](mailto:team@cwtch.im) with the language you are interested in translating and an email we can use to invite you to our Lokalise team.
### Directly via Git
For new translations, you can make a copy of [https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/branch/trunk/lib/l10n/intl_en.arb](https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/branch/trunk/lib/l10n/intl_en.arb) and begin translating - you can then either [submit pull requests or directly](/docs/contribute/developing#cwtch-pull-request-process) send updates to us (team@cwtch.im) and we will merge them in.
For adding to existing translations you can make pull requests directly on any file in [https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/branch/trunk/lib/l10n/](https://git.openprivacy.ca/cwtch.im/cwtch-ui/src/branch/trunk/lib/l10n/) and we will review and merge them in.
## Manuale utente di Cwtch
Il manuale è tradotto attraverso [Crowdin](https://crowdin.com).
1. Registra un account sul sito.
2. Vai al progetto [cwtch-users-handbook](https://crowdin.com/project/cwtch-users-handbook) e unisciti.
This handbook is translated through [Crowdin](https://crowdin.com).
To join our Crowdin project:
1. Sign up for an account on [Crowdin](https://crowdin.com).
2. Join the [cwtch-users-handbook project](https://crowdin.com/project/cwtch-users-handbook).
We bundle up changes to the documentation in batches and sync them with the Crowdin project on a regular basis.
:::note
All contributions are [eligible for stickers](/docs/contribute/stickers)
:::

7
i18n/it/docusaurus-plugin-content-docs/current/getting-started/_category_.json Normal file
View File

@ -0,0 +1,7 @@
{
"label": "Getting started",
"position": 2,
"link": {
"type": "generated-index"
}
}

Some files were not shown because too many files have changed in this diff Show More