Javascript / Koordinaten vor Kopierern schützen

Sagt mal, gibt es einen eleganten, einfachen und vor allem kostenlosen Weg, ein Javascript bzw. enthaltene Daten vor Fremden zu schützen? Problem ist, die Daten stehen da ja quasi als Reintext drinnen und können schlicht binnen Sekunden kopiert werden. Finde ich weniger schön. Mir geht es nicht um das ganze Javascript, nur um Daten, die es für die Verarbeitung braucht.

In dem Fall speziell Koordinaten für Google Maps bzw. Leaflet. Über die Koordinaten werden Polygone generiert, aber auch einfach Standorte auf der Karte gezeigt, z.B. "Hundestrände an der Nordsee". Da steckt jeweils verdammt viel Arbeit drinnen, vor allem in den Polygonen. Das können schon mal an die 500 Datenpunkte sein, für eine einzige Region in Deutschland und bekanntlich gibt es da sehr viele.

Im Grunde erzeugt das quasi solche Karten:

Das ist nun eine Übersicht aller erfassten Regionen. In der Nutzung sind die jeweils alleine. Die Daten für die Polygone müssen aber halt ins Javascript und stehen mehr oder weniger so im Quelltext (Beispiel für die Schwäbische Alb):

Wie man sich nun denken kann, das ist ein Kinderspiel, sich die Koordinaten zu kopieren.

Wie kann ich die nun schützen? Hat da einer eine Idee? Mir ist klar, irgendwo müssen die Daten wieder "normal" werden, sondern kann Leaflet die nicht anzeigen. In der Datenbank selbst stehen sie als Binärdaten für Geo-Objekte. Abgerufen werden sie als GeoJson und übergeben. Leaflet verarbeitet die dann zu SVG weiter und zeigt sie an. GeoJson muss es aber zu Beginn bleiben und am Ende, also bevor Leaflet das verarbeitet, muss es auch wieder GeoJson sein.

Aber der Weg dazwischen ist eigentlich völlig offen und im Prinzip auch genau die Stelle, wo einfach kopiert werden kann.

Aktuell fange ich schon an, das Array nach einem bestimmten Muster vor der Übermittlung zu verändern, z.B. jede zweite Koordinate mit der vorherigen vertauschen. Das ganze dann kurz vor der Anzeige wieder zurückrechnen. Das geht, einfach so kopieren ist auch nicht mehr, kommt dann nur Mist bei raus, aber es ist sehr rechenintensiv. Da muss das GeoJson, das ja schon fertig ist, erst wieder in ein normales Json umgewandelt werden, dann zerpflückt werden, dass man nur die "Coordinates" hat, das Array dann durchlaufen werden und die Koordinaten getauscht. Später dann, vor der eigentlichen Nutzung das ganze Prozedere per Javascript wieder rückwärts. Und wenn man nicht ganz doof ist, dann sieht man auch die Funktion, die den "Koordinaten-Swap" ausführt.

Nur welche Möglichkeiten gibt es noch? Habe da durchaus zwei Tools gefunden, die verschlüsseln mit verschiedenen Routinen. Aber das ist irgendwie auch Quatsch, denn der Key zur Entschlüsselung muss im Javascript mit hinterlegt sein, in Klartext. Zudem sind das Eigenentwicklungen von Leuten und keine offiziellen Module oder Klassen. Dann hatte ich schon versucht, die Koordinaten zu komprimieren, mit zip, bz2 oder sonst was, aber da scheint es kein Gegenstück in Javascript zu geben, jedenfalls nichts Offizielles, das auch überall funktioniert.

Einer hat wohl dafür eine Lösung, aber das ist dann Overkill. Der erzeugt aus solchen Daten Bilder mit farbigen Punkten. Also z.B. ein Bild mit 100x100 Pixel und jedes Pixel hat 12 verschiedene Farbmöglichkeiten, 10 für die Ziffern 0 bis 9 und zwei für die Zeichen "Punkt und Komma". Ok, damit kann man nix anfangen, aber der muss das auch wieder Pixel für Pixel zurückrechnen und sich dabei auf die Farberkennung des verwendeten Browsers verlassen. Sehr fehleranfällig und noch rechenlastiger also.

Hat einer eine Idee, wie man solche Datenbestände in Javascript schützen kann?

