Veröffentlichung einer Web-App(Stream-Counter) [Rechtliches]

Hallo liebe Bohnen,

als ich vor einiger Zeit ein gestreamt hatte, habe ich festgestellt, dass es keine „einfache“ Lösung gibt, einen (Death-)Counter zu erstellen und so habe ich selbst eine Web-Applikation entwickelt, mit der man einen Counter für seinen Stream, mit einem Klick, erstellen kann.
Man kann den Counter mit Icons und/oder Text versehen. Außerdem kann man den Counter über den Web-Browser als auch über das Smartphone steuern.

Die Web-App funktioniert ohne Probleme und mein Plan war es eigentlich da ganze, online, für alle verfügbar zu machen. Als ich mich aber ein bisschen mit dem Thema „Rechtliches“ beschäftigt habe, habe ich Bedenken bekommen, da ich logischerweise nicht wegen irgendetwas abgemahnt/angezeigt werden will. Gerade beim Thema Icons bin ich mir ziemlich unsicher.

Meine Frage ist also:
Reicht es wenn ich ein „Benutzung auf eigene Gefahr“-Popup hinzufüge, das bestätigt werden muss, um sich rechtlich komplett abzusichern oder Bedarf es dazu noch weiterer Schritten?

Noch als kleiner Hinweis, es werden keine personenbezogene Daten gespeichert. DSGVO sollte also kein Thema sein.

Wenn sich jemand mit dem Thema auskennt, würde ich mich sehr über einen Rat/Tipp freuen. Danke schon mal im voraus :slight_smile:

Hi,
sobald du eine Website(-Anwendung) zur Verfügung stellst, solltest du drüber nachdenken eine „Terms and Conditions“ zu erstellen, die entsprechend vor Benutzung bestätigt werden muss bzw. drauf hingewiesen wird, dass bei der Benutzung diese gelten. Es gibt einige „Generators“ im Internet, mit denen man relativ einfach eine grundlegende T&C erstellen kann. Genügt im Normalfall um sich wie in deinem Fall „Benutzung auf eigene Gefahr“ abzusichern :wink:
100% sicher kannst du dir nur sein, wenn du wirklich mit einem Anwalt hergehst und haargenau prüfst was Sache ist :smiley:
Zusätzlich solltest du dir sicher sein, was bei der Benutzung von entsprechenden APIs alles erlaubt ist und wie Daten verwendet werden dürfen.
Du hast auch Icons erwähnt. Da kommts natürlich drauf an, was sind das für Icons.
Ansonsten wenn du das z.B. als Open Source veröffentlichst, kann man entsprechende Lizenzen mitgeben, z.B. " GNU Affero General Public License v3.0" fürs Self-Hosting.

Die DSGVO zieht übrigens nicht nur bei der Speicherung von personenbezogenen Daten, sondern auch schon bei der Erhebung, Verarbeitung/Bearbeitung, ggf. Weiterleitung usw.

Ich will dir damit jetzt keine Angst machen. :smiley:
Ich denke deine Web-App ist relativ rudimentär, von daher sollte eine einfache T&C mit Hinweis auf „Nix Liability und nix Warranty“ genügen :wink:

1 „Gefällt mir“

Vielen Dank schon mal für die Antwort :slight_smile:

Derzeit verwende ich 2 Icon Fonts:

Wobei der Streamer (Nutzer) nur die Rpg-Awesome Icons in seinem Stream verwenden kann. Fontawesome-Icons werden nur in der Web-App verwendet.

Die API habe ich mir selbst programmiert, deswegen bin ich mir 100% sicher, dass ich keine personenbezogene Daten in irgendeiner Weise verarbeite o.ä…

Von Open-Source bin ich ein großer Freund und denke, dass ich das ganze dann auch veröffentlichen werde.

Ok, da sollte es ja keine Probleme geben.

Achso, das hab ich dann falsch verstanden. Dachte du verwendest die API von der Streamplattform, wie Twitch oder so :smiley:

Dann sollte das ganze eigentlich alles ohne Probleme laufen :wink:

Hi,

