Datenschutz

Das Bundesdatenschutzgesetz (Frameversion oder BDSG - fortlaufend) regelt die Verarbeitung personenbezogener Daten. Innerhalb des hiesigen Angebotes tauchen personenbezogene Daten an unterschiedlichen Stellen auf. So teilt die Erstanmeldung eines Interessenten server-daten dessen personenbezogene Daten mit. Ferner kann ein Kunde in seiner Datenbank Informationen, bsp. Daten seiner Geschäftspartner, ablegen, für welche das BDSG Gültigkeit beansprucht. Läßt er andere Nutzer zu seiner Datenbank zu, so erfährt er mindestens deren Mailadressen. Schließlich werden personenbezogene Daten bei der kontinuierlich mitlaufenden Protokollierung sämtlicher Schreibzugriffe kanonisch erzeugt. Die folgenden Ausführungen unterscheiden diese verschiedenen Fälle.

1. Verhältnis zwischen dem Kunden und server-daten

server-daten erhebt, verarbeitet und nutzt personenbezogene Daten eines Kunden nur, soweit sie für die Vertragsbegründung und -abwicklung sowie zu Abrechnungszwecken erforderlich sind.

Zwingend erforderlich sind Name, Anschrift sowie eine gültige Mailadresse. Ohne diese Daten kann ein Vertrag nicht begründet werden.

Freiwillig sind Telefon und Fax. Diese werden - falls vorhanden - genutzt, um mit dem Kunden in bezug auf seine Datenbank in Kontakt zu treten. Falls der Kunde aufgrund von Störungen seines Netzanbieters seine Datenbank nicht erreichen kann, ermöglichen Telefon bzw. Fax den Rückruf durch server-daten und gestatten hierdurch ausnahmsweise eine ersatzweise Authentifizierung des Kunden. Fehlen diese Daten, so kann server-daten nur nach schriftlicher Bestätigung per Post tätig werden.

Die erhobenen Daten werden außerhalb der Kundendatenbank in einer Zeile einer gesonderten Tabelle gespeichert. Der Kunde kann diese jederzeit im Menü <Eigene Einstellungen> - <Kundendaten> abrufen. Der Kunde ist verpflichtet, die Korrektheit seiner Daten bei Änderung seiner Adresse o.ä. sicherzustellen. server-daten protokolliert, wie bei allen Änderungen innerhalb der Kundendatenbank, auch für die Kundendaten jeden Schreibzugriff und zeigt dieses Protokoll in gewohnter Weise an. Diese Daten sind nur für server-daten, den Kunden (= admin dieser Datenbank) sowie für Nutzer des Kunden sichtbar, welchen dieser das Recht zum Zugriff auf diese Daten eingerichtet hat.

Mietet ein Kunde mehrere Datenbanken, so wird immer auf denselben Kundendatensatz zurückgegriffen. Pro Datenbank werden die Informationen gespeichert, welche im Menü <Eigene Daten> - <Datenbank> angezeigt werden. Ändert der Kunde hier Daten, so wird dies analog protokolliert und angezeigt. Die Mailadresse kann für jede Datenbank individuell gewählt werden und entspricht immer der Mailadresse für den Nutzer admin in dieser Datenbank. Eine Änderung der Mailadresse über <Kundendaten> ist gleichbedeutend mit der Änderung über <Eigene Daten> - <Sicherheit>.

Für jede Datenbank ist unter <Eigene Daten> - <Datenbank> ein Disclaimer für Mails festzulegen. Dieser wird an Mails angehängt, die Nutzer bei ihrer Erstanmeldung (anonym, anonym mit Nick, Initialpasswort), dem Anfordern eines neuen Passworts, dem Ändern einer Mailadresse oder dem Einrichten einer Urlaubssperre erhalten. Diese Mails werden vom System automatisiert versandt. Der Disclaimer sollte Name und Mail eines verantwortlichen Ansprechpartners enthalten. Diese Mails werden immer von noreply @ server-daten.de versandt. Mails an diese Adresse werden gelöscht.

Die Abrechnungsdaten sind über <Eigene Einstellungen> - <Buchungen> zugänglich. Die dort gelisteten Daten werden anhand der letzten sowie der aktuellen Buchung berechnet.