Also im Prinzip bist Du schon auf dem richtigen Weg, nur wohl nicht ganz. Diese Obfuscator habe ich schon versucht und kam damit nicht ans Ziel, also nichtmal ansatzweise. Kann aber auch sein, dass ich das Online-Teil falsch benutzt habe, denn hier in Deinem Artikel hatten die genau das gleiche Problem. Bei denen war ja anfangs das "Hallo SUS" auch leserlich, der Rest verschwurbelt. Bei mir quasi genauso, alles unleserlich, aber ausgerechnet die Variable mit den Koordinaten blieb unberührt. Naja, es wurden die Leerzeichen unkenntlich gemacht. Also genau so, wie in dem Artikel. Dass es da noch eine andere Option gibt, hatte ich nicht gewusst.

Aber ich bin mir nicht sicher, ob mir das weiterhilft. Es geht mir ja nur um die Daten, nicht um das Script selbst. Also die Daten in der "var polygon".

Die sind also in der Datenbank und werden von PHP verarbeitet. Intern für diverse Dinge genutzt wie Umkreisberechnungen etc. Dann sollen die aber auch in die Map mit aufgenommen werden und das ist dann eben Javascript. Also schreibe ich die als "var polygon" in den Quelltext und JS nutzt die dann in seinem Programm weiter. Genau diese Stelle ist das Problem, diese, wo die Daten öffentlich einfach so 1zu1 sichtbar sind.

Mit dem Obfuscator kam ich ja noch nicht so weit, aber ich glaube, da zwei Probleme zu sehen.

1. muss diese "Verschwublung" PHP selbst machen. So wie es scheint, braucht der Obfuscator aber Node.js. Das muss aber PHP on-the-fly machen, also direkt aus den Originaldaten beim Seitenaufruf. Bei jeder Seite andere Daten.

2. Muss dann am Ende, wenn die Daten in die Map sollen, die Variable "var polygon" wieder den Originalwert enthalten, also den original GeoJson-String. Alles andere geht da nicht, da gibt dann die Map-Klasse sonst Fehler aus. Sichtbar ist der dann dort ja nicht, ist ja nur eine Variable. Sichtbar ist er nur beim Übergang von PHP nach JS. Es scheint aber so zu sein, dass die dann nach dem Obfuscator auch nicht die Originaldaten hat, sondern diese berechnet werden müssen. Also nicht im Sinne von decode -> encode.

Witzigerweise, dieses rot13. Der Klassiker aus 1995 So was in der Art, also PHP muss es "unkenntlich" machen und JS wieder "lesbar". Im Grunde ist dieses GeoJSON ja nur ein String und keine Koordinaten im technischen Sinne. Also ein String, der zufällig 98% Ziffern enthält. Dooferweise wandelt aber rot13 keine Ziffern um, nur Buchstaben. Und performant ist das auch nicht, da bei 500 Koordinaten, alle jeweils mit LAT und LON und dann jeweils 9-10 Stellen, das Zeichen für Zeichen zu machen. Das sind ja, ohne die Leerzeichen, Anführungszeichen, Punkte und sonstiges Zeug alleine schon 10.000 Ziffern. Da kommt schon was zusammen und läuft ja in Echtzeit. PHP könnte das recht gut, aber JS scheitert daran. Das verdoppelt oder verdreifacht die Script-Ausführung und so lange das nicht ausgeführt ist, gibt es halt auch nix anderes.

Also wenn Du eine Idee hast, wie das anders geht, gerne

Die Maps gehen ja nicht ohne Javascript. Also ohne JS braucht es dann auch kein Polygon. Das ganze intern per PHP lösen oder so geht ja nicht wirklich. Das muss ja in die Map und entsprechend auch zoom- und verschiebbar sein. Also da ein statisches SVG erzeugen und drüberlegen funktioniert nicht. Naja, technisch schon, ergibt aber keinen Sinn, passt dann ja nicht zur Karte. Daher braucht das JS ja das GeoJSON, damit es dann, je nach Zoom oder Position, das Polygon als SVG berechnen kann.

Dass das aktuell direkt im Quelltext steht, ist nur aus der Not und zum Test heraus. Später soll das mal per Ajax abgerufen werden, so wie die ganzen Pins für die Unterkünfte auch. Das ändert aber nichts an dem Datenstring. Denn auch bei einem externen Request stehen die dann ja als Klartext in der Antwort.

Dachte schon an eine Lösung per Cookie, aber das ist halt so eine Sache. Per PHP Cookie setzen und dann per JS auslesen. Aber das sind bis zu 25 kB an Daten, also zu viel für Cookies.

