Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Google Drive macht in macOS-Systemdateien Copyright-Verstoß aus

Google Drive funktioniert ähnlich wie iCloud Drive: Nutzer können Dateien zwischen verschiedenen Geräten synchronisieren und auf Wunsch auch anderen Anwendern zur Verfügung stellen. Google scannt beim Upload die Dateien nicht nur nach kinderpornografischen Inhalten, sondern auch nach sonstigen Verstößen gegen die eigenen allgemeinen Geschäftsbedingungen. Hierunter fallen unter anderem Verstöße gegen das Urheberrecht.


Bereits im letzten Jahr berichteten einige Entwickler, dass Google kleinere Dateien mit einfachen Zahlen als Copyright-Verstoß wertet. Hierbei handelte es sich um Beschreibungsdateien, welche nur aus Zahlen wie zum Beispiel "0", "1", oder "256" bestanden. Der Google-Algorithmus verwendet Hash-Werte der Dateien, um zu erkennen, ob bereits andere Anwender Dateien mit ähnlichen Inhalten hochgeladen haben – und diese Vergleichszahlen schlugen natürlich bei diesen simplen Dateien an, da andere Entwickler und Anwender in der Vergangenheit solche Dateien über Google Drive synchronisieren.

".DS_Store"-Dateien als Urheberrechtsverletzung
Apple verwendet auf dem Mac so genannte ".DS_Store"-Dateien (kurz für "Desktop Services Stores"), um Informationen über Dateien in einem Ordner zu speichern und sich die aktuellen Finder-Darstellungsoptionen zu merken (Genauere Informationen zu ".DS_Store" finden Sie in diesem Artikel: ). Diese Dateien legt der Finder oder andere Systemprozesse automatisch an – und der Nutzer kann dies nicht verhindern

Oftmals ist der Inhalt dieser Dateien gleich – und da diese Dateien als unsichtbar markiert sind, sollte Google Drive diese nicht synchronisieren. Doch Google Drive scheint unter bestimmten Voraussetzungen auch diese Dateien automatisch abzugleichen und nach einer gewissen Zeit erhalten die Anwender dann eine E-Mail wegen eines Copyright-Verstoßes, weil andere Nutzer bereits ".DS_Store"-Dateien mit vergleichbarem oder gleichem Inhalt hochgeladen haben.


Momentan nur Abwarten möglich
Im Dezember 2021 entfernte Google leider die Möglichkeit, die vermeintlichen Copyright-Verstöße an Google zwecks manueller Begutachtung zu melden. Aktuell besteht für Betroffene nur die Möglichkeit, abzuwarten, bis Google das ärgerliche Problem korrigiert. Aufgrund der Anzahl der Betroffenen, welche sich über soziale Medien zu Wort melden, dürfte Google bereits informiert sein. Wenn Google zu viele "Copyright-Verstöße" für ein Nutzerkonto registriert, könnte durch ein Automatismus sogar der Sync über das Google-Konto deaktiviert oder der Zugriff auf die Dateien gesperrt werden. Es ist hier allerdings zu erwarten, dass Google das Problem schnell behebt und die Konten wieder freigibt.

Kommentare

Marcel Bresink21.02.22 08:42
Wie man im Screenshot sehen kann, geht es überhaupt nicht um die .DS_Store-Datei, sondern um die Erweiterten Attribute dieser Datei, die zusätzlich im Apple-Double-Format gespeichert wurden, da Google Drive kein natives Mac-Dateisystem ist, das solche Metadaten unterstützen kann. Bei den Attributen dürfte es sich um die Finder-Markierung handeln, dass die .DS_Store-Datei unsichtbar ist.
+10
aMacUser
aMacUser21.02.22 08:51
Marcel Bresink
Wie man im Screenshot sehen kann, geht es überhaupt nicht um die .DS_Store-Datei, sondern um die Erweiterten Attribute dieser Datei, die zusätzlich im Apple-Double-Format gespeichert wurden, da Google Drive kein natives Mac-Dateisystem ist, das solche Metadaten unterstützen kann.
Das macht es jetzt allerdings auch nicht wirklich besser.
Marcel Bresink
Bei den Attributen dürfte es sich um die Finder-Markierung handeln, dass die .DS_Store-Datei unsichtbar ist.
Nein, bei Unix-Artigen Betriebssystemen ist eine Datei automatisch unsichtbar, sobald der Dateiname mit einem Punkt beginnt.

