Newsletter URL´s Maskieren
Rodger
- php
Hallo,
zur Erfolgskontrolle unseres Newsletters möchten wir Links tracken. Hierfür sollen Links wie
http://example.com/meinbeitrag.html
getrackt werden mit diversen zusatzparametern zur Analyse des Newsletters
http://newsletter.example.com/weiterleitung.php?url=http://example.com/meinbeitrag.html&newsletter=2014-04&designversion=4
. Unser Problem ist, das solche URL's weder gut aussehen, noch vor Spielereien der Nutzer einen Schutz bieten. Daher war unser erster Ansatz. Wir fügen alles in einen BASE64 Code ein somit haben wir eine kleine Hürde geschaffen (Mit Modrewrite gibt es auch eine richtig schöne URL :
http://newsletter.example.com/weiterleitung/c2VsZmh0bWwub3JnDQo=
Leider sind im Base64 Code auch Zeichen wie "/" vorgesehen. Hierdurch wird natürlich unser Modrewrite aus der Bahn geworfen zudem funktioniert unser XSS Filter:
preg_replace('/[^-a-zA-Z0-9_]/', '', $safe2)
nicht. Gibt es eine einfache Methode zu verschlüsseln und wieder zu entschlüsseln? Der Nutzer muss ja nicht unbedingt wissen wohin die Reise geht...
Hello,
die Abforderung der Dokumente würde ich dann lieber ins "tolerante Ausland" verlegen.
Und da heißt der Link dann z. B.:
www.international-document-service.center/your_comp_name/ab12789dff131224ccfdff131224ccf.pdf
Du könntest mal versuchen, die Firma und den Server für die Domain in Guantanamo oder ähnlich unterzubringen. Da ließe sich bestimmt Geschäft drau machen. Und zum nächsten Backbone der NSA ist es dann auch nicht allzu weit, so dass Du bestimmt volle Rückendeckung von Obammel bekommen wirst.
Und von dem Server aus diesem Land sollte das Dokument dann tunlichst auch ausgeliefert werden. Ob der Server in diesem Land dann Tracking betreibt, das kannst Du als 'your_com_name' nicht wissen.
Jedenfalls ist das, was Du vor hast in DE ohne substantiierte Einwilligung des Clients nicht zulässig.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Jedenfalls ist das, was Du vor hast in DE ohne substantiierte Einwilligung des Clients nicht zulässig.
Hallo Tom,
das ist bei allen großen Newsletterbetreibern (auch in Deutschland) gang und gebe. Gerade A/B Testing bei Designvarianten ist doch Marktüblich.
Wie sonst sollte man auch Öffnungsraten und co bestimmen: https://www.google.de/search?q=newsletter+öffnungsrate
Hello,
Jedenfalls ist das, was Du vor hast in DE ohne substantiierte Einwilligung des Clients nicht zulässig.
Hallo Tom,
das ist bei allen großen Newsletterbetreibern (auch in Deutschland) gang und gebe. Gerade A/B Testing bei Designvarianten ist doch Marktüblich.
Wir werden demnächst eine Gesetzesänderung bekommen, bzw. diverse Durchführungsbestimmungen für die bereits lange geltenden Gesetze. Das ist die Folge des überzogenen Versuchs der Regierung, sich mittles "Anti-Kinder-Porno-Gesetzen" noch weiter ermächtigen zu lassen, Schindluder mit unseren Daten treiben zu können.
Das EU-Parlament ist da nun merkwürdiger Weise mal ganz anderer Meinung.
Ich verstehe das Hin und Her zwar auch nicht mehr, aber USER-Tracking ohne dessen Einwilligung ist schon länger strikt verboten und wird demnächst vermutlich demnächst als Offizialdelikt behandelt werden.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hello,
kleiner Nachtrag:
In deinem LAN könntest Du doch mal einen Versuchsaufbau gemäß meiner Beschreibung erstellen.
Den darfst Du dann natürlich nicht ins WAN/GAN verschieben :-P
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Hi,
Leider sind im Base64 Code auch Zeichen wie "/" vorgesehen. Hierdurch wird natürlich unser Modrewrite aus der Bahn geworfen
Na dann passt euer Rewriting halt entsprechend an.
zudem funktioniert unser XSS Filter:
preg_replace('/[^-a-zA-Z0-9_]/', '', $safe2)
nicht.
Der ist ja auch unsinnig.
Was hat bspw. ein simpler Slash an sich denn mit XSS zu tun?
MfG ChrisB
http://newsletter.example.com/weiterleitung/c2VsZmh0bWwub3JnDQo=
Überleg Dir das genau:
So einen Mist klicke ich gewiss nicht an. Von dem Newsletter verabschiede ich mich schneller als Deine Server tracken können.
Und ich bin nicht allein.
Jörg Reinholz