Ich persönlich suche ja eigentlich auch irgendeine "kreative" Möglichkeit, also so was wie mein bisheriges "jeden zweiten Wert vertauschen". Der Obfuscator wäre eine fertige Lösung, der alles extrem kompliziert macht, geht in dem Fall aber nicht wirklich. Das was das "verschleiert" werden soll, ist ja im Grunde nur eine Variable mit Daten, in dem Fall halt viele Daten. Der Rest vom Script ist ca. 100x größer und völlig egal. Das beruht ja ohnehin auf den öffentlichen Klassen, die man überall downloaden kann.

Urheberrecht? Kann ich mir nicht vorstellen. Im Grunde sind das ja auch nur öffentliche Daten, aber eben zusammengesucht. Hundestrände: Da kann man die nehmen, die schon in den Maps sind. Ich kann aber sagen, 20% fehlen und von den vorhandenen Daten sind 50% falsch. Ich suchte mir das halt alles selbst zusammen, über die Orte und Gemeinden, deren Satzungen etc. Dann hat man Daten wie "Nordstrand Abschnitt 17b". Toll, also erst mal den Nordstrand finden und dann noch, wo der Abschnitt 17b ist. Genau deswegen sind ja bisher die Daten so oft falsch, weil die Leute bisher einfach den Nordstrand genommen haben und einfach einen Pin da rein setzen. Ob das dann aber 17b oder 12a ist, egal. Steht in den Maps ja auch nicht, muss man suchen über Gebäude, Straßen, Verformungen an den Lüsten, Routen von Schiffen etc.

Also ist das alles eigentlich nur eine Liste an Koordinaten für etwas, was auf den einzelnen Gemeinden selbst in Text steht. Nee sau Arbeit, aber wirklich geheim oder neu ist das ja nicht.

Und kopiert wird so was sehr gerne, vor allem von Blogs, die eben so was darstellen wollen. Die klauen ja schon die Texte und schreiben um. Im Text steht ja quasi auch jeder Strand drinnen, aber eben als Textform mit eben "Abschnitt 17b". Ist halt einfacher, wenn man eine Seite hat, auf der 288 Strände der Ostsee in einer Liste stehen, als die selbst suchen zu müssen. In der Map sind ist dann die genauen Positionen. Sehe ich gut mit einem Hundestrand am Bodensee. Ich war eigentlich der Erste, der den erwähnte, denn es ist kein "offizieller", aber geduldet. Der hat auch keinen Namen oder so, sondern heißt einfach nur "zwischen Meersburg und Überlingen". Der Uferbereich da ist aber 25 km lang und nur ca. 2 km sind Strand und davon nur 500 Meter Hundestrand. Das wurde in Textform auch übernommen, aber ohne genaue Position und zeug erfunden wie "feiner Sand". Naja, da gibt es keinen Sand. Da gibt es groben und großen Kiesel. Ich selbst hatte keine Karten, die anderen versuchten es und lagen völlig falsch. Naja, wenn man den Uferbereich nicht kennt, dann ist das halt Mist. Auf den normalen Maps sieht man den auch nicht wirklich, denn der ist nur ca. 12 Meter breit und daneben ist eine Böschung mit Bäumen, Böschung zur Straße hin. Man sieht also im Luftbild eigentlich nur Bäume und dann Wasser. Mittlerweile habe ich da Positionen und nun tauchen die auch bei anderen auf. Das ist aber eine einzelne Koordinate und eben keine Liste von 500.

Und das mit den Polygon dito. Viele regionale Tourismusbüros und offizielle Seiten haben solche Karten, aber eben nur für ihre Region selbst und das dann auch noch als Bild, das eher eine Strichzeichnung ist. So wirklich erkennen, wo da die Region genau aufhört und eine andere anfängt, kann man da nicht. Das geht mit meinen Polygonen aber, denn das ist genau der Sinn von denen. Aber auch hier. Einen groben Umriss für das Allgäu kannste mit 20 Datenpunkten machen, dauert 2 Minuten, fertig. Meine Polygon hat 6 Stunden gebraucht. Warum? Weil das viel genauer ist. Weil das Allgäu nicht nur das klassische Allgäu in Bayern ist, sondern da auch noch Bayerisch Schwaben mit tangiert, Oberschwaben-Allgäu in BW, z.B. Orte wie Wangen / Lindau etc, die zwar auch zum Allgäu gehören, aber touristisch dem Bodensee zugeordnet werden. Genau diese Anhängigkeiten sind in den Polygonen. Sieht man z.B. oben in meinem Bild mit den Regionen. Je dunkler blau die sind, desto mehr Überlagerungen gibt es mit anderen Regionen. Wobei meine Polygone bisher auch nur der Anfang sind, also primäre Grundebene, um Deutschland abzudecken. Alleine das vorhandene Allgäu hätte ja noch einige weiter in sich: West, Ost etc.