Für mich sehen diese ganzen Probleme nach mangelnder Qualitätssicherung seitens Google aus. Dabei sollte man doch eigentlich meinen, dass Google genug Geld hat, um ein paar Qualitätssicherer einzustellen. Der Fehler hätte dich eigentlich sofort auffallen müssen.
+5
Mendel Kucharzeck
Mendel Kucharzeck21.02.22 08:56
Marcel Bresink
Wie kommst du darauf? Auf dem Screenshot steht doch astrein, dass Google dort einen Copyright-Verstoß ausmachte? Meinst du wegen dem "._."?
+1
Tammi
Tammi21.02.22 09:00
Google und copyright? Ausgerechnet Google?
+5
WollesMac
WollesMac21.02.22 09:02
.DS vs. ._.DS meint Marcel wohl
+1
Marcel Bresink21.02.22 09:10
aMacUser
Nein, bei Unix-Artigen Betriebssystemen ist eine Datei automatisch unsichtbar, sobald der Dateiname mit einem Punkt beginnt.

Du hast das Problem nicht verstanden. Die unsichtbare .DS_Store-Datei ist nicht bemängelt worden, da Google die entweder kennt, bzw. gar nicht synchronisiert hat. Die ebenso unsichtbare Apple-Double-Datei, mit der der Finder das Erweiterte Attribut "hidden" für die Originaldatei speichert, ist jedoch synchronisiert worden und wird als Copyright-Verstoß gemeldet, da das Hidden-Attribut immer gleich aussieht. Es ist ein Bug im Finder, bereits versteckte Dateien noch einmal zusätzlich durch ein Attribut als versteckt zu markieren, was aber auch nicht verboten ist.
Mendel Kucharzeck
Meinst du wegen dem "._."?

Ja, das ist ja ganz klar keine .DS_Store-Datei.
+5
Mendel Kucharzeck
Mendel Kucharzeck21.02.22 09:20
Marcel Bresink
Gerade gesehen, dass es auch Meldungen bezüglich ".DS_Store" (ohne ._.) gibt und nicht nur für die Metadaten. Also scheint beides wohl als Copyright-Verstoß behandelt zu werden.
+3
Marcel Bresink21.02.22 09:43
Dieser Fall dürfte allerdings unwahrscheinlicher sein, da .DS_Store-Dateien im Allgemeinen unterschiedlichen Inhalt haben.

Für die Unsichtbarkeitsmarkierung speichert der Finder aber immer die gleiche ExtendedFinderInfo-Datenstruktur als Erweitertes Attribut ab:
xattr -px com.apple.FinderInfo .DS_Store
20 20 20 20 20 20 20 20 40 10 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

Beim Kopieren auf ein nicht-natives Dateisystem wandelt macOS das Attribut in eine Apple-Double-Datei um, wodurch sich die Datenmenge auf das 128-fache aufbläht:

hexdump -C ._.DS_Store
00000000  00 05 16 07 00 02 00 00  4d 61 63 20 4f 53 20 58  |........Mac OS X|
00000010  20 20 20 20 20 20 20 20  00 02 00 00 00 09 00 00  |        ........|
00000020  00 32 00 00 0e b0 00 00  00 02 00 00 0e e2 00 00  |.2..............|
00000030  01 1e 20 20 20 20 20 20  20 20 40 10 00 00 00 00  |..        @.....|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 41 54 54 52  09 c2 01 90 00 00 0e e2  |....ATTR........|
00000060  00 00 00 78 00 00 00 00  00 00 00 00 00 00 00 00  |...x............|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000ee0  00 00 00 00 01 00 00 00  01 00 00 00 00 00 00 00  |................|
00000ef0  00 1e 54 68 69 73 20 72  65 73 6f 75 72 63 65 20  |..This resource |
00000f00  66 6f 72 6b 20 69 6e 74  65 6e 74 69 6f 6e 61 6c  |fork intentional|
00000f10  6c 79 20 6c 65 66 74 20  62 6c 61 6e 6b 20 20 20  |ly left blank   |
00000f20  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000fe0  00 00 00 00 01 00 00 00  01 00 00 00 00 00 00 00  |................|
00000ff0  00 1e 00 00 00 00 00 00  00 00 00 1c 00 1e ff ff  |................|
00001000
+6
BarbedAndTanged21.02.22 09:43
Selbst schuld, wer Google Drive nutzt.
-1
CHL21.02.22 10:14
Heute Google, morgen Dropbox, Microsoft, Apple oder welcher Cloud-Anbieter auch immer.

