Datenschutz – UkrainianCommunity

Version 2026.22 · Veröffentlicht am 15. Oktober 2026 · ersetzt Version 2026.21Версія 2026.22 · Опубліковано 15 жовтня 2026 р. · замінює версію 2026.21

1. Verantwortlicher und Kontakt

Verantwortlicher gemäß Datenschutz-Grundverordnung (DSGVO) ist:

Timofeev Philipp
Egger-Lienz-Straße 47, 6020 Innsbruck
Österreich
E-Mail: ukrainian.community@outlook.com

Es wurde kein Datenschutzbeauftragter bestellt, weil nach der derzeitigen Tätigkeit keine gesetzliche Benennungspflicht festgestellt wurde. Datenschutzanfragen können an die oben genannte E-Mail-Adresse gerichtet werden.

2. Geltungsbereich und Rollen

Diese Erklärung gilt für die iOS- und Android-App UkrainianCommunity sowie die öffentlichen Support- und Rechtsseiten. UkrainianCommunity ist Verantwortlicher für Konten, Plattformbetrieb, Zugriffskontrolle, Moderation, Sicherheit, Benachrichtigungen und die hier beschriebene Erstanbieter-Analyse.

Organisationen, Veranstalter, Geschäfte und Fachpersonen können für Daten, die sie eigenständig für ihre Angebote erheben oder außerhalb der Plattform weiterverarbeiten, selbst Verantwortliche sein. Dies betrifft etwa Anmeldelisten, Anfragen, Verkäufe oder direkte Kontakte. Deren eigene Datenschutzhinweise sind zusätzlich zu beachten. UkrainianCommunity und eine Organisation sind nicht allein deshalb gemeinsam Verantwortliche, weil ein Eintrag auf der Plattform erscheint.

3. Datenkategorien

Je nach Nutzung verarbeiten wir:

Konto und Profil: Firebase-Benutzer-ID, E-Mail-Adresse, Anzeigename, Profilbild, Biografie, optionaler Telegram-Benutzername, Sprache, Bundesland, Rolle, Kontostatus, Verifizierungs- und Zustimmungsstatus.
Inhalte: Nachrichten, Veranstaltungen, Organisationen, Beschreibungen, Kategorien, Orte oder manuell eingegebene Koordinaten, Bilder und Galerien, Kommentare, Kontaktdaten und Metadaten zur Erstellung oder Änderung.
Interaktionen: Likes, gespeicherte Inhalte, Organisationsabos, Veranstaltungsregistrierungen, Aufruf-Deduplizierung, öffentliche Zähler und zuletzt angesehene Inhalte.
Kommunikation und Moderation: Supportanfragen, Feedback, Beschwerden, Inhaltsmeldungen, genaue Fundstelle, Begründungen, Kontaktangaben der meldenden Person, Antworten, Entscheidungen, Verwarnungen, Sperren, Einsprüche und zugehörige Nachweise. Für den öffentlichen DSA-Fallzugang werden Vorgangsnummer und ausschließlich der Hash eines vertraulichen Zugangscodes gespeichert.
Organisationserstellung und rechtliche Nachweise: bestätigte Regelversion, serverseitiger Zeitpunkt, Konto-ID, App-Sprache und -Version sowie ID und angegebener Name der geplanten Organisation. Ein kurzlebiger technischer Erstellungsnachweis bindet die Zustimmung an genau diesen Eintrag.
Benachrichtigungen: Firebase Installation ID, APNs-/FCM-Registrierungstoken, Gerätezustand für die Zustellung, Themen oder Präferenzen und Zustellergebnis. Für optionale Mitteilungen können ein aus einem Installationsgeheimnis abgeleiteter Dokumentbezeichner, eine kurzlebige Challenge sowie Präsentations-, Bestätigungs- und Aktionsnachweise mit Plattform, Sprache, Konto- und Zeitbezug verarbeitet werden. Ein während der Migration vorhandenes älteres Token kann bis zur sicheren Bereinigung parallel gespeichert sein.
Sicherheit und Technik: App Check mit Apple App Attest beziehungsweise Google Play Integrity, IP-Adresse und technische Anfragedaten bei Firebase, Zeitstempel, Versions- und Geräteinformationen, Fehlerdiagnose sowie System-, Sicherheits- und Auditprotokolle. Der Gerätename kann in einer Push-Registrierung erscheinen, wenn die App ihn dafür bereitstellt.
Optionale Erstanbieter-Analyse: nach ausdrücklicher Einwilligung minimale tägliche Signale zu Aufrufen und Aktionen, Inhalts-ID, Zeitpunkt, Zustimmungs-Generation und gegebenenfalls ein einmaliger Aktionsnachweis. Während der Deduplizierung sind diese Signale kontobezogen; Betreiberberichte enthalten zusammengefasste Werte, keine Teilnehmerlisten.
Freiwillige Banner-Messung: nach gesonderter Einwilligung Banner-ID, App-Bereich, sichtbare Einblendung oder Tippen und Zeitpunkt. Konto-, Zustimmungs- und Ereignis-ID dienen der Autorisierung und Deduplizierung. Die täglichen Berichte enthalten zusammengefasste Werte je Banner und App-Bereich, keine Besucherlisten.

Wir verwenden keine Werbe-ID (IDFA), kein App Tracking Transparency für Werbung, keine Werbenetzwerke und kein Google/Firebase Analytics-Produkt. Wir verkaufen keine personenbezogenen Daten und nutzen sie nicht für app- oder unternehmensübergreifendes Werbetracking.

4. Zwecke und Rechtsgrundlagen

Verarbeitung	Zweck	Rechtsgrundlage
Konto, Anmeldung, Profil und gewünschte Funktionen	Vertragliche Bereitstellung der Plattform und vom Nutzer ausgelöster Funktionen	Art. 6 Abs. 1 lit. b DSGVO
Veröffentlichung und Verwaltung von Inhalten/Organisationen	Bereitstellung des angeforderten Veröffentlichungs- und Verwaltungsdienstes	Art. 6 Abs. 1 lit. b DSGVO; bei rein vorvertraglicher Nutzung ebenfalls lit. b
Likes, Lesezeichen, Abos, Registrierungen und notwendige Funktionszähler	Ausführung und Konsistenz der ausdrücklich gewählten Funktion	Art. 6 Abs. 1 lit. b DSGVO
Moderation, Missbrauchsabwehr, Beweissicherung und Plattformsicherheit	Schutz von Nutzern, Rechten und zuverlässigem Betrieb	Art. 6 Abs. 1 lit. f DSGVO; soweit erforderlich lit. c
Bearbeitung rechtlicher Meldungen und Behördenanfragen	Erfüllung gesetzlicher Pflichten, insbesondere nach DSA und anwendbarem Recht	Art. 6 Abs. 1 lit. c DSGVO
Support und freiwilliges Feedback	Bearbeitung der Anfrage	Art. 6 Abs. 1 lit. b oder lit. f DSGVO, abhängig vom Inhalt
Erforderliche servicebezogene In-App-Mitteilungen	Kontosicherheit, Moderationsentscheidungen und Vertragserfüllung	Art. 6 Abs. 1 lit. b, c oder f DSGVO
Optionale Push-Benachrichtigungen	Zustellung ausgewählter Hinweise auf das Gerät	Art. 6 Abs. 1 lit. a DSGVO; technisch notwendige Tokenverwaltung zusätzlich lit. b/f bis zur Abmeldung
Optionale Erstanbieter-Analyse	Zusammengefasste Reichweiten- und Nutzungsberichte für Inhaltsverantwortliche	Art. 6 Abs. 1 lit. a DSGVO
Freiwillige Banner-Messung	Zusammengefasste Berichte über sichtbare Einblendungen und Aufrufe für den Plattforminhaber	Art. 6 Abs. 1 lit. a DSGVO (gesonderte Einwilligung)
Rechtsverteidigung	Geltendmachung, Ausübung oder Verteidigung von Rechtsansprüchen	Art. 6 Abs. 1 lit. f DSGVO und gegebenenfalls Art. 9 Abs. 2 lit. f DSGVO