Die Subdomains werden lokal eingerichtet. Deren Namen bzw. die Kundendaten werden deshalb nicht an Einrichtungen wie die DENIC weitergegeben. Der Kunde ist sich jedoch bewußt, daß Adressen der Form <datenbank-name.server-daten.de> nicht geheim sind, auch wenn der Kunde selbst keine Ausgabeseiten erstellt bzw. keine erstellte Ausgabeseite verlinkt. Ein anderer Interessent kann bsp. bei der Eingabe seiner Daten feststellen, daß der von ihm gewünschte Datenbank-Name bereits vergeben ist und daß eine Subdomain schon existiert. Daraufhin erstellt dieser Interessent einen Hyperlink auf seiner Domain auf die Subdomain von server-daten.de, Suchmaschinen finden den Link und listen die Subdomain, Nutzer von Suchmaschinen finden über die site-Abfrage die 'geheime Subdomain'.

Bei Vorliegen der entsprechenden Voraussetzungen ist server-daten berechtigt, die personenbezogenen Daten zu erheben, verarbeiten und zu nutzen, die zum Aufdecken sowie Unterbinden von rechtswidrigen Inanspruchnahmen und zur Durchsetzung von Ansprüchen gegenüber dem Nutzer erforderlich sind. Soweit es im Einzelfall erforderlich ist, ist server-daten berechtigt, zum Erkennen, Eingrenzen und Beseitigen von Störungen und Fehlern von Datenbanken die Bestands- und Verbindungsdaten der Beteiligten zu erheben, verarbeiten und zu nutzen.

Gemäß der hierfür geltenden gesetzlichen Bestimmungen ist server-daten berechtigt, Auskunft an Strafverfolgungsbehörden und Gerichte für Zwecke der Strafverfolgung zu erteilen.

Abgesehen von den genannten Fällen werden die erhobenen Daten nicht an Dritte weitergegeben und nicht von server-daten für Werbung genutzt. Die einzigste Nutzung der Mailadresse besteht darin, mit dem Kunden in bezug auf Probleme mit dessen Datenbank zu kommunizieren sowie zur Information bei einer geänderten AGB oder einer wesentlichen Änderung des Angebotes.

server-daten erteilt dem Kunden gemäß § 34 Abs. 1 BDSG auf Verlangen unentgeltlich und unverzüglich Auskunft über die zu seiner Person gespeicherten Daten. server-daten weist jedoch darauf hin, daß bei regulärer Nutzung durch den Kunden sämtliche zu ihm erhobenen Daten über die oben genannten Menüs vom Kunden abrufbar sind.

2. Verhältnis zwischen den Daten in Kundendatenbanken und server-daten

Daten in Kundendatenbanken gehören dem Kunden. Sie werden in keinem Fall von server-daten an Dritte verkauft oder weitergegeben, ausgenommen Auskunft an Strafverfolgungsbehörden und Gerichte.

Bei dem vordefinierten Nutzer <server-daten>, welcher zusätzlich zu <admin> in jeder Datenbank vordefiniert ist, handelt es sich nicht um einen Nutzer, der von server-daten interaktiv über den Browser aufgerufen werden könnte. Einen Nutzer mit dieser Eigenschaft gibt es nicht. Dem Nutzer <server-daten> ist die interaktive Anmeldung explizit untersagt. Er dient dazu, für gewisse Objekte (etwa den Nutzer <admin>) einen Besitzer bereitzustellen und für gewisse Systemaktivitäten einen Nutzer für die Protokollierung bereitzustellen. Hat bsp. ein Nutzer seine Mailadresse geändert und den Bestätigungsschlüssel in das Formular eingetragen, so wird die Freischaltung der Mail im Protokoll als Aktion von <server-daten> vermerkt.

server-daten versichert, daß es keine geheime Backdoor oder ähnliches gibt, welche es ihm ermöglichen würde, über einen Standardbrowser auf die Datenbank eines Kunden zuzugreifen. Der Kunde ist sich jedoch bewußt, daß server-daten als Administrator des Datenbank-Servers bzw. der MS-SqlServer-Grundsoftware jederzeit über diesen Weg auf alle Daten zugreifen kann und daß server-daten als Entwickler der zusätzlichen Module technisch dazu in der Lage ist, bsp. Daten unter Umgehung der im Modul implementierten Protokollierung direkt zu ändern, ohne daß diese Änderung in dem Protokoll erfaßt wird, welches für den Kunden sichtbar ist. Diese Sachverhalte werden hier erwähnt, nicht, weil geplant ist, sie mißbräuchlich zu nutzen, sondern weil sie sich aus der Architektur des Gesamtsystems ergeben.

