Framebreaker-Test bei Powerlinks

[Miro]

Hi,

ist es eventuell möglich, dass man nach Öffnen des PL-Pop-Ups, eine wahrlos generierte und an den Link gehängte ID überprüft (alle 10 Sekunden bzw. einmal am Ende)? Dazu müsste dann, so denke ich mir, ein neues Browserfenster (oder auch ein Pop-Up) geöffnet werden und wie jetzt der PL im gleichen Tab/ Registerkarte angezeigt werden.

Ich hab in Erinnerung, dass ich schonmal mit JS Instanzen mit ID geöffnet habe und später abgefragt habe, ob sie existieren oder nicht. Waren damals nur Spielereien. Hab dann eine neue Instanz geöffnet, wenn keine mehr da war.
Bei den PL`s kann man ja dann im PL-Pop-Up eine Meldung bringen "Keine Berechtigung, da Vergütungsfenster geschlossen wurde" oder so. Läuft die Prüfung fehlerfrei durch, dann erfolgt natürlich auf herkömmliche Weise die Vergütung des PL`s.

Das ich mit JS "rumgespielt" habe ist jedoch schon eine Weile her. Daher kann ich nicht sagen, ob das heutzutage noch zu realisieren ist. Wäre aber meiner Meinung nach eine Möglichkeit den Framebrechern aus dem Weg zu gehen.

Ich hoffe ich konnte helfen oder einen Anstoss für den richtigen Weg geben.

MfG

Miro

 

[sonnenhexer]

Hallo Lukas,

bei Reading4money (nutzt Jagusch-Script mit Addons) werden Framebrecher über ein Popup vergütet, es geht also. Im Popup wird auch runtergezählt.

LG

Michael

 

[klamm]

Hallo Lukas,

bei Reading4money (nutzt Jagusch-Script mit Addons) werden Framebrecher über ein Popup vergütet, es geht also. Im Popup wird auch runtergezählt.

Aber merkt das Popup dann auch wenn Du die Seite closed?
(und stoppt die Vergütung)

 

[sonnenhexer]

Aber merkt das Popup dann auch wenn Du die Seite closed?
(und stoppt die Vergütung)

Ja. Ist mir nämlich schonmal passiert.

 

[DaPhreak]

Die beste Lösung wäre eine Realisierung der Powerlinks ohne den oberen Frame. Damit wären Framebrecher wieder erlaubt.... allerdings sehe ich anders momentan keine Möglichkeit, aus dem Popup heraus zu kontrollieren ob das Content-Fenster noch geöffnet ist.

Es reicht IHMO nicht mal aus zu prüfen, ob das Fenster noch auf ist. Wenn ich einfach im selben Fenster nen anderen Link ansurfe dürfte mir der ja auch nicht mehr vergütet werden. Das ist aber nicht unterscheidbar von einer Weiterleitung, die der beworbene Link macht, welche ja erlaubt werden soll (Framebrecher ist effektiv gesehen eine Weiterleitung: Link ändert sich halt).

Deshalb ist das meiner Meinung nach so nicht konsistent umsetzbar.

Lieber Framebrecher verbieten und geeignete Schutzmechanismen bauen.

JS-Freaks dürfen mich gerne korregieren.

Dürfen Dich auch Rechtschreibfreaks korrigieren?

*SCNR*

 

[klamm]

Dass man innerhalb des Fensters weiter surfen kann geht eh schon immer, denn wie Du schon sagtest: Die URL zu checken ist nicht sinnvoll. Ich probier mal was aus später.

 

[Djdjrjf8e]

Ich bin ja immer noch für eine Prüfsumme der aufgerufenen Datei und evtl. eingebundener JS-Scripts.

• Ist ein Framebrecher vorhanden gleich vor Freischaltung ablehnen
• Unterscheidet sich die Größe der Datei bei Aufruf des PL von der Prüfsumme Erneute Prüfung auf Framebrecher, ablehnen, wenn kein FB, neue Prüfsumme speichern und bei dyn. Seiten eine gewisse Größenänderung als Toleranz freigeben +- 1 - 2KB z.B.
• Als öfter erkannte gemeldete PL mit Framebrecher dauerhaft sperren

Wer Framebrecher einbaut, tut es entweder in der Webseite oder in einer eingebundenen JS-Datei --> Größenänderung der Dateien.
Wer dynamische Webseiten bewirbt, sollte nach möglichkeit eine statische Seite als Werbeseite bewerben, so schwierig ist das ja nun nicht..
Und man kann für diese Seite ja eine gewisse Größen-Toleranz nach erneuter Überprüfung freigeben..
Und wie schon erwähnt, wer dauerhaft als FB-Seite auffällt (sagen wir mal min. 2x pro beworbener URL/PL-Kampagne), deren Domain wird in eine blacklist aufgenommen und schon bei Versuch der Buchung eines PL darauf hingewiesen.

 

[klamm]