Soweit wir uns auf berechtigte Interessen stützen, bestehen diese in Plattform- und Kontosicherheit, Betrugsprävention, nachvollziehbarer Moderation, Schutz anderer Personen und Abwehr von Ansprüchen. Betroffene können aus Gründen ihrer besonderen Situation widersprechen; wir prüfen dann die Interessenabwägung.

5. Pflichtangaben und Folgen der Nichtbereitstellung

Für ein Konto benötigen wir eine E-Mail-Adresse, einen Anzeigenamen, das ausdrücklich ausgewählte österreichische Bundesland, die Bestätigung des Mindestalters und eine technische Konto-ID. Ein Passwort ist nur bei Registrierung mit E-Mail und Passwort erforderlich; es wird von Firebase Authentication verarbeitet und nicht als Profilfeld oder im Administrationsbereich gespeichert. Bei Anmeldung mit Apple oder Google erhalten wir die für die Anmeldung und Kontoverknüpfung erforderlichen Anbieterangaben über Firebase Authentication. Für eine Organisation oder Veranstaltung sind die als erforderlich gekennzeichneten Angaben notwendig, um Prüfung, Veröffentlichung und Kontakt zu ermöglichen. Ohne Pflichtangaben kann die jeweilige Funktion nicht bereitgestellt werden. Optionale Profilfelder, optionale Analyse und nicht notwendige Push-Benachrichtigungen können abgelehnt oder später deaktiviert werden, ohne das Basiskonto zu verlieren.

6. Öffentliche Inhalte und Daten anderer Personen

Veröffentlichte Profilelemente, Organisationen, Veranstaltungen, Nachrichten, Bilder, Kommentare und zugehörige Zähler sind für andere Personen sichtbar und können von ihnen außerhalb unseres Einflussbereichs gespeichert oder weitergegeben werden. Vor einer Veröffentlichung ist zu prüfen, ob persönliche Telefonnummern, Privatadressen, Kennzeichen, Dokumente oder Daten von Minderjährigen wirklich erforderlich sind.

Wer Daten anderer Personen hochlädt, muss sie hierüber informieren und eine gültige Rechtsgrundlage besitzen. Für Kinderbilder, Teilnehmerlisten und sensible Informationen gelten erhöhte Anforderungen. Zahlungs-, Gesundheits-, Ausweis- oder Zugangsdaten dürfen nicht in öffentliche Freitextfelder eingestellt werden.

7. Standort

Die App fordert derzeit weder unter iOS noch unter Android eine Standortberechtigung an und liest den Gerätestandort nicht aus. Herausgeber können Orte oder Koordinaten für öffentliche Inhalte manuell eingeben. Regionale Statistiken beziehen sich auf die dem Inhalt oder Profil zugewiesene Region und nicht auf eine laufende Geräteortung.

8. Firebase, Apple und Empfänger

Für den technischen Betrieb verwenden wir Dienste der Google-Gruppe (Firebase Authentication, Cloud Firestore, Cloud Storage, Cloud Functions, Cloud Messaging, Firebase Installations und App Check) als Auftragsverarbeiter. Firebase kann technische Daten, Identifikatoren und Inhalte auf unserer Weisung verarbeiten. Je nach Dienst und Konfiguration findet Verarbeitung im Europäischen Wirtschaftsraum und in Drittländern statt.

Wenn Sie in der iOS- oder Android-App „Mit Apple anmelden“ wählen, fordert die App Name und E-Mail-Adresse an; Apple kann statt der persönlichen Adresse eine Weiterleitungsadresse bereitstellen. Für die Firebase-Anmeldung übermittelt die App das Apple-Identitätstoken und den Namen, soweit Apple ihn bereitstellt. Wenn Sie „Mit Google anmelden“ wählen, verwendet die App die von Google bereitgestellten Anmeldetoken zur Anmeldung bei Firebase. Firebase Authentication verarbeitet dabei die Anbieterkennung sowie die bereitgestellten Kontoangaben, insbesondere E-Mail-Adresse und gegebenenfalls Namen oder Profilbild. Apple oder Google verarbeiten die Anmeldung bei ihrem jeweiligen Dienst nach ihren eigenen Datenschutzbedingungen. Ein Anbieterwechsel verknüpft bestehende Konten nicht automatisch.

Für Push-Nachrichten werden Apple Push Notification service (APNs) und Firebase Cloud Messaging eingesetzt. Apple und Google verarbeiten dabei Token, technische Zustelldaten und den Inhalt der Benachrichtigung nach ihren jeweiligen Bedingungen. Sensible Inhalte sollen deshalb nicht in Push-Vorschauen erscheinen.

Weitere Empfänger sind nur: von uns autorisierte Administratoren nach Rollen- und Erforderlichkeitsprinzip; die jeweils betroffene Organisation, wenn eine vom Nutzer gewählte Funktion dies erfordert; Rechts-, Sicherheits- oder IT-Dienstleister unter Vertraulichkeit; sowie Behörden oder Gerichte bei gesetzlicher Pflicht oder wirksamer Anordnung. Eine Offenlegung erfolgt nicht pauschal, sondern nur im erforderlichen Umfang.

9. Drittlandübermittlungen

Bei Übermittlungen außerhalb des EWR verwenden wir einen Angemessenheitsbeschluss, insbesondere eine gültige Zertifizierung nach dem EU-US Data Privacy Framework, oder die Standardvertragsklauseln der Europäischen Kommission einschließlich erforderlicher Zusatzmaßnahmen. Eine Kopie oder Information über die einschlägigen Garantien kann über unseren Datenschutzkontakt verlangt werden. Die tatsächliche Firebase-Konfiguration und aktuelle Anbieterzertifizierung werden vor jeder Veröffentlichung erneut geprüft.

10. Optionale Analyse und Einwilligung

Die optionale Erstanbieter-Analyse ist standardmäßig nicht aufgrund der bloßen App-Nutzung aktiviert. Die Einwilligung wird versioniert serverseitig protokolliert und kann in den Einstellungen mit Wirkung für die Zukunft widerrufen werden. Der Widerruf stoppt neue optionale Signale und entfernt unvereinbare lokal wartende Signale.

Notwendige Funktionsdatensätze – etwa der Zustand eines Likes, Lesezeichens, Abos oder einer Veranstaltungsregistrierung sowie Deduplizierung öffentlicher Aufrufzähler – sind davon getrennt. Sie entstehen nur durch die angeforderte Funktion und werden nicht durch das Abschalten der optionalen Analyse rückgängig gemacht. Die Analyse wird nicht als anonym bezeichnet, solange serverseitige Deduplizierung kontobezogen erfolgt.

Die Banner-Messung ist standardmäßig ausgeschaltet und von der Einwilligung in die Inhaltsanalyse unabhängig. Eine Einblendung zählt nach mindestens einer Sekunde bei mindestens 50 % Sichtbarkeit; ein bewusstes Tippen zählt als Aufruf. Nur für angemeldete Konten mit einer gesonderten, versionierten und serverseitig bestätigten Einwilligung werden Ereignisse übertragen. Die Wahl gilt für das Konto auf allen angemeldeten Geräten und kann jederzeit in den Einstellungen für die Zukunft widerrufen werden. Ablehnung oder Widerruf beeinträchtigen weder das Basiskonto noch die Anzeige der Banner. Nach dem Widerruf werden lokal wartende Ereignisse verworfen und eine noch nicht bestätigte Widerrufsanfrage erneut gesendet. Wir verwenden dafür keine Werbe-ID, keine Drittanbieter-Werbenetzwerke und kein appübergreifendes Tracking. Der Plattforminhaber sieht nur zusammengefasste Zahlen; Werbepartner erhalten keine Besucherlisten.

11. App Check, Sicherheit und Protokolle