3. Daten und Nutzer aus der Sicht des Kunden

Der Kunde ist verpflichtet, sich über die für ihn gültigen datenschutzrechtlichen Bestimmungen zu informieren und diese für seine Datenbank sowie gegenüber seinen Nutzern einzuhalten. Zu beachten ist, daß verschiedenste Möglichkeiten existieren. Ein Kunde kann seine Datenbank verwenden, ohne weitere Personen zuzulassen. Dann ist er der einzigste, der Objekte erstellt und Daten einträgt, importiert und exportiert. Hier fehlt das Verhältnis Kunde - Nutzer vollständig. Oder er läßt nur interne Nutzer zu, welche ohnehin in einem Rechtsverhältnis zu ihm stehen. Dies gilt bsp. bei einer Firmendatenbank, die nur von Mitarbeitern genutzt wird. Hier dürften die bereits existierenden Rechtsbeziehungen alles weitere regeln. Oder es werden Bekannte, Teilnehmer eines Kongresses oder ähnliche Personen als interne Nutzer eingetragen, Personen wird die anonyme Anmeldung auf einer Ausgabeseite erlaubt, sie werden als Nutzer der inneren Masken zugelassen oder erhalten weitere Rechte. In solchen Fällen erhebt ein Kunde Daten seiner Nutzer bei deren Anmeldung (Name, Mail), für die er verantwortlich ist. Ferner nutzt ein Kunde seine Datenbank vielleicht, um personenbezogene Daten seiner eigenen Geschäftsbeziehungen zu speichern. Hier könnte ein Geschäftspartner gemäß § 34 Abs. 1 BDSG Auskunft über die zu ihm gespeicherten Daten verlangen. Schließlich ist denkbar, daß der Kunde Daten importiert, die von Dritten bereitgestellt wurden und vom Kunden zum Zwecke der Marktforschung o.ä. genutzt werden.

Der Kunde hat eigenständig dafür Sorge zu tragen, daß seine Verantwortlichkeit sichtbar wird. Hierfür gibt es allerdings, je nachdem, welche Art von Ausgabeseiten gewählt wird, unterschiedlichste Lösungen. Erstellt ein Kunde keine Ausgabeseiten, so ist zwar die Login-Maske auf http://datenbank-name.server-daten.de/ sichtbar, ansonsten gibt es jedoch keine Informationspflichten. Bindet ein Kunde seine Ausgabeseiten so nahtlos in sein bereits bestehendes Webangebot ein, daß Leser ohnehin die Kontaktdaten des Hauptangebotes nutzen, so könnten weitere Hinweise überflüssig sein. Verfügt der Kunde über keine eigene Domain und erstellt er Ausgabeseiten, welche ohne iFrame/Frame-Einbindung direkt aufgerufen werden, so fügt er gegebenenfalls Impressum und weitere Daten seiner Subdomain hinzu.

server-daten ist für die einzelnen, für Kunden eingerichteten Subdomains nur im Rahmen der Mitstörerhaftung verantwortlich.

Zu beachten ist, daß server-daten nicht berechtigt ist, Auskunftsersuchen gemäß § 34 Abs. 1 BDSG, die von Dritten an Kunden gestellt werden, ersatzweise für den Kunden zu beantworten. Solche Auskunftsersuchen können nur von den Kunden beantwortet werden, welche diese Daten erhoben haben, server-daten muß solche Anfragen mit Verweis auf die Autonomie des Kunden in bezug auf seine Daten ablehnen.

4. Die Notwendigkeit zur Authentifizierung für jeden Schreibzugriff, die kontinuierlich mitlaufende Protokollierung

Datenbanken sind, bei hinreichend ausdifferenzierter Struktur, akzeptabel gegen Angriffe von außen schützbar. Alle von außen kommenden Anfragen werden zunächst über die Firewall auf den Http-Port 80 eingeschränkt und an den Internetserver weitergegeben. Erst dieser authentifiziert sich beim Datenbankserver über eine schwache Verbindung und fordert Informationen an bzw. übergibt Daten gespeicherten Prozeduren, welche die Daten in Tabellen schreiben.

