nicht angemeldet
seth
Auge
seth
Rolf B
TS
Linuchs
Linuchs
Der Martin
seth
marctrix
Henry
gudn tach!
eine zweistellige anzahl von websites, die heterogen erstellt wurden und gepflegt werden (plain-old-html, wordpress, joomla, static mirrors von lokalen wordpress-/joomla-instanzen, ...)
eine (dsgvo-konforme) moeglichkeit, um sowohl das impressum als auch die datenschutzerklaerung (DSE) zentral zu pflegen. die impressen und DSEs der verschiedenen websites unterscheiden sich immer nur geringfuegig. zentrale pflege ist wichtig, weil sich hin und wieder bestandteile von impressum und DSE aendern und man vermeiden moechte, alles ueberall von hand nachzuziehen, da dies grosses fehlerpotenzial birgt.
ein zentrales PHP-template (auf einer anderen website), das via GET-parameter den gewuenschten output liefert, kann via iframes eingebunden werden. fuer browser, die keine iframes supporten, wird alternativ ein link auf impressum bzw. DSE angezeigt. bei den heterogenen websites muss dann nur ein mal dieser iframe fuers impressum und einmal fuer die DSE eingebaut werden.
der "chef" mag iframes nicht, weil man bei abgeschalteten iframes zwei klicks braucht, um zur DSE zu gelangen. er will aber, dass man nicht mehr als einen klick dorthin braucht.
die notloesung, die ich momentan sehe, ist, zumindest bei den static mirrors in den mirror-prozess eine automatische konvertierung der iframes in "richtigen" html-code vorzunehmen, das wuerde zumindest schon mal einen teil der arbeit abnehmen. aber es wuerde eben nur bei einem teil der websites funktionieren.
welche alternativen loesungen koennten sinnvoll sein?
prost
seth
Hallo
Solange alle Angebote auf einem Server (in einem Dateisystem) gehostet werden, kannst du das die gewünschten Inhalte zentral lagern und mit einer serverseitigen Sprache (Perl, PHP, Python, WasAuchImmer) aus dem Dateisystem heraus einbinden.
Tschö, Auge
gudn tach!
da die antwort von Rolf B quasi eine verallgemeinerung dessen ist, antworte ich dort.
prost
seth
Hallo seth,
dumme Frage: verlangt die DSGVO oder das TMG, dass das Impressum unter der gleichen URL wie der Rest der Webseite liegt? Es werden bestimmte Inhalte verlangt, und leichte Erreichbarkeit dieser Inhalte. Aber gleiche URL? Dazu finde ich nichts.
Wenn auf example.org/index.html ein Link auf ein Impressum ist, und der Link auf example.com/impressa/example.org/impressum.html führt, könnte das doch zulässig sein, es wäre zumindest eine Möglichkeit, die man prüfen sollte.
Rolf
Hallo,
dumme Frage: verlangt die DSGVO oder das TMG, dass das Impressum unter der gleichen URL wie der Rest der Webseite liegt?
du meinst unter der gleichen Domain. Und nein, so dumm ist die Frage gar nicht.
Es werden bestimmte Inhalte verlangt, und leichte Erreichbarkeit dieser Inhalte. Aber gleiche URL? Dazu finde ich nichts.
Ist mir auch nicht bekannt. Und ich habe das tatsächlich schon gesehen, dass das Impressum unter einer anderen Domain lag, weil der Betreiber mehrere Domains unterhalten hat.
Das heißt natürlich noch nicht, dass das so korrekt ist, könnte aber ein Hinweis sein.
Ciao,
Martin
Hi,
du meinst unter der gleichen Domain. Und nein, so dumm ist die Frage gar nicht.
Was, wenn die Inhalts-Domain erreichbar ist, die Impressum-Domain aber nicht (DNS-Problem, …).
Dann wäre die Inhalts-Site ohne Impressum online …
cu,
Andreas a/k/a MudGuard
Hallo MudGuard,
das wäre bei einem iframe-Impressum aber genauso der Fall.
Wenn man für jede Seite, die das betrieben wird, die Server in der Hand hat und dort PHP laufen lassen kann, könnte man auch über einen file_get_contents das Impressum vom zentralen Server laden und im jeweiligen Web als Temp-Datei speichern. Oder vielleicht besser mit cURL, sofern verfügbar, da hat man mögliche Timeouts besser im Griff.
Wenn der Hintergrund-Download fehlschlägt, gibt man einfach die zwischengespeicherte Temp-Datei aus. Das Impressum ist dann möglicherweise nicht ganz aktüll, aber immerhin fehlt es nicht.
Rolf
gudn tach!
ja, sowas hatte ich mir auch schon ueberlegt. es wuerde erfordern, dass
meine hoffnungs war, dass es was einfacheres gibt.
prost
seth
Hello,
meine hoffnungs war, dass es was einfacheres gibt.
Vier Maß und eine Runde Copy & Paste. ;-P
Glück Auf
Tom vom Berg
gudn tach!
es ist ein grundsaetzliches problem, dass bei seiten, die offline sind, meist weder impressum noch DSE vorhanden sind. ich hab letztes jahr im mai vergeblich im www nach rechtlichen vorgaben dazu gesucht.
grundsaetzlich wird ja selbst bei einem 500er noch die ip-adresse (also ein personenbezogenes datum) samt timestamp im error.log gespeichert. somit muesste da nach strenger auslegung der dsgvo wohl eigentlich auch eine datenschutzerklaerung hin.
andererseits ist es ja an sich gaga, dass man dem visitor nun per DSE sagen muss, dass man seine (meist eh nur temporaere) ip-adresse kennt. wenn man per telefon angerufen wird, sagt man dem anrufer ja auch nicht, dass man dessen nummer jetzt kennt. aber ok, das ist vielleicht einfach ein schwachpunkt der dsgvo, der kuenftig noch geklaert wird, oder ich habe sie in diesem punkt einfach noch nicht verstanden.
solange die DSE bzw. das impressum nur kurz nicht erreichbar sind, also die downtimes nur temporaer und nicht gehaeuft auftreten, wird einem -- so meine hoffnung/vermutung (IANAL) -- kein richter daraus einen strick drehen.
prost
seth
gudn tach!
die frage, wie "nah" eine DSE der website sein muss, hatte ich mir auch schon mal gestellt und alleine nicht beantworten koennen. im gespraech mit einem juristen (der sich gerade in dsgvo-zeugs reingearbeitet hat, allerdings leider zu wenig web-technik-verstaendnis mitbrachte) hat sich mir die vermutung aufgedraengt, dass diese technische frage, die leute wie wir automatisch stellen, dem juristen bzw. der dsgvo im zweifel egal ist -- es laeuft wohl auf die alte frage nach den grenzen einer website hinaus (also: was gehoert noch dazu und was nicht?).
IANAL und ich denke: wichtig ist nicht, wo die DSE sich physikalisch bzw. addresstechnisch befindet, sondern wichtig ist nur, ob es fuer den visitor hinreichend deutlich ist, dass sie zu jener website gehoert, auf der er sich befindet (bzw. glaubt zu befinden). solange die zugehoerigkeit deutlich ist und die DSE inhaltlich die rechtlichen anforderungen erfuellt, wird einem da vermutlich auch niemand einen strick draus drehen. (analog halte ich es beim impressum.)
zum technischen problem, das MudGuard aufwirft, antworte ich dort.
prost
seth
Beim Impressum gab es mal die Regel, dass "zentrale Impressumsseiten" angeben müssen, für welche Webseiten ("domains") diese gelten, damit "fuer den visitor hinreichend deutlich ist, dass sie zu jener website gehoert" von wo er das Impressum aufgerufen hat.
Für Datenschutzerklärungen dürfte das selbe gelten.
Es gilt:
"Gummiparagraph" → Klärung den Gerichten überlassen → "Hohe See, Gottes Hand".
Also: Lieber nicht, wenns denn nicht viel kostet. Man kann ja auch Teile einer Webseite von einer zentralen Ressource laden...
Hallo X11,
Beim Impressum gab es mal die Regel, dass "zentrale Impressumsseiten" angeben müssen, für welche Webseiten ("domains") diese gelten, damit "fuer den visitor hinreichend deutlich ist, dass sie zu jener website gehoert" von wo er das Impressum aufgerufen hat.
Hast du da eine Quelle?
Für Datenschutzerklärungen dürfte das selbe gelten.
oder dafür?
Also: Lieber nicht, wenns denn nicht viel kostet. Man kann ja auch Teile einer Webseite von einer zentralen Ressource laden...
Könnte man. Aber muss man?
Gruss
Henry
Beim Impressum gab es mal die Regel, dass "zentrale Impressumsseiten" angeben müssen, für welche Webseiten ("domains") diese gelten, damit "fuer den visitor hinreichend deutlich ist, dass sie zu jener website gehoert" von wo er das Impressum aufgerufen hat.
Hast du da eine Quelle?
Nur meine Erinnerung an ein Urteil und ein Beispiel. (Das Beispiel hat mit dem Urteil nichts zu tun). Nein, ich habe das Urteil, respektive den Bericht darüber, nicht wieder gefunden.
Könnte man. Aber muss man?
Wir müssen alle sterben. Irgendwann.
Warum nicht gleich alles zentralisieren? Das schreit doch direkt nach einem multidomainfähigem Framework. MFG
gudn tach!
grundsaetzlich waere sowas wuenschenswert. leider habe ich das in diesem fall nicht in der hand.
prost
seth
grundsaetzlich waere sowas wuenschenswert. leider habe ich das in diesem fall nicht in der hand.
Fakt ist, daß Deine Domains in zweistelliger Anzahl schon irgendwie miteinander zusammenhängen. Sonst hättest Du ja die Frage nicht gestellt. Und weil das so ist, kann es auch nur eine Antwort geben. Und daraus ergeben sich, neben einer zukunftsorientierten und nachhaltigen Skalierbarkeit, sicher auch noch weitere Synergieeffekte. MFG
Hallo Email,
mal angenommen, man würde deins verwenden. Würdest Du darin Wordpress- und Joomla Sites integrieren können?
Ich kann mir nämlich vorstellen, dass ein Neuschrieb dieser in Fertig-CMS verfassten Inhalte nicht vorgesehen ist (weil zu teuer).
Rolf
Genau! Es kommt darauf an die Idee zu begreifen. Und gut von Dir, die Kostenfrage anzusprechen, denn langfristig ist ist eine Multi-Domain-Lösung ohnehin wirtschaftlicher. MFG
Hallo,
Es kommt darauf an die Idee zu begreifen.
Ein einfaches „Nein“ wäre kürzer gewesen…
Gruß
Kalk
Hallo Tabellenkalk,
dann müsste er doch - wie von mir angeregt - zugeben, dass der Ideenvektor zwar auf der Ziel gerichtet, aber leider falschrum orientiert ist.
Rolf
Hi @Rolf B
mal angenommen, man würde deins verwenden. Würdest Du darin Wordpress- und Joomla Sites integrieren können?
Selbstverständlich. Mein FW gibt es auch in PHP. MFG
Hello,
eine RSS-Lösung sollte es bringen. Bau dir einen RSS-Loader, der die Daten für dielokalen Seiten immer aktuell abfragt und lokal ersetzt, wenn sich etwas geändert hat.
Solange keine Verbindung zu neuen Daten besteht, wird immer die lokale Kopie angezeigt.
Glück Auf
Tom vom Berg
gudn tach!
mit RSS habe ich mich noch nie befasst. verstehe ich es richtig, dass ich dafuer eine serverseitige scriptsprache benoetigen wuerde und es somit eine variante der loesung von Rolf B waere?
prost
seth
Hallo
mit RSS habe ich mich noch nie befasst. verstehe ich es richtig, dass ich dafuer eine serverseitige scriptsprache benoetigen wuerde und es somit eine variante der loesung von Rolf B waere?
Prinzipiell ja, auch wenn der Weg des Zugriffs technisch gesehen ein anderer wäre.
Tschö, Auge
Hello,
gudn tach!
mit RSS habe ich mich noch nie befasst. verstehe ich es richtig, dass ich dafuer eine serverseitige scriptsprache benoetigen wuerde und es somit eine variante der loesung von Rolf B waere?
Das nehme ich mal stark an. Aber wenn Wordpress im Spiel ist, sollte doch auch PHP laufen. Da könntest Du das dann mif der Prepend-Page-Option erledigen.
Glück Auf
Tom vom Berg
Moin,
welche alternativen loesungen koennten sinnvoll sein?
Da *.css und *.js Dateien von fremden Servern geladen werden können (ich nutze das bei Landkarten), kannst du Texte mit denen einbauen.
Server example-a.com
MudGuard
Tabellenkalk
derdicki<link rel=stylesheet href="http://example-b.com/css/dsgo.css">
...
<div id="fremdtext"></div>
Datei http://example-b.com/css/dsgo.css
#fremdtext:after {
content: "Hallöchen, hier fremder Text"
}
Getestet, funzt.
Gruß, Linuchs
Frage: Wenn ich Text von einer anderen Domain per Javascript einfüge und der Leser hat JS abgeschaltet, ist das ein rechtliches Problem?
Meine CSS-Lösung habe ich weiter getestet. HTML-Tags wie <p> oder <br> werden nicht ausgeführt.
Zumindest der FF akzeptiert Zeilenumbrüche in der Form \A kombiniert mit pre-wrap:
#fremdtext:before {
content: "Hallöchen, hier Text vom Server remso.eu";
display: block;
margin-bottom: .5em;
}
#fremdtext:after {
content: "Mehr Text vom Server remso.eu\AZeile 2\A\AZeile 3";
display: block;
margin-bottom: .5em;
white-space: pre-wrap;
}
Linuchs
Hallo,
Frage: Wenn ich Text von einer anderen Domain per Javascript einfüge und der Leser hat JS abgeschaltet, ist das ein rechtliches Problem?
vor einigen Jahren war die mehrheitliche Meinung noch "Ja". Ich bin immer noch der Meinung, denn die entscheidenden Informationen müssen meiner Ansicht nach auch ohne optionale Techniken verfügbar sein. Damals galt die Devise, dass ein nur mit Javascript erreichbares Impressum als nicht vorhanden gilt.
Heute hat sich das, glaube ich, sehr stark verschliffen.
Meine CSS-Lösung habe ich weiter getestet. HTML-Tags wie
<p>oder<br>werden nicht ausgeführt.
Natürlich nicht. Der Wert der content-Eigenschaft ist per definitionem nur Text, nicht HTML.
Ciao,
Martin
gudn tach!
Frage: Wenn ich Text von einer anderen Domain per Javascript einfüge und der Leser hat JS abgeschaltet, ist das ein rechtliches Problem?
IANAL; ich wuerde darauf achten, dass keine informationen durch gaengige filtermechanismen ausgeblendet werden, also z.b. ad-blocker oder js-filter fuer bestimmte anwendungsszenarien (z.b. tracking und ad-networks). nicht hinzurechnen wuerde ich sowas wie greasemonkey, denn damit kann sowieso alles ausgehebelt werden.
so hatte es mir auch mal ein datenschutzexperte erklaert/bestaetigt.
prost
seth
Hej Linuchs,
#fremdtext:after { content: "Hallöchen, hier fremder Text" }Getestet, funzt.
Mit einem Screenreader? Mit eigenem Nutzer-CSS?
Oder wie waren die Testbedingungen?
Ich denke, du weißt, wo ich drauf hinaus will: nicht jeder sitzt an Deinem Rechner.
"Getestet, funzt" sollte man nicht so leichtfertig behaupten.
😉
Kurz gesagt: Inhalte gehören ins HTML.
Marc
Hallo seth,
ich weiß nicht ob das rechtskonform ist, ich nutze aber für den gleichen Fall eine seperate Domain. Einige meiner Projekte enthalten den Link dorthin und so komme ich ohne Einbindung oder sonstwas aus. Es handelt sich allerdings alles um Unterprojekte unter einer gemeinsamen Dachfirma. Wenn das aber nicht so wäre, müsste die Datenschutzvereinabrung dennoch für alle gelten, weil wie ich hier schon mal angefragt habe, es genau so gemacht habe, dass ich eigentlich alles abdecke, obwohl ich nahezu nichts davon wirklich nutze. Schreckt ja auch offensichtlich keine User ab, die akzeptieren eh alles, einer der Gründe warum diese DSGVO sachen auch für unsinnige Verpflichtung halte. Man könnte auch reinschreiben, "durch den Besuch unserer Seite, stellen Sie ihre Pc-gebunden Infrastrukturen und Datenbestände dem Inhaber dieser Webseite zur exklusiven Verfügung". Auch das würden die Leute überlesen und bestätigen, hauptsache sie haben ihre Ruhe.
Gruss
Henry
Hallo,
Schreckt ja auch offensichtlich keine User ab, die akzeptieren eh alles, einer der Gründe warum diese DSGVO sachen auch für unsinnige Verpflichtung halte.
ja, das ist auch mein Eindruck.
Man könnte auch reinschreiben, "durch den Besuch unserer Seite, stellen Sie ihre Pc-gebunden Infrastrukturen und Datenbestände dem Inhaber dieser Webseite zur exklusiven Verfügung". Auch das würden die Leute überlesen und bestätigen, hauptsache sie haben ihre Ruhe.
Das ist so ähnlich wie bei Fehlermeldungen, die ein Programm dann und wann produziert. Kaum einer achtet darauf oder liest sie überhaupt. Wenn meine Mutter anruft und von irgendeinem Problem am PC berichtet, und ob ich nicht bitte mal danach schauen könnte ... Nach zwei, drei Rückfragen erfahre ich dann, dann zufällig, dass da eine Fehlermeldung aufgepoppt ist. "Und was stand da?", frage ich dann, und sie antwortet: "Keine Ahnung, ich hab's einfach weggeklickt."
Ich glaube, dieses Verhalten entspricht durchaus einer Mehrheit der Nutzer.
So long,
Martin
gudn tach!
die direkte verlinkung dessen, was aktuell im iframe angezeigt wird, hatte ich auch schon im sinn.
problem dabei ist vor allem das layout:
entweder man nutzt target="_blank", was ich eigentlich versuche zu vermeiden, weil es den user (der selbst entscheiden koennen soll, wann er etwas in einem neuen tab oeffnet) unnoetigerweise bevormundet.
oder man verlaesst die website und hat dann nicht mehr das navigationsmenue parat.
aber je mehr ich darueber nachdenke, tendiere ich immer mehr zur target-blank-loesung, weil sie die wenigste arbeit macht und ohne jedwede scripts auskommt.
prost
seth
Hej seth,
aber je mehr ich darueber nachdenke, tendiere ich immer mehr zur target-blank-loesung, weil sie die wenigste arbeit macht und ohne jedwede scripts auskommt.
Warum nicht "zweigleisig" - die Target-blank-Methode auf statischen Seiten, eine dynamische Lösung auf anderen.
So wie ich das verstanden habe willst du doch gar nicht überall ein identisches Impressum?
Dan wäre vielleicht sogar folgender Weg am sinnvollsten. Du pflegst die Textbausteine zentral, z.B. mit einer einfachen DB-Maske.
Mit einem Skript holst du die überall gleichen Texte und die unterschiede abhängig vom Namen der Site, auf der das Impressum erscheinen soll und legst sie auf einem zentralen Server ab.
Du kannst dann in den variablen Bereich sogar das CSS der jeweiligen Seite importieren und so vermeiden, dass man komplett aus dem Design rausfällt.
Außerdem kannst du zwei drei Links einbauen (zurück zur letzten Seite per JavaScript-Verweis auf den Referrer, zur Startseite des Zielangebotes, zur Suchseite, so ähnlich, wie man es für eine gute 404-Seite machen würde).
Die so erstellten Seiten speicherst du unter imprint-site1.html usw ab und kannst diese im Ziel verlinken, wie du willst. Egal ob handgestrickte Anwendung, Wordpress oder statische Seite. Du kannst das Impressum nun einbinden wie immer du möchtest. Auch ins Menü.
Das lässt sich auf Dauer noch verfeinern. Du kannst z.B. die Zielseiten parsen und die erste Ebene des Menüs mit in das Impressum aufnehmen und andere Verbesserungen Schritt für Schritt umsetzen, wenn mal Zeit dafür ist, so dass man als Besucher bald nur noch an der Adresse merkt, dass die Datei imprint-xxx.html irgendwo zentral abgelegt ist. S kannst du individualisierten sogar für Eure Social-Media-Aktivitäten erstellen, alles zentral pflegen und dennoch auf notwendige oder aufhübschende Unterschiede der aufrufenden Seiten eingehen.
Marc
gudn tach!
aber je mehr ich darueber nachdenke, tendiere ich immer mehr zur target-blank-loesung, weil sie die wenigste arbeit macht und ohne jedwede scripts auskommt.
Warum nicht "zweigleisig" - die Target-blank-Methode auf statischen Seiten, eine dynamische Lösung auf anderen.
die dynamischen sind nur ein paar wenige. muss mal schauen, ob der aufwand (sowas fuer joomla und wordpress zu erstellen) dafuer lohnt.
So wie ich das verstanden habe willst du doch gar nicht überall ein identisches Impressum?
richtig. sowohl impressum als auch DSE sind parametriert. ueber GET-parameter wird z.b. mitgegeben, ob videos von irgendeiner plattform eingebunden werden, wie das projekt heisst, wie der verantwortliche heisst, ob kontaktformulare existieren etc. ausserdem gibt's einen parameter fuer die sprache und ein paar fuer die formatierung (farben, schriften).
Dan wäre vielleicht sogar folgender Weg am sinnvollsten. Du pflegst die Textbausteine zentral, z.B. mit einer einfachen DB-Maske.
Mit einem Skript holst du die überall gleichen Texte und die unterschiede abhängig vom Namen der Site, auf der das Impressum erscheinen soll und legst sie auf einem zentralen Server ab.
ja, grundsaetzlich hatte ich mir bereits die frage gestellt, ob ich die spezialisierung zentral vornehme (was deinem vorschlag entspraeche) oder der einbindenden website ueberlasse.
entschieden habe ich mich fuer letzteres, weil die jeweiligen website-verantwortlichen dann alles in ihrem CMS direkt aendern koennen. eine maske, die den langen url ausspuckt, kann ich, wenn man zeit ist, immer noch zusaetzlich bauen.
Du kannst dann in den variablen Bereich sogar das CSS der jeweiligen Seite importieren und so vermeiden, dass man komplett aus dem Design rausfällt.
genau, das mach ich bereits, allerdings nur rudimentaer. grafiken, menues und sowas werden nicht angezeigt.
Außerdem kannst du zwei drei Links einbauen (zurück zur letzten Seite per JavaScript-Verweis auf den Referrer, zur Startseite des Zielangebotes, zur Suchseite, so ähnlich, wie man es für eine gute 404-Seite machen würde).
die idee mit einem history.back()-link kam mir gestern beim lesen der forums-antworten ebenfalls. aber du hast natuerlich recht, man koennte das dann auch gleich mit richtigen links machen. guter punkt!
Die so erstellten Seiten speicherst du unter imprint-site1.html usw ab und kannst diese im Ziel verlinken, wie du willst. Egal ob handgestrickte Anwendung, Wordpress oder statische Seite. Du kannst das Impressum nun einbinden wie immer du möchtest. Auch ins Menü.
bin mir nicht sicher, ob ich den punkt richtig verstanden habe. du wuerdest das impressum (und die DSE) einmalig generieren und dann statisch einbinden? das will ich eher vermeiden, weil 1. die zentralen bestandteile sich hin und wieder aendern und 2. bestandteile der jeweiligen website sich aendern koennen, sodass andere bestandteile aus dem DSE-baukasten geladen werden sollen.
Das lässt sich auf Dauer noch verfeinern. Du kannst z.B. die Zielseiten parsen und die erste Ebene des Menüs mit in das Impressum aufnehmen
grundsaetzlich ja, allerdings sind in meinem fall dafuer die websites zu heterogen, um diesen aufwand zu betreiben.
vielen dank fuer die vielen anregungen. :-)
prost
seth
Hej seth,
vielen dank fuer die vielen anregungen. :-)
Habe nur "laut" gedacht. Freut mich, wenn es hilfreich ist.
Ich versuche noch mal zusammenzufassen:
Du hast viele statische Seiten, einige dynamische.
Die dynamischen Seiten sollte Teile zum Impressum dazu liefern, die von Redakteuren in deren gewohnter Umgebung geliefert werden sollen.
Nach wie vor handelt es sich bei der Ausgabe um reine Textbausteine. die Frage ist nur woher nehmen und wie ausgeben.
Idee: Die Textbausteine gibst jemand über eine online-Erfassung in eine DB ein - einen Teil der Daten holt das verarbeitende Skript aus der DB der Content-Management-System?!?
Marc
gudn tach!
Schreckt ja auch offensichtlich keine User ab, die akzeptieren eh alles, einer der Gründe warum diese DSGVO sachen auch für unsinnige Verpflichtung halte.
ich finde die dsgvo eigentlich ziemlich gut, nur in teilen nicht streng genug (ausnahme: das aufklaeren ueber das speichern der ip-adresse halte ich fuer ueberfluessig); sie wurde halt zu naiv bzw. nicht hinreichend wasserfest formuliert. eine erwartung war, dass websites ihre unnuetzen und nervigen 3rdparty-einbindungen nun einfach endlich rausschmeissen. stattdessen haben sich praktisch alle (selfhtml.org ist eine ausnahme!) nach und nach auf die noch nervigeren cookie-banner gestuerzt, die nach meinem ermessen eigentlich nicht im sinne der dsgvo sind, aber halt auch nicht dagegen verstossen.
in der folge schimpfen die user auf die dsgvo und natuerlich wieder mal auf die EU. fcbook und co basteln cookie-banner und zucken mit den schultern. die dsgvo-begruender werden sich denken: "wtf!?" und wir web-nerds koennen uns zwischen langsamem kopfschuetteln und facepalm entscheiden.
prost
seth
n'Ahmd,
ich finde die dsgvo eigentlich ziemlich gut, nur in teilen nicht streng genug (ausnahme: das aufklaeren ueber das speichern der ip-adresse halte ich fuer ueberfluessig); sie wurde halt zu naiv bzw. nicht hinreichend wasserfest formuliert.
der DSGVO liegt das Bestreben zugrunde, EU-weit einheitliche Datenschutz-Standards zu schaffen. Diese Vereinheitlichung ist eigentlich eine gute Sache; in DE haben wir aber auch schon seit Jahren ein Datenschutzgesetz, das deutlich weiter geht als die DSGVO.
Insofern wird die DSGVO in DE total überbewertet, weil unser nationales BDSG eigentlich eine Obermenge davon ist, die in Teilen sogar noch weiter geht. Deswegen ist der Hype um diese Verordnung hierzulande im Grunde Blödsinn.
eine erwartung war, dass websites ihre unnuetzen und nervigen 3rdparty-einbindungen nun einfach endlich rausschmeissen.
Was meinst du damit?
stattdessen haben sich praktisch alle (selfhtml.org ist eine ausnahme!) nach und nach auf die noch nervigeren cookie-banner gestuerzt, die nach meinem ermessen eigentlich nicht im sinne der dsgvo sind, aber halt auch nicht dagegen verstossen.
Du meinst diese omnipräsenten Banner, auf denen irgendwas über Cookies steht, dem man erstmal zustimmen soll? Dagegen gibt's zumindest für Firefox die Extension "I don't care about cookies", die solche Nervensägen automatisch beseitigt. Wenn man dann noch einstellt, dass beim Beenden des Browsers sowieso alle Cookies gelöscht werden, ist die Welt größtenteils wieder in Ordnung.
und wir web-nerds koennen uns zwischen langsamem kopfschuetteln und facepalm entscheiden.
Genau. Und Millionen von Internet-Nutzern fragen sich:
Was soll der Scheiß? Lasst mich gefälligst in Ruhe!
Ciao,
Martin
gudn tach!
Insofern wird die DSGVO in DE total überbewertet, weil unser nationales BDSG eigentlich eine Obermenge davon ist, die in Teilen sogar noch weiter geht. Deswegen ist der Hype um diese Verordnung hierzulande im Grunde Blödsinn.
naja, die maximalen strafen wurden meines wissens deutlich erhoeht, was fuer viele unternehmen einen unterschied ausmacht. das BDSG hatte kaum jemanden interessiert -- leider.
eine erwartung war, dass websites ihre unnuetzen und nervigen 3rdparty-einbindungen nun einfach endlich rausschmeissen.
Was meinst du damit?
z.b. das einbetten von fcbook-buttons direkt von fcbook, was z.b. durch nutzen des shariff verbessert werden kann. oder das einbinden von google-fonts. eine erwartung war, dass sowas aufhoert und die betreiber auf datenschutzfreundlichere loesungen umschwenken.
stattdessen haben sich praktisch alle (selfhtml.org ist eine ausnahme!) nach und nach auf die noch nervigeren cookie-banner gestuerzt, die nach meinem ermessen eigentlich nicht im sinne der dsgvo sind, aber halt auch nicht dagegen verstossen.
Du meinst diese omnipräsenten Banner, auf denen irgendwas über Cookies steht, dem man erstmal zustimmen soll?
genau. sie heissen cookie-banner, man stimmt dabei allerdings nicht nur der verwendung von cookies, sondern in der regel der kompletten DSE zu, wo dann z.b. drinsteht, dass die halbe welt darueber informiert wird, wie lange du auf jener website verweilst.
Dagegen gibt's zumindest für Firefox die Extension "I don't care about cookies", die solche Nervensägen automatisch beseitigt. Wenn man dann noch einstellt, dass beim Beenden des Browsers sowieso alle Cookies gelöscht werden, ist die Welt größtenteils wieder in Ordnung.
ja, wenn's denn nur um die cookies ginge ...
prost
seth
Hallo,
das BDSG hatte kaum jemanden interessiert -- leider.
das liegt aber vor allem daran, dass es wenig bekannt ist/war und kaum jemals eingeklagt wurde - weder von amtlicher, noch von kommerzieller Seite.
Aber wenn ich irgendwelchen Unternehmen gegenüber mit juristischen Konsequenzen im Sinne des BDSG gedroht habe, dann haben die meistens mit eingekniffenem Schwanz klein beigegeben.
eine erwartung war, dass websites ihre unnuetzen und nervigen 3rdparty-einbindungen nun einfach endlich rausschmeissen.
Was meinst du damit?
z.b. das einbetten von fcbook-buttons direkt von fcbook, was z.b. durch nutzen des shariff verbessert werden kann. oder das einbinden von google-fonts.
Ach, solches Ungeziefer. Verstehe.
sie heissen cookie-banner, man stimmt dabei allerdings nicht nur der verwendung von cookies, sondern in der regel der kompletten DSE zu, wo dann z.b. drinsteht, dass die halbe welt darueber informiert wird, wie lange du auf jener website verweilst.
Ja, okay. Wobei die nicht feststellen können, wie lange ich deren Webseite betrachte, sondern nur, dass ich sie mal aufgerufen habe.
Dagegen gibt's zumindest für Firefox die Extension "I don't care about cookies", die solche Nervensägen automatisch beseitigt. Wenn man dann noch einstellt, dass beim Beenden des Browsers sowieso alle Cookies gelöscht werden, ist die Welt größtenteils wieder in Ordnung.
ja, wenn's denn nur um die cookies ginge ...
Naja, diese Extension geht in erster Linie gegen die offensichtliche Belästigung der Nutzer vor.
Ciao,
Martin
Hallihallo!
sie heissen cookie-banner, man stimmt dabei allerdings nicht nur der verwendung von cookies, sondern in der regel der kompletten DSE zu, wo dann z.b. drinsteht, dass die halbe welt darueber informiert wird, wie lange du auf jener website verweilst.
Ja, okay. Wobei die nicht feststellen können, wie lange ich deren Webseite betrachte, sondern nur, dass ich sie mal aufgerufen habe.
Durch den Einsatz von onunload und einem kleinen XHR-Requests liesse sich aus Das feststellen.
Beste Grüsse, Tobias Hahner
Hej Henry,
ich weiß nicht ob das rechtskonform ist, ich nutze aber für den gleichen Fall eine seperate Domain. Einige meiner Projekte enthalten den Link dorthin und so komme ich ohne Einbindung oder sonstwas aus. Es handelt sich allerdings alles um Unterprojekte unter einer gemeinsamen Dachfirma. Wenn das aber nicht so wäre, müsste die Datenschutzvereinabrung dennoch für alle gelten, weil wie ich hier schon mal angefragt habe, es genau so gemacht habe, dass ich eigentlich alles abdecke, obwohl ich nahezu nichts davon wirklich nutze.
Das ist keine gute Idee. Wenn du da zum Beispiel behauptest Nutzerdaten zu sammeln und jemand sagt nun, dass du seine Daten Löschen sollst und er möchte einen Nachweis. Wie willst du den Nachweis liefern, dass nicht vorhandene Daten gelöscht wurden?!?
Schreckt ja auch offensichtlich keine User ab,
Wie hast du herausgefunden, dass keine User (also nicht ein einziger) den Besuch der von dir betreuten Seiten abbrechen nach Lektüre all der vielen Dinge, die du in deiner DSE hast.
die akzeptieren eh alles, einer der Gründe warum diese DSGVO Sachen auch für unsinnige Verpflichtung halte.
Die DSGVO ist nicht für die Gleichgültigen gemacht, sondern für die Leute, denen etwas an ihren Rechten liegt.
Man könnte auch reinschreiben, "durch den Besuch unserer Seite, stellen Sie ihre Pc-gebunden Infrastrukturen und Datenbestände dem Inhaber dieser Webseite zur exklusiven Verfügung". Auch das würden die Leute überlesen und bestätigen, hauptsache sie haben ihre Ruhe.
Mal abgesehen davon, dass deine Konkurrenz über so einen Honigtopf herfallen könnte (d.h. eine Meldung machen könnte).
Ein einziger interessierter Mensch, der da drüber stolpert kann im schlimmsten Fall reichen, um den ersten Stein für eine Shitstorm-Lawine ins Rollen zu bringen.
Ja die Mehrheit ist gleichgültig (geht auch gar nicht anders, schließlich kann man sich nicht um alles kümmern, was sinnvoll ist. Dafür gibt es viel zu viel), aber daraus den Schluss zu ziehen es interessiert niemanden, kann dich in Teufels Küche bringen.
Manchmal ist das nur eine Frage der Zeit.
Marc