App Check mit Apple App Attest beziehungsweise Google Play Integrity hilft zu prüfen, ob Anfragen von einer echten App-Instanz stammen. Sicherheits- und Auditprotokolle dokumentieren unter anderem Anmelde-, Rollen-, Moderations-, Lösch- und Administrationsvorgänge. Zugriff erhalten nur berechtigte Rollen. Wir verwenden technische und organisatorische Maßnahmen wie Zugriffskontrollen, serverseitige Prüfungen, Transportverschlüsselung, minimale Berechtigungen und protokollierte Verwaltungsaktionen. Absolute Sicherheit kann nicht garantiert werden.

Neue Kommentare werden vor der Veröffentlichung serverseitig anhand begrenzter Regeln auf eindeutige Drohungen, Hassbegriffe, sexuelle Ausbeutung von Kindern und massenhaftes Link-Spam geprüft. Bei einem Treffer wird der Kommentar nicht gespeichert; die Person kann den Text korrigieren und erneut absenden oder den Support kontaktieren. Der abgelehnte Text und die Trefferkategorie werden dafür nicht als Moderationsakte gespeichert. Die Prüfung ersetzt weder Meldungen noch die menschliche Beurteilung veröffentlichter Inhalte.

Es findet keine ausschließlich automatisierte Entscheidung mit rechtlicher oder ähnlich erheblicher Wirkung statt. Automatisierte Sicherheitsprüfungen oder Priorisierungen können eine Veröffentlichung technisch ablehnen oder eine menschliche Prüfung auslösen, entscheiden aber nicht allein über Kontosperren oder rechtliche Moderationsfälle.

12. Speicherdauer

Unvollständige Registrierungen werden drei Tage nach Erstellung des Firebase-Anmeldekontos bei der nächsten täglichen Bereinigung gelöscht: wenn die E-Mail-Adresse bei E-Mail/Passwort nicht bestätigt wurde oder unabhängig von der Anmeldemethode kein App-Profil angelegt wurde. Gelöscht werden Anmeldekonto, anfängliches Profil, anfängliche Zustimmungsbelege und zugehörige technische Mitteilungen. Werden weitere Daten oder Unstimmigkeiten festgestellt, wird die automatische Löschung zur Prüfung angehalten. Die nachstehend beschriebenen Sicherungs- und Providerfristen bleiben davon unberührt.
Kontodaten werden grundsätzlich bis zur Kontolöschung gespeichert. Eine dauerhafte Sperrung bewirkt nicht automatisch eine Löschung; begrenzte Nachweise können danach für gesetzliche Pflichten und Rechtsansprüche verbleiben.
Veröffentlichte Inhalte und Funktionsdatensätze folgen grundsätzlich dem Lebenszyklus des Inhalts, Kontos oder der Organisation. Die planmäßige Bereinigung berücksichtigt veröffentlichte Nachrichten 30 Tage nach ihrer Veröffentlichung und Veranstaltungen sechs Kalendermonate nach ihrem Enddatum. Begrenzte Verarbeitungsläufe können die tatsächliche Bereinigung verzögern; Fehlschläge müssen überwacht und behoben werden. Frühere Löschungen und gesetzlich erforderliche Sicherungen bleiben möglich.
Abgeschlossene oder archivierte Planungseinträge werden sechs Kalendermonate nach Abschluss beziehungsweise Archivierung zur Löschung fällig. Nicht mehr benötigte Bildkopien werden erst nach Prüfung bestehender Verknüpfungen bereinigt. Aus dem Posteingang gelöschte Mitteilungen werden nach 30 Tagen zur endgültigen Löschung berücksichtigt. Diese Bereinigungen laufen asynchron.
Für die Wiederherstellung der Firestore-Datenbank bestehen ein siebentägiges Wiederherstellungsfenster, tägliche Sicherungen mit 14 Tagen und wöchentliche Sicherungen mit 98 Tagen Aufbewahrung. Gelöschte Storage-Dateien können während der siebentägigen Soft-Delete-Frist wiederherstellbar bleiben. Sicherungen dienen der Notfallwiederherstellung, nicht der gewöhnlichen Nutzung; Löschanforderungen sind auch bei einer Wiederherstellung zu berücksichtigen.
Firebase-Authentifizierungsdaten werden nach Kontolöschung gemäß dem technischen Lösch- und Backup-Zyklus des Dienstleisters entfernt; Sicherungskopien können nach Anbieterangaben bis zu 180 Tage benötigen. Authentifizierungs-IP-Adressen können nach Anbieterangaben für einige Wochen gespeichert werden.
Ungültige Push-Token werden bei Abmeldung, Kontolöschung oder erkannten Zustellfehlern bereinigt; ein noch vorhandener Migrationseintrag wird nur bis zur abgeschlossenen Migration gespeichert.
Optionale Analysebelege zur Deduplizierung werden 72 Stunden gespeichert; zugehörige Aktivitäts-, Registrierungs-, Lösch- und Migrationsmarker 60 Tage. Zeitbezogene Detailaggregate werden 60 Tage gehalten; feste zusammengefasste Berichte bleiben bis zur planmäßigen Ersetzung oder Löschung erhalten.
Banner-Ereignisbelege werden nach 72 Stunden und technische Anfragelimits nach zwei Stunden zur Löschung fällig; planmäßige Löschung kann sich verzögern. Tägliche Banner-Zusammenfassungen werden 395 Tage aufbewahrt. Lokal wartende Ereignisse werden nach 48 Stunden nicht mehr gesendet und beim nächsten Verarbeitungslauf entfernt. Zustimmungsnachweise bleiben während der Kontobeziehung und danach nur soweit für gesetzliche Pflichten oder Rechtsansprüche erforderlich; bei Kontolöschung wird die Konto-ID darin anonymisiert.
Geschlossene Support-, Feedback- und Meldungsvorgänge samt Nachrichten werden grundsätzlich sechs Monate nach Abschluss gelöscht.
Ein pseudonymer Tageszähler begrenzt missbräuchliche Anfragen an das öffentliche DSA-Portal und wird nach höchstens zwei Tagen gelöscht; die rohe Netzwerkkennung wird dafür nicht im Zählerdokument gespeichert. Übliche technische Providerprotokolle können unabhängig davon nach deren Sicherheitsfristen bestehen.
Technische Systemprotokolle werden je nach gekennzeichneter Schutzklasse 90 Tage, normale Auditprotokolle 365 Tage, Sicherheitsprotokolle 730 Tage und Nachweise zu Moderationsstreitigkeiten bis zu 1.095 Tage gespeichert. Gesonderte auditLogs werden höchstens 1.095 Tage gespeichert.
Technische Nachweise, die eine Zustimmung an die anschließende Organisationserstellung binden, verfallen nach 30 Tagen und werden danach gelöscht. Der getrennte rechtliche Zustimmungsnachweis kann für die Dauer der Kontobeziehung und anschließend nur soweit für gesetzliche Pflichten, Streitklärung oder Rechtsansprüche erforderlich gespeichert bleiben.

Fristen können verlängert werden, wenn ein Rechtsstreit, eine behördliche Sicherungsanordnung, Betrugsverdacht oder eine zwingende gesetzliche Pflicht besteht. Nach Wegfall des Zwecks werden Daten gelöscht oder irreversibel anonymisiert.

13. Rechte betroffener Personen

Nach Maßgabe der DSGVO bestehen Rechte auf Auskunft, Berichtigung, Löschung, Einschränkung, Datenübertragbarkeit, Widerspruch gegen Verarbeitung nach Art. 6 Abs. 1 lit. e oder f und Widerruf einer Einwilligung für die Zukunft. Außerdem besteht das Recht, keiner unzulässigen ausschließlich automatisierten Entscheidung unterworfen zu werden.

Anfragen sind an ukrainian.community@outlook.com zu richten. Wir antworten grundsätzlich innerhalb eines Monats. Bei komplexen oder zahlreichen Anträgen kann die Frist gesetzlich verlängert werden. Zum Schutz vor Offenlegung an Unbefugte dürfen wir angemessene Identitätsnachweise verlangen. Offensichtlich unbegründete oder exzessive Anträge können nach den gesetzlichen Voraussetzungen abgelehnt oder mit einem angemessenen Entgelt verbunden werden.