Schätzungen sprechen jedoch davon, daß Angriffe gegen Datenbanksysteme zu mehr als 60% von internen, ohnehin authentifizierten Nutzern durchgeführt werden. Hierfür gibt es unterschiedliche Möglichkeiten. Es kann sich um zu schwache Konfigurationsmöglichkeiten handeln, so daß alle Nutzer gleichermaßen stärkste Rechte haben. Die interne Protokollierung mag fehlen, so daß bei Änderungen unbekannt ist, welcher der schreibberechtigten Nutzer verantwortlich ist. Schließlich sind Administratoren meist berechtigt, Passwörter zu vergeben bzw. zu ändern, so daß sie die Identität eine anderen Nutzers annehmen, in dessen Namen Änderungen vornehmen und das Protokoll auf den in Wirklichkeit unbeteiligten Nutzer verweist.

Das hiesige System sieht deshalb vor, daß nur Nutzer mit Passwort schreibberechtigt sind. Die Ausnahme stellen Konfigurationen wie die anonyme Pizza-Bestellung dar. Für anonyme Nutzer gibt es ansonsten nur die Möglichkeit, das Formular zur Erstanmeldung auszufüllen. Dessen Daten werden jedoch nicht in den Kundendatenbanken gespeichert. Damit ist - mit Ausnahme expliziter Freigaben (Pizzabestellung) sichergestellt, daß bsp. nicht eine Kundendatenbank über eine Ausgabeseite mit sinnlosen Daten aufgefüllt wird, ihre Maximalgröße erreicht und keine weiteren Eingaben mehr annimmt. Ferner werden sämtliche Schreibzugriffe protokolliert (Tabelle, Zeile, ausführender Nutzer und Datum/Uhrzeit) und jedem Nutzer der internen Masken pro Datensatz angezeigt. Direkt sichtbar ist der letzte Editierzugriff, ein Link öffnet ein weiteres Fenster und zeigt sämtliche Bearbeitungen für diesen Datensatz an. Man könnte sagen: Wer in die Datenbank schreibt, kann sich nicht vor anderen Nutzern verstecken und übernimmt die Verantwortung für die Korrektheit der von ihm eingegebenen bzw. geänderten Daten. Schließlich gibt es keine Möglichkeit, daß ein Administrator für einen anderen Nutzer ein Passwort vergibt. Ein Passwort wird entweder automatisiert generiert und dem Nutzer zugesandt oder der Nutzer meldet sich an und ändert sein Passwort eigenständig.

Diese Sachverhalte sind wesentliche Teile der Gesamtkonzeption. Sie sind für alle Kunden und Nutzer verbindlich und nicht optional. Die mitlaufende Protokollierung stellt die Eingabekontrolle gemäß Punkt 5 der Anlage zu § 9 Satz 1 BDSG zur Verfügung und dehnt diese auf sämtliche Eingaben aus, anstatt sie auf personengebundene Daten zu beschränken. Jeder interne Nutzer kann über <Eigene Daten> - <Protokoll> die von ihm erzeugten Protokollaufzeichnungen tabellen- und datensatzübergreifend abrufen. Somit erzeugt die Protokollierung einerseits kontinuierlich neue personengebundene Daten, andererseits ist diese spezielle Form ausdrücklich vom BDSG gefordert. Die Möglichkeit einer nur optional wählbaren, zu einzelnen Tabellen hinzuschaltbaren Protokollierung wurde explizit nicht implementiert. Eine solche 'unscharfe Konzeption' tendiert dazu, unsinnige Konflikte zu erzeugen (Tabelle mit/ohne Protokollierung), so daß die Gefahr besteht, daß höherrangige Nutzer die Protokollierung ausschalten, um ungestört 'spielen' zu können und andere Nutzer Leidtragende der ungültig gewordenen, 'verspielten' Daten sind.

5. Verwendung von Cookies während einer Sitzung

Falls sich ein Nutzer anmelden möchte, muß er einmalig Nutzername und Passwort senden. Nach erfolgreicher Anmeldung sollten diese Daten gecacht und bis zur Abmeldung wiederverwendet werden.

Nur: Das Http-Protokoll, mit dem Browser und Webserver Daten austauschen, ist statuslos. Zwei Anfragen durch denselben Nutzer sind für den Webserver voneinander isoliert. Der Webserver kann - ohne weitere Maßnahmen - nicht für die zweite Anfrage Nutzername und Passwort des ersten Aufrufs verwenden. Zur Lösung dieses Problem gibt es drei Möglichkeiten:

• Nutzername und Passwort werden bei jeder Anfrage mitgesendet, entweder in der Seitenadresse (seite.html?user=karl&pwd=topsecret) oder als Formulardaten. Im zweiten Fall wäre die Funktionalität einer Seite drastisch eingeschränkt.
• Durch Url-Umschreibungen: Der Webserver generiert nach der Anmeldung einen Zufallsschlüssel und hängt diesen an jeden Link an: seite.html?id=E94F0822-0FDC-4BBD-A725. Der Browser sendet bei jedem Aufruf diesen Zufallsschlüssel in der Adresse mit.
• Verwendung eines Session-Cookies: Der Webserver generiert ein Session-Cookie mit einem Zufallsschlüssel und sendet dieses an den Browser. Anschließend schickt der Browser bei jeder Anfrage an diese Domain das Session-Cookie mit.

Im ersten Fall müßten Nutzername/Passwort bei jedem Aufruf geprüft werden - ein offensichtlich aufwendiges Verfahren. Im zweiten und dritten Fall cacht der Webserver die Daten und verwendet als Verweis den zufälligen Schlüssel.

5.1 Warum werden Cookies verwendet?

Das System verwendet ein Session-Cookie, um auf die Laufzeitdaten des Nutzers zu verweisen und diese auf dem Webserver (nicht im Browser) zu cachen. Ein Session-Cookie sieht wie folgt aus:

• Name: sd-Session
• Content: qxfchp55nwbwdl553uckpy45
• Host: server-daten.de
• Path: /
• expires: at end of session

Der Name ist immer gleich. Der Content enthält eine zufällige, einmalige Zeichenfolge. Das Cookie läuft am Ende einer Session aus. Dies bedeutet, daß beim Beenden des Webbrowsers dieser solche Cookies im Normalfall von sich her löscht.

Bei den Laufzeitdaten des Nutzers kann es sich bsp. um den Namen der aktuell ausgewählten Tabelle im internen Menü 1 oder um eine Kopie des Datensatzes handeln, der dem Nutzer zur Ansicht angezeigt wird. Oder das System merkt sich, was der Nutzer zuletzt gesucht hat, um beim Neusortieren diesen Suchfilter beizubehalten. Die Aufgabe dieser Laufzeitdaten besteht darin, unnötige wiederholte Abfragen bei der Datenbank zu vermeiden und gleichzeitig nicht unnötig viele der für die korrekte Verarbeitung notwendigen Daten in versteckten Feldern mitsenden zu müssen. Nach erfolgreicher Authentifizierung enthalten die Laufzeitdaten zusätzlich einen zufälligen Anmeldeschlüssel, der vom Webserver verwendet wird, um den Nutzer bei Aktionen auf der Datenbank zu identifizieren. Meldet sich ein Nutzer ab, so wird dieser Anmeldeschlüssel intern gelöscht und die Session geschlossen. Aufgrund der verwendeten NET-Architektur öffnet die NET-Laufzeitumgebung allerdings sofort eine neue Session. Eine Session wird automatisch nach einer halbstündigen Zeit der Inaktivität geschlossen.

Diese Form der Session-Cookies wird von der auf dem Webserver verwendeten NET-Umgebung transparent genutzt. Ferner wird ein permanentes Cookie genutzt, um zu prüfen, ob der Browser Cookies akzeptiert, ansonsten wird eine Fehlermeldung ausgegeben. Weitere Cookies werden nicht verwendet. Die Entscheidung zum Einsatz von Cookies anstelle von Url-Umschreibungen (seite.html?id=E94F0822-0FDC-4BBD-A725) wurde aus dem folgenden Grund getroffen: Werden mehrere Ausgabeseiten in eine Kundendomain eingebunden und gibt es die Möglichkeit, nach dem server-daten-Login einige Aktionen auszuführen, anschließend auf die Domain zu wechseln und einige Seiten später wieder Ausgabeseiten aufzurufen, so würde mit Url-Umschreibungen die Anmeldesession des Nutzers beim ersten Verlassen einer Ausgabeseite beendet werden. Würde derselbe Nutzer wenig später erneut eine für anonymen Zugriff gesperrte Ausgabeseite aufrufen, so müßte er sich erneut authentifizieren. Ein Cookie dagegen wird im Browsercache gespeichert und bei jedem Aufruf automatisch mitgesendet. Die Anmeldung bleibt damit im Rahmen solcher Bewegungen zwischen Ausgabeseiten und Seiten auf der Domain des Kunden geöffnet.