Ich sehe folgendes Szenario: Die ganzen Daten (sehr gerne machen das ja auch Firmen) per Default in die Cloud meines Anbieters um ja "sicher" zu sein. Dann passiert so ein Fehler und der Zugriff auf die Dateien wird durch eine Kontosperre blockiert. Dem nicht genug, zur "Sicherheit" sperrt der lokale Sync-Client auch den Zugriff auf die lokale Datei oder noch schlimmer, er löscht dieses "verbotene Ding" lokal "zur Sicherheit". Muss ja nicht zwingend ein Copyright-Verstoss sein sondern könnte ja auch eine Fehlerkennung als Virus sein oder neue rechtliche Aspekte.

Backup? Wozu.... die Cloud ist ja soooooooo sicher, gut, praktisch, toll und noch dazu günstig.

Und dann?

Fazit: wenn es wirklich wichtig ist, dann bitte die Daten (zumindest zusätzlich nochmal) selbst im Haus haben und nicht vergessen: Backup, backup, backup.... und zur Sicherheit: Backup!

Ergänzung: Ein Backup ist nur dann gut und sicher, wenn es auch wieder sicher lesbar ist.... wird leider selten genug getestet
+8
aMacUser
aMacUser21.02.22 10:39
Marcel Bresink
Du hast das Problem nicht verstanden.
Doch, habe ich schon.
Marcel Bresink
Die ebenso unsichtbare Apple-Double-Datei, mit der der Finder das Erweiterte Attribut "hidden" für die Originaldatei speichert,
Und genau das ist halt falsch. Die .DS_Store Datei ist nicht deswegen unsichtbar, weil irgendeine andere Datei dem Finder das sagt. Die Datei ist deswegen unsichtbar, weil sie mit einem Punkt anfängt. Jede Datei, die mit einem Punkt anfängt, ist bei Unix- und Linux-System automagisch unsichtbar. Da braucht es keine gesonderten Flags mehr. Ich habe keine Ahnung, wofür die ._.DS_Store Datei da ist. Aber für die Unsichtbarkeit definitiv nicht.
-5
system7
system721.02.22 10:57
Wer Fotos aus dem Jahr 1986 in der Cloud hat, auf dem Fotos von einem N_g_rkusswettbewerb unter diesem Namen gespeichert sind, sollte sie schon einmal in Sicherheit bringen. Ebenfalls, wenn sich jemand damals im Karneval als Indianer verkleidet hat.
+1
system7
system721.02.22 11:01
CHL

Ergänzung: Ein Backup ist nur dann gut und sicher, wenn es auch wieder sicher lesbar ist.... wird leider selten genug getestet

Ganz einfach ist das ganze nicht. Zu Hause können die Daten bei einem Feuer oder Einbruch auch entwendet werden.

Am sichersten sind mehrere Festplatten an unterschiedlichen Orten. Unverschlüsselte idealerweise. Dann kann auch niemand das Passwort vergessen. Nur sind die Daten dann eben auch nicht geheim.



Da aber zunehmend auch die Programme in die Cloud wandern, mit denen man die Dateien anzeigen kann, wird es immer schwieriger, wenn man nicht auf irgendeine
+1
SelbstgewaehlterName21.02.22 11:16
Und wieder ein wunderbarer Beitrag aus der Reihe "Warum es sich lohnt selber oder dezentraler zu hosten".
+3
X-Jo21.02.22 11:16
aMacUser
[…]
Und genau das ist halt falsch. Die .DS_Store Datei ist nicht deswegen unsichtbar, weil irgendeine andere Datei dem Finder das sagt. Die Datei ist deswegen unsichtbar, weil sie mit einem Punkt anfängt. Jede Datei, die mit einem Punkt anfängt, ist bei Unix- und Linux-System automagisch unsichtbar. […]
Warum kann dann der Finder versteckte Dateien überhaupt anzeigen?
Und woher weiß der Finder, ob er versteckte Dateien anzeigt, oder nicht?
Einfach mal ein Finderfenster öffnen, . drücken und darüber nachdenken.
+1
CHL21.02.22 11:23
system7
CHL