Beschwerden können bei der Österreichischen Datenschutzbehörde, Barichgasse 40–42, 1030 Wien, E-Mail dsb@dsb.gv.at, oder bei einer sonst zuständigen Datenschutzaufsicht eingebracht werden.

14. Kinder

Die Plattform richtet sich nicht gezielt an Kinder unter 14 Jahren. In Österreich ist eine auf Einwilligung gestützte Verarbeitung bei einem direkt an ein Kind gerichteten Dienst ab Vollendung des 14. Lebensjahres ohne Zustimmung der Eltern möglich. Andere Regeln zur Geschäfts- und Deliktsfähigkeit bleiben davon unberührt. Erlangen wir Kenntnis von einem unzulässigen Konto oder einer ohne erforderliche Zustimmung erfolgten Verarbeitung, prüfen und löschen oder beschränken wir die Daten angemessen.

15. Website und lokale Spracheinstellung

Die öffentlichen Support- und Rechtsseiten verwenden derzeit keine Werbe- oder Analyse-Cookies. Die gewählte Sprache wird ausschließlich im lokalen Speicher des Browsers unter uc-language gespeichert. Server und Hostinganbieter können technisch notwendige Zugriffs- und Sicherheitsprotokolle verarbeiten. Wird die Website künftig um Formulare, Analyse, externe Medien oder neue Speichermechanismen erweitert, muss diese Erklärung vor Aktivierung angepasst werden.

16. Änderungen und Versionierung

Diese Erklärung wird bei Änderungen von Funktionen, Datenflüssen, Empfängern, Rechtsgrundlagen oder Fristen aktualisiert. Neue Versionen werden mit Datum und Änderungszusammenfassung veröffentlicht. Eine Datenschutzerklärung wird nicht durch bloße Nutzung „akzeptiert“; erforderliche Einwilligungen werden separat eingeholt. Bei wesentlichen Änderungen informieren wir in der App. Frühere Fassungen und Annahmenachweise der Nutzungsbedingungen werden soweit erforderlich dokumentiert.

17. Quellen der Daten

Daten stammen überwiegend direkt von der betroffenen Person, aus ihren App-Handlungen oder vom Gerät/Firebase-Dienst während des Betriebs. Rollen- und Organisationsdaten können von einer berechtigten Organisation oder einem Administrator stammen. Meldungen können Angaben Dritter enthalten. Bei nicht direkt erhobenen Daten informieren wir nach Art. 14 DSGVO, soweit keine gesetzliche Ausnahme greift.

18. Administrativer Online-Status und letzte Aktivität

Die aktuelle App übermittelt für angemeldete aktive Konten im Vordergrund ungefähr alle 90 Sekunden sowie bei Zustandswechseln ein minimales Anwesenheitssignal. Es enthält die Konto-ID, eine zufällige Sitzungskennung, eine laufende Nummer und den Aktivstatus; der Server setzt den Zeitpunkt. „Online“ und „zuletzt online“ sind von der letzten Anmeldung bei Firebase Authentication getrennt. Der serverseitige Online-Status gilt bis zu 180 Sekunden nach dem letzten bestätigten aktiven Signal. Ohne ein neues aktives Signal läuft diese Frist ab; die sichtbare Anzeige kann sich abhängig von Aktualisierung und Verbindung verzögert ändern. Die Anzeige ist eine Annäherung und kein Nachweis genauer Anwesenheits- oder Abmeldezeiten.

Nur der Plattforminhaber und berechtigte Plattformadministratoren mit aktivem, verifiziertem Konto können den abgeleiteten Status und den letzten bestätigten Zeitpunkt in der Benutzerverwaltung sehen. Andere Nutzer sowie Inhaber, Administratoren oder Moderatoren einzelner Organisationen erhalten dadurch keinen Zugriff. Zweck ist die Unterstützung bei aktuellen Konto- und Verbindungsproblemen sowie die nachvollziehbare Verwaltung des Plattformbetriebs. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO: unser berechtigtes Interesse an diesem beschränkten administrativen Support. Aus der Anzeige allein werden keine Sperren oder anderen nachteiligen Entscheidungen abgeleitet.

Gespeichert werden ein letzter bestätigter Zeitpunkt und höchstens 32 technische Sitzungsmarker pro Konto. Es werden dafür keine besuchten Seiten, Inhalte, Gerätekennungen, Standorte oder Verlaufslisten gespeichert. Marker älter als zehn Minuten werden beim nächsten Update entfernt; ohne weitere Updates können sie bis zur Kontolöschung verbleiben, gelten aber nicht weiter als online. Der letzte Zeitpunkt wird bei erneuter Aktivität überschrieben und bei Kontolöschung entfernt. Die App führt keine dauerhafte Offline-Warteschlange für diese Signale.

Diese Verarbeitung ist keine optionale Reichweitenanalyse und erfolgt unabhängig von deren Einwilligung. Sie dient weder Werbung noch appübergreifendem Tracking. Ein Widerspruch aus Gründen Ihrer besonderen Situation kann an ukrainian.community@outlook.com gerichtet werden; wir prüfen ihn nach Art. 21 DSGVO. Einwilligungen zur optionalen Analyse gelten nicht als Einwilligung zum Online-Status.

Änderung gegenüber Version 2026.10: Diese neue administrative Funktion, ihr Empfängerkreis, Zweck und Speicherumfang werden ausdrücklich beschrieben. Die übrigen Verarbeitungszwecke und die Bedingungen für optionale Analyse bleiben unverändert.

19. Freiwilliger lokaler Schutz mit Face ID / Touch ID

Bei der Registrierung oder später im Profil kann freiwillig eine lokale App-Sperre aktiviert werden; die Auswahl ist zunächst ausgeschaltet. Sie schützt eine bereits bei Firebase angemeldete Sitzung unabhängig davon, ob die Anmeldung mit E-Mail und Passwort, Apple oder Google erfolgte. Die lokale Sperre ist von diesen Anmeldemethoden getrennt und ersetzt sie nicht. Ein- und Ausschalten bleiben im Profil möglich.

Die Prüfung erfolgt durch die lokale Systemauthentifizierung des Geräts — auf iOS über Apple LocalAuthentication, auf Android über die geschützte Biometrie-/Gerätecode-Schnittstelle. Je nach Gerätekonfiguration kann der Gerätecode als Alternative angeboten werden. Wir erhalten ausschließlich das Ergebnis der Prüfung, keine Gesichtsvorlage, Fingerabdrücke oder den Gerätecode. Biometrische Daten werden nicht an uns oder Firebase übertragen. Lokal wird lediglich eine kontobezogene Einstellung unter einer gehashten Konto-ID gespeichert; das ist keine anonyme Kennung. Diese Einstellung wird nicht mit anderen Geräten synchronisiert. Die freiwillig angeforderte lokale Schutzfunktion dient der Kontosicherheit und Vertragserfüllung (Art. 6 Abs. 1 lit. b DSGVO).

20. Technische SDK-Diagnose und regionale Kontostatistik

Die in Abschnitt 10 beschriebene Einwilligung steuert ausschließlich die optionalen täglichen Inhalts- und Aktionssignale unserer eigenen Auswertung. Sie schaltet nicht sämtliche technischen Verarbeitungen der eingebundenen Firebase-Dienste ab. Die verwendeten SDKs können technische Angaben wie Betriebssystem-, Geräte- und App-Version sowie SDK-/Transportdiagnosen für Betrieb, Fehleranalyse und Produktqualität übermitteln. Dies ist kein Google-Analytics-SDK und kein Werbetracking. Anbieterdiagnosen und kontobezogene eigene Fehlerprotokolle werden in den Datenschutzangaben der jeweiligen App-Plattform entsprechend ihrer jeweiligen Zwecke offengelegt. Für die erforderliche technische Bereitstellung und Sicherheit gelten die in Abschnitt 4 beschriebenen Zwecke und Rechtsgrundlagen; Empfänger und Übermittlungsgarantien sind in den Abschnitten 8 und 9 erläutert. Weitere Angaben zu den Diensten: https://firebase.google.com/support/privacy.