du Verarbeitest mit Sicherheit die IP-Adresse vom Client. (Webserver) Also das gehört z.B. zu den Personenbezogenen Daten, (IP + Zeit).

Wichtig bei der DSGVO und deiner privaten App (denke mal wird nicht gewerblich genutzt) das du mit dem Hoster den Auftragsdatenverarbeitungsvertrag abschließt. (Macht man egtl. mittlerweile automatisch)

Eine generierte Datenschutzrichtlinie reicht in den meisten fällen völlig aus.

Darf ich fragen wie deine API funktioniert?

Hi @Larsonnn,
ich könnte in meiner API die IP-Adresse abrufen/loggen/speichern, tue dies jedoch an keiner Stelle. Sofern das reine Hosting nicht zur Verarbeitung von IP-Adressen zählt, sollte es mich also nicht betreffen.
Lediglich die Zeit wird genutzt um ein Ablaufdatum zu erzeugen.

Den Code zu meinem API (und FrontEnd) wollte ich demnächst Online verfügbar machen. Muss nur nochmal überprüfen, ob keine Secrets in der Git-History sind.

Die grundlegende Ablauf ist jedoch:

  1. User ruft FrontEnd und klickt auf „Neuen Counter“
  2. Anfrage an API (GraphQL-Endpunkt)
  3. Neuer Counter wird auf dem Server generiert und in einer (Mongo-)DB gespeichert (Ablaufdatum: 1 Tag)
  4. Counter wird zurück an den Client gegeben (wird zusätzlich im LocalStorage gespeichert)
  5. User kann Counter über OBS als Browser-Input einbinden (aktualisiert sich automatisch bei Änderung von Werten/Eigenschaften) (Subscriptions über Websockets)
  6. User kann über den Client, Werte/Eigenschaften des Counters verändern, dabei werden die Daten in der DB über die API angepasst (Mutation)
  7. Wenn der Counter abgelaufen ist, fliegt er aus der DB.
  8. Ein User kann die Werte/Eigenschaften seines letztens Counters (aus dem LocalStorage) wiederherstellen, um einen neuen Counter zu erstellen.

Zusätzlich besteht die Möglichkeit den Counter über das Smartphone o.ä. zu steuern.
Sobald die API online verfügbar ist, kann Sie theoretisch auch von anderen Programmen verwendet werden (z.B. Twitch-/Discord-Bots o.ä.).

Hoffe ich hab es einigermaßen verständlich erklärt :sweat_smile:
Falls du noch mehr wissen willst sag gerne Bescheid :smiley:

PS: Hosting würde, nach jetzigem Plan, einfach bei mir Zuhause stattfinden. Habe eine Domain und einen kleinen Server daheim.

Die Frage ist: tut dies dein Hoster, z.B. im Rahmen von Access-Logs durch dessen Webserver? Daher auch der Hinweis weiter oben auf den Auftragsdatenverarbeitungsvertrag.

Da du’s selbst hostest musst du selbst wissen, was dein Webserver (unabhängig vom API-Code) macht :wink: – in der Standardkonfiguration loggen die meisten Webserver-Installationen irgendwas mit (z.B. bei Fehlern).

1 „Gefällt mir“

Danke @simmscmi für den Hinweis :slight_smile:

Ich verwende einen NGINX (als Reverse Proxy) und habe jetzt für (Sub-)Domain folgendes eingetragen:
access_log off;
log_not_found off;
error_log /dev/null;

Das sollte (so wie ich verstanden habe) alle Logs für diese (Sub-)Domain ausschalten.

Hallo,

Das Reicht leider nicht du musst in den Datenschutzrichtlinien dennoch drin stehen haben , das du die IP verwendest.

Das liegt einfach daran das der Webserver die Antwort an den Client schickt. Das zählt halt schon zur Verarbeitung. Das ist aber ein Einzeiler in den Datenschutzrichtlinien.

Hm, ok.
Echt viel, auf das man achten muss…
Naja dann werd ich mir zur Sicherheit eine Datenschutzerklärung generieren und einbinden.

Nochmal vielen Dank für die Tipps. :smiley:
Ich mach das zum ersten Mal und will nix falsch machen