Gibt es heutzutage überhaupt noch eine statische Seite im Netz? Die Prüfsumme würde doch alleine schon durch ein anderes Banner/Shoutbox/Counter/etc kaputtgehen. Diese Variante finde ich noch unhaltbarer als einen URL-Check.

 

[Djdjrjf8e]

Gibt es heutzutage überhaupt noch eine statische Seite im Netz? Die Prüfsumme würde doch alleine schon durch ein anderes Banner/Shoutbox/Counter/etc kaputtgehen. Diese Variante finde ich noch unhaltbarer als einen URL-Check.

Warum sollte sie kaputt gehen?
Wenn Du nur den reinen HTML-Anteil der beworbenen Webseite bewertest, änder sich da meist nichts, da die meiste Werbung nur durch ein entsprechendes JS-Script durchgeführt wird, dessen Aufruf sich im HTML-Code ja nicht ändert.
Die Shoutbox ist ja meist auch ein eingebundenes JS-Script.

Und wenn die Toleranz einer Größen-Änderung kann man dann ja vorgeben..
vielleicht bei der Buchung angeben:
[ ] dyn. Seite [ ] statische Seite
wobei intern dann ein entsprechender Wert vorgegeben wird bzw. nachträglich angepasst werden kann..

Wieviele Seiten ändern denn wirklich ihre Größe, nachdem Sie denn ins PL-System eingebunden wurden?

Die meisten Seiten die ich gesehen habe waren im PL-Zeitraum eher statisch als dynamisch.

 

[DaPhreak]

Dass man innerhalb des Fensters weiter surfen kann geht eh schon immer, denn wie Du schon sagtest: Die URL zu checken ist nicht sinnvoll.

Stimmt, aber durch den Frame ist man schon etwas eingeschränkt. Ich kann natürlich weiterführende Links klicken aber das ist ja quasi "Nutzen des beworbenen Angebotes". Habe ich kein Frame ist es ein leichtes, eine komplett andere Adresse anzusurfen, was für mich ein qualitativer Unterschied ist. Der Frame bietet da ein bisschen mehr inhärenten "Schutz".

Wenn Du nur den reinen HTML-Anteil der beworbenen Webseite bewertest, änder sich da meist nichts, da die meiste Werbung nur durch ein entsprechendes JS-Script durchgeführt wird, dessen Aufruf sich im HTML-Code ja nicht ändert.
Die Shoutbox ist ja meist auch ein eingebundenes JS-Script.

Kann aber genauso gut durch PHP erzeugter dynamischer Content sein. Anderes Beispiel Weblog/Nachrichtenseiten: Mit jeder neu geschriebenen Eintrag ändert sich der HTML-Content erheblich.

Für manche Seiten würde das sicher funktionieren, aber einige würden immer durch das Raster fallen. Und ich glaube das primäre Ziel ist hier, eine voll automatisierte Lösung zu finden.

 

[Djdjrjf8e]

[...]
Kann aber genauso gut durch PHP erzeugter dynamischer Content sein. Anderes Beispiel Weblog/Nachrichtenseiten: Mit jeder neu geschriebenen Eintrag ändert sich der HTML-Content erheblich.

Für manche Seiten würde das sicher funktionieren, aber einige würden immer durch das Raster fallen. Und ich glaube das primäre Ziel ist hier, eine voll automatisierte Lösung zu finden.

Na, es geht ja nicht um den Inhalt sondern eher um die Größe der eigentlichen Seite, also eher ein KB-Vergleich statt einem MD5-Prüfsummenvergleich der, da geb ich recht, absolut sinnlos ist.

Und bei dynamischen Seiten kann man ja auch einen gewissen Toleranz- bzw. Schwellenwert festlegen, in der sich die Größe der Seite bewegen darf.

Und eine 100%-Lösung wird man nie finden, da ja nicht nur auf Framebrecher sondern auch auf Porn oder nicht Porn und andere sachen geprüft werden muss.

Gruß,

jiw

 

[molleonline]

Na, es geht ja nicht um den Inhalt sondern eher um die Größe der eigentlichen Seite, also eher ein KB-Vergleich statt einem MD5-Prüfsummenvergleich der, da geb ich recht, absolut sinnlos ist.

KB Vergleich ist ebenso absolut sinnlos.
1. Der Klammserver müsste dann bei jedem PL Aufruf die Inhalte des PL herunterladen und vergleichen => Ressourcenverschwendung.
2. Ehrliche Powerlinkbesteller, deren Content verändert wird (bei vielen steht es oft nicht in der Macht, grundlegenge Änderungen an der Seite zu verhindern, z.B. bei Reflinks), werden nachher ausgesperrt, jedoch die, die Framebrecher nutzen wollen, könnten nur durch 56 Byte an Code (0,056 KB) eben diesen einbauen, ohne bestraft zu werden.