Die Gesamtzahl der Konten sowie Registrierungs-, Status- und Bundeslandstatistiken werden getrennt von der optionalen Inhaltsanalyse aus notwendigen Kontodatensätzen zusammengefasst. Das manuell ausgewählte Bundesland ist kontobezogene regionale Information; es ist keine GPS-Messung. Diese zusammengefassten Berichte sind nur für den Plattforminhaber zugänglich und unterstützen die Verwaltung des Kontobestands und des regionalen Plattformangebots. Grundlage ist Art. 6 Abs. 1 lit. f DSGVO, unser berechtigtes Interesse an dieser beschränkten Betriebsverwaltung. Die Berichte enthalten keine Teilnehmerlisten, dienen weder Werbung noch individuellen nachteiligen Entscheidungen und sind keine GPS-Auswertung. Das Widerspruchsrecht nach Abschnitt 13 bleibt bestehen. Eine frühere Erklärung wird nicht als neue Einwilligung behandelt.

21. Zusätzlicher Anmeldeschutz mit einer Authenticator-App

Für geschützte Inhaber- und Administratorzugriffe wird ein zeitbasiertes Einmalpasswort (TOTP) über Firebase Authentication verwendet. Bei der Einrichtung werden ein technischer Einrichtungsschlüssel beziehungsweise ein QR-Code an die von Ihnen gewählte Authenticator-App übergeben. Firebase verarbeitet die Faktorzuordnung zum Konto und die zur Prüfung eingegebenen Einmalcodes. UAC speichert Einrichtungsschlüssel und Einmalcodes nicht in öffentlichen Profilen, Firestore-Inhalten oder Anwendungsprotokollen. Die Authenticator-App verarbeitet den Schlüssel nach ihren eigenen Bedingungen. Sicherheitsrelevante Verwaltungs- und Wiederherstellungsvorgänge können ohne Schlüssel oder Einmalcode im Auditprotokoll dokumentiert werden; dafür gelten die Fristen in Abschnitt 12. Dies dient dem Kontoschutz nach Abschnitt 4 und ist von der lokalen Face-ID-/Touch-ID-Sperre getrennt.

Änderungen gegenüber 2026.11: freiwillige lokale Gerätesperre, Pflichtregion, technische Firebase-Diagnose, getrennte regionale Kontoberichte, TOTP-Anmeldeschutz sowie präzisere Lösch- und Sicherungsfristen. Die Bedingungen für optionale Inhaltsanalyse bleiben unverändert.

22. Passkeys für geschützte Konten

Personen mit bestätigtem Konto können freiwillig einen Passkey einrichten. Für Inhaber und Administratoren ist vor dem Hinzufügen oder Entfernen eines Passkeys eine frische Anmeldung mit dem Authenticator erforderlich; für andere Konten eine frische Anmeldung. Das Gerät erzeugt ein Schlüsselpaar. Der private Schlüssel und die biometrischen Merkmale beziehungsweise der Gerätecode bleiben beim Geräte- und Passkey-Anbieter; UAC erhält sie nicht. UAC speichert in Firebase Firestore die öffentliche Schlüsselkomponente, eine technische Kennung des Passkeys, den Signaturzähler, die Zuordnung zur Konto-ID sowie Erstellungs- und letzte Nutzungszeit. Bei der Anmeldung prüft unser Server eine signierte, einmalige Challenge und übergibt Firebase Authentication einen zeitlich begrenzten Anmeldetoken für dieselbe bestehende Konto-ID. Dadurch kann die geschützte Sitzung ohne TOTP-Code beginnen. TOTP bleibt als alternativer Anmeldeweg bestehen.

Challenges sind nach fünf Minuten ungültig und werden regelmäßig entfernt. Beim Entfernen eines Passkeys wird sein serverseitiger Datensatz gelöscht; bereits bestehende geschützte Passkey-Sitzungen verlieren durch einen neuen Sitzungsmarker die Berechtigung. Bei Kontolöschung werden auch die Passkey-Datensätze entfernt. Diese Verarbeitung dient der sicheren, nutzerfreundlichen Kontoverwaltung gemäß Art. 6 Abs. 1 lit. b und f DSGVO. Sie ist von der freiwilligen lokalen App-Sperre aus Abschnitt 19 getrennt.

Änderung gegenüber 2026.18: Der Inhalt bleibt unverändert. Diese Version stellt sicher, dass die aktualisierte Datenschutzerklärung vor der weiteren Nutzung ausdrücklich bestätigt wird.

Änderung gegenüber 2026.19: Veröffentlichte Nachrichten werden bereits 30 Tage nach der Veröffentlichung für die planmäßige Löschung berücksichtigt. Die Aufbewahrungsfrist für Veranstaltungen bleibt unverändert.

Änderung gegenüber 2026.20: Eine gesonderte freiwillige Einwilligung ermöglicht zusammengefasste Berichte über sichtbare Banner-Einblendungen und Aufrufe. Die Passkey-Beschreibung berücksichtigt die Verfügbarkeit für alle bestätigten Konten.

1. Відповідальна особа та контакт

Відповідальною особою за Загальним регламентом захисту даних (GDPR) є:

Timofeev Philipp
Egger-Lienz-Straße 47, 6020 Innsbruck
Австрія
Електронна пошта: ukrainian.community@outlook.com

Уповноваженого із захисту даних не призначено, оскільки за поточної діяльності обов’язок такого призначення не встановлено. Запити щодо даних можна надсилати на адресу вище.

2. Сфера дії та ролі

Ця політика поширюється на застосунок UkrainianCommunity для iOS та Android, а також на публічні сторінки підтримки й правових документів. UkrainianCommunity є відповідальною особою щодо облікових записів, роботи платформи, контролю доступу, модерації, безпеки, сповіщень і описаної тут аналітики першої сторони.

Організації, організатори подій, магазини й фахівці можуть самостійно бути відповідальними особами щодо даних, які вони збирають для власних пропозицій або обробляють поза платформою, наприклад списків учасників, замовлень, продажів чи прямих контактів. Додатково застосовуються їхні повідомлення про конфіденційність. Сама поява сторінки організації на платформі не робить її та UkrainianCommunity спільними відповідальними особами.

3. Категорії даних

Залежно від використання ми обробляємо:

Обліковий запис і профіль: Firebase UID, електронну адресу, ім’я для показу, фото, біографію, необов’язкове ім’я Telegram, мову, федеральну землю, роль, статус, підтвердження та згоди.
Вміст: новини, події, організації, описи, категорії, місця чи вручну введені координати, зображення й галереї, коментарі, контакти та метадані створення або зміни.
Взаємодії: вподобання, збереження, підписки на організації, реєстрації на події, усунення повторного підрахунку переглядів, публічні лічильники та нещодавно переглянуте.
Комунікацію й модерацію: підтримку, відгуки, скарги, точне місце вмісту, пояснення, контактні дані заявника, відповіді, рішення, попередження, блокування, оскарження та докази. Для публічного доступу до DSA-справи зберігаються номер справи та лише хеш конфіденційного коду доступу.
Створення організації та юридичні докази: прийняту версію правил, серверний час, ID облікового запису, мову й версію застосунку, а також ID і вказану назву запланованої організації. Короткостроковий технічний доказ пов’язує згоду саме з цим профілем.
Сповіщення: Firebase Installation ID, APNs/FCM-токени, технічний стан доставки, теми або налаштування та результат доставки. Для необов’язкових повідомлень можуть оброблятися похідний від секрету встановлення ідентифікатор документа, короткостроковий challenge, а також докази показу, підтвердження й дії з платформою, мовою, прив’язкою до акаунта та часом. Під час міграції старий токен може тимчасово зберігатися паралельно.
Безпеку й технічні дані: App Check разом з Apple App Attest або Google Play Integrity, IP-адресу та технічні дані запитів у Firebase, час, версію й інформацію про пристрій, помилки, системні, безпекові та аудиторські журнали. Назва пристрою може бути частиною реєстрації push, якщо застосунок її передає.
Необов’язкову аналітику першої сторони: після явної згоди — мінімальні щоденні сигнали переглядів і дій, ID матеріалу, час, покоління згоди й іноді одноразовий доказ дії. Під час усунення дублів сигнал пов’язаний з обліковим записом; звіти містять агреговані значення без списків учасників.
Добровільне вимірювання банерів: після окремої згоди — ID банера, розділ застосунку, видимий показ або натискання та час. ID акаунта, згоди й події використовуються для перевірки прав і усунення дублів. Денні звіти містять зведені показники за банером і розділом, без списків відвідувачів.

