 So, letzter Track heute, wir haben den Herbert Wärmischer hier, kann auf 25 Jahre Management und Technologie Beratung zurückblicken, macht zusammen mit seinem Sohn als Side Hustle den Website Radar, beleuchtet die Landschaft der österreichischen Website Betreiber in Richtung DSGFO, Security-Protokolle und werden wahrscheinlich entweder überraschende oder vielleicht gar nicht so überraschende Ergebnisse hören. Also bitte Applaus für den Herbert. Danke für die Einleitung. Als letzten Vorderk haben wir ein ganz besonderes Schmankerl vorbereitet. Die Sache ist die, dass wir ja heute den ganzen Tag schon gehört haben, wie man mit Websiten umgeht, wie man sie designen, wie man diverse Aspekte mit berücksichtigt, was wir jetzt haben, ist, wir haben viele Webseiten in Österreich überprüft, das heißt aus einem riesigen Anteil aller österreichischen Webseiten und haben dort Aspekte der DSGFO überprüft, wir haben geschaut Aspekte der Security, wie die Webseiten praktisch genutzt werden, beziehungsweise für Karten und so weiter, aber auch Aspekte des Hostings und sind dort raufgekommen, dass einige sehr überraschende Ergebnisse da sind. In der Präsentation heute wäre ganz kurz praktisch auf unsere Motivation eingehen. Also wer sind wir, warum machen wir das? Ich werde dann kurz über die Anforderungen sprechen, was muss jemand, der eine Website betreibt, die mir eine Website gehört, was muss der denn alles machen, abgesehen von Design natürlich, abgesehen von Search Engine Optimization, alles, was die Standardthemen sind, werden da praktisch das nicht berücksichtigt. Dann das dritte Thema ist praktisch, wie wir das ganz implementiert haben, also einen kleinen Ausflug in die Technologie, dass wir auch wirklich die Daten sehr automatisiert aufnehmen können und dann auch verarbeiten können und Präsentation ausmachen können und last but not least ganz am Schluss dann auch unsere Ergebnisse, also ein Teil unserer Ergebnisse, weil das wäre sonst wirklich gigantisch für Daten. Also zur Einleitung, das ganze hat eigentlich da begonnen, dass ich im Rahmen meiner beruflichen Tätigkeit auch nebenbei ein paar Webseiten von unserer Gruppe betreue. Ich schaue immer wieder zu ihr alles Update, dass ich Backups mache, ich schaue, dass alles sauber ist. Ich bin halt von klein auf schon immer Technologie gewesen und mit dem Internet bin ich halt mit dem Internet mitgewachsen. Und dann haben wir im letzten Jahr diesen Anwaltsbrief bekommen, dieser Anwalt, der bezüglich Google-Fans-Clienting gehabt hat, die ganze aufgeregt war über viele 10.000 oder mehr Websites, die sie alle aufgeregt haben. Und genau diesen Brief haben wir auch bekommen und wir haben dann bei uns im Unternehmen uns das ganze angeschaut, was ist da los? Wir haben eigentlich nicht einmal so richtig gewusst, dass das mit dem Runterladen von Google-Fans gar nicht richtig ist, alles mit dem Cookies haben wir ein bisschen ignoriert, haben uns das also angeschaut und haben gesehen, dass mehrere Webseiten bei uns eigentlich dieses Problem haben und haben alle Firmen praktisch angehalten, diese Problematik zu lösen. Was natürlich dann dazu geführt hat, dass ein Haufen Leidewes Thema geredet haben und eigentlich das unheimlich viel Ressourcen gekostet hat. Nicht nur, dass man darüber geredet hat und jedes gescheitert als der andere, weil er überall in den Nachrichten liest und auch, weil man immer wieder prüfen muss, wie weit sind die jetzt? Haben die Cookies jetzt schon abgefragt, haben sie die Google-Fans jetzt schon weggetan? Jedenfalls haben wir dann das ein bisschen automatisiert. Ich habe praktisch in meiner Freizeit Software entwickelt, mit der man dann abfragen kann, ob ein Website Cookies verwendet, beziehungsweise, ob jetzt keine Cookies kommen und auch abfragt, ob irgendwelche Daten, wie zum Beispiel Google-Fans automatisch runtergeladen werden, ohne dass jemand gefragt wird. Und diese Automatisierung hat uns praktisch zu diese Idee gebracht, dass das Know-how, was ich einerseits habe mit der Technologie, auch mit Datenschutz und Cyber Security und das, was mein Sohn hat, also im Bereich Marketing und Social Media Marketing, haben wir gesagt, wir machen das Thema Projekt. Wir haben immer schon Projekte gemacht in der Family und wenn die Kinder größer werden, werden halt die Projekte größer. Und so ist praktisch die Idee geboren. Und was natürlich von meiner Seite auch sehr wichtig war, ist, dass der Datenschutz etwas ist, was uns wirklich alle was angeht und was wirklich wesentlich ist. Und wenn man bedenkt, dass man eine Webseite hat, einem Kunden etwas anbietet und den Kunden dann, wie so sagen, Daten rauszieht, weiter schickt, aufzeichnet, Statistiken draus macht, ohne den Kunden zu informieren, ist das eigentlich nicht richtig. Und das müssen wir alle verstehen, wenn wir Webseiten machen, dass der Datenschutz, also das nicht nur SEO und nicht nur das Design wesentlich ist, sondern genauso auch, dass wir unseren Kunden, unsere Webshop Benutzer schützen. Und im Rahmen praktisch des Projekts haben wir gesagt, es gibt eigentlich, und da gibt es diesen Spruch, to run efficient. The team is the only three things that you need, is the hipster hacker und der Hustler. Und der hipster sozusagen bei Sohn in Form von Marketing, der Hacker, das wäre dann ich sozusagen und der Hustler, den haben wir jetzt noch nicht. Und das sieht man wahrscheinlich auch, wenn man auf unsere Website geht, wir haben jetzt noch kein Produkt direkt definiert, wir verkaufen auch noch gar nichts, das machen wir eigentlich jetzt mal aus unserem Spaß heraus. Aber wie gesagt, das Projekt ist ganz schön groß geworden, wenn man dann weiter sieht. Die Anforderungen, die man an eine Webseite stellt, also wie gesagt, außer Search Engine Optimization, außer den Designen und den Texten und den Inhalten, ist, man muss schauen, dass man die Sicherheit im Griff hat, nicht nur die eigene Sicherheit, sondern auch die Datensicherheit für die Kunden. Man muss die DSGFO, also gewisse rechtliche Aspekte checken und was wir heute schon öfters gehört haben, das Hosting ist auch sehr wesentlich und vom Hosting, da kann man einiges an Fehlern machen, was wir vielleicht unter Umständen gar nicht wissen und was wir mit unseren Crawlern dann praktisch abprüfen. Die Motivation, die man haben sollte, habe ich jetzt aufgezeichnet, aus zwei Aspekten, der andere ist der Sicherheitsaspekt natürlich, weil Sicherheit ist immer wesentlich und der andere ist praktisch der Datenschutzaspekt. Und vom Sicherheitsaspekt her haben wir, wie, wo forscht sich mich, also die verschiedenen Angriffsvektoren, die es gibt und da gibt es wirklich einen Haufen, aber die populärsten sind im Wesentlichen, dass man, sie, Frau Dieter, aus der Decke schützen kann oder sollte, was mir was zum Beispiel Hosting macht, dass man Fishing-Attacken entgegenwirkt, das sollte man machen, indem man seine Mitarbeiter heute darüber informiert, wie man Basswörter gestaltet und weiter. Und dass man, dass es natürlich auch automatisierte Hecks gibt, wenn man das jetzt vergleichen will, zum Beispiel mit einem Einbruch in einem Haus, da muss der Dieb, muss jetzt erst einmal das Haus anschauen, der Museum hier reinkommt, Alarmanlage, alles das, das macht er für ein Haus einmal, bricht er einmal ein und das war es. Im Internet ist es genau anders. Der hat so viel Websites, wir werden dann sehen, in Österreich gibt es über Millionen Websites, der hat so viel Websites, wo er es einfach ausprobiert und tut, wo die Türe offen ist, dort geht er rein, dort, wo jemand sein Auto nicht abschlüsst, dort geht er rein und hat das Auto Radio in meiner Generation, in der jetzigen, muss wahrscheinlich die Laptop-Tasche erst im Auto rausfischen. Aber es ist einfacher Unterschied, ob man einen Einbruch macht in einem Haus, also etwas Physisches oder ob das im Internet ist, das ist nämlich hochskalierbar. Und es gibt natürlich dann eben diese Folgen, die man sich anschaut und die matchen sich zum Teil auch mit dem Datenschutz, wir haben die Reputationen zum Beispiel, wir haben ein Produktionsausfall, was ist, wenn ein Webshop praktisch steht und wir haben natürlich auch das Thema Datenverlust. Motivation Datenschutz, das habe jetzt eher in Pool- und Push-Faktoren unterteilt, also etwas, wo ich hin will oder ein Problem, von dem ich weg will. Wo will ich hin? Ich will unbedingt, dass meine Kunden geschützt sind, die würden nicht offensichtlich die Daten meiner Kunden ausspionieren, die würden eigentlich das sicher haben, im Eckert rechtliche Aspekte folgen, im Eckert, also das Gesetz nicht brechen, im Eckert natürlich, wenn ich Datenschutz-Dinge implementiere und umstände auch einen Wettbewerbsvorteil, also es sind alle diese Dinge, die guten Dinge, wo ich hin will, aber es gibt auch die schlechten Dinge, von denen ich weg will und da haben wir zum Beispiel den Datenverlust, den Reputationsverlust, da haben wir auch rechtliche Konsequenzen und Last but not least in der DSGVO, an der ganz schihohe monetäre Strafen vorgesehen, die natürlich nicht so oft zum Tragen kommen, aber was genau so passieren kann. So was muss er machen, ein Websitebesitzer muss auf alle Fälle die Datenschutzaspekte befolgen und da ist natürlich der Datenschutz, also der Schutz der persönlichen Daten, das mit Abstand wesentlichste, der Heilige Graal, das sollte man immer machen, das sollte man immer berücksichtigen und den Datenschutz sozusagen von sich heraus automatisiert bei allem, was man macht, anwenden oder überdenken, das darf man auf keinen ver vergessen. Es geht natürlich wie ganz klar, um die Cookies, die Cookies werden gesetzt, werden nicht gesetzt, ich speichere praktisch einen Datensatz beim Browser meines Kunden, das muss zum Teil erlaubt werden, zum Teil ist es jetzt nicht unbedingt notwendig, da brauche ich es nur erwähnen, aber zum Teil muss erlaubt werden, diese Cookie-Dialog ist dann nicht unwesentlich, man darf ihn nicht vergessen, nur weil für ein Cookie-Dialog Zoll heißt das nicht, dass ich mir Cookie-Problem gelöst habe, weil das muss richtig konfiguriert werden. Wir haben natürlich auch Forms, also Kontaktforms, Newsletter und so weiter, wo wir Daten eingeben, diese Daten gibt der Kunde ein, schickt diese Daten an mich, hätte ich kein HTTPS-Protokoll, sondern nur HTTB-Protokoll, bedeutet das, dass im Prinzip einsehbare Daten über das Publik Internet rüberschickt, was auf keinen Fall geht. Es ist natürlich auch noch mehr, wie behandlicht die Daten des Kunden, wenn mir das eine E-Mail-Adress-Telefonnummer geht, ist es die eine Geschichte, wenn das jetzt eine Kontaktform ist von einem Krankenhaus, wo man vielleicht irgendwelche noch persönlicher und wichtigeren Daten hinein gibt, ist das Ganze nur mehr entscheidender, also nur mehr problematischer zu betrachten. Man hat natürlich auch noch rechtliche Verantwortung in Europa, wo muss man im Presse machen, gibt es ein Haufen Webseiten, werden wir dann sehen, die kein Impressum haben oder wo wir ebenfalls ganz gefunden haben. Ähnlich mit der Datenschutzerklärung ist ein Standard, muss sein, muss auf einer eigenen Webseite sein, gibt es eigene Forms, ganz klare Vorschriften, nicht nur Gesetze, sondern ganz klare Vorschriften, wie man sowas macht, wird oft nicht gemacht. Und dann natürlich die Geschäftsbasis in den AGBs, Terms and Conditions, wo man halt seine rechtlichen Prozesse abbildet. Was muss man machen, auf alle Fälle als Webseitenbetreiber, man muss ein Zertifikat installieren, das ist einfach wesentlich, ohne dem geht das nicht, der Zertifikat schützt praktisch nicht nur den Kunden selber, sondern schützt einen auch selber. Das Zertifikat ist im Prinzip für den Websitebetreiber die persönliche Identität oder die persönliche zeigt demjenigen, der auf meiner Webseite kommt, dass es wirklich in meiner Webseite ist. Das ist sehr entscheidend und wenn man sich die Schutzziele anschaut, in einigen Vorträgen, heute habe ich das schon gesehen, die CIA Tried, wo man Confidentiality, Integrity und Availability anschaut, Availability ist zum Beispiel Backups zu machen, aber Integrity zum Beispiel wird geschützt durch ein Zertifikat und nicht nur das, sondern man hat praktisch die Integrität, die Vertraulichkeit und man hat auch die Authentizität, weil ein Zertifikat wird an den Websitebetreiber geissuert, im Mindestfall muss man beweisen, dass einem die Domäne auch wirklich gehört und das ist auf alle Fälle Sicherheit, weil dann war es der Endbenutzer, dass von dieser Domäne wirklich dieser Inhalt geschickt wird, dass der Inhalt auch dadurch, dass er verschlüsselt ist, nicht modifiziert wird. Was muss man nachmachen, was vielleicht oder was ganz sicherlich jetzt einigem Auditorium überrascht ist, man muss HTTP Security Header implementieren. HTTP Security Header sind im Wesentlichen Informationen, die der Webserver, dem Web Browser gibt, dass der Web Browser den Benutzer des Web Browsers und denjenigen, dem Internet herumbraust, erschützt. Ich habe jetzt ein kleines Beispiel gegeben, ich habe jetzt, glaube ich, kein Beamer drauf, aber ich habe ganz kurz gezeigt, wieso HTTP-Request ausschaut. HTTP ist praktisch von der Protokoll-Ebene über dem TCP. TCP ist praktisch eine Verbindung, die wirklich funktioniert, die wirklich steht und nicht durch Zufall funktioniert wie UDP. Wird der TCP-Verbindung auf den Port 80 aufgebaut, das kann man zum Beispiel simulieren auf seiner Konsole, in dem er Dellnet auf den Webserver macht, auf den Port 80. Dann wird praktisch im Protokoll, im HTTP-Protokoll wird ein Get-Befil abgesetzt, im Get-Befil ist einmal der Name Get, da gibt es natürlich nur andere Sachen, wenn man Daten übertragt und wenn man das Dat modifiziert und so weiter. Aber der Get-Befil sagt, ich will jetzt diese Seite haben, das erste Slash heißt, das ist sozusagen die Route-Seite, die Landing-Page, der Web-Page und dann der Port 80 ist der Port, der ich, den ich dann auf dem Server ansteuere, für den ich, der dann für HTTP steht. Also ich schicke diesen Befehl, Get-Slash mit dem Port, dann muss ich noch sagen, wer ich welchen Server ich will, weil es gibt da praktisch Server, auf denen mehrere Webseiten drauf sind, in dem Fall zum Beispiel WebsiteRadar.com, es könnte dort jetzt Wärmescher.com auch auf dem selben Server sein, darum muss man das dem Server mitgeben, weil in dem wir die Dellnetzeichen machen, kriege ich nur die App-Irdress und gehe auf die App-Irdresse. Wenn ich jetzt diesen Befehl abgesetzt habe, antwortet der Server und der Server antwortet dann mit seinen Basis antworten, das ist in dem Fall, schreibt einmal, dass er mit HTTP das Ganze zurückschickt. Und er sagt auch, was für ein Zustand das jetzt hat. Also wenn ich jetzt eine Webseite bekommen würde, würde dort jetzt 200 OK stehen, aber es steht dort 300 ans Move permanent. Warum ist es so? Weil natürlich die Website unter HTTPS erreicht werden kann, das heißt, wenn ich per HTTPS auf diese Website gehe, sagt er, geh bitte auf die HTTPS-Seite und schick mir gar kein Content mit. Der Grund, warum ich das vorgezeigt habe, ist der, dass diese ersten Teile, Date, Content-Type, Transfer, Endcoding usw. das sind alles HTTPS-Header. Das sind Header, die das Server dem Kleinen mitteilt. Und in dem Header kann das Server dem Kleinen genauso mitteilen, als ein Beispiel, mach, wenn du diese Website aufmachst, keine einzige, hol dir keine einzigen zusätzlichen Daten unter HTTPS. Mach das nur mit HTTPS. Da drinnen kann auch stehen, schaut nicht das Mikrofon ein, schaut nicht das GPS ein, weil oft mal wird mal gefragt, wollen sie die Location-Daten hergeben und so weiter. Über die HTTPS-Header kann ich als Website-Betreiber dem Kleinen sagen, das interessiert mich alles nicht. Das heißt, wann jemand meine Website hekt, geht das trotzdem nicht. Er kommt nicht hin, weil allein der Header dem Kleinen sagt, du hättest nicht. Wir haben, glaube ich, eine Frage. Ganz genau, ganz genau. Und genau deswegen haben wir nicht nur DSG4-Aspekte scannen, sondern auch Hosting-Aspekte. Und in dem Fall ist das auch ein Security-Aspekt. Also das ist ganz wesentlich, solche Header kann man nicht unbedingt, also in dem Fall bei den Security-Headern geht es auch so, ich könnte sie über den Web-Server steuern, ich kann es über HTT-Access steuern und ich könnte es auch über PRP-Code im Web, also in meiner WordPress-Seite steuern. Also in dem konkreten Fall kann man da einiges selber machen, es ist aber nicht ganz trivial. Aber es ist auf alle Fälle machbar und es macht jeden Fall Sinn, dass jede Website das hat. Ich muss ein bisschen aufpassen auf die Zeit. Ich habe jetzt da bei Security-Header drinnen, ich überspringe das jetzt, weil ich es schon ein bisschen erwähnt habe. Es gibt eben verschiedenste Header, die eigentlich, das sind nur einige davon und wir haben auch, eben im Laufe unserer Website-Radar haben wir einen Blogartikel gemacht und das ist einer von den Blogartikeln, wo man einfach sagt, das ist so wesentlich, wir schreiben darüber, was man alles machen sollte. Und für diejenigen, die es ernst nehmen sollten, praktisch die OSHB, also die OSP Security-Header, das Security-Header-Project sich anschauen, dort werden alle Security-Headers aufgeführt und dort werden Beispiele gegeben bei Spractis, was in dem Security-Header im Normalfall praktisch drinnen steht. Und das ist aus meiner Sicht etwas, was wirklich gehört war. Und ich sage, der Kunde, mein Kunde ist mal was wert. Es ist nicht so viel technischer Aufwand, das ist einmal gemacht, man muss es überprüfen, das ist wirklich dann fast regelmäßig, aber es ist relativ rasch gemacht. Was muss man auch implementieren? Man braucht Sicherheitsprotokolle, es genügt ja nicht nur Zertifikat zu installieren, sondern über welche Sicherheitsprotokolle verfüge ich, dass mein Server dann mit diesem Zertifikat mit den Kleinen kommunizieren kann. Da gibt es alte Zertifikat, die jetzt rot dargestellt und das gibt alte Protokolle, die wird rot dargestellt und neuere Protokolle, die wird gründ dargestellt. Also wirklich deprecated ist DLS 1.0, 1.1, da ist SSLV 3, die sind deprecated, das sollte man nicht mehr verwenden. Es gibt natürlich Ausnahmen, wenn ich zum Beispiel rein theoretisch die Firma Amazon wäre und ich brauche noch immer uralte Handys, die auf meiner Website dann Sachen kaufen können. Uralte Handys, wenn er abgedeht hat, haben alte Security-Protokolle, drum lasse ich da noch etwas offen, schütze mich auf eine andere Art und Weise, dann kann man das verwenden. Aber die meisten Webseiten genügen, das genügt vollkommen, dass man DLS 1.2 bzw. 1.3 verwendet und die alten Protokolle gar nicht mehr. Was natürlich dann ist, die Protokolle sagen nur aus, wie ich gewisse Dinge mache, sie sagen aber nichts darüber aus, welche Schlüssel oder welche Mechanismen ich dann verwendet zur Verschlüsselung, zur Authentifizierung und so weiter, das nennt sich Cypher-Sweets. Das heißt, ich hab einerseits das Protokoll, DLS 1.2 zum Beispiel oder DLS 1.3 und verwendet dann dort drinnen ein Cypher-Sweets. Und das Cypher-Sweets besteht aus einem Schlüsselausdausch, aus der Indifizierung, aus der Massenverschlüsselung und aus der Message Authentication Algorithmus, also MD5, SHA und so weiter. Und diese Cypher-Sweets haben noch einmal die Problematik, dass jedenfalls bei DLS 1.2 aktuell es schon einige Cypher-Sweets gibt, die man gar nicht mehr verwenden sollte. Ist auch, wie Sie gefragt haben, eine Thematik, die man, die der Hoster praktisch machen muss. Ich muss sagen, ich will, kann schaut, die mechert nicht angreifbar sein, wie genügt es, dass ich praktisch diese Protokolle habe. Ja, was muss man noch machen? Die Sicherheitsvorkehrungen. Ich muss auf alle Fälle einiges nur mit berücksichtigen. Ich muss hergehen, das Hosting praktisch richtig machen, dass ich die DOS attacken und eventuell ein Windows Application Firewall praktisch dort davor habe. Ich brauche gescheite Passwörter. Ich muss regelmäßig patchen. Ich muss Backups machen. Ich muss Prozesse definieren, was ist, wann, was passiert, wer. Ich würde mir dann mal Backup installieren und so weiter. Und den Auftrags, das Verarbeitungsverzeichnis für die Auftragsverarbeiter, also AV-Verträge, müssen auch gemacht werden, gesammelt werden. Das muss jedes Unternehmen machen. Das muss jedes Unternehmen machen. Ein AV-Verteichnis ist ein Muss. Wenn man einen Hack-Hot auf seiner Webseite kommt, das ist die erste Frage, die die Datenschutzbehörde stellt, wo ist eigentlich AV-Verzeichnis? Welche Daten habt ihr gespeichert? In welche, wen muss man eventuell vorwarnen? Und da geht es auch um den Reputationsverlust. Es gibt Datenschutzbrüche, die so gefährlich sind oder die so problematisch sind, dass man wirklich eine Presseaussendung aufmachen muss, um diese Informationen weiterzugeben. Und beim Hosting Aspekt haben wir, haben wir im Großen und Ganzen schon gesagt, Webserver, welches Team verwende, welches Plug-in verwende, wie oft wir das updaten, also einerseits die Installation am Anfang. Ein Team kann vielleicht veräuert werden, ein Plug-in kann dann veräuert werden. Eventuell muss man dann andere Teams verwenden oder andere Plug-ins verwenden. Das muss man ganz am Anfang entscheiden, in welche Richtung man geht und dann, dass man die Wartung auf alle Fälle im Griff hat, weil die Wartung bei einem Security-Vortrag vom Mittagessen, haben wir gehört, jedes Monat kein Update von Plug-ins ist 10 Prozent Verlust von seiner Verteidigungsfähigkeit. Und das würde ich genauso unterschreiben. Wie haben wir das Ganze jetzt dann realisiert, wie sind wir vorgegangen? Als allererstes sage ich den Technologie Stack her, wir haben also den Scanner und den Crawler in Java programmiert. Wir haben natürlich BRB verwendet, weil wir WordPress Plug-in haben, wir haben aber auch BRB verwendet, weil wir für Backend Larawell-Applikation programmiert haben. Wir haben Shellscripts, wir haben Python-Scripts, wir verwenden REST-API, wir verwenden Chasen als Daten-Abspeicherformat. Wir haben am Anfang das Ganze sehr lose programmiert und weil es eigentlich nur um die Firma gegangen ist und nur um 5, 6 Webseiten, aber wie wir dann das Projekt gestaltet haben, ist das Ganze immer größer geworden. Mittlerweile haben wir eine Microservices-Architektur mit lauter kleinen Servern, die alle ihre einzelnen Stateless Aufgaben haben und RabbitMQ, Message-Q im Hintergrund, dass wir hochskalibber geworden sind mittlerweile. Und natürlich, dass wir alte Protokolle, alte Sicherheitsprotokolle lesen können, haben wir bei manchen Servern auch die Sicherheit nach unten gedreht, dass wir das überhaupt noch erkennen. Weil SSLV3 ist schon so alt, dass es eigentlich keinen Sinn mehr gibt. Wir haben begonnen mit dem Scraping, also wir haben eigentlich nur die Webseite runtergeladen, wir haben geschaut, wird der Cookie geschickt, wird Google Fund runtergeladen, wie schauen diese Aspekte aus? Das war eigentlich das erste Programm, das wir programmiert haben, aber wir haben dann gesehen, dass die Webseiten zum Teil echte Implementationsfehler haben und haben einfach mehr Daten gebraucht und sind dann im Weg gegangen, dass wir auch ein Crawler programmiert haben, der praktisch unseren Haufen verschiedener Webseiten gibt, die wir dann eben wiederum Scraping, wo wir dann die Daten wieder runterladen und von dort aus dann wissen, welche Fehler kann man machen, wie kann man das so lösen, dass wir trotzdem valide Daten bekommen. Und was auch noch wichtig ist, vielleicht bei dem Crawling gehen wir her und schauen uns die URL zunächst einmal an, wenn es ein HTTB URL ist, probieren wir trotzdem aus, ob es ein HTTBS auch funktioniert, weil dann braucht man nicht mit HTTB ausprobieren, wir probieren auch aus, ob mit WWW davor oder ohne WWW davor einen Sinn ergibt und dann entscheiden wir uns anhand von der Webseiten, was die eigentliche URL dieser Webseite ist, wo wir dann auch Fehler gefunden haben. Wir analysieren die Daten, die Daten werden dann in so ein JSON-Datenpaket abgespeichert, das wir dann immer durchsuchen können, das wird dann in eine Datenbank abgelegt und von dort aus können wir dann unsere Statistik machen und ja, immer wieder kommt man dann auf Fehler drauf und wir gehen wieder den Prozess von vorne. Die ganzen Webseiten durchcrawlen ist eigentlich etwas, was relativ rasch geht, dadurch, dass wir jetzt so hochskalierbar sind. Ich habe ganz kurz, als Leute jetzt noch drinnen, weil ich einen Hinweis bekommen habe, es ist kein Problem, wenn ich ein bisschen was technischer zeige. Ich habe da jetzt gezeigt, dass man so viel, also in die Horizontale skalieren kann. Wir können so viel scraper, wie wir wollen, laufen lassen parallel. Wir können so viel crawler laufen lassen, wie wir wollen. Wir haben eine Datenbank, wo wir alle Firmen im großen, ganzen hochskalierbar drinnen haben und eine Datenbank, die halt massiv Data hat, wo ganz rechts unten die Ergebnisse stehen, wo wir dann die Statistiken rausziehen können und wo wir auch regelmäßig dann Tests machen können. Also unsere Webseite, man kann die URL eingeben, man kann dort praktisch einen DSGFO-Test fahren, man kann dort ein Hosting-Test fahren und ein Security-Test fahren, aber wir haben auch ein System, das einfach auch mal am Tag zum Beispiel auf eine Webseite geht, alle diese Dinge sich anschaut, in einer Datenstruktur ablegt, am nächsten Tag das selber macht und die beiden Datenstrukturen vergleicht. Somit war es mal relativ rasch. Da habe ich zusätzliches Gucke, da habe ich zusätzliche Daten, die eigentlich dort gar nicht hingehören. Warum haben wir uns jetzt so auf WordPress spezialisiert, weil wir dann eine der letzten Statistik-Leits sehen, dass das mit Abstand größte CMS-System, das in Österreich verwendet wird, WordPress ist und dadurch, dass wir relativ kleines Team haben, also Philipp und ich und wir haben praktisch bekannte oder Freunde von einem Out-of-Housing-Projekt in Bosnien, die uns bei manchen Sachen unterstützen, weil das ist ja doch schon komplexe Struktur, aber wir haben dann gesagt, wir wollen jetzt mal schauen, was ist bei WordPress speziell und haben dann auch sehr spezielle Sachen für WordPress überprüft. Wir können einige der WordPress-Plugins scannen, wir können Versionen zum Teil scannen, wir schauen nach dem WordPress-Readme, wir schauen nach der WordPress-Datenstruktur, also ob man dort Verzeichnisse zum Beispiel auflisten kann und so weiter. Das ist alles sehr, sehr spezifisch dann für WordPress. Was kein Problem ist, dass man für andere Systeme macht, aber wie gesagt, so für WordPress-Seiten die anderen Systeme sind da weit abgeschlagen. Und was auch vielleicht spannend ist, wir haben natürlich sehr viel über unser Projekt auch gesprochen, nicht nur miteinander, sondern auch mit anderen und haben dort eigentlich gesehen, dass da sehr viel Verständnis fehlt. Also Leute, die wirklich professionell Webseiten betreuen und nicht einmal wissen, was hat denn die Security Header sind, das tut mir in der Seele weh und aus dem Grund haben wir eben auch einen Blog begonnen, wo wir halt ein bisschen was über diese Themen schreiben und auch ein Glossar gemacht oder wir sind noch immer dabei, wo wir halt regelmäßig neue Artikel mit hinein tun oder neue Beschreibungen oder Erklärungen dabei haben. So da, die Ergebnisse. Mit all dieser Technologie, mit all unserem Einsatz, mit dem gesamten Crawl, was jetzt wären, wir da sitzen oder stehen hineingesteckt haben, parallel dazu laufen die Crawler und parallel dazu generieren wir neue Daten. Und wenn man sich jetzt vielleicht ganz kurz die Datenbasis anschaut, das sind Daten von der Nikatä einfach kopiert und relativ leicht und eingefügt. Wir haben also 1,5 Millionen ungefähr österreichische AT Domains, was aber nicht bedeutet, dass es österreichische Unternehmen sind. Wir haben versucht, uns möglichst auf österreichische Unternehmen zu konzentrieren. Ich glaube der Rechtsundnis des Österreichs, es sind von diesen 1,5 Millionen, sind ungefähr 1 Millionen davon österreichische Webseiten. Aber wenn man uns darüber schaut, dann sieht man Low Content, High Content, also die AT Webseiten, die ein Inhalt haben, sind ungefähr 1 Million, von denen dann 70 Prozent sind dann die österreichischen AT Domains, aber man kann ruhig nur einiges an Dotcom und anderen Domains dazu tun, die dann zu österreichischen Webseiten gehören. Also ich sage im Schnitt ungefähr 1 Million österreichischer Webseiten werden es schon sein oder ein bisschen mehr vielleicht. Und das ist die Datenbasis von der wir ausgehen. Wir sind nur nicht bei der Million angelangt, aber wir sind ganz weit mittlerweile schon gekommen. Leider haben wir jetzt nur keinen Zugriff auf die Nikatä. Ich habe nur nicht einmal gefragt. Also falls jemand zuschaut von der Nikatä, bitte die Daten hätte gern. Dann folgt man Scroll natürlich viel leichter. Das erste Ergebnis, also ich bin jetzt doch am Anfang nicht in Richtung DSG4, von wo wir gekommen sind, sondern in Richtung Security gegangen, von all diesen Webseiten, die wir gecrawled haben. Wie schaut der Einsatz der Zertifikate aus? Das ist wirklich jetzt ein Standard und man sieht auch an der Statistik, dass es doch jeder berücksichtigt. Und wenn man jetzt so sieht, 70 Prozent aller Webseiten haben korrekte HTTPS Installationen oder korrekte Zertifikatsinstallationen, weil es gibt auch einen Anteil, den haben wir jetzt mit 17 Prozent, wo zwar HTTPS da ist, aber wo das eigentlich nur nicht ganz so richtig funktioniert. Zum Teil sind die Zertifikate alt abgelaufen oder so in der Richtung. Also dann ist der Button oben nicht grün, aber zum Teil gibt es auch Cypher Suites, die praktisch angeboten werden, aber die dann falsch ausverhandelt werden. Wo man dann sieht, da ist doch die Webseite passt nicht ganz. Aber ein großer Teil der Webseiten hat praktisch oder ein relativ großer Teil der Webseiten hat HTTPS und jedenfalls jeder, der was von sich hält, jede Agentur, die was von sich hält, achtet darauf, dass das auch wirklich funktioniert, dass nichts ablauft. Die Nutzung der Security-Protokolle schaut dann schon ein bisschen anders aus. Wir haben zwar knapp bei 70 Prozent TLS 1,3, war das jetzt 70, weit über 70 Prozent TLS 1,2, das ist natürlich das örtere Protokoll, ist nach wie vor noch sehr gut und hat dann viele Cypher Suites, die wirklich gut funktionieren, aber über 20 Prozent TLS 1,0 und sogar vom SSLV 3, was wirklich uralt ist, haben acht Prozent aller Webseiten, die HTTPS anbieten, SSLV 3, also das ist wirklich uralt. Und das ist ein Datensatz, also eigentlich misst man die alle persönlich anrufen und sagen, das ist nicht, ja das geht so nicht. Wir haben dann auch die Security-Header überprüft und auch die statistisch ausgewertet, das hat jetzt nichts mit HTTPS zu tun, also das ist wiederum die gesamte Bandbreite aller Webseiten, die wir gekrawlt haben und das ist aus meiner Sicht ein wirklich trauriges Ergebnis, ich würde das jetzt gar nicht mit Deutschland vergleichen, wir haben die deutschen Datensätze nur nicht, aber das ist wirklich horrendend, weil es ist wirklich nicht schwierig das einzubauen, es ist wirklich kein großes Problem und wenn es mal drinnen ist, dann hat man seinem Kunden, die einige, der auf der Webseite schaut, echte Sicherheit, Datensicherheit gegeben. Also ich sage jetzt mal zum Beispiel District Transport Security, da geht es darum, dass der Webbrowser, wenn man mal auf meiner Seite niesen mit HTTPS, er darf dann keine Ressourcen nachladen über HTTPS, das darf er nicht und das war ganz einfach zu integrieren, also 18 Prozent nur und gibt es einige, die nur für weniger oder nur für schlechter sind, die auch echt wesentlich waren. Wie schaut es mit die Cookies aus, das kennt natürlich auch jeder, wir haben bei den Cookies meiner Meinung nach auch ein spannendes Ergebnis, hätte man nie erwartet, wir haben knapp 50 Prozent, also 46 Prozent aller Webseiten, die wir gekrawlt haben, haben sind Kuckiles, also entweder haben sie Gorkan Cookie oder sie haben einen Cookie-Banner, der Gorkan Cookie davor zulässt und wenn man den Cookie-Banner auf OK klickt und dann Cookies da ist, dann ist alles im grünen Bereich, aber 46 Prozent, das ist jetzt immer nicht so schlecht, aber wir haben zwar 40 Prozent, die nicht, die ist geconfirmt sind, 42 Prozent, die Cookies schicken, die sind nicht schicken dürften, ich habe es jetzt immer so geschrieben, warum tut man das? Es gibt wahrscheinlich, das haben wir natürlich nicht mit dem Radar sozusagen eröhren können, es ist jedenfalls auf alle Fälle Leute, die das ignorieren, es gibt Leute, die Cookie-Banner einfach falsch konfigurieren, die glauben, sie sind jetzt schon geschützt, sind sie aber nicht und dann gibt es diejenigen, die das geschäftlich benötigen und ich muss auch wirklich ehrlich zugeben, so wie die Situation jetzt aktuell ist, ich brauche gewisse Mechanismen, um einen Webshop zu betreiben, ich kann die nicht obdrehen, wenn der Kunde wirklich sagt, die Wüde ist Cookies nicht, dann kostet mir die Werbung so viel mehr, da habe ich so weniger Intelligents über meine Kunden oder potenziellen Kunden, das ist extrem schwierig, also man merkt natürlich, dass viele Webshops praktisch dann unabsichtlich oder absichtlich darauf verzichten und dann haben wir noch und das sind da 12%, die praktisch sehr wohl Cookies schicken, aber das sind dann First-Party-Session-Cookies und First-Party-Session-Cookies darf man schicken, das ist kein Problem, man muss es dann nur in der Datenschutz-Erklärung angeben, welche Cookies man warum praktisch schickt, weil es ist im Prinzip okay, wenn es rein für den Betrieb des Systems, wenn es nur darum geht. Als nächstes, welche Cookies und das sind natürlich nur die Cookies, die durchgedrungen sind, also wir klicken keine Cookie-Banners, das heißt alles was entweder automatisiert kommt oder was kommt, bevor der Cookie-Banner da ist, kann man in vier Teile teilen, das ist Google Analytics, Google Analytics, Google Analytics und Nr. Google Analytics und der Rest ist dann Wix und Facebook. Facebook haben wir nur sehr wenige, haben wir überrascht, ich dachte, dass die auch riesige Menge haben, aber die gestalten offensichtlich die Technologie ein bisschen anders und Wix ist halt dieses System, wo man Webseiten selber designen kann, hosten kann, alles auf einmal und die haben es sehr, sehr leicht machen auf DSGV zu verzichten, so wie das die Statistik jedenfalls jetzt aktuell aussagt. Wir haben dann auch geschaut, die nennen es Digital Assets, weil es geht natürlich nicht nur um Google Fonts, es geht da um Content Delivery Networks, es geht um große Grafiken, die dann nicht von meinem Webserver geladen werden, sondern von einem Fremdserver, nichtsdestotrotz, sobald das Server im EU-Ausland steht, habe ich größeres Problem im Fall, wenn es im EU-Ausland steht, dann habe ich kleineres Problem, wenn es außerhalb der EU ist, praktisch habe ich größeres Problem und das muss ich im Prinzip in den Griff bekommen und Umständen, also außerhalb der EU darf ich das eigentlich gar nicht machen, und das sind wiederum Daten, die wo ich keinen Cookiebeiner geklickt habe. Ich gehe einfach auf die Webseiten, schauen wir das an und wenn man bei seinem Chrome Browser auf Inspekt schaut, würde man diese Daten sehen, die wir hier da automatisiert auslesen. Und das sind mit Abstand am meisten Google Analytics und Google Fonts ungefragt. Muss man es überlegen, von wo das kommt oder was man dagegen tun kann oder was man besser machen kann. Wir haben dann praktisch noch ein paar kleinere Statistiken, ein bisschen separator, jetzt nicht pro Seite ein Statistik, sondern ein bisschen nur ein paar spannende Themen rausgesucht. Das eine ist, was mich total überrascht hat, das ist das Impressum, wir haben bei 19 Prozent aller Webseiten kein Impressum gefunden. Wir haben dieses Impressumsuch Algorithmus, den haben wir immer wieder verbessert und praktisch, wenn man jetzt die Daten schaut, wo man kein Impressum findet, dann findet man es wirklich nicht oder es ist so inkorrekt, dass man sagen muss, das ist kein Impressum. Es gibt also Firmen, die dann vielleicht die Adresse oder was auf die Hauptwebseite schreiben, aber es gibt eine Formvorschrift für Impressen und da müsste ein bisschen mehr sein, was dann dort dargestellt wird. Ähnlich ist es bei Datenschutz, es ist nur ein bisschen dramatischer, es ist um 10 Prozent mehr. Datenschutz-Erklären muss man im Wesentlichen auf jeder Webseite oben haben, weil man immer was mit Datenschutz zu tun hat und eigentlich an dem Kunden zeigen sollte, dass man das ernst nimmt. Sobald man eine IP-Adresse sammelt, sobald man ein Plug-in verwendet, das ein bisschen Datemambulam macht, ist es eigentlich schon notwendig, darüber zu schreiben, was man mit den Daten des Kunden macht. Und im Speziellen dann, wenn ich zum Beispiel den Host, den Server, nicht bei mir in der Firma habe, sondern ich habe den Host dann bei einem Host da, wahrscheinlich 100 Prozent oder 99 Prozent aller Webseites ist, muss ich mit dem natürlich einen AV-Vertrag haben, anders als weil er die Daten meiner Kunden auf seinem Server in seinem Hosting-Center ist, aber ich muss natürlich auch in der Datenschutz-Erklärung reinschreiben, dass ich den Host da verwende, ich muss die Adresse und so weiter, also ich muss einige Daten angeben. Das heißt Datenschutz-Erklärung ist notwendig und muss gemacht werden. Was auch wichtig ist für jede Webseite, robots.txt, man sagt praktisch den Crawlern, wie man Crawlern soll, man sagt Google, ich mag dich gerne, darum, bitte schau da mein Webseit genau an und zwar folgende Art und Weise, 30 Prozent oder 26,2 Prozent aller Webseiten haben keine robots.txt.dei. Wir haben dann noch ein glanzschmankerl, 4,8 Prozent aller robots.txt Aufrufe, das sind Weiterleitungen auf irgendwelche Seiten, die einfach nicht korrekt sind, beziehungsweise überhaupt die Four of Wars, diese Seite ist nicht verfügbar. Also, schwarer Fehler muss im Prinzip unbedingt behoben werden. Und ähnlich auch für die Suchmaschine, auch wichtig ist die Sidemap, da haben wir auch über 20 Prozent aller Webseiten, die KSidemap praktisch haben oder K korrektes Sidemap haben, das ist entscheidend, weil dann wird auch abgeworfen. Was haben wir nur für typische Fehler, das Canonical Tag, das ist im Prinzip ein Tag, der verhindert, dass Seiten doppelt, auch von Google doppelt gesehen werden, dann war es Google, okay, der Inhalte auf der einen Seite ist auf der anderen Seite, das Canonical Tag sollte korrekt sein, wann das nicht einmal auf der Basis Seite korrekt ist, sprich zum Beispiel Weiterleitung WWW oder ohne WWW oder HTTPS oder HTTB, dann haben wir da in Österreich 40 Prozent, die das oder auch der 20 Prozent die falsch gesetzt sind und nur 60 Prozent aller Seiten haben über der Canonical Tag auf der Webseiten koppt. Also, beim CMS System ist es natürlich normalerweise automatisiert drauf. Was auch entscheidend ist, aus Sicherheitsgründen Directory Browsing sollte abgedreht sein, wenn man auf die richtige Seite einsteigt, auf einmal habe ich den gesamten Inhalt des Verzeichnisses, kann dann schauen, welche Plugins hast du dort installiert oder welche Daten sind dort, wo ich weiß, dass sie eventuell angreifbar sind. Wunderbar, für ein Hacker haben wir 9,4 Prozent aller Webseiten, haben praktisch das Directory Browsing nicht abgeschalten. Ganz ein einfaches Thema, Hosting Provider, bitte machen wir das, schreibt was in die HTTPS Datei und die Sache ist geritzt. Apropos HTTPS Datei, 4 oder 5,4 Prozent der Webseiten haben die HTTPS Datei im falschen Zugriff. Also, wo man es dann lesen kann zum Beispiel oder wo man falsche Weiterleitungen bekommt, ist ganz spannend. Wir haben auch die WordPress Readme Datei abgefragt, die meiner Meinung auch eigentlich nicht oben sein sollte und da haben wir von 18,4 Prozent aller Webseiten die Readme Datei noch gefunden. Da kann man natürlich über HTTPS machen, kann man anders auch machen. Und jeder kennt es, eine weitere WordPress-Seite, wenn man eine deutschsprachige Installation macht, gibt es ein Haufen Webseiten, 0,6 Prozent von unserem Suchvolumen, von allerdings gerechnet auf alle Webseiten, nicht nur auf die WordPress-Webseiten, aber Großteil sind ohne WordPress-Webseiten, haben diesen Text am top. Also, das heißt, da hat sich jemand wirklich nicht um alles geschehrt. Ich habe jetzt oft darüber gesprochen, dass man natürlich österreichische Webseiten scannen und nicht nur WordPress-Webseiten, aber warum wir uns auf WordPress konzentrieren, sagt diese Statistik. Und ich weiß, dass es ein Haufen Statistiken dazu gibt, wie viel WordPress es auf der Welt gibt. Wahrscheinlich gibt es ja so, wie viel WordPress es in Österreich gibt. Ich kann nur sagen, das, was wir gescannt haben, und das ist relativ konstant, je mehr Webseiten, dass wir haben, rund um die 60 Prozent sind WordPress-Webseiten. Die Geschmauer, es geht unheimlich tief nach unten, es gibt dann Haufen CMS-Systeme, es gibt aber auch viele Webseiten, die wir gar nicht erkannt haben. Also, wo wir einfach sagen, keine Ahnung, das kann ein WordPress-Seiten sein, man kann das praktisch ein bisschen verstecken und wir haben nicht aggressiv gesucht. Wir haben einfach nur aufgrund von ein paar Kriterien gesucht. Aber von denen, wo wir mit unseren Algorithmen festgestellt haben, welche Webseiten das sind, sind wir bei 70 Prozent. Und der nächste Legende ist Type 3 mit 7,4 Prozent. Also, man sieht praktisch, dass es ein riesiger, riesiger Unterschied ist. Ja. Zuletzt, Herr Bauschmankerl, wir haben ein Haufen Probleme mit den Umlauten gehabt und die Umlaut-URLs, die wir in unserer Datenbank haben, sind eigentlich relativ gering. Also, da haben wir 0,15 Prozent. Wenn man sieht, die Nicht-Statistiken anschaut, sind das über 2 Prozent. Aber was wir ja gemacht haben, ist, wir haben die URL genommen und haben geschaut, gibt es mitharte.deb, ohne harte.deb, wir haben die Canonokulität angeschaut und sind dann auf die Website gekommen, die der Websitebetreiber wirklich haben will. Und sehr viele Betreiber, die eine Umlaut-URL haben, haben wir auch eine Nicht-Umlaut-URL. Und das ist dann eigentlich die Hauptseite. Das heißt, die Umlaut-URL ist sicherlich oft rausgekickt worden. Ich nehme an, dass das der Grund ist, warum das doch ganz schön anders ist. Ja. Bei den Fans vielleicht noch, wir haben von den Seiten, wo wir Fans praktisch geschickt bekommen haben, ist eigentlich Google-Fans dramatisch dominierend und 27 Prozent von diesen Seiten oder 26 Prozent von diesen Seiten verwenden Google-Fans. Und der nächste Fan-Aussamm, das ist fast nicht relevant. Das ist spannend, weil ich habe mir das eigentlich anders vorgeschrieben. Ich dachte, dass da viel mehr Auswahl ist. Ja, also wir haben nur so viele andere Sachen dort reingescannt. Wir haben Kanten, die Lieferin-Netzwerks uns angeschaut. Man kann anhand von der IP-Adresse herausfinden oder weiß man sehr, sehr einfach. Wir müssen auch machen, wo der Server steht. Ist der in Europa, ist der in Österreich oder ist der in Amerika oder irgendwo anders im Ausland? Wir können feststellen, wer ist die Registrar? Wir können feststellen, wer betreibt die Website? Also da kann man eigentlich ganz schön viel nur mit in die Datenbank hineinnehmen, wo jetzt für uns in dem Kontext jetzt nicht ganz so wichtig ist. Das sind aber trotzdem sehr, sehr spannende Daten. Ja. Und ja, dann komme ich so mit praktisch zu meiner letzten Slide. Ich habe es am Anfang erwähnt. Wir haben das Projekt eigentlich gemeinsam begonnen mit ein bisschen Unterstützung von Freunden in der Software-Entwicklung. Wir haben auf unserer Website, wenn man schaut, das ist nichts Kommerzielles dort. Aber wir haben natürlich immer in den Diskussionen da, mit den Diskussionen mit anderen, die aus dem Fach sind, immer die Überlegung, was könnte man machen. Und da sind uns die drei Sachen eingefallen. Wir könnten zunächst einmal Leads generieren, weil wir können relativ leicht in unserer Datenbank herausfinden, wer hat eine Website auf Wix und ist relativ aktiv dort, könnte man sagen, dort kriege ich dann aus dem Press und die E-Mail, ich kann den anschreiben oder ich kann den über LinkedIn finden oder ich kann den, kann errühren, wer das ist und kann den praktisch so finden. Zweite Sache, was wir ohnehin schon machen, eben auch für unsere Websites, ist das Monitoring, dass sie praktisch diese Daten von Security-Aspekten, von Hosting-Aspekten, von DSGFO-Aspekten regelmäßig Obscanner, Vergleiche mit dem letzten Scan und dann war es welche Änderungen, dass ich gehabt habe. Wir haben da sogar ein kleines Plug-in geschrieben, das war uns auf dem WordPress Server drauf, installiert ist, kriege natürlich alle Plug-ins, kriege alle Versionen von Plug-ins heraus und so weiter. Also da kann ich nur zusätzlich sagen, du hast nur immer BRB 5.4, da kann ich sagen, du hast durch der alte Version installiert und so weiter. Und das letzte Thema, das was wir an Wissen praktisch angesammelt haben und an Freunden gewonnen haben, die sie da zum Teil sehr gut auskennen, DSGFO, natürlich gibt es Anwälte, die sie damit gut auskennen, haben wir gedacht, dass es eventuell auch die Möglichkeit gäbe, eine, die automatisierte, das automatisierte Scannen praktisch mit echter Main-Bau zu unterstützen und nummerens Detail zu gehen. Das heißt konkreter, die DSGFO-Aspekte zum Beispiel vergleichen mit dem, was in der Datenschutz-Erklärung drinnen steht. Konkret, nur mal intensivere Security-Scans zu machen bis hin zu einem Bandtest und konkret auch Aspekte wie zum Beispiel Search Engine Optimization zu überprüfen. Also da stehen wir jetzt gerade mit unserem Projekt, wir haben unheimlich viele Daten gesammelt, wir sind recht stolz auf das, was wir bis jetzt geschafft haben, dann natürlich auf dem Projekt parallel dazu immer weiter und sind glücklich über jeden Input und somit danke ich immer für die Aufmerksamkeit.