wie schon geschrieben, es gibt immer noch keinen Hinweis, wie man über Google die geschützten Bilder finden könnte ...Ansonsten kann man es gleich entfernen und hinweisen das alle Bilder öffentlich sind.
Follow along with the video below to see how to install our site as a web app on your home screen.
Anmerkung: This feature may not be available in some browsers.
wie schon geschrieben, es gibt immer noch keinen Hinweis, wie man über Google die geschützten Bilder finden könnte ...Ansonsten kann man es gleich entfernen und hinweisen das alle Bilder öffentlich sind.
ja wenn, aber ist es denn schon einmal geschehen?Wenn auch nur eines der angeblich geschützten Bilder zufällig in einer Bildersuche auftaucht, ist das ein Fehler der nicht passieren darf, das ist einfach indiskutabel.
ja wenn, aber ist es denn schon einmal geschehen?
wenn ich Google die direkte Adresse zu Daten gebe, welche es nicht crawlen sollte, dann ist es doch klar, dass es dann auch in Google zu finden ist
[...]..
wie schon geschrieben, es gibt immer noch keinen Hinweis, wie man über Google die geschützten Bilder finden könnte ...
Spielt das denn eine Rolle?ja wenn, aber ist es denn schon einmal geschehen?
Das darf dann auch keiner, dem man Zugriff auf die Bildger gegeben hat, kann man aber selber nicht kontrollieren.Ergo: Wer ein Bild schützen will, darf das Bild nicht öffentlich posten. Das ist für mich aber auch ganz logisch denn sobald ich es irgendwo poste wo google dran kann, kann auch jeder andere dran und es ist nicht mehr geheim.
Das darf dann auch keiner, dem man Zugriff auf die Bildger gegeben hat, kann man aber selber nicht kontrollieren.
bitte hör mal auf ständig theoretisch zu diskutieren zeig mir bitte mal wie man geschützte Bilder bei Google findet!Spielt das denn eine Rolle?
Was ist das denn bitte für eine Risikoanalyse wenn Du Gefahren niedrig bewertest nur weil sie noch nicht eingetreten sind? Die Tragweite diese Falles würde ich als durchaus hoch bewerten, was auf jeden Fall Handlungsbedarf auslöst.
Wenn Du Passwortschutz für bestimmte Daten anbietest, darf dieser Schutz nicht durch irgendeine Suchmaschine/Linkkonstallation übergangen werden können.
ODER man muß im Voraus klar darauf hinweisen, dass diese Zugriffschutz nur rudimentär ist.
Möglicherweise wurden andere Bilder schon x-fach offengelegt was keinem aufgefallen ist da der Nutzer der Suchmaschine ja nicht weiß, dass die Bilder geschützt sein sollten.
Irgendwie schon lustig, dass sich hier immer alle über Facebook beschweren, dann aber klamm in Schutz nehmen, wenn es um Sicherheit geht.
Ich habe das Bild nicht bei Google "hochgeladen" nur die URL reicht aus, um das Bild bei Google zu sehen. Nachdem Google mit Leichtigkeit mit seinen Crawlern Bilder von Seiten indiziert (macht es ja nicht erst seit gestern) ist das nicht schön.
Ein Hinweis Passwortschutz ist eigentlich unsinnig würde zwar helfen, aber dann braucht man sich auch nicht mehr wundern, wenn so wenige User bei Klamm sind.
Nur leider hat deine Kassette ein Loch auf der Rückseite an die jeder (Google) ran kann.
Tut mir Leid, deine Argumentation überzeugt mich nicht.
Wenn ein Schutz in Form eines Passworts da ist dann sollte dieses auch greifen. Ansonsten kann man es gleich entfernen und hinweisen das alle Bilder öffentlich sind.
skandalös kommt von Dir. Leg mir bitte keine Worte in den Mund, die ich nicht gesagt habe.k... Ich habe eben drei Bilder in einen geschützten Ordner geladen... Dank des "skandalösen Bugs" sollte es jetzt doch ein Leichtes für dich sein, "durch das Loch an der Rückseite zu greifen" und mir zumindest eines der Bilder hier zu posten... oder? Immerhin sind sie ja quasi öffentlich.
Gruß Aru
... Der URL ist das Passwort, wer den URL postet hat sein Passwort verraten. Ist für mich ganz logisch?
Der GoogleBot scannt mehrfach pro Tag / Stunde klamm.de ab, automatisch. Und nur, weil man per Browser eine Abfrage präsentiert bekommt, heißt es nicht automatisch, das der GoogleBot diese Abfrage überhaupt sieht.Googles Crawler indizieren das was sie finden können. Nur wenn Du den URL öffentlich postest kann Google ihn finden. "Von selbst" passiert das jedenfalls nicht, also leicht zu vermeiden.
Da hilft nur informieren zum Thema .htaccess / robots.txt, GoogleBotDen Satz verstehe ich nicht.
Die Bild-URL enthält keinerlei Authentifizierungsmerkmale sondern ist nach dem Muster:
https://img4.klamm.de/gallery/picz/30000/<Klamm-UserID>/<10stellige-Hex-Zahl>_big.<Datei-typ> aufgebaut.
Der GoogleBot scannt mehrfach pro Tag / Stunde klamm.de ab, automatisch.
Und nur, weil man per Browser eine Abfrage präsentiert bekommt, heißt es nicht automatisch, das der GoogleBot diese Abfrage überhaupt sieht.
Da hilft nur informieren zum Thema .htaccess / robots.txt, GoogleBot
Desweiteren bietet Google für Mobiles eine Datenkomprimierung an, wird ein Proxy-Server zwischen geschaltet, der die Daten komprimiert.
Ruft ein User seine Daten aus geschützten Bereich ab und Google wertet das Proxy-Log aus
<10stellige-Hex-Zahl> ist unbekannt und spielt somit hier die Rolle des Passworts. Dürfte sicherer sein als die Passwörter die manche Nutzer sich so ausdenken. Steht natürlich beim Aufruf im Klartext im HTTP-Get-Request. Ja und? Das würde für ein per Formular übertragenes Passwort nicht anders sein.
Also diese Aussage zeigt wie wenig Ahnung der Verfasser hat! 10 stellige Hex Zahlen (Hash?) sind ja wohl nicht sicher
DaPhreak, das ist Schwachsinn einen automatisch generierten Dateinamen auf die Stufe eines Passworts zu erheben.<10stellige-Hex-Zahl> ist unbekannt und spielt somit hier die Rolle des Passworts.
Jedes Passwort ist sicherer, als keines für eine Datei die ansonsten keinen Zugriffshutz hat und deren Namen sich durch Bruteforce erraten läßt. (Welche Latenzen / Bandbreiten / und Systeme werden heutzutage eingesetzt? klingels?)Dürfte sicherer sein als die Passwörter die manche Nutzer sich so ausdenken.
Klar... spätestens bei einer HTTPS-verschlüsselten Übertragung ist hier aber Schluss.Steht natürlich beim Aufruf im Klartext im HTTP-Get-Request. Ja und? Das würde für ein per Formular übertragenes Passwort nicht anders sein.
schon wieder eine Halb-Wahrheit.Sicher tut er das. Er sieht dabei aber nur die Seiten die öffentlich zugängig sind.
wieder Halb-Wahrheit.Solange $user nicht den Link (also die 10-stellige Hex-Zahl) im Forum oder sonstwo postet wird GoogleBot diesen Link nicht sehen und damit auch nicht indizieren.
...hast Du denn mal ausprobiert, worum es hier geht? Nein? Dann hättest Du herausgefunden das eine Abfrage bei Kenntnis der URL nicht auftaucht. Gilt auch für Bots.Und ob. Vorausgesetzt die Abfrage ist richtig implementiert. Ihr Zweck ist Authentifizierung, ein Bot ist ganz klar nicht authentifiziert - wenn er die Abfrage nicht sehen würde hätte sie ihren Zweck verfehlt.
Da hat du dir ja doch noch die Einleitung zur robots.txt durchgelesen.[...]Ich halte übrigens eine robots.txt für das so ziemlich unsicherste Mittel, da sie nur eine Empfehlung darstellt.
Wo steht es, das sie es nicht tun? Nutze ich solche Dienste, hab ich bei Klartext-Übertragung bzw. -Aushandlung immer das Problem, das jemand mitlesen kann. Im Beschreibungstext zur Daten-Reduzierung in meiner JB-Android-Version wird auf das Risiko nicht hingewiesen.Seit wann wertet Google denn Proxy-Logs aus das wäre mir neu...
Muss es nicht, allerdings haben beide den Passus drin, das sie Daten auswerten durfen zu Verbesserung ihrer Dienste, gerade FB zeigt seit diesem Monat ja was das bedeutet und wie sie es bewerkstelligen wollen.Ich glaube auch, dass das schon aufgefallen wäre - denn viele Seiten nutzen die Technik (z.B. auch Facebook), dann müssten sich ja längst alle geschützten Bilder im Google Index befinden? Wenn da was dran wäre, müsste es dazu einen Artikel bei heise geben. Ich schaue mal ob ich was finde.
Wow.. Am Ende die Erkenntnis und ein Griff in die Phrasenkiste...Natürlich muss klar sein, dass im Grunde jeder Proxy die URLs abfangen kann. Das gilt aber auch für über HTTP gesendete Passwörter. Für richtige Sicherheit hilft nur Ende-zu-Ende-Verschlüsselung, alles andere ist am Ende nicht mehr und nicht weniger sicher als das System was wir hier haben...
Jedes Passwort ist sicherer, als keines für eine Datei die ansonsten keinen Zugriffshutz hat und deren Namen sich durch Bruteforce erraten läßt. (Welche Latenzen / Bandbreiten / und Systeme werden heutzutage eingesetzt? klingels?)
Klar... spätestens bei einer HTTPS-verschlüsselten Übertragung ist hier aber Schluss.
Setzen 6.
schon wieder eine Halb-Wahrheit.
Der GoogleBot fragt höfflich ab, welche URLs er denn scannen darf, dafür nimmt er die Angaben aus der robots.txt.
Er kann sich daran halten, muss es (und andere Bots) aber nicht.
Hausaufgaben nicht gemacht.
Setzen. 6
...hast Du denn mal ausprobiert, worum es hier geht? Nein? Dann hättest Du herausgefunden das eine Abfrage bei Kenntnis der URL nicht auftaucht. Gilt auch für Bots.
Natürlich kann ich für Bots eine Abfrage generieren. Ich kann sie aber auch zulassen trotz Abfrage auf PW, wenn $Browser zugreift. Nur muss ich das aktiv einrichten.
Da hat du dir ja doch noch die Einleitung zur robots.txt durchgelesen.
Ja die robots.txt ist nur eine Empfehlung, in Zusammenhang mit einer oder mehreren .htacces -Dateien / -Regeln
kann man daraus aber schon einen guten Zugriffsschutz aufbauen.
Wo steht es, das sie es nicht tun? Nutze ich solche Dienste, hab ich bei Klartext-Übertragung bzw. -Aushandlung immer das Problem, das jemand mitlesen kann. Im Beschreibungstext zur Daten-Reduzierung in meiner JB-Android-Version wird auf das Risiko nicht hingewiesen.
Muss es nicht, allerdings haben beide den Passus drin, das sie Daten auswerten durfen zu Verbesserung ihrer Dienste, gerade FB zeigt seit diesem Monat ja was das bedeutet und wie sie es bewerkstelligen wollen.
Wenn Du gerade auf Heise bist, lese Dir doch den Artikel bei Heise Security durch zum Thema "Wie sichere ich meine Dateien auf meinem Webserver richtig" duch, ja?
Fassen wir zusammen:
[...]
Fazit: Sicherheit? Nur vorgetäuscht.