 Ja, dann würde ich sagen, liegen wir los, oder? Ja. Sehr schön. Moin moin. Willkommen zu dieser späten Stunde. Danke, dass ihr da seid. Der ganze Rest wird wahrscheinlich drüben sitzen bei der Eurovision-Kontest irgendwas. Das ist harte Konkurrenz für diesen Vortrag. Das war uns bewusst, umso fröhlicher sind wird, dass ihr jetzt hier seid und euch darüber informieren lassen wollt, was wir euch mitgebracht haben, bezüglich der automatischen Analyse von Webseiten. Ich bin Tobi. Ich bin aus Hamburg. Das ist Pascal. Pascal ist auch aus Hamburg. Und wir haben zusammen mit der Uni Dortmund, wollte ich grad sagen, Uni Darmstadt und Uni Bamberg PrivacyScope.org gemacht oder betreiben das und machen das immer noch. Und in diesem Slot würden wir gerne euch das Projekt vorstellen, zeigen, was es kann, was die Ziele sind, was wir in der Zukunft noch erreichen wollen. Und im Idealfall habt ihr auch Ideen, was man noch machen kann mit PrivacyScore und wie man die Plattform noch benutzen oder erweitern kann und welche hoffentlich interessanten Daten man noch aus dieser Plattform heraus extrahieren kann. Jetzt überlege ich grad, ob wir hier noch eine E-Mail-Adresse haben, aber haben wir nicht. Ich glaube, die haben wir am Ende vielleicht. Haben wir auch diese Moderne mit diesem Twitter, glaube ich, ist am Ende auch noch da drauf und so. Genau, ich bin Tobi. Pascal steht neben mir. PrivacyScore.org ist eine Plattform zur automatischen Analyse von Privacy and Security Properties von Webseiten. Das klingt erstmal ein bisschen abstrakt, nicht? Was heißt das? Die Fragestellung, die uns bewegt hat, war, ist es eigentlich normal, dass wenn ich mich auf Hamburg, unsere Heimatstadt, über Sozialhilfe informiere, wenn ich also die Webseite aufrufe, auf Hamburg.de und mir Sachen anschaue, die vielleicht ein bisschen von denen möglichst wenig andere Leute vielleicht erfahren sollen, dass ich mich darüber gerade informiere, ist es eigentlich normal, dass andere Firmen davon etwas mitbekommen, dass ich mich gerade eben über dieses vielleicht touchy Subject informiere, dass ich da Informationen brauche. Und in dem Hamburg-Fall sehen wir, dass sich der Privacy-Badger ordentlich beschwert, darüber, dass Informationen gerade an dritte Parteien rausgeleitet werden. Und nun stellt sich die Frage, ist es normal, ist das die schöne neue Welt, in der wir leben, wo man sich nicht ungestört im Web über Dinge informieren kann, die man gerne wissen möchte. Und wir behaupten, es gibt kein Tool, welches einem diese Analyse erlaubt, schon gar nicht von verschiedenen gleichartigen Webseiten und dann auch nicht über die Zeit. Und mit privacyscorp.org wollen wir also diese Frage beantworten, ist es normal, dass ich von dritten Parteien getrackt werde, dass ich dritten Parteien erzählen muss, dass ich mich über soziale Hilfe informiere, bei deutschen Städten, meinen Wegen. Und im Verlauf jetzt dieses Talks wollen wir präsentieren, wie das mit Privacy-Score geht und wie wir das gebaut haben, wie die Implementierung aussieht, die das realisiert, diesen Test. Nun sagen gleich mal, ja, aber es gibt doch Webscanner zuhauf. Und die, ja, muss man auch sagen, ja, gibt es. Es gibt Webscanner zuhauf. Der bekannteste ist wahrscheinlich dieser SSL-Test von Qualis. Das ist auch sehr schön, sehr schönes Interface. Man sieht gleich mit A bis F, wie gut oder wie schlecht die eigene Präsenz im Internet ist. Und man kriegt auch ein bisschen Detailinformationen darüber, wie das Ergebnis zustande gekommen ist. Aber es ist eben auch nur das in Anführungszeichen. Also es geht hier bei dem Qualistest im speziellen um TLS. Ist fair enough, ist nicht gut, nicht schlecht. Ist halt ein bisschen ein anderer Fokus, als das, was wir uns wünschen. Von diesen TLS-Scanners gibt es noch ein paar andere ähnliche Dienste, die auch speziell TLS-Scanners. Es gibt auch bisschen Dienste, die noch ein bisschen mehr machen oder ein bisschen einen anderen Fokus haben. Einer davon ist das Web-Call von den schwedischen Datenschützern. Die haben ziemlich, oder die haben ein Dienst gebaut, der PrivacyScorp.org sehr nahe kommt. Oder andersherum PrivacyScorp.org wurde, ist inspiriert von diesem schwedischen Tool. Und was dieses Tool macht, ist, es besucht die Webseiten und zeigt einem an, wie viele Cookies es gibt und wie viele Requests zu dritten Parteien. Und wie viele Trackers es gibt. Und das ist gut. Was man mit dieser Webseite jetzt nicht machen kann, ist, man kann nicht feststellen, oder nicht einfach feststellen, ob Hamburg.de jetzt speziell schlecht ist. Ob Hamburg.de eine speziell schlechte Webseite von einer deutschen Stadt ist. Es gibt jetzt hier kein vergleichendes Element von gleichartigen Webseiten. Man kann nicht alle deutsche Städte jetzt hier in einem Ranking gegenüberstellen und sagen, Hamburg.de ist jetzt besonders schlecht oder Hamburg.de ist besonders normal im Vergleich zu anderen Städten. Es gibt vergleichende Scanner. Es gibt Dienste, die einem gleichartige Webseiten vergleichen. Hier haben wir Secure the News mitgebracht. Das ist eine ganz hübsche gemachte Webseite und die haben speziell den News Sektor eben, die Medienfirmen, die Nachrichtenfirmen im Blick und Listen also auf, wie gut oder wie schlecht das jeweilige Publishing House ist. Das ist gut, das ist nett, das ist schön. Es ist jetzt für unseren Hamburg.de-Fall natürlich ein bisschen schwierig, weil Hamburg.de ist erstmal keine Nachrichtenseite und es gibt für diesen Secure the News-Dienst erstmal auch keinen offensichtlichen Weg, wo wir unsere deutschen Städte rein oder wie wir unsere deutschen Städte da reinkriegen. Es gibt noch andere Dienste, die dann ein Bewerfungsschimmer benutzen, was einmal vorgesehen ist und was dann nicht verändert werden kann. Also unsere Idee ist auch, es dem Benutzer überlassen, sich eine Meinung zu bilden und auch, naja, es dem Benutzer überlassen, wie stark er ein gewisses Kriterium in seinem Ranking berücksichtigt haben will oder nicht. Ein besonders prägnantes Beispiel ist der Server-Standort oder die Server-Standorte. Wir haben ein Check bei uns drin in PrivacyScope.org, der den physischen Standort des Servers versucht zu ermitteln. Das ist eine Idee, dass man vielleicht lieber bei einer Bankkunde wird, die ihre Server nur in Deutschland stehen hat oder nur bei einem Mail-Provider-Kunde wird, der seine Mail-Server nur in Europa stehen hat. Das könnte für jemanden relevant sein. Das ist aber vielleicht für jemanden nicht relevant. Für jemanden, der einen amerikanischen Dienst scanert oder für Menschen, der dieses Bedürfnis nicht hat, ist dieser Test gar nicht so sehr relevant. Derjenige, der PrivacyScope.org benutzt diesen Test eben im Zweifel weniger Gewichten oder vielleicht auch ganz untergewichten kann. Solche existierenden Scanners, hier habe ich das HTDP Observatory mitgebracht. Da geht es halt nicht. Die haben ein Ranking und das benutzt man oder man benutzt es nicht. Ein ganz witziger Dienst ist Trackography. Die fokussieren sich auch auf Nachrichtenagenturen und da kann man sogar dann sehen, wohin die Requests gehen, woher die Tracker kommen. Von solchen Diensten gibt es noch eine ganze Handvoll. Wir glauben aber, dass das Featureset von PrivacyScope.org hinreichend unique ist, als dass die existierenden Scanners das nicht abbilden. Und zwar insbesondere dieses vergleichende Element von gleichartigen Webseiten. Inklusive der Attribute, man mit PrivacyScope.org ist die Idee, dass man Webseiten mit Attributen anotiert und dass man dann über diese Attribute Aussagen machen kann. Wie beispielsweise Städte im Norden sind besonders anfällig für Tracking oder für das Hosen von Tracking Code als Städte im Süden oder so. Vielleicht mit der Hypothese, dass die Städte im Süden generell ein bisschen reicher sind als die Städte im Norden und deswegen die Städte im Norden ihre Webseiten monetarisieren müssen. Weil sie ist eine Arbeitshypothese, kann man untersuchen wollen diese Frage. Und wir behaupten, dass es bis ja keinen Tool gibt, um diese Arbeitshypothese zu überprüfen. Mit PrivacyScope.org wollen wir so einen Tool bereitstellen. Diese Tools sind auch noch ganz nett, weil sie mitunter technisch sehr detailliert eine sehr detaillierte Ansage machen, wie gewisse Ergebnisse zustande kommen. Die Zielgruppe dieser Tools ist aber auch offensichtlich, also das steht ja auch irgendwo, dass die Serverbetreiber ganz im Fokus dieser Tools sind. Das ist auch okay, ist nichts Falsches dran. Wir wollen einen Tool bereitstellen, was nicht nur von den Betreibern von Webseiten benutzt werden soll, sondern auch insbesondere von dem mündigen Bürger, von dem souveränen Bürger, der sich informieren will, darüber, was ihn erwartet, wenn er eine bestimmte Webseite besucht, um dann Entscheidungen zu treffen, wie beispielsweise bei welcher Bank werde ich kunde, welche Krankenversicherung nehme ich, oder zu welcher Krankenversicherung gehe ich lieber? Vielleicht gehe ich lieber zu einer Krankenversicherung, die ihre Mehls in Deutschland abwickelt, oder vielleicht gehe ich lieber zu einer Bank, die ein vernünftiges TLS-Deployment hat. Genau, Zielgruppe 1, der mündige Web-Server. Zielgruppe 2, auch Server-Operator oder Betreiber von Auftritten, die wissen wollen, wie ihr Auftritt im Vergleich zu anderen Auftritten abschneidet. Also wenn ich wieder bei den Banken bleibe, ist meine Bank besonders gut in TLS oder besonders schlecht, kann ich das vielleicht sogar als Marktvorteil benutzen, kann ich das sogar aktiv in meiner Werbung kommunizieren, dass unser TLS besonders gut ist, oder muss ich vielleicht an unserem TLS-Deployment ein bisschen was feilen, weil, naja, alle anderen Banken sind besser. Und ich glaube auch, dass es bisher noch kein richtig guten Dienst für Server oder für Web-Auftrittsbetreiber gibt, der einem Bescheid sagt, wenn, naja, der eigene Auftritt ein bisschen, vielleicht sagen, wenn es eine Sicherheitsschwankung gibt am eigenen Web-Auftritt, beliebt ist, dass man mal das Git Repository öffentlich rumliegen lässt oder dass man das Backup, das Sequel-Dump öffentlich abrufbar auf dem Web-Auftritt liegen lässt, weil man arbeitet gerade auf dem Server, dann macht man sich seinen Backup und lädt es dann runter selbst und dann vergisst man, das in das Sequel-Dump zu löschen. Und ich glaube, solche Sachen, die passieren, also, nein, ich glaube nicht nur, dass sie passieren, sie passieren, und die Leute, glaube ich, die lassen nicht freiwillig ihr Sequel-Dump öffentlich abrufbar liegen. Ich glaube, die Leute lassen nicht freiwillig ihr Private Key öffentlich abrufbar liegen. Ich glaube, das passiert unfällig und, naja, mit PrivacyScope.org gibt es einen Dienst, der einem zumindest Anzeigwenden, was schief geht. Die Operator- oder Webseitenauftritte, die Betreiber von Webseitenauftritten sind auch eine intendierte Zielgruppe von PrivacyScope.org. Was wir noch wollen, ist, dass die Aufsichtsbehörden PrivacyScope.org benutzen. Eben vor dem Hintergrund, dass man gleichartige Webseiten vergleichen kann, dass es mit PrivacyScope.org ein vergleichenes Element gibt, um feststellen zu können, ob jetzt ein Vertreter einer Branche besonders gut oder besonders schlecht performt. Auch mit Hinblick auf die jetzt bald in Kraft treten und von der alle jetzt wie wild aufgesteuigt rumlaufen, die GDPR, die Datenschutz-Grundverordnung, die auch, naja, mit der du härter bestraft wirst, wenn du PrivacyScope.org nicht vernünftig umgesetzt hast. Dann stellt sich die Frage sofort, was ist PrivacyScope.org? Ich weiß noch niemand so genau, aber es könnte sein, dass man die Frage so beantwortet, dass, naja, wenn alle Vertreter deiner Branche einen bestimmten Schutzmechanismus umgesetzt haben und du aber nicht, dann wirst du vielleicht härter bestraft, als wenn ein Vertreter deiner Branche diesen Mechanismus umgesetzt hätte und bei dem dann Datenschutzverstöße festgestellt werden. Genau, und das alles öffentlich und transparent. Das Hauptziel ist eigentlich Transparenz zu schaffen, naja, beim Besuch von Webseiten, dass man weiß und dass man sieht und das öffentlich wird, was passiert, wenn man diese oder jene Webseite besucht. Und diese Transparenz stellen wir her, indem wir unsere Scans und unsere Daten öffentlich zur Verfügung stellen, und das jeder, naja, die Seite benutzen kann und die Daten daraus benutzen kann. Die Rankings, die wir erstellen, sollen beeinflussbar sein von den Benutzer vor dem Hintergrund, dass die Leute sich selbst ihre eigene Meinung bilden können, sollen mit den Daten, die wir liefern und nicht unbedingt auf die Meinung der Plattform angewiesen sind. Wir sind in Teilen noch nicht so weit, wie wir gerne wollen oder wollten, insbesondere mit dem Ranking. Da fehlt noch ein bisschen Code, dass man eigene Ranking-Schemes hinterlegen kann und vielleicht auch verschiedene Ranking-Schemes auswählen kann. Also ich möchte vielleicht einen Ranking-Schemen für, was ich auch nicht speziell für Webseitenbetreiber, für E-Mail-Provider haben und vielleicht eins für Bank-Provider oder so, weil ich für diese Art von Business unterschiedliche, weil mir da unterschiedliche Sachen wichtiger sind. Wie gesagt, mein E-Mail-Provider, von dem hätte ich vielleicht gern, dass die E-Mail-Server in Deutschland stehen. Vielleicht gerne, dass das TLS vernünftig ist. Und bisher haben wir diese Möglichkeit zumindest nicht so komfortabel wie es geht. Und da sind wir auch noch auf der Suche nach Leuten, die da fähig und willens sind, Patches zu schreiben und uns, na ja, vielleicht sagen, mit uns die Plattform ein bisschen besser machen. Oh, jetzt habe ich irgendwas gedrückt. Das tut mir leid. Wir sind große open-sourcenfreien Softwarefreunde. Die Plattform gibt es auf github.com und kann sich jeder unterladen und selber betreiben, wenn er will. Das ist auch die Idee. Wir unterstützen die Leute mit Freude dabei, die Plattform selbst zu betreiben und hoffen dann auf Feedback und Bugreports und natürlich auch Patches. Was wir nicht machen wollen, ist ein aggressiven Pentester. Wir wollen kein Siegel vergeben für diese Seite, hat keine Bugs oder so. Wir wollen nicht, dass unser Tool missbräuchlich benutzt wird, um irgendwelche Seiten anzugreifen. Und eines der Features, die dieses vergleichende Element unterstützen, was uns relativ wichtig ist, sind diese Attribute. Man kann Webseiten anotieren mit bestimmten Werten, z.B. Hamburg.de ist im Norden. Dann kann man einen nächsten Eintrag in der Liste haben. Bayern.de ist im Süden. Wir werden gleich Beispiele sehen, wie das aussieht in der Praxis. Z.B. hier sind die News. Es ist eine Liste von News Webseiten, die gibt es auch auf privacyscop.org, kann man sich so anschauen. Ein Attribut von den News Webseiten ist das Land. Dann kann man die Arbeitshypothese haben, dass amerikanische News Webseits generell mehr tracken als deutsche News Webseits. Dann kann man die Arbeitshypothese haben. Jetzt hat man ein Tool, um das zu überprüfen. Man kann die Hypothese haben, dass die amerikanischen News Webseits ein besseres TLS-Deployment haben, als die deutschen Webseits. Das könnte man überprüfen wollen, die Hypothese. Mit privacyscop.org hat man eine Möglichkeit, das zu überprüfen. Was haben wir noch für Listen? Wir haben z.B. eine Liste von aktiven Nullinux-Distributionen und mit sämtlichen Metadaten. Das passt jetzt hier alles gar nicht auf diese Seite drauf. Dann kann man die Möglichkeit, diese Liste und die Ergebnisse entsprechend anhand der Metadaten, die dazugehören, zu korrelieren. Jetzt kann ein findiger Data Scientist sich diese Daten ziehen und kann darauf hoffentlich interessante Querys stellen und hoffentlich interessante Erkenntnisse aus diesen Daten gewinnen. Was haben wir noch? Wir haben auch eine Liste von KOSR-Vertreffs und R-Version KOSR-Vertreffs. Hier kann man dann auch entsprechend sehen, wie die jeweiligen Städte performen und wie die sich im Vergleich zueinander verhalten. Das ist ganz cute, als wir das gemacht haben und wir das ein bisschen kommuniziert haben. Dann ist den Leuten auf einmal aufgefallen, dass sie irgendwie Double-Click einbinden. Eigentlich hat kein Hackerspace ernsthaft Interesse, das zu tun. Und es war den Leuten gar nicht klar. Nur dadurch, dass wir die Liste hatten und dadurch das sichtbar war, dass transparent wurde, dass dieser oder jener Tracker eingebunden wurde, haben die Leute angefangen zu sehen, dass das mitunter ein Problem ist. Die Quelle von diesem Einfall, den ich im Kopf habe, war ein eingebundenes Video über Vimeo. Also hat der entsprechende Hackerspace ein Video eingebunden gehabt, ein Video von Vimeo, von Vimeo und Vimeo hat dann weiterhin noch mehr Kot nachgeladen und irgendwann hat dann über Bande, gab es dann recht fest zu einem Tracker. Und das war vorher, vorher war das nicht klar. Und mit privacyscorp.org wurde auf einmal sichtbar, wurde transparent, dass diese Webseite getrackt wird, wenn man diese Webseite besucht. Von ja, den Institutionen, die eigentlich am wenigsten Interesse haben, von da war das, glaube ich, schon Erfolg und es ist auch ganz spannend, sich die Entwicklung über die Zeit mal anzuschauen. Da haben wir am Ende auch noch ein bisschen was mitgebracht, wie die Entwicklung über die Zeit passiert. Was testen wir eigentlich? Jetzt habe ich die ganze Zeit erzählt, was wir machen, aber wir haben noch gar nicht richtig gesagt, was wir eigentlich machen. Vielleicht erzählt es uns ein bisschen Pascal, was wir eigentlich tatsächlich jetzt checken, wie die Webseiten krank werden. Genau, es gibt im Wesentlichen vier verschiedene Gruppen, in die diese checks aufgeteilt sind. Das ist einmal zunächst dieses No Tracking, dass eben eine Webseite den Benutzer nicht aktiv überwacht, indem man z.B. aktiv Google Analytics benutzt oder irgendwelche Cookies setzt. Genau, in den Third Parties sind da eben oft, dass man eben externe Dienstleister nutzt, die dann diese Überwachung durchführen. Da gibt es dann oft halt auch Third Parties, die einfach so Dienst anbieten. Aber auch verschiedene, die eben bekannte Tracker sind, von dem man weiß. Das heißt, wenn man auf Google Analytics, das ist jetzt definitiv ein Tracker. Und wenn die Seite sowas einbindet, dann weiß man daraus entsprechend, dass diese Seite aktiv den Benutzer eben überwachen möchte. Und das hatte Tobias von auch schon angedeutet, eben die Server-Standorte. Das heißt, gerade für deutsche Webseitenbesucher ist es jetzt vielleicht spannend zu wissen, dass die alle Server in Deutschland stehen und dann im Zweifel da höhere Datenschutzstandards gelten, als wenn die Server jetzt z.B. in den USA wären und vorher noch über die transatlantischen Datenleitungen und da womöglich auch noch von anderen Leuten mitgelesen werden können, wenn womöglich keine Verschlüsselung da ist. Und das ist auch schon der nächste Punkt. Das ist einmal die Verschlüsselung zur Webseite. Bietet die Webseite überhaupt HTTPS an. Und falls ja, leitet sie auch dahin um, weil für die meisten Nutzer, die einfach nur ein Browser installieren und dann im Web surfen, die werden praktisch keine HTTPS-Version nutzen, wenn nicht eben verbindlich dahin umgeleitet wird, weil die einfach nicht auf die Idee kommen, zu gucken, ob es vielleicht eine HTTPS-Version gibt. Und das gar nicht mitkriegen. Das heißt, der Durchschnittsnutzer hätte dann eben halt gar nichts davon, wenn HTTPS nur angeboten wird, aber nicht dahin umgeleitet wird. Dann prüfen wir auch noch, ob das Zertifikat gültig ist und auch, was das für eine Keysize nutzt. Denn wenn die jetzt besonders klein ist, oder das Zertifikat vielleicht auch schon relativ alt ist, oder mit alten Standards generiert wurde, dann hilft es im Zweifel ja auch nicht so viel zu verschlüssen. Und das geht erstaunlich oft tief. Man würde meinen, insbesondere bei Krankenversicherungen, wird wenigstens ein gültiges Zertifikat da sein. Also mit Verlaub, wie schwer ich kann sein. Das ist für 2018. Wir haben die Liste von Krankenversicherung auf privacyscop.org, kann man jetzt nebenbei auch gucken. Und der Prozett war alle Anteil an Webseiten, die kein vernünftiges TLS haben. Also so unvernünftig, dass nicht mal das Zertifikat validiert, der ist erstaunlich hoch. Also erschreckend hoch, muss man sagen. Ja, genau. Und gerade bei Krankenkassen, die er dann entsprechend schon eher im Zweifel sensiblere Daten benutzen, ist es dann schon besonders erschreckend, dass nicht einmal in solchen Umfeldern dann im Zweifel vernünftig genug damit umgegangen wird. Genau. Und dann gibt es eben auch noch verschiedene bekannte Schwachstellen, wie zum Beispiel Heartbleed, die eben seit Längerem schon bekannt sind, wo man dann relativ einfach prüfen kann, ist der Server dagegen jetzt anfällig. Und wenn das ist, dann ist es im Zweifel auch wieder hinfällig, dass sie überhaupt verschlüsselt wird. Genau. Das Ganze machen wir einmal zur Webseite und dann auch noch zum Mail-Server. Denn wenn man vielleicht den Betreiber der Webseite in die E-Mail schreibt, dann würde die E-Mail ja auch an den Server gehen. Und das Gleiche geht auch für die Server-Standorte, die ich von erwähnt hatte. Auch da prüfen wir die E-Mail-Server mit. Denn was bringt das, wenn die Webseite Server in Deutschland hat, aber man jetzt irgendwie eine E-Mail zum Beispiel dahin schickt und die E-Mail dann jetzt auf amerikanischen E-Mail-Server landet. Insofern ist auch das ein Punkt, den wir prüfen. Genau. Bei Webseiten gibt es dann zusätzlich noch verschiedene andere Encryption, spezifische Sachen, wie zum Beispiel diesen Strict and Transport Security-Header, der den Browser eben anweist, dass er diese Webseite nur per HTTPS aufrufen darf und unter keinen Umständen eben zulassen darf, dass der Nutzer ohne HTTPS mit der Webseite spricht. Und da gibt es auch Preloading-Listen. Das heißt, dass also sozusagen in den Browser schon einkompiliert ist, die Liste der Domains, die das eben preloadet haben. Und dann kann eben von vornherein diese Webseite dann wirklich nur noch mit HTTPS aufrufen werden. Wenn dieses Preloading entsprechend nicht gemacht wird, dann würde das eben erst dann gelten, sobald die Webseite mindestens einmal aufrufen wird. Genau, dann gibt es auch noch Public Keypinning. Das ist mittlerweile wahrscheinlich so ein bisschen obsolet, wo einige Browser das jetzt schon nicht mehr machen wollen. Von daher ist das bei uns nur noch ein Informational Check, der also nicht in die Bewertung sozusagen eingeht. Aber wir prüfen eben trotzdem mit, ob die Webseite so ein Public Keypinning Header setzt. Und dann genau so hat er eben schon angesprochen, die automatische Weiterleitung zu HTTPS, die natürlich nur beim Web-Server relevant hat, die dann auf der Webseite leiten. Genau, und dann gibt es noch verschiedene andere Angriffe, das sind zum Beispiel diese Informationslecks, die auch Tobias schon viel angesprochen hatte, das zum Beispiel irgendwie ein Datenbankdampf auf der Webseite rumliegt oder das ein privater Key, der vielleicht sogar rumfliegt. Aber was auch sehr oft vorkommt, ist, dass zum Beispiel eine PHP Info.PAP-Datei auf der Webseite liegt, die dann den gesamten Debuglock des Servers im Zweifel beinhaltet und Angreifer dann auch mit wertvollen Informationen versorgen kann. Und dann auch noch verschiedene weitere Security Header, zum Beispiel eine Content Security Policy, die dann eben halt auch versucht im Browser direkt verschiedene Arten von Angriffen abzuwehren, damit der Nutzer eben dann bzw. die Webseite da eben nicht anfällig ist. Ja, dann gibt es entsprechend aus diesen Checks wird dann sozusagen ein Ranking aufgebaut. Das heißt, innerhalb dieser Gruppen, das sieht man dann hier so ein bisschen, okay Laser Point, der bringt nicht so viel, das dann entsprechend pro Gruppe werden alle Checks einzeln bewertet. Und in dem Moment, wo sämtliche Checks in einer Gruppe eben gut verlaufen sind, dann gibt es so einen grünen Haken, das sieht man ganz oben. In dem Moment, wo mindestens ein Checks nicht gut verlaufen ist, dann gibt es nur noch ein orangisches Ausrufezeichen. Und in dem Moment, wo entweder alle Checks negativ verlaufen sind oder mindestens ein Checks kritisch ist, dann gibt es eben so ein X, wobei kritisch sind die Checks dann, wenn zum Beispiel, was wir beschlossen hatten, dass bei fehlenden Weiterleitungen zu HTTPS betrachten wir das als kritisch, weil, wie ich erwähnt hatte, ein durchschnittlicher Nutzer von dieser Verschlüsselung gar nicht profitieren würde, weil er sie eben nie einsetzen würde. Und das ist jetzt die Übersicht von PrivacyScope.org. Wenn man eine Liste aufmacht, dann sieht man das. Zum ersten natürlich die Beschreibung der Liste selbst, was man gerade anschaut. Und dann diese kurze Übersicht darüber, wie die Gesamtliste jetzt performt hat. Und es ist ja auch vielleicht schon interessant zu wissen, dass wenn es jetzt hier 300 Krankenversicherung gäbe und davon sind irgendwie 100 wenigstens kritisch. Das war auch schon vielleicht eine Information, die eine gewisse Relevanz hat für den ein oder anderen. Und dann gibt es eben die Ergebnisse wie Pascal gesagt hat. Aber das ist das zentrale Element von PrivacyScope.org, das Konzept von Listen, von anotierten Listen. Naja, das, wenn man irgendeiner von diesen Listen anschaut, dann sieht man eben das. Und die Idee ist auch mit einem relativ simpel, erstmal mit einer simplen Übersicht zu beginnen und dann mehr Details aufzumachen, wenn der Benutzer sich offensichtlich für mehr Details interessiert. Aber erst mal mit einer Art Ampelsystem anzuzeigen, wie ist überhaupt the State of the Union so ganz groß. Und dann kann man tiefer einsteigen. Das heißt, es ist viel Kontrolle über unser Tool geben wollen. Das heißt, er soll möglichst dieses Ranking auch ein bisschen beeinflussen können. Bisher funktioniert es nur darüber, dass er die Reihenfolge von diesen Gruppen verändern kann. Also, dass er sozusagen von diesen 4 Check-Gruppen, die ich eben vorgestellt hatte, die Priorisierung festlegen kann. Wobei das denn immer so ist, dass das von links nach rechts diese Gruppen alle durchgeht. Das heißt, zunächst werden alle, die Ranking-Gruppe vergleichen und so immer weiter. Das heißt, auf diese Weise kann der Nutzer dann die Priorisierung von diesen Gruppen verändern und dadurch dann das Ranking beeinflussen. Das heißt, wenn jetzt jemand zum Beispiel im Wesentlichen auf Tracking Wert legt, dann würde er eben nur Track ganz nach links schieben, wie das hier der Fall ist. Oder auch wenn zum Beispiel jemand auf E-Mail besonders Wert legt, dann könnte er Mail nach links verschieben und darüber eben das Ranking beeinflussen. Prinzipiell ist auch zumindest langfristig geplant, diese Check-Gruppen und generell, dass für Ranking relativ frei wählen kann, aber bisher sind das eher abstrakte Ideen. Also da gibt das bisher leider auch Mangelskapazitäten noch keine konkrete Umsetzung. Sandpatches. Genau, empfiehlt euch frei da mitzuwirken und auf GitHub reinzuschauen und vielleicht auch Ideen, wie man das konkret umsetzen könnte, weil das eben halt, ja, uns auch noch gar nicht richtig klar ist, wie man eigentlich so ein Ranking gut für den Nutzer konfigurierbar machen kann. Also wenn da Ideen sind, dann freuen wir uns, wenn ihr da auf uns zukommt. Ja, und dann gibt es neben den Listen auch noch die Detailergebnisse, die dann jeweils für eine Einzelne Seite sind, die wirklich diese Checks hier, Check für Check durchgehen, dann einmal anzeigen, was dabei rausgekommen ist. Hier rechts gibt es auch noch ein Hinweis, wie zuverlässig das ist. Also manche Checks, zum Beispiel auch der Server-Standort ist im Zweifel dann eben unzuverlässig, wenn zum Beispiel Content Delivery Networks genutzt werden und dass der Server-Standort anders aussieht, als er tatsächlich ist. Genau, und dann kann man das Ganze auch noch aufklappen. Dann gibt es da noch einen zusätzlichen Erklärenden-Text, der dann einmal erklärt, was ist das überhaupt und unter welchen Umständen besteht die Webseite das und was für Konsequenzen hat das jetzt eigentlich, wenn eine Webseite hier jetzt schlecht ausgefallen ist. Gerade auch unter dem Hintergrund des Privacy-Scores sich eben an, sozusagen, durchschnittliche Nutzer richtet, die all diese technischen Details im Zweifel gar nicht kennen und ein bisschen mehr Erklärungstext benötigen. So, dann kommen nun diese typischen Informationslecks. Also hier oben sind ein paar verschiedene Beispiele, zum Beispiel eine PHP Info-Datei oder eine Test.php oder auch SQL-Dams oder Zertifikate, die auch teilweise unter Domainname-Punkie liegen. Das heißt, da setzen wir dann auch tatsächlich dynamisch den Domainnamen der Webseite ein und versuchen das dann abzurufen. So, hier ist zum Beispiel ein PHP 5.3.10, das wir in der Wildnis gefunden haben, das dann eben schon relativ alt ist. Hier zum Beispiel der Körne, sieht man hier jetzt, der wurde 2016 gebaut und seitdem gab es dann auch schon diverse PHP-Sicherheits-Updates, die alle möglichen gefährlichen CWIs entsprechend entschlossen haben, die eben halt, wenn man das jetzt so sieht, diese Webseite relativ leicht angreifen lassen würden, weil dieses PHP eben relativ alt ist und es für die meisten von diesen CWIs wahrscheinlich wahrscheinlich auch schon fertige Exploits gibt, die man nur noch ausführen braucht und dann Zugriff auf die Webseite gewinnt. Ja, und das haben wir nicht zusammengesponnen. Also, Mangels Vorbereitung haben wir das gerade noch in halben Stunden zuvor geklickt und haben uns dieses Screenshots rausgeholt. Also, das ist jetzt nicht zusammengesponnen, das ist jetzt, im Prinzip ist es gerade live. Also, Information von jetzt. Also, das PHP war damals schon alt und das Linux, ich kann mich gar nicht erinnern, dass wir das letzte Mal Linux 2.6er-Körnel aufrufen haben. Also, das ist so alt sind wahrscheinlich hier die wenigsten im Raum. Also, da kann man natürlich argumentieren, na ja, mein Gott, PHP Info, also Standard gibt es überall, das ist so watcht. Und es ist auch richtig, es ist ja nicht unmittelbar, es ist ja nicht unmittelbar ein Problem für die Security oder die Privacy an der Webseite. Also, weil da steht ja auch erstmal nichts Security oder Privacy-mäßiges drin. Das es dem Angreifer-Informationen gibt, wie das der Körnel 6 Jahre alt ist und das PHP Version, mein Gott, das sind wenigstens 3 Patches, aber wir haben ja hier, also, wenigstens 4 Patch-Level sind übersprungen. Und wir haben hier gleich die CVIs und wir können das potenziell mit dieser Information können wir dann die Webseite besser aufmachen. Genau, noch ein weiterer Serverleck ist dann hier so ein Apache-Server-Status, wo man auch mehrere findet, die dann eben alle Zugriffe auf die Webseite loggen und noch weitere Debug-Informationen, die eigentlich nicht öffentlich sein sollten, die dann im Zweifel sogar hier ist, das jetzt glaube ich nur, genau hier sieht man jetzt eine IP zum Beispiel vom Client, das heißt, dann kann man im Zweifel sogar die IP-Adressen der Nutzer herausfinden und noch im Zweifel auch hier wieder Informationen, die einem helfen, den Server gezielt anzugreifen. So, das hier ist dann ein Git-Repository gewesen, das auf einer Webseite auch öffentlich rumflog, wo dann zum Beispiel auch hier irgendwie Passwortzugänge, also für den Passwortschutz auf einer Webseite mit-committed waren. Also wir sind große Open-Source-Freunde, wie gesagt, und wir freuen uns immer ganz besonders, wenn wir Git-Repositories auf den Webseiten finden und dann abziehen können. Das sind immer ganz schön, insbesondere, wenn da eine Credentials mit rumhängen in dem Git-Repository, aber vermutlich ist das nicht die Intention des Webseitenbetreibers, gleich die Passworder der Staging-Environments und der Datenbank- Host und so mit zu exposen. Vermutlich. Das hat eine Konsequenz davon, dass einfach zum Beispiel per FTP das gesamte Lokale hochgeladen wurde und dann eben vergessen wurde, das Git-Repository auszunehmen und dann einfach durch sozusagen durch Unwissenheit der Administratoren, das dann eben miterlandet, wo es nicht landen soll. Genau, hier ist noch ein weiteres Apache-Server-Status, das auch noch in der Wildnis sozusagen rumfliegt. Und das hier ist ein SQL-Dampf, wobei hier das besonders witzige 500 Megabyte groß ist und das dann entsprechend auch ein ziemliches Datenreichtum ist, dass da offensichtlich ein SQL-Dampf der gesamten Bank rumliegt, der anscheinend ziemlich viele Daten beinhaltet und hier ist auch ein Auszug aus einem, hier wird eben eine Tabelle angelegt und dann sieht man hier auch, dass tatsächlich anscheinend Nutzername und zumindest ein gehächtes Passwort damit drin steht und das sind definitiv Daten, die da sind, dass sie die Passwörter gehächtes speichern. Vielleicht ist das ja mit Absicht, liegt das darum, dass der Auditor sehen kann, dass die Passwörter nicht im Klartext rumliegen. Ja, und hier auch nochmal eine Nummer besser, ein RSA Private Key, der im Idealfall vielleicht sogar noch zu dem Zertifikat der Webseite gehört, auch solche Sachen fliegen zumindest vereinstelt tatsächlich auf Webseiten rum. Und also von jetzt, also es ist 2018, man könnte meinen, die Nutzername, das ist nicht trivial. Und also die Dinge passieren jetzt gerade, das haben wir eben wie gesagt von einer halben Stunde Mangelvorbereitung, gerade eben erst auseinander, aus dem Web aus unseren Ergebnissen rausgezogen. Genau, dann stellt man sich natürlich auch die Frage, wie wir jetzt scanieren jetzt Webseiten, die Nutzern geben eben ULs bei uns ein und dann scannen wir daraufhin dann die Webseite, das machen wir jetzt ohne vorher den Betreiber zu fragen, ist es eigentlich okay und ja, im Prinzip können wir jetzt SSL testen und dann mehrere Handshakes fahren, das heißt dann gibt es natürlich auch rechtliche Fragestellungen, ist das überhaupt rechtlich zulässig, dass man ohne vorher um Zustimmung zu fragen Webseiten scannt? dürfen wir eine Webseite aufmachen, ist ja Deutschland hier, kann man nicht einfach so eine Webseite besuchen, muss man sich fragen, dürfen wir eine Webseite besuchen, ja oder nein, ist nicht trivial die Frage, weil also das PrivacyScore.org ist im Wesentlichen automatisierter Firefox, also wir machen jetzt kein exploit toolkits oder so, wir machen instrumentalisieren Firefox und das machen auch nicht wir selbst, wir benutzen OpenWPM und das braucht dann die Webseite, also ruft die UL in Firefox auf und dann sobald das bei der Seite geladen ist, geht da wieder zu kann man sich die Frage stellen, darf man das in Deutschland, darf man das? Genau, die Frage wollen wir eigentlich auch so gar nicht in Detail beantworten, also die Kursfassung ist ja, das darf man, es gab da auch ein etwas längeres Webpaper zusammen mit Juristen, das kann man sich hier unter dem Link dann später nochmal abrufen. Da gibt es dann auch eine etwas längere ausführlichere juristische Behandlung des Themas, aber das Fazit ist, grundsätzlich ist der Betrieb erlaubt so ein bisschen, was Tobias ja auch gerade angedeutet hatte, effektiv rufen wir ja eigentlich auch nur Webseiten auf, wie das jeder normale Nutzer tut. Genau, aber neben den rechtlichen Fragestellungen gibt es natürlich auch ethische, das ist eben ein dual use tool, das heißt auch als Angreifahrer und Git drum, wo im Zweifel auch wieder Passwortdateien drin sind. Das heißt hier muss man sich jetzt schon auf ethischer Ebene fragen, ist das überhaupt in Ordnung, dass wir das jetzt den Leuten so einfach machen? Dementsprechend nicht so einfach machen wir das den Leuten gar nicht, das heißt wir haben zum Beispiel nicht irgendwie eine Liste, wo dann alle URL drin stehen, wo zum Beispiel ein Git repository lag, sondern eben, dass diese Information nur gezielt auf den Detailseiten zu den Seiten anzeigen. In allen Seiten, die solche Leaks haben, müsste man sich dann schon auch selber zusammenstellen. Und gleichzeitig machen wir auch ein Rate Limiting, weil an Anfall könnte ja jetzt jemand ankommen und 10 mal pro Sekunde die gleiche Webseite mit Privacy Score scanen und damit dann im Zweifel vielleicht über DOS sogar den Server Alarm legen. Dementsprechend erlauben wir, dass ich glaube aktuell nur alle halbe Stunde pro Webseite, dass eben eine Webseite nur alle halbe Stunde gescannt werden kann und dadurch dann eben nicht DOS Angriffe sondern außerdem haben wir auch noch ein Blacklisting auf Wunsch, das heißt wenn jetzt irgendwie Webseitenbetreiber ankommen und sagen, ich finde das jetzt aber gar nicht gut, dass meine Webseite hier nicht auf dem ersten Platz in der Liste ist, dann kann man eben auf Wunsch in dieses Blacklisting aufgenommen werden. Das bedeutet dann, dass wir in Zukunft keine weiteren Scans dieser Webseite mehr machen und die Webseite auch aus dem Ranking gesondert hervorheben in einer Liste der Blacklisteten Seiten. Das heißt, wir haben einmal die Webseite und dann außerdem noch mal ein Abschnitt geBlacklistete Seiten. Stellt sich aus, dass Krankenkassen nicht so gerne möchten, dass sie unten im Ranking sind. Jetzt sind sie ganz unten auf der Blacklist. Genau. Ja, dann kommt jetzt der Aspekt der technischen Umsetzung. Das alles war jetzt so generell das Konzept und die Motivation dahinter. Jetzt auch nochmal ein bisschen die technischen Details. Wie machen wir das eigentlich? Wie sieht unsere Infrastruktur aus? Wir haben hier ein Master, auf dem läuft zum einen das Webinterface, also PrivacyScore.org, wo der Nutzer sich über diese Ergebnisse informieren kann und wo er auch neue Scans veranlassen kann und URLs eingeben kann. Und dann haben wir außerdem im Hintergrund relativ viele Worker, die dann das tatsächliche Scan durchführen. Das heißt, unser Master, der gibt dann Aufträge an diese verschiedenen Worker und diese Worker, die arbeiten diese Aufträge dann alle ab und geben ihre Ergebnisse hinterher zurück und aktuell ist das noch über ein RabbitMQ mit Celery, der die Aufgaben an die Worker verteilt und dann über ein Redis zurückgibt und dann hinterher wird das alles in der Postgres-Datenbank gespeichert. Wir arbeiten allerdings an einer Version, die auch das MQ-Management direkt mit Postgres macht. Das ist vermutlich noch ein bisschen in der Zukunft, bis das fertig ist. Aber wir versuchen auch im Rahmen der GPN-18 ein bisschen daran weiter zu arbeiten, also wenn ihr Lust habt einfach kleinere Ideen habt, die eben nicht direkt diese ganze Infrastruktur betreffen, dann könnt ihr auch gerne bei uns vorbeikommen und vielleicht arbeiten wir dann ja auch gerade in dem Moment heran und können euch auch da unterstützen, uns zu helfen. Es gibt am Bamberger Tisch hier drüben gibt es ein paar Leute, die PrivacyScope.org machen und da, also wenn ihr noch weitere Fragen, Kommentare oder am besten auch Patches habt oder Zeit und Lust habt Patches zu schreiben, dann ist der Bamberger Tisch die auch das MQ-Management. Genau. So, das war jetzt einmal die Infrastruktur in sich, wie die Aufgaben eigentlich verteilt werden. Dann gibt es zudem noch, ich hatte ja von die Checks vorgestellt, die werden nun aber nicht direkt beim Scan ausgeführt, sondern beim Scan werden sozusagen erstmal nur Fakten gesammelt. Das heißt, wir haben verschiedene sogenannte Scan-Module, also zum Beispiel Network, es macht dann grundlegende Dinge wie DNS und dann gibt es auch Test-SSL.sh, das ist ein inbash geschriebenes Skript, das die in verschiedenen SSL Prüfungen macht, um eben zu gucken, ist das Zertifikat gut, werden alte SSL-Versionen angeboten und solche Dinge, die eben SSL betreffen. Und dann wird außerdem noch OpenBPM genutzt, um eben, das hatte Tobias ja schon erklärt, dass dann ein Firefox instrumentalisiert wird, um wie ein echter Browser diese Webseite aufzurufen. All diese Scan-Module sammeln entsprechend Fakten, das heißt so was wie SSL 2 vorhanden, ja oder nein, das ist ja jetzt erstmal ein Fakt und die Bewertung, das so schlecht ist, die würde dann später kommen. Das sind dann sozusagen diese Shacks, die ich vorhin vorgestellt hatte, die also erst während der Auswertung ausgeführt werden. Das heißt auch diese Shacks, die könnte man jetzt relativ leicht noch verändern, weil die ja nur auf diesen Fakten beruhen, die zur Scan-Zeit gesammelt werden. Das heißt, wir könnten jetzt noch die Shacks verändern und damit dann sozusagen auch rückwirkend für die Scanner-Gebnisse von vor handen, das Ranking entsprechend anpassen. Wenn sich jetzt zum Beispiel herausstellt, oh, TL S1.0 ist jetzt auch kaputt, jetzt sollte man kein TL S1.0 mehr verwenden. Und dann eben noch HTTPS vorhanden, bekannte Tracker und all diese anderen Shacks, die ich vorhin noch vorgestellt hatte. Ja, dann kommen jetzt noch verschiedene Statistiken. Das sind zunächst einmal die Gesamtstatistiken, also wir betreiben so im wesentlichen seit ungefähr Juni letzten Jahres ist 5syscore.org aktiv. Und seitdem gibt es jetzt mittlerweile 73.000 Seiten in unserer Datenbank und knapp 500.000 Scans, also die Webseiten werden dann auch regelmäßig immer neu gescannt, weil ein wesentlicher Gedanke ja auch der ist, dass wir über die Zeit Veränderung feststellen wollen. Also im Zweifel auch erkennen können, dank Privacy-Score oder dank dieser Einliste, die wir sehr publik gemacht haben, hat sich jetzt was verbessert. Und deshalb scannen wir regelmäßig diese Seiten an. So, HTTPS ist dabei auf ungefähr 44 Prozent der Webseiten verfügbar, wird sich davon nutzen sogar auch eine Umleitung. Aber 3 Prozent dieser Seiten bieten noch veraltete SSL2 oder 3 Versionen an, teilweise sogar SSL2, was ja nun mittlerweile wirklich sehr alt ist und echt nicht mehr genutzt werden sollte. Also genau wie SSL3 an sich. Genau, dann gibt es noch diese Informations-Lags. Insgesamt haben wir auf unsere Webseiten Informations-Lags gefunden. 2,6 davon diese Status oder die Backinformation, also insbesondere diese PRP Info-Sahien sind eben sehr beliebt auf 0,7 Prozent. Also knapp über 500 sind es immerhin auch, dass wir solche Git- oder SWN-Repositories gefunden haben. Auf 102 Seiten haben wir Datenbank-Dumps gefunden und auf 10 Seiten immerhin auch private RSA Keys oder also private Keys generell. Die Statistiken im Mittelwert werden auf den Seiten 16,9 Cookies verwendet, davon 11,1 im Durchschnitt für Third-Party-Tracking. So, aber jetzt haben wir hier natürlich Gesamtstatistiken, das ist insofern ja nicht so spannend, als das hier ja im Prinzip keine konkrete Gruppe von Webseiten, die man miteinander vergleichen kann, herrscht. Das heißt, wir haben das auch für die deutschen Kommunen noch einmal gemacht. Also das ist eine Liste mit 8000 deutschen Kommunen. Alle Kommunen, die irgendwie zu einem bestimmten Zeitpunkt die Webseite hatten und beinhaltet. Genau, und die haben wir inzwischen 106.000 Mal gescannt. Hier von haben nur 21 Prozent dieser Seiten HTTPS, was entsprechend weniger ist als bei den Gesamtstatistiken. Aber dafür machen hier in diesem Fall tatsächlich sämtliche Webseiten, die HTTPS haben auch nur Umleitung und veraltetes SSL wird bei einem Prozent der Webseiten genutzt. Bei 6 kommt ja auch ein bisschen weniger vor. Das sind bei knapp unter 3 Prozent. Und auch hier ist die Verteilung, dass im Wesentlichen das Status und Debackinformationen sind und eben vereinzelt Repositories und Datenmankdams. Und was man hier aber sieht, ist, dass im Vergleich zu den Gesamtstatistiken deutlich weniger Kukis eingesetzt werden. Das heißt, hier liegt der Durchschnitt bei 1,7 Kukis und davon auch nur 0,3 für Third Party Tracking. Das heißt, das ist im Fall gleich zu deutlich besser. So, und dann soll jetzt ja auch noch diese Zeitkomponente mit hereinkommen. Das heißt, wir haben nicht nur für Mai 2018 jetzt einmal diese Daten, die hier sind, sondern auch im November haben wir diese Daten einmal gesammelt. Da gab es entsprechend erst 70.000 Scans dieser Seiten. Und es waren noch etwas weniger Seiten, die HTTPS angeboten haben. Da waren es 1.600. Aber auch da war es immerhin schon so, dass jede Webseite die HTTPS angeboten hat, das ist gut. Das heißt, man sieht hier, auch bei den veralteten SSL-Versionen ist das gleichzeitig auch zurückgegangen seit November. Das heißt, in beiden Fällen eine positive Veränderung. Die Informationslex sind dann seitdem allerdings überraschenderweise hochgegangen. Was das nun für genaue Ursachen haben mag, ist unklar. Aber das hat sich in der Hinsicht dann verschlechtert. Das heißt, das ist im Zweifel auch eine schlechte Entwicklung. Man könnte auch augmentieren, dass das in dem Fall eher neutral ist, solange es eben keine third-party-Turk in Kukis sind. Denn auf der Partie Kukis kann man ja auch aus sehr legitimem Gründen nutzen, um zum Beispiel eine CSRF-Protection einzubauen. Und dann gibt es auch noch eine ganz lustige Beobachtung. Man sieht hier einmal die Veränderung. Man sieht hier einmal die Top 20-Städte sortiert nach den bekannten Trackern und den third-party-Servern. Und wenn man nun einmal hier all die mit Punkten sieht, das sind all die Webseiten, die von media Agenturen betrieben werden. Das heißt, man sieht, es sind irgendwie verdächtig viele Punkte im oberen Bereich der Tabelle und relativ wenige im unteren Bereich. Um die Eingangsfrage aufzugreifen, ist Hamburg besonders gut oder besonders gut? Wenn es um Tracking geht, ist es normal, dass wenn ich bei Hamburg.de mich über Sozialhilfe informiere, das dritte Parteien darüber Kenntnis erlangen. Und wir können jetzt konstatieren, so normal ist es tatsächlich nicht. Hamburg ist von den größten Städten jedenfalls auf Platz 1. Was das Tracking betrifft, jetzt haben wir die Antwort für die Eingangsgestellte Frage. Und jetzt können wir eben mit der Eingangsgestellte Frage kommen. Die Frage ist, dass Hamburg.de als große Stadt mit viel Geld das nicht selber macht, sondern machen lässt von einer externen Firma. Und diese externe Firma macht das so, wie sie das immer macht mit all ihren Kunden. Die betten natürlich die third party Fonds. Und das JQuery aus dem CDN. Und alles das, was die großen Jungs eben im Web machen machen, die da oft mit auf den Weg geben wollten. Und wie gesagt, wir werden im Rahmen der GPN18 wahrscheinlich ein bisschen im Privacy-Score weiterarbeiten. Und wenn da Ideen sind oder auch Bereitschaft damit zu arbeiten, dann kommt gerne auf uns zu. Und es ist ja auch nicht so, dass man nur die Infrastruktur machen kann, sondern zum Beispiel diese Scan-Module, die sind dann eben relativ kompakt. Das sind einfach nur Python-Module, die im Trivialfall einfach nur eine DNS-Abfrage machen oder einfach nur eine entsprechende gar keine fundierten Kenntnisse von der tatsächlichen internen Infrastruktur haben. Aber auch wenn zum Beispiel Ideen da sind, wie man dieses Ranking für die Notzeit besser machen könnte, da sind wir für Ideen gerne offen. Oder vielleicht sonst jetzt auch gleich, wenn jetzt noch Fragen sind, dann können wir die sicher gerne beantworten. Jetzt haben wir hier glaube ich noch Send-Ideas, Send-Lists, weil wir haben ja das Konzept von den Listen mit vergleichenden Elementen und das ist das Problem, dass es dort Listen gibt. Also wenn ihr jetzt eine Idee habt von einem Business Sektor den man mal abscannern und vergleichen könnte, dann lade diese Liste hoch und macht Ergebnisse zum State of the Web. Und selbstverständlich Bug Reports nehmen wir gerne entgegen entweder per E-Mail, die wir hier, da ist gut genug, die wir da rumzustehen haben über das GitHub-Interface. Und selbstverständlich nehmen wir am allerliebsten fertige Patches an. Und jetzt sind wir noch da für Fragen und Diskussionen. Also auch gerne für weitere Naja-Checks, die man machen könnte oder für weitere Daten, die man erheben könnte oder Experimente, die man machen könnte. Dafür sind wir da. Vielen Dank, gibt es spontanen Diskussionsbeiträge. Haben wir einen Mic? Ja, da kommt das Mikrofon. Ja, erstmal danke für den Talk. Eine Idee für einen Check, den ihr vielleicht schon auf der Roadmap habt, habt ihr über DNS-Sec nachgedacht? Ja, es gibt tatsächlich die neuere Version von PrivacyScope und Doc, die wir gerade testen, die noch nicht live geschaltet ist, die hat ein paar Testdiesbezüglich. Auch wenn, na ja, DNS-Sec ist so ein bisschen wie RATP Public Keeping, muss man mögen, sag ich mal, ist nicht für jedermann. Aber hoffentlich kriegen wir bald die, das freien, andere Ranking sozusagen, dann kann man sich anklicken, ob man DNS-Sec gut findet oder nicht. Aber ja, sehr guter Punkt kann man machen. Ja, auch danke, dass ihr das besuchtest, besser zu machen. Meine erste Frage ist, wenn man so ein Private Key findet, man macht erstmal ein Faceform natürlich, aber dann. Ja, das ist ein sehr guter Punkt. In meinem, tatsächlich in meinem allerletzten Vortrag diesbezüglich, hab ich da relativ viel Zeit darauf verwendet, weil das ist wirklich schlecht. Die, in dem konkreten Fall, hab ich, oder haben wir Unis gescannt, nicht? Unis haben eigentlich kein Interesse daran, weiß ich auch nicht, dich zu tracken oder die Server-Logs öffentlich rumliegen zu lassen und da könnte man meinen, dass die Leute hinreichend, wie soll ich sagen, Zeit haben, um das Böse zu formulieren in der Behörde, um sich darum zu kümmern. Aber es ist erstaunlich schwierig, solche Reports abzuliefern. Also es ist wirklich katastrophal schwierig für diese Rund 20 oder was ich da gefunden, oder was wir gefunden hatten, Dinge, war kein Private Key mit dabei, aber Git Repositories und Server-Logs und so, habe ich knapp 100 E-Mails in meiner Inbox, die ich hin und her geschickt habe, weil es sehr schwierig ist, diese Reports abzuliefern. Und ja, ich, also falls ihr entweder selber Webseiten betreibt oder jemanden kennt der Webseiten betreibt, dann bitte, bitte, bitte sorgt dafür, dass es ein Security-Ed gibt, oder wenigstens Webmaster-Ed oder so. Es gibt das RFC 21, 42 glaube ich, oder da 40, dass vorsicht, dass es solche Adressen gibt und bitte, bitte sorgt dafür, dass es diese Mail-Alliase gibt. Falls jemand Angst vor Spam hat, Fair enough, das ja, E-Mail ist ja im Prinzip ein Fotospferd. Es gibt auch relativ hippes.wellknown-slash-Security-Takes die, und da ist dann die Idee, dass man dort auch Security-Contacts hinterlebt. Ja, wir haben auch das ein bisschen schlimmer, um das noch ein bisschen dramatischer zu machen. Wir sind dann auch über das Zert gegangen und haben dann über das Zert die jeweiligen Unis informiert und da ist dann auch, also eigentlich nichts passiert. Und ja, es ist ein bisschen, ein bisschen polemisch, es ist nicht ganz so schlimm, wie ich das darstelle, aber es ist schon insgesamt sehr schlecht und es ist auch manchmal bisschen, wie soll ich sagen, ist es auch tatsächlich kein Problem, wenn die PHP-Info rumliegt. Weil, na ja, tatsächlich ist es häufig der Fall bei so Scherthostern, bei so, ich weiß nicht, Stratto oder weiß nicht All Inkel oder wie sie heißen. Und von denen, wie gesagt, das ist deren Business, dass sie die Server auch up-to-date halten. Und das ist egal, ob dann Enterprise-Linux von 2010 läuft, weil, also Red Hat wird immer noch bezahlt dafür, dass der Kasten sicher gehalten wird. Und dann ist das auch okay. Aber, na ja, deswegen ist also auch nicht immer alles ein Problem, was sozusagen bei uns aufschlägt und was wir feststellen. Ein bisschen grundsätzlichere Frage, warum bietet ihr die Option an, dass Seiten black List auf einem relativ sicheren Fuß steht? Na ja, gibt ja recht haben und recht bekommen sind ja zwei Sachen. Und während wir durchaus der Meinung sind und das auch relativ lautstark vertreten, dass es okay ist, eine Webseite aufzumachen und dann der Welt zu erzählen, was dann passiert, sind auch wir nur begrenzt ausgestattet mit Zeit und Lust und Nerven und Geld, sich um die Konsequenzen dann zu kümmern. Und für uns ist es eigentlich sogar gut, wenn wir die black list haben, aber es ist ja auch nicht so, dass wir die Pistosen, die wir für das Scan von Webseiten aufbringen müssen. Also es ist so ein bisschen ein Entgegenkommen, um einfach den Stresslevel ein bisschen niedriger zu halten. Und wir verstecken das ja nicht die Tatsache. Also es ist ja nicht so, dass sich jemand weiß ich auch nicht vom Scan freikauft oder von dem schlechten Platz freikaufen kann. Wir sind ja kein Ayo oder so, die diesen Adblock plus betreiben, wo du dich mafiafios wieder freikaufen kannst. Ja, ich bin auch, muss ich gestehen, kein richtig großer Fan davon, aber tatsächlich muss ich auch gestehen, dass ich keinen Bock habe, mich mit Leuten zu streiten, sondern ich will eben das Web besser und sicherer machen. Und wenn jemand meint, da nicht mitspielen zu müssen, dann wollen wir ihm auch nicht zum Glück zwingen. Weitere Wortmeldungen, doch noch eine. Sehr schöne Diskussion, gefällt mir sehr gut. Du hast sehr viel Wert auf diese Listen gelegt. Ja genau, weil dieses Scanner, also dieses Scanner gibt es darauf, es gibt wirklich echt nicht 100, aber ein Dutzend von diesen Scanners, die auch sehr detailliert dir sagen und noch viel besser als sie das können, wie jetzt eine spezielle Webseite performt. Aber das vergleichende Element behaupten wir es nur um. Ja und genau darum gibt es ja, gibt es schon Leute, die das aufgegriffen haben und irgendwelche besonderen Sachen schon herausgefunden haben, also die da wirklich schon Arbeit reingesteckt haben, weil das ist ja so ein bisschen Big Data Analyse, da kann ich mir vorstellen, dass das irgendwelche Sachen, ob ihr da schon irgendwie solche Sachen erlebt. Völlig, völlig richtiger Punkt, das ist die Idee, dass wir da hinkommen. Da brauchen wir ein bisschen Methodenkompetenz in Richtung Data Science und vielleicht auch ein bisschen diesen Big Data Bereich, wobei wir haben gar nicht so richtig Big Data. Aber ja, also das wollen wir tatsächlich machen und wir haben auch ein paar Ergebnisse, auf der Webseite sind ein paar Paper verlinkt, ein bisschen gibt es, aber ich glaub da geht noch deutlich mehr. Also ich glaub mit den Daten kann man noch deutlich, deutlich mehr Informatiker und keine, weiß ich auch nicht, Statistiker oder Data Scientist, da können wir also durchaus noch, wie soll ich sagen, noch Hilfe gebrauchen und können wir unter die Arme genommen werden und dass uns da jemand mit Methodenkompetenz ausstattet. Oder auch die richtigen Fragen stellen, ist ja nicht nur, also die Daten haben ist das ein und dann die richtigen Fragen über diesen Daten zu stellen, ist das andere. 3, 2, 1, verkauft. Vielen Dank für die Aufmerksamkeit. Wir hängen noch hierherum auf dem Mega-Tisch und so. Bis spieltaufendlich.