Ми не використовуємо рекламний IDFA, App Tracking Transparency для реклами, рекламні мережі або продукт Google/Firebase Analytics. Ми не продаємо персональні дані й не використовуємо їх для рекламного відстеження між застосунками чи компаніями.

4. Мета та правові підстави

Обробка	Мета	Правова підстава
Обліковий запис, вхід, профіль і вибрані функції	Надання платформи та функцій за договором	ст. 6(1)(b) GDPR
Публікація й керування вмістом/організацією	Надання запитаної послуги публікації та керування	ст. 6(1)(b) GDPR
Вподобання, збереження, підписки, реєстрації та потрібні лічильники	Виконання й узгодженість явно вибраної функції	ст. 6(1)(b) GDPR
Модерація, протидія зловживанням, докази й безпека	Захист користувачів, прав і надійної роботи	ст. 6(1)(f), а коли потрібно — (c) GDPR
Юридичні повідомлення й запити органів	Виконання обов’язків, зокрема за DSA	ст. 6(1)(c) GDPR
Підтримка й добровільний відгук	Опрацювання звернення	ст. 6(1)(b) або (f) GDPR залежно від змісту
Необхідні службові повідомлення	Безпека, модераційні рішення й виконання договору	ст. 6(1)(b), (c) або (f) GDPR
Необов’язкові push-сповіщення	Доставка вибраних повідомлень	ст. 6(1)(a); технічне керування токеном також (b)/(f) до відключення
Необов’язкова аналітика першої сторони	Агреговані звіти охоплення й використання	ст. 6(1)(a) GDPR
Добровільне вимірювання банерів	Зведені звіти про видимі покази й натискання для власника платформи	ст. 6(1)(a) GDPR (окрема згода)
Правовий захист	Подання, здійснення або захист правових вимог	ст. 6(1)(f), за потреби ст. 9(2)(f) GDPR

Наші законні інтереси: безпека платформи й облікових записів, запобігання шахрайству, простежувана модерація, захист інших осіб і захист від вимог. Особа може заперечити з причин своєї конкретної ситуації; тоді ми проведемо балансування інтересів.

5. Обов’язкові дані та наслідки ненадання

Для облікового запису потрібні електронна адреса, ім’я для показу, явно вибрана федеральна земля Австрії, підтвердження мінімального віку й технічний ID. Пароль потрібен лише для реєстрації за електронною адресою і паролем; його обробляє Firebase Authentication, а не поле профілю чи адміністративний розділ. Під час входу через Apple або Google ми отримуємо через Firebase Authentication дані постачальника, потрібні для входу та прив’язки облікового запису. Позначені як обов’язкові поля організації чи події потрібні для перевірки, публікації та контакту. Без них відповідна функція недоступна. Необов’язкові поля, аналітику й необов’язкові push можна відхилити або вимкнути без втрати базового облікового запису.

6. Публічний вміст і дані інших осіб

Опубліковані елементи профілю, організації, події, новини, зображення, коментарі й лічильники видимі іншим та можуть бути збережені або поширені поза нашим контролем. Перед публікацією перевірте, чи справді потрібні приватні телефони, домашні адреси, номери, документи або дані дітей.

Особа, яка завантажує дані іншої людини, повинна її поінформувати й мати правову підставу. До дитячих фото, списків учасників і чутливої інформації діють підвищені вимоги. Не публікуйте платіжні, медичні, паспортні дані або паролі у відкритих полях.

7. Місцезнаходження

Застосунок не запитує дозвіл на місцезнаходження в iOS чи Android і не зчитує геолокацію пристрою. Автор може вручну ввести місце чи координати публічного матеріалу. Регіональна статистика використовує регіон матеріалу або профілю, а не постійне відстеження пристрою.

8. Firebase, Apple та одержувачі

Для роботи ми використовуємо сервіси групи Google як процесора: Firebase Authentication, Cloud Firestore, Cloud Storage, Cloud Functions, Cloud Messaging, Firebase Installations і App Check. Firebase може за нашими інструкціями обробляти технічні дані, ідентифікатори та вміст. Залежно від сервісу й конфігурації обробка відбувається в ЄЕЗ і третіх країнах.

Якщо в застосунку для iOS або Android ви виберете «Увійти з Apple», застосунок запитає ім’я та електронну адресу; Apple може надати адресу для пересилання замість особистої. Для входу у Firebase застосунок передає токен ідентифікації Apple та ім’я, якщо Apple його надає. Якщо ви виберете «Увійти з Google», застосунок використовує надані Google токени входу для авторизації у Firebase. Firebase Authentication обробляє ідентифікатор постачальника та надані дані облікового запису, зокрема електронну адресу, а за наявності — ім’я чи фото профілю. Apple або Google обробляють вхід у власному сервісі за своїми умовами конфіденційності. Зміна способу входу не об’єднує наявні облікові записи автоматично.

Push доставляють Apple Push Notification service (APNs) і Firebase Cloud Messaging. Apple і Google обробляють токени, технічні дані доставки та текст сповіщення за своїми умовами. Тому чутливу інформацію не слід показувати в push-попередженні.

Інші одержувачі обмежені уповноваженими адміністраторами за ролями; організацією, якщо цього потребує вибрана користувачем функція; юридичними, безпековими чи ІТ-постачальниками під конфіденційністю; органами або судами за законом чи чинною вимогою. Розкриття відбувається лише в необхідному обсязі.

9. Передача за межі ЄЕЗ

Для передачі за межі ЄЕЗ ми використовуємо рішення про належний рівень захисту, зокрема чинну сертифікацію EU–US Data Privacy Framework, або стандартні договірні положення Єврокомісії з необхідними додатковими заходами. Інформацію про конкретну гарантію можна запитати через контакт приватності. Перед публікацією ми повторно перевіряємо фактичну Firebase-конфігурацію й актуальний статус постачальника.

10. Необов’язкова аналітика та згода

Сама лише робота застосунку не вмикає необов’язкову аналітику як згоду. Згода версіонується, записується сервером і може бути відкликана в налаштуваннях на майбутнє. Відкликання зупиняє нові сигнали та видаляє несумісні локальні черги.

Необхідні функціональні записи — стан вподобання, збереження, підписки, реєстрації та усунення повторного підрахунку публічних переглядів — відокремлені від аналітики. Вони виникають лише через запитану функцію й не скасовуються вимкненням аналітики. Аналітика не називається анонімною, поки серверне усунення дублів пов’язане з обліковим записом.

Вимірювання банерів початково вимкнене й не залежить від згоди на аналітику вмісту. Показ зараховується, коли банер видно щонайменше на 50 % протягом однієї секунди; свідоме натискання зараховується окремо. Події передаються лише для акаунтів, у які виконано вхід, після окремої, версійної та підтвердженої сервером згоди. Вибір діє для цього акаунта на всіх пристроях, де виконано вхід, і його можна відкликати в налаштуваннях у будь-який час із дією на майбутнє. Відмова або відкликання не обмежують базовий акаунт і показ самих банерів. Після відкликання локальні події в черзі видаляються, а непідтверджений запит надсилається повторно. Рекламний ID, сторонні рекламні мережі й відстеження між застосунками не використовуються. Власник платформи бачить лише зведені числа; рекламодавці не отримують списків відвідувачів.