Und die Daten sind halt auch nicht frei erfunden, sondern von den jeweiligen Bundesländern, Städten, Ministerien, Landesvermessungsamt, Statistisches Bundesamt der Länder etc. zusammengetragen und dann mühevoll in den Karten erfasst.

Ähm, ja, genau das ist das Dilemma. Irgendwo muss das vor der Verarbeitung wieder Klartext werden, sonst geht keine Verarbeitung.

Daher suche ich ja eine kreative Lösung, die zumindest diesen Block der Variable im Quelltext des HTML unkenntlich macht oder die Nutzung erschwert. Also ganz normal könnte man den Block einfach kopieren und übernehmen, fertig. Das mache ich aktuell auch so, wenn so ein Polygon nachbearbeitet werden muss

Mein Ziel ist aber, das zu erschweren. Also dass da nicht einfach ein Strg-C + Strg-V reicht. Daher das aktuelle jeden zweiten Wert tauschen. Wenn man das nun aktuell einfach so kopiert, kommt dann bei der Nutzung Unfug bei raus, weil die "Rückwärtsdrehung" fehlt. Klar, die ist im JS, das könnte man, wie Du sagst, einfach mit einem Breakpoint umgehen. Dann hätte man die "korrigierten" Daten aus dem JS. Das ist aber schon schwerer als das einfach direkt aus dem HTML zu kopieren. Wenn die Daten original sind, kann man mit denen ja alles machen, also auch in externe Software einspielen, die die Datenbank oder sonst was. Sind gültige Daten. "Gedreht" sind sie nicht gültig.

Mein Vorhaben ist also, das noch etwas komplizierter zu machen, ohne dabei aber merklich an Performance zu verlieren. So was wie ein rot13 wäre eigentlich gut, aber das geht mit Ziffern halt nicht und selbst geschrieben ist das ein Performancekiller in JS. PHP hat damit keine Probleme.

Alleine schon so was wie ein Base64 wäre nicht schlecht. Dann schaut das gedanklich nicht mehr nach Koordinaten aus. Aber leider nein, beim Base64 bleiben die ganzen Ziffern quasi wie sie sind.

Ich habe es bei diversen anderen Seiten ehrlich gesagt noch nicht gefunden, wie die das machen. Da müssen ja auch Koordinaten-Sets kommen, um derartige Polygone oder Pfade anzuzeigen. Habe ich dort aber noch nicht bemerkt. Gut, im JS habe ich nicht geschaut, genau deswegen, weil das aufhält. in Klartext habe ich aber nichts gefunden. Das würde vollkommen ausreichen, dass eben die Daten einem nicht quasi sofort ins Auge springen.

Aktuell war ich im Gedankengang, die Daten so aus der DB zu übermitteln, wie sie drinnen sind, also als BLOB. Stelle mich da aber irgendwie zu doof an, denn ich bekomme aus denen dann in JS keinen String zusammen. Eigentlich gibt es dafür ja die FileReader-Api, aber irgendwie bekomme ich da am Ende auch nur Mist raus. Ich habe dann zwar keinen Blob mehr, aber irgendwas anderes, was völlig unkenntlich ist, was es ist.

Genau das dauert in JS leider ewig, weil das quasi alle in einzelne Zeichen zerpflückt, dann ersetzt und wieder zusammenbaut. Das ist dort leider wirklich fürchterlich. Hatte ich schon versucht. Geht dann auch ohne rot13, kann man ja gleich machen als 0 = m. Das rot13 mit Zahlen, gibt ja fertige Klassen dafür, macht nichts anderes. Daher ist das so langsam.

Wie das die anderen machen, weiß ich noch nicht. Habe das noch nicht herausgefunden. Bei Leaflet weit ich allerdings, dass die das völlig anders machen, das geht bei mir nicht. Die haben kein Polygon als Datenquelle, sondern lauter einzelne Points in einem XML. Da kann man nix rauskopieren, da durch das XML viel zu viel sonstiger Ballast drinnen ist. Auch sind die Points nicht in Reihenfolge. Die haben da noch eine andere Funktion drinnen, die die Punkte dann zusammenbaut. Geht wohl bei denen dann über die jeweilige ID, was nach was kommen muss und in welcher Richtung, also im oder gegen den Uhrzeigersinn. Die haben dann aber kein Polygon, sondern einen Path und genau das geht hier nicht. Ich brauche Polygon, denn einen Path kann man nicht mit Farbe füllen, ist ja nur eine Linie mit vielen Ecken, da gibt es kein "innen" oder "außen".