Da das System auf Url-Überschreibungen aus diesem Grund verzichtet, sind für alle authentifizierten Zugriffe Cookies erforderlich. Ansonsten gibt es für den Webserver keine Möglichkeit, den Aufruf nach einem erfolgreichen Login demselben, nun authentifizierten Nutzer zuzuordnen. Folglich verweigert der Webserver weiterhin den Zugriff auf geschützte Ressourcen, obwohl Nutzername und Passwort korrekt sind.

5.2 Wie aktiviere ich Cookies im Browser?

Internet Explorer: Extras - Internet-Optionen - Sicherheit - Vertrauenswürdige Sites, dann den Button 'Sites' auswählen:

Bei 'Diese Website zur Zone hinzufügen' die Adresse

http://datenbank-name.server-daten.de

eintragen, den Haken unten ('Für Sites dieser Zone ist eine Serverüberprüfung erforderlich') entfernen, Ok/Schließen.

Oder: Extras - Internet-Optionen - Datenschutz - Sites: Fügen Sie im Feld 'Adresse der Website' die Adresse

datenbank-name.server-daten.de

hinzu und wählen Sie 'Zulassen'. Das verändert keine Einstellungen für andere Domains.

Netscape: Tools - Cookie Manager - Manage stored Cookies - Cookie Sites: Fügen Sie in dieses Feld die Adresse

datenbank-name.server-daten.de

hinzu und wählen Sie Allow / Erlauben. Oder rufen Sie die Domain

http://datenbank-name.server-daten.de

auf und wählen Sie: Tools - Cookie Manager - Allow Cookies from this Site / Cookies für diese Site erlauben.

FireFox: Tools - Optionen - Cookies - Exceptions / Ausnahmen: Fügen Sie die Adresse

datenbank-name.server-daten.de

hinzu und wählen Sie Allow / Erlauben.

Opera: F12 - Enable Cookies / Cookies erlauben. Dies scheint allerdings eine globale Einstellung zu sein, die sich zumindest bei der älteren Opera-Version 8.53 nicht auf einzelne Domains einschränken läßt.

6. Verwendung von JavaScript

Die Regeln für HTML lassen es nur zu, daß mit Formulardaten eine Aktion ausgeführt wird. Diese wird im action-Attribut des <form>-Elements angegeben und durch das Anklicken des Senden-Buttons durch den Nutzer ausgelöst. Soll mit Formulardaten eine von mehreren, sich einander ausschließenden Aktionen ausgeführt werden, so gibt es zwei Möglichkeiten: Entweder müssen Nutzer aus einer zusätzlichen Pulldown-Liste einen Wert auswählen, mit welchem ein Feldwert geeignet belegt wird. Anschließend muß auf den Senden-Button geklickt werden. Oder es werden mehrere Schaltflächen erstellt, bei deren Aufruf dieses interne Feld per JavaScript vorbelegt und anschließend das Formular abgeschickt wird. Die erste Möglichkeit widerspricht der für die meisten Nutzer verständlichen Logik, mehrere Buttons mit erläuternden Beschriftungen anzugeben, aus welchen ein Button auszuwählen ist. Für die internen Masken wurde deshalb die zweite Lösung implementiert. Deren Nutzung erfordert die Aktivierung von JavaScript.

Für Ausgabeseiten sind die Anforderungen geringer, da hier bsp. nicht eine derzeit editierte Ausgabseite gespeichert, validiert oder in der Vorschau angezeigt werden soll. Hier wird der Button zum Suchen oder Speichern per JavaScript als a-Element erzeugt. Bei ausgeschaltetem JavaScript wird der Suche/Speichern-Button im <noscript>-Element als gewöhnlicher Submit-Button ausgegeben, so daß er nicht weiter formatiert werden kann. Die Suchbox zum Durchsuchen von Relationen steht nur bei aktiviertem JavaScript zur Verfügung. Bei deaktiviertem JavaScript könnten hier nur ebenfalls zwei Submit-Buttons eingefügt werden, um den eingegebenen Wert abzusenden. Diese wären nicht mehr voneinander unterscheidbar. Alle anderen Funktionen wie Sortierpfeile, ein Reset- und ein Neu-Link werden als gewöhnliche Links realisiert und senden den Formularinhalt nicht erneut.

server-daten ist Mitglied der Gesellschaft für Datenschutz und Datensicherung e.V. (GDD)