11. App Check, безпека та журнали

App Check разом з Apple App Attest або Google Play Integrity допомагає підтвердити, що запит надходить від справжнього екземпляра застосунку. Журнали безпеки й аудиту фіксують, зокрема, вхід, ролі, модерацію, видалення й адміністративні дії. Доступ мають лише дозволені ролі. Ми застосовуємо контроль доступу, серверні перевірки, шифрування під час передачі, мінімальні права та журналювання адміністративних дій. Абсолютну безпеку гарантувати неможливо.

Нові коментарі до публікації проходять обмежену серверну перевірку на явні погрози, мову ненависті, сексуальну експлуатацію дітей і масовий спам посиланнями. При збігу коментар не зберігається; особа може виправити текст і надіслати його знову або звернутися до підтримки. Відхилений текст і категорія збігу не зберігаються як справа модерації. Ця перевірка не замінює скарги чи людську оцінку вже опублікованого вмісту.

Ми не приймаємо виключно автоматизованих рішень із правовим або подібним істотним наслідком. Автоматичні безпекові перевірки чи пріоритизація можуть технічно відхилити публікацію або ініціювати людський перегляд, але не вирішують самостійно питання блокування акаунта чи юридичної модераційної справи.

12. Строки зберігання

Незавершені реєстрації видаляються через три дні після створення облікового запису Firebase під час найближчого щоденного очищення: якщо не підтверджено електронну адресу при вході з паролем або якщо незалежно від способу входу не створено профіль у застосунку. Видаляються обліковий запис для входу, початковий профіль, початкові записи про згоду та пов’язані технічні повідомлення. Якщо виявлено інші дані або невідповідності, автоматичне видалення зупиняється для перевірки. Строки резервного зберігання та обробки постачальником, описані нижче, залишаються чинними.
Дані облікового запису зберігаються до видалення; постійне блокування саме по собі не видаляє обліковий запис; обмежені докази можуть залишатися для виконання закону й правових вимог.
Опублікований вміст і функціональні записи загалом відповідають життєвому циклу матеріалу, облікового запису або організації. Планове очищення враховує новини через 30 днів після публікації, а заходи — через шість календарних місяців після завершення. Обмежені пакети обробки можуть затримувати очищення; збої потрібно відстежувати й виправляти. Можливі раніше видалення й обов’язкове законне збереження.
Завершені або архівовані записи планування підлягають видаленню через шість календарних місяців після завершення чи архівування. Непотрібні копії зображень очищаються лише після перевірки наявних зв’язків. Видалені з вхідних сповіщення враховуються для остаточного очищення через 30 днів. Ці процедури виконуються асинхронно.
Для відновлення бази Firestore діють семиденне вікно відновлення, щоденні резервні копії зі строком зберігання 14 днів і щотижневі — 98 днів. Видалені файли Storage можуть залишатися відновлюваними протягом семиденного строку м’якого видалення. Резервні копії призначені для аварійного відновлення, а не звичайного використання; під час відновлення також необхідно враховувати запити на видалення.
Після видалення облікового запису дані Firebase Authentication видаляються за технічним циклом сервісу; резервні копії, за даними постачальника, можуть потребувати до 180 днів. IP-адреси автентифікації можуть зберігатися кілька тижнів.
Недійсні push-токени очищаються після виходу, видалення або помилки доставки; міграційний запис — лише до завершення міграції.
Докази усунення дублів необов’язкової аналітики зберігаються 72 години; пов’язані маркери активності, реєстрації, видалення й міграції — 60 днів. Часові деталізовані агрегати — 60 днів; фіксовані агреговані звіти — до планової заміни чи видалення.
Квитанції подій банерів підлягають видаленню через 72 години, а технічні ліміти запитів — через дві години; планове видалення може затримуватися. Денні зведення банерів зберігаються 395 днів. Локальні події не передаються після 48 годин і видаляються під час наступної обробки. Докази згоди зберігаються протягом існування акаунта, а після цього лише наскільки потрібно для законних обов’язків або правових вимог; під час видалення акаунта його ID знеособлюється.
Закриті звернення підтримки, відгуки й повідомлення разом із листуванням зазвичай видаляються через шість місяців після завершення.
Псевдонімний денний лічильник обмежує зловживання публічним DSA-порталом і видаляється не пізніше ніж через два дні; вихідний мережевий ідентифікатор у документі ліміту не зберігається. Звичайні технічні журнали провайдера можуть окремо зберігатися за його строками безпеки.
Технічні системні журнали зберігаються залежно від класу 90 днів, звичайний аудит — 365 днів, безпекові журнали — 730 днів, докази спорів щодо модерації — до 1 095 днів. Окремі auditLogs зберігаються не довше 1 095 днів.
Технічні докази, що пов’язують згоду з подальшим створенням організації, спливають через 30 днів і після цього видаляються. Окремий юридичний доказ прийняття може зберігатися протягом дії облікового запису, а потім лише настільки, наскільки це потрібно для закону, вирішення спору або правових вимог.

Строк може бути подовжено через спір, вимогу органу зберегти дані, підозру шахрайства або обов’язок закону. Після зникнення мети дані видаляються або незворотно анонімізуються.

13. Права особи

Відповідно до GDPR особа має право на доступ, виправлення, видалення, обмеження, перенесення, заперечення проти ст. 6(1)(e)/(f), відкликання згоди на майбутнє та захист від незаконного виключно автоматизованого рішення.

Запити надсилаються на ukrainian.community@outlook.com. Зазвичай ми відповідаємо протягом одного місяця; строк може бути законно подовжений для складних або численних запитів. Для захисту від стороннього доступу можна вимагати розумне підтвердження особи. Очевидно необґрунтований або надмірний запит може бути відхилений чи оплачуваним лише за умов закону.

Скаргу можна подати до Австрійського органу із захисту даних: Barichgasse 40–42, 1030 Wien, dsb@dsb.gv.at, або іншого компетентного наглядового органу.

14. Діти

Платформа не орієнтована спеціально на дітей до 14 років. В Австрії дитина, яка досягла 14 років, може самостійно надати згоду на обробку в онлайн-сервісі, що пропонується їй безпосередньо. Інші правила дієздатності й відповідальності неповнолітніх залишаються чинними. Якщо ми дізнаємося про недозволений обліковий запис або обробку без необхідної згоди, ми належно обмежимо або видалимо дані.

15. Вебсайт і локальне налаштування мови

Публічні сторінки підтримки й документів не використовують рекламні чи аналітичні cookies. Вибрана мова зберігається лише локально у браузері під ключем uc-language. Сервер і хостинг можуть вести технічно необхідні журнали доступу й безпеки. До активації форм, аналітики, зовнішніх медіа або нового сховища ця політика має бути оновлена.

16. Зміни та версії

Політика оновлюється при зміні функцій, потоків даних, одержувачів, правових підстав або строків. Нова версія публікується з датою й описом змін. Політика приватності не «приймається» самим користуванням; потрібні згоди запитуються окремо. Про істотні зміни повідомляємо в застосунку. Попередні версії та підтвердження прийняття Умов зберігаються, коли це потрібно.

17. Джерела даних

Переважно дані надходять від самої особи, з її дій у застосунку або від пристрою/Firebase під час роботи. Роль чи організаційні дані може надати уповноважена організація або адміністратор. Повідомлення можуть містити дані третіх осіб. Для даних, отриманих не безпосередньо від особи, ми надаємо інформацію за ст. 14 GDPR, якщо не діє законний виняток.

18. Адміністративний статус онлайн та остання активність