Die einzige (automatische) Methode zum Blockieren von Framebrecher-PL's ist AFAIK eine genaue Analyse des JavaScripts auf der Zielseite bei jedem PL Aufruf und selbst dann kann man das System noch austricksen, wenn man nicht gerade einen eigenen JavaSkript Interpreter schreibt und dann das Verhalten des Skripts untersucht => Viel zu aufwändig.

Gruß molleonline

 

[Djdjrjf8e]

Natürlich ist das Ressourcenverschwendung aber anscheinend ja leider notwendig... Und Du kannst mir ja sicher erklären, welcher Webspace-Provider freiwillig Framebrecher einsetzt, die in etwa so beliebt sind wie SPAM-Mails...
Es wäre ja kein Problem, wenn nicht schon bei der Freischaltung darauf geachtet würde ob die Seite ein Framebrecher enthält und sei es durch einen einfachen Test durch laden innerhalb eines Frames. Dieses wird aber anscheinend nicht gemacht, da ansonsten solche bescheuerten Seiten wie pennergame.de gar nicht erst angenommen würden.

Diese würden durch einen einfachen Testframe bei der Überprüfung sofort auffallen.

Und nachträglich sag ich mal, haben vielleicht 10% die Möglichkeit, einen Frambrecher einzubauen, nämlich nur dijenigen, die auch tatsächlich an den Sourcecode rankommen.

Die meisten Powerlinks sind allerdings beworbene Seiten, wo wenn überhaupt der Framebrecher standardmäßig drin ist. Diese Seiten sollten sofort gesperrt und auf eine Blacklistkommen, die eine Freischaltung verhindert... und das kann dann automatisch gemacht werden.

Ich sehe also eher den Nachbesserungsbedarf bei denjenigen, die eine Freischaltung durchführen als bei einer aufwändigen Überprüfung.

Entweder haben diejenigen nicht die entsprechende Test-Umgebung, haben Anweisung jeden nicht explizit offensichtlichen Verstoss gegen die PL-Regeln durchzulassen, es werden die Augenverschlossen weil "Super-Angebot XY" geflossen ist oder nehmen sich nicht die Zeit dafür, nach dem Motto "Is ja egal, KLAMM kriegt das Geld ja so oder so..."

Ärgerlich ist es auf jeden Fall, wenn man sich schon die PL anschaut diese nicht auch noch korrekt gutgeschrieben bekommt.

Gruß,

jiw

 

[klamm]

Wie schon gesagt: Mein Ziel ist es, framebrechende Seiten zu erlauben und trotzdem zu checken ob das Fenster noch offen ist. Das eine schließt JS-Rechte-Technisch halt das andere aus.

 

[DaPhreak]

Das eine schließt JS-Rechte-Technisch halt das andere aus.

Richtig. Ergo musst Du auf eins von beiden verzichten. Und da ich mir nicht vorstellen kann, dass es eine Option ist, darauf zu verzichten, zu prüfen, ob das Fenster noch auf ist*, folgt daraus, dass framebrechende Seiten verboten werden müssen und entsprechende Überprüfungen eingebaut... Vorschläge kamen ja hier im Thread.



* Ich liebe Schachtelsätze.

 

[klamm]

Daraus folgt aber auch, dass z.B. eBay verboten wird, was in ca 10% schrumpfender Powerlink-Menge resultiert. Ergo schmälert das Deinen Verdienst.

 

[sonnenhexer]

haste bei Jagusch mal nachgehakt?
Weil gibt ja dort bei den Mailern die Möglichkeit, per Popup Framebreaker zu vergüten.
Hatte das ja vorgeschlagen

 

[klamm]

Bricht die Vergütung auch ab wenn das Fenster (mit der Werbung) dann zugeht und reagiert das Popup entsprechend? Falls ja genügt mir ein Auszug des Popup-Quelltextes.

 

[sonnenhexer]

Bricht die Vergütung auch ab wenn das Fenster (mit der Werbung) dann zugeht und reagiert das Popup entsprechend? Falls ja genügt mir ein Auszug des Popup-Quelltextes.

Die Frage hatte ich mit ja beantwortet

 

[DaPhreak]

Daraus folgt aber auch, dass z.B. eBay verboten wird, was in ca 10% schrumpfender Powerlink-Menge resultiert. Ergo schmälert das Deinen Verdienst.

Wenn ein Powerlink den Frame bricht bekomme ich ihn nicht vergütet*, ergo Verdienst = 0. Wenn dieser Powerlink verboten wird, sehe ich ihn gar nicht, ergo Verdienst immer noch = 0. Relative Änderung: 0%.


* außer man drückt schnell genug Escape, ja. Das kann aber auch nicht im Sinne des Erfinders sein, da dann das Hauptframe auch nicht geladen wird. Damit bekommt derjenige, der den Link eingetragen hat nicht, was er glaubt zu bekommen, nämlich Besucher. Auf lange Sicht hin wird er schließlich von der Werbeform Powerlink ganz Abstand nehmen.