Ergänzung: Ein Backup ist nur dann gut und sicher, wenn es auch wieder sicher lesbar ist.... wird leider selten genug getestet

Ganz einfach ist das ganze nicht. Zu Hause können die Daten bei einem Feuer oder Einbruch auch entwendet werden.

Am sichersten sind mehrere Festplatten an unterschiedlichen Orten. Unverschlüsselte idealerweise. Dann kann auch niemand das Passwort vergessen. Nur sind die Daten dann eben auch nicht geheim.

Absolut richtig. Aber die DSGVO schreibt ja im Unternehemsnbereich eine Verschlüsselung vor - somit werden wir über kurz oder lang unsere Daten dann physisch absolut sicher intern wie extern lagern und dank vergessener Kennwörter nie wieder nutzen können...
+1
Marcel Bresink21.02.22 11:33
aMacUser
Doch, habe ich schon.

Dein Kommentar beweist, dass Du es nicht verstanden hast.
aMacUser
Und genau das ist halt falsch. Die .DS_Store Datei ist nicht deswegen unsichtbar, weil irgendeine andere Datei dem Finder das sagt.

Das weiß hier jeder. Du hast nicht begriffen, dass der Finder diese Datei nicht nur mit einem führenden Punkt, sondern zusätzlich noch mit einem Finder-Attribut als unsichtbar markiert. Das dient der Kompatibilität mit Programmen aus dem klassischen Mac OS.
aMacUser
Ich habe keine Ahnung, wofür die ._.DS_Store Datei da ist.

Das merkt man.
aMacUser
Aber für die Unsichtbarkeit definitiv nicht.

Vergleiche die oben angegebenen 32 Bytes mit der Carbon-"FileInfo"-Datenstruktur des Finders: Type- und Creator-Code sind durch Leerzeichen 0x20 inaktiv gemacht. Danach wird durch den Wert 0x4010 das Finder-Flag "kIsInvisible" gesetzt. Ansonsten sind die Info-Daten leer. Das Attribut dient also nur dazu, die Datei (doppelt) als unsichtbar zu kennzeichnen.
+4
Wellenbrett21.02.22 11:39
aMacUser
Marcel Bresink
Du hast das Problem nicht verstanden.
Doch, habe ich schon.
Marcel Bresink
Die ebenso unsichtbare Apple-Double-Datei, mit der der Finder das Erweiterte Attribut "hidden" für die Originaldatei speichert,
Und genau das ist halt falsch. Die .DS_Store Datei ist nicht deswegen unsichtbar, weil irgendeine andere Datei dem Finder das sagt. Die Datei ist deswegen unsichtbar, weil sie mit einem Punkt anfängt. Jede Datei, die mit einem Punkt anfängt, ist bei Unix- und Linux-System automagisch unsichtbar. Da braucht es keine gesonderten Flags mehr. Ich habe keine Ahnung, wofür die ._.DS_Store Datei da ist. Aber für die Unsichtbarkeit definitiv nicht.
Es gibt im Finder bzw. macOS zwei parallele Mechanismen um Dateien als unsichtbar zu markieren. Die von Marcel beschriebene über das Attribut und, die es meines Wissens so oder so ähnlich schon unter MacOS 7-9 gab und die altbekannte Unix-Konvention, wonach Dateien mit führendem Punkt nicht angezeigt werden.
+6
aMacUser
aMacUser22.02.22 12:42
Gut, dann habe ich mich offensichtlich geirrt, das kann passieren. Das macOS eine Datei doppelt unsichtbar macht, nur um macOS 9 Programme zu unterstützen, die schon seit vielen Jahren überhaupt nicht mehr auf dem Mac laufen, ist jetzt auch nicht gerade logisch. Daneben habe ich diese Dateien bei mir auf dem Mac noch nie gesehen.

Alles in allem gebe ich dir einen Tipp Marcel Bresink: Gehe in Zukunft etwas freundlicher mit anderen Menschen um und halte sie nicht direkt für blöd und behandle sie nicht wie unwürdige Idioten. Deine Antworten haben dann auch überhaupt nicht geholfen, weil du meinen Irrtum in keinster Weise aufgeklärt hast, sondern nur deine Aussage in verschiedenen Varianten wiederholt hast. Das hat erst Wellenbrett gemacht.
+1

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.