Поточний застосунок для авторизованих активних облікових записів надсилає мінімальний сигнал присутності приблизно кожні 90 секунд, поки він активний на екрані, а також під час зміни стану. Сигнал містить ID облікового запису, випадковий ID сеансу, порядковий номер та ознаку активності; час визначає сервер. «Онлайн» і «востаннє в мережі» відрізняються від останньої авторизації у Firebase Authentication. Серверний статус «онлайн» діє до 180 секунд після останнього підтвердженого активного сигналу. Без нового активного сигналу цей строк спливає; видимий статус може змінитися із затримкою залежно від оновлення та з’єднання. Це приблизна інформація, а не доказ точного часу присутності чи виходу.

Лише власник платформи та уповноважені адміністратори платформи з активним підтвердженим обліковим записом можуть бачити обчислений статус і останній підтверджений час у керуванні користувачами. Інші користувачі, а також власники, адміністратори й модератори окремих організацій не отримують такого доступу. Мета — допомога з поточними проблемами облікового запису та з’єднання, а також обґрунтоване адміністрування роботи платформи. Правова підстава — ст. 6(1)(f) GDPR: наш законний інтерес у такій обмеженій адміністративній підтримці. Сам по собі цей статус не є підставою для блокування чи інших несприятливих рішень.

Для облікового запису зберігаються один останній підтверджений час і щонайбільше 32 технічні маркери сеансів. Для цієї функції не зберігаються відвідані сторінки, вміст, ID пристрою, місцезнаходження чи історія активності. Маркери, старші за десять хвилин, видаляються під час наступного оновлення; без нових оновлень вони можуть залишатися до видалення облікового запису, але більше не означають статус «онлайн». Останній час перезаписується при новій активності та видаляється разом з обліковим записом. Застосунок не зберігає постійну офлайн-чергу цих сигналів.

Ця обробка не є необов’язковою аналітикою охоплення та не залежить від згоди на неї. Вона не використовується для реклами чи відстеження між застосунками. Заперечення з причин, пов’язаних із вашою особливою ситуацією, можна надіслати на ukrainian.community@outlook.com; ми розглянемо його відповідно до ст. 21 GDPR. Згода на необов’язкову аналітику не є згодою на статус онлайн.

Зміна порівняно з версією 2026.10: прямо описано нову адміністративну функцію, коло одержувачів, мету й обсяг зберігання. Інші цілі обробки та умови необов’язкової аналітики залишаються незмінними.

19. Добровільний локальний захист Face ID / Touch ID

Під час реєстрації або пізніше в профілі можна добровільно ввімкнути локальне блокування застосунку; спочатку цей перемикач вимкнений. Воно захищає сесію, у яку вже виконано вхід через Firebase, незалежно від способу входу: електронна адреса й пароль, Apple або Google. Локальне блокування є окремим від цих способів входу й не замінює їх. У профілі його можна вмикати та вимикати.

Перевірку виконує локальна системна автентифікація пристрою — Apple LocalAuthentication в iOS або захищений системний інтерфейс біометрії чи коду пристрою в Android. Залежно від налаштувань альтернативою може бути код пристрою. Ми отримуємо лише результат перевірки, а не шаблон обличчя, відбитки пальців чи код пристрою. Біометричні дані не передаються нам або Firebase. Локально зберігається лише налаштування для акаунта під хешованим ідентифікатором; це не анонімний ідентифікатор. Налаштування не синхронізується з іншими пристроями. Добровільно запитана функція локального захисту забезпечує безпеку акаунта та виконання договору (Art. 6 Abs. 1 lit. b DSGVO).

20. Технічна діагностика SDK і регіональна статистика акаунтів

Згода з розділу 10 керує лише необов’язковими щоденними сигналами щодо вмісту та дій для нашої власної аналітики. Вона не вимикає всю технічну обробку у Firebase. Використані SDK можуть передавати технічні відомості про версію операційної системи, пристрою й додатка та діагностику SDK/передавання для роботи, аналізу помилок і якості сервісу. Це не Google Analytics SDK і не рекламне відстеження. Діагностика постачальника й власні журнали помилок, пов’язані з акаунтом, зазначаються у відомостях про конфіденційність відповідної платформи застосунків згідно з їхніми цілями. Для необхідного технічного забезпечення та безпеки діють цілі й правові підстави з розділу 4; одержувачі та гарантії передавання описані в розділах 8 і 9. Докладніше про сервіси: https://firebase.google.com/support/privacy.

Загальна кількість акаунтів і статистика реєстрацій, статусів та федеральних земель узагальнюються з необхідних записів акаунтів окремо від необов’язкової аналітики вмісту. Вибрана вручну федеральна земля є регіональною інформацією, пов’язаною з акаунтом, а не GPS-вимірюванням. Ці зведені звіти доступні лише власнику платформи й допомагають адмініструвати облікові записи та регіональне наповнення платформи. Підстава — ст. 6(1)(f) GDPR, наш законний інтерес у такому обмеженому адмініструванні. Звіти не містять списків учасників, не використовуються для реклами чи індивідуальних несприятливих рішень і не є аналізом GPS. Право на заперечення з розділу 13 зберігається. Попереднє підтвердження не трактується як нова згода.

21. Додатковий захист входу через застосунок-автентифікатор

Для захищених дій власника й адміністратора використовується одноразовий код на основі часу (TOTP) через Firebase Authentication. Під час налаштування технічний ключ або QR-код передається вибраному вами застосунку-автентифікатору. Firebase обробляє прив’язку фактора до акаунта та введені для перевірки одноразові коди. UAC не зберігає ключі налаштування й одноразові коди в публічних профілях, вмісті Firestore або журналах застосунку. Застосунок-автентифікатор обробляє ключ за власними умовами. Безпекові дії адміністрування та відновлення можуть фіксуватися в аудиті без ключа й одноразового коду; діють строки з розділу 12. Це захищає акаунт відповідно до розділу 4 і є окремим від локального блокування Face ID / Touch ID.

Зміни порівняно з 2026.11: добровільне локальне блокування, обов’язковий регіон, діагностика Firebase, окремі регіональні звіти, TOTP-захист входу та точніші строки видалення й резервного зберігання. Умови необов’язкової аналітики вмісту залишаються незмінними.

22. Ключі доступу для захищених облікових записів

Власники підтверджених акаунтів можуть добровільно створити ключ доступу. Для власника платформи й адміністраторів перед додаванням або видаленням ключа потрібен нещодавній вхід із кодом автентифікатора; для інших акаунтів — нещодавній вхід. Пристрій створює пару ключів. Приватний ключ і біометричні дані або код пристрою залишаються у постачальника пристрою та ключів доступу; UAC їх не отримує. UAC зберігає у Firebase Firestore відкритий ключ, технічний ідентифікатор ключа доступу, лічильник підписів, зв’язок з ID облікового запису, час створення й останнього використання. Під час входу наш сервер перевіряє підписаний одноразовий запит і передає Firebase Authentication обмежений у часі токен входу для того самого наявного ID облікового запису. Це дає змогу розпочати захищену сесію без коду TOTP. TOTP залишається альтернативним способом входу.

Запити стають недійсними через п’ять хвилин і регулярно видаляються. Після видалення ключа доступу його серверний запис видаляється, а наявні захищені сесії з ключем втрачають доступ завдяки новому маркеру сесії. Під час видалення облікового запису записи ключів доступу також видаляються. Мета обробки — безпечне й зручне керування обліковим записом відповідно до ст. 6(1)(b) і (f) GDPR. Це окрема функція від добровільного локального блокування застосунку, описаного в розділі 19.

Зміна порівняно з 2026.18: зміст не змінено. Ця версія забезпечує обов’язкове підтвердження оновленої політики конфіденційності перед подальшим користуванням застосунком.

Зміна порівняно з 2026.19: опубліковані новини підлягають плановому видаленню вже через 30 днів після публікації. Строк зберігання заходів не змінюється.

Зміна порівняно з 2026.20: окрема добровільна згода дозволяє зведені звіти про видимі покази й натискання банерів. Опис ключів доступу враховує їхню доступність для всіх підтверджених акаунтів.