DE102017116432A1

DE102017116432A1 - Anti-Werbeblocker-Lösung Vpaid

Info

Publication number: DE102017116432A1
Application number: DE102017116432.4A
Authority: DE
Inventors: Martin Matzanke; Maria Nowak; Sascha Stojakovic
Original assignee: Glomex GmbH
Current assignee: Sevenone Media GmbH
Priority date: 2017-07-20
Filing date: 2017-07-20
Publication date: 2019-01-24
Also published as: EP3432244A1

Abstract

Die Erfindung betrifft ein System, ein Verfahren und ein Computerprogramm zum Einblenden einer Werbung bei Vorhandensein eines Werbeblockers.

Description

Visuelle oder audio-visuelle Werbung, die dem Nutzer mittels eines Webbrowsers geliefert wird, ist für viele Websites der primäre Weg, um Geld zu verdienen.
Die Bereitstellung von Werbung beruht auf einer eingebauten Browser-Funktionalität. Die Browser-Funktionalität kann durch Browsererweiterungen modifiziert werden. Werbeblocker-Browsererweiterungen, etwa Adblock Plus, haben den spezifischen Zweck des Behinderns des Übermittelns von Werbung und Einblendung von Werbung.
Wir beanspruchen, dass wir selbst bei Vorhandensein eines Werbeblocks Werbung mit den nachstehend definierten Eigenschaften (d.h. auf Javascript beruhend) übermitteln können.
Die vorgeschlagenen Techniken beruhend auf dem Modifizieren von bestehenden Browserfunktionen in einer Weise, die das Umgehen von derzeit erhältlichen Werbeblockern erlaubt, während immer noch die zunächst gewünschte Funktionalität dieser Browserfunktionen gewahrt wird. Werbetreibende müssen somit die Umsetzung ihrer Werbung nicht ändern. Nutzern kann sowohl alte als auch neue Werbung ohne Vorkenntnis der in dieser Schrift vorgeschlagenen Lösungen übermittelt werden.
Während die hier präsentierte Technik bei jeder Art von Werbung verwendbar ist, konzentrieren wir uns spezifisch auf eine Lösung, um bei Vorhandensein eines Werbeblockers Javascript-VPAID-Werbung (VPAID= Video Player-Ad Interface Definition) zu übermitteln.
Die Haupttechniken, die eine Werbungsübermittlung in einem Webbrowser behindern, sind

a) Modifizieren des DOM (Dokumentenobjektmodell) im Browser
b) Verhindern von Anfragen an Werbe-Server
c) Einfügen von Javascript in die Website

Die zuletzt erwähnte Technik c) des Einfügens von Javacript in die Website wird für sehr unzuverlässig gehalten und wird von Werbeblockern nur selten genutzt. Während die vorliegende Lösung auch auf den Fall c) anwendbar ist, fußt der Großteil der Werbungsblockierung auf den Techniken a) und b), und daher konzentriert sich die vorliegende Lösung auf diese. Die Blockierung von Werbung durch DOM-Modifikation und durch Verhindern von Anfragen an Werbe-Server wird nachstehend näher beschrieben.
Das DOM (Dokumentenobjektmodell) ist die Darstellung einer Website für den Browser. DOM-Elemente werden mit Attributen wie „class“ „id“ u.a. konfiguriert. Diese Attribute geben im Detail an, wie der Browser diese Elemente auf dem Bildschirm darstellt. Typischerweise sind „class“ und „id“ vom Menschen lesbar und deuten somit ihren Zweck an: „class“ könnte z.B. „Werbebanner-Top“ oder ähnliches sein. Attribute, die bekannterweise zum Einblenden von Werbung verwendet werden, sind in den von Werbeblockern verwendeten Filterlisten enthalten. Wenn eine Filterliste „id“ oder „class“, die einem spezifischen DOM-Element zugeordnet sind, enthält, entfernt der Werbeblocker dieses DOM-Element mittels verschiedener Techniken (z.B. Entfernen des Elements oder Versetzen desselben in einen unsichtbaren Zustand) aus der sichtbaren Bildschirmfläche.
Die vorliegende Lösung ist bestrebt, den Zweck von DOM-Elementen für den Werbeblocker zu verschleiern, was einen Weg, die Sichtbarkeit dieser Elemente zu blockieren, unmöglich macht.
Die Einblendung von Werbung beruht auf Ressourcen wie Bildern, Audiodateien, Styling-Dateien, Video-Dateien, Javascript-Dateien und eventuell anderen. Das Laden dieser Ressourcen wird von dem Browser mittels Anfragen an Server, die diese Dateien hosten, durchgeführt. Dateispeicherorte sind Teil der Werbungsbeschreibung. Der Browser liefert eine API an Browsererweiterungen, um diese Anfragen zu modifizieren oder sogar abzuweisen. Typischerweise werden Dateien, die zum Einblenden von Werbung genutzt werden, auf Servern gehostet, die einfach als Werbe-Server identifizierbar sind (z.B. Google gehörende „Doppelclick“-Server). Werbeblocker erhalten eine Liste aller bekannten Werbe-Server und Werbe-Ressourcen und können das Ausführen dieser Anfragen verhindern.
Die vorliegende Erfindung kann die wesentlichen Techniken, die von Werbeblockern genutzt werden, verhindern (Beschreibung von wesentlichen Techniken siehe oben), um eine ungehinderte Werbeübermittlung für jede Werbung, die zur Werbeübermittlung auf Javascript beruht, zu ermöglichen.
Die in dieser Schrift beschriebenen Techniken sind bei der gesamten derzeit bekannten Javascript-Funktionalität in dem Browser verwendbar und können auf künftige Funktionalität erweitert werden.
Alle Modifikationen der Funktionalität des Browsers werden so implementiert, dass der gewollte Zweck der Funktionalität beibehalten wird, insbesondere im Kontext der Werbeübermittlung. Agenturen, die Werbung liefern, müssen daher keinerlei Änderungen an bestehender Infrastruktur, bestehender Werbung vornehmen. Werbung kann entworfen werden, ohne Techniken zum „Entblocken“ derselben zu berücksichtigen.
Die Technik wird bei VPAID-Javascript-Werbung, die in einem isolierten Browserkontext läuft (d.h. iframe) angewendet und im Kontext derselben näher erläutert. Die Technik kann auf den gesamten Browserkontext erweiteret werden und kann somit bei jeder Werbung, die auf Javascript beruht, angewendet werden.
VPAID-Javascript-Werbung ist im Stand der Technik gut bekannt und kann auf andere Versionen, die auf den im Stand der Technik festlegten Standards beruhen und aus diese abgeleitet sind, ausgeweitet werden. Eine entsprechende Offenbarung findet sich in https://www.iab.com/guidelines/digital-video-player-ad-interfacedefinition-vpaid-2-0/.
VPAID-Javascript-Werbung wird typischerweise in einer VAST xml-Datei und sowohl früheren als auch künftigen Iterationen dieses IAB-Standards geliefert, wie im Stand der Technik gut bekannt ist. Eine entsprechende Offenbarung findet sich in https://www.iab.com/guidelines/digital-video-ad-serving-template-vast-4-0/.
Das VAST xml wird auf eine Anfrage zu einem Werbe-Server geladen. Das VAST xml beschreibt zusätzliche Anfragen. Die zusätzlichen Anfragen sollen typischerweise zusätzliche Ressourcen anfragen, die für Werbungsanzeige erforderlich sind, oder werden für Trackingzwecke, wie durch IAB-Standard definiert, verwendet. Alle diese Anfragen können durch werbungsblockierende Browsererweiterungen blockiert werden.
Die zu ladende VPAID-Javascript-Datei wird von dem VAST xml wie durch den IAB-Standard definiert beschrieben. Dieses VPAID-Javascript soll DOM-Elemente erzeugen, die die dem Nutzer anzuzeigende tatsächliche Werbung bilden. Das Javascript VPAID kann auch vorhandene DOM-Elemente (zum Beispiel einen vorhandenen Videoplayer) erneut nutzen.
Werbung in VAST-Dateien dient dem Zweck, vor, während und nach einem Video eingeblendet zu werden. Dies konzentriert sich auf Werbung, die in diesem Kontext übermittelt wird.
Typischerweise fordert eine Website dynamisch Ressourcen an, die für Werbungseinblendung erforderlich sind. „Dynamisch“ bedeutet in diesem Kontext, dass der Besitzer der Website nach Erfolgen der ersten Anfrage keine volle Kontrolle über alle involvierten Werbe-Server hat. Die erste Anfrage zu einem Werbe-Server wird direkt auf der Website implementiert und ist dem Website-Besitzer bekannt. Die Antwort auf diese erste Anfrage kann zusätzliche Werbe-Server zuweisen, die entsprechend angefragt werden. Dies bietet den Vorteil des Maßschneiderns von Werbung für bestimmte Nutzer. Es entzieht dem Website-Besitzer aber auch Kontrolle dahingehend, dass Nutzer, die auf der Website browsen, Werbungsinhalt von Servern anfragen, die dem Besitzer der Website nicht bekannt sind. Dies hat zur Folge, dass die Funktionalität der Website typischerweise dem gewünschten Zweck dienen muss (d.h. der Anzeige von Inhalt), selbst wenn aus technischen oder sonstigen Gründen keine Kommunikation mit den Werbe-Servern möglich ist.
Für die vorgeschlagene Lösung wird ein Mechanismus zum Laden von zunächst blockieren Ressourcen vorgestellt.
Dies erfolgt durch Einführen eines Service auf der Seite des Unified Server, der Zugriff auf alle Ressourcen gewährt, die für Werbungsübermittlung, d.h. Einblenden der Werbung, erforderlich sind. Dieser eine Server beseitigt die dynamische Natur des Umgangs mit unbekannten Werbe-Servern, während Anfragen an diese Server immer noch proxifiziert werden können. Während Anfragen an diesen einen Server durch werbeblockierende Techniken immer noch blockiert werden können, bleibt es dem Besitzer der Website belassen, einfach zu steuern, ob Kommunikation mit diesem Werbe-Server möglich ist. Wenn Kommunikation blockiert ist, kann die Website entscheiden, auch die Anzeige des Inhalts der gewünschten Website zu stoppen. Dieser Unified Server wird fortan als „Proxy-Werbe-Server“ bezeichnet.
Im Kontext von Javascript-VPAID-Werbung bedeutet dies, dass das Anzeigen des Inhalt-Videos nur stattfindet, wenn die Kommunikation mit dem Proxy-Werbe-Server ungehindert ist. Ein solcher Proxy-Werbe-Server wird bereits genutzt und im Stand der Technik beschrieben, wie in EP3016054A1 beschrieben.
Der Proxy-Werbe-Server muss zwei Hauptfunktionen bieten, um im Kontext von VPAD-Javascript-Werbung (sowie anderer eingeblendeter Werbung) die Einblendung von Werbung zuzulassen.

a) Er muss das Proxifizieren einer beliebigen Ressource zulassen. Wenn eine Datei auf einem Drittserver (z.B. einem Werbe-Server) gehostet wird, erhält der Proxy-Werbe-Server die url über Mittel, die von werbungsblockierender Technologie nicht detektierbar sind. Dies kann durch Kodieren der URI und durch Senden der kodierten URI über Websocket erfolgen. Diese kodierte URI wird dann von dem Werbungs-Proxy-Server dekodiert. Die von der URI spezifizierte Ressource wird dann von dem Server abgefragt (wo keine Störung durch werbungsblockierende Technologie möglich ist). Die erfasste Ressource wird dann kodiert und mittels Websocket dem Webbrowser zurückgesendet, wo Dekodieren erfolgt.
b) Während die in a) beschriebene Lösung im Prinzip das Abfragen einer beliebigen Ressource erlaubt, können manche Ressourcen von dem Browser nur korrekt gehandhabt werden, wenn sie mittels des gewünschten Protokolls (z.B. http oder https) statt Websocket geladen werden. Der Aufwand eines Websocket-Betriebs kann bei manchen Dateien (z.B. Videodateien und große Bilder) auch sehr teuer sein. Zu diesem Zweck liefert der Werbungs-Proxy-Server Funktionalität, um jede Art von Ressource zu einem Ort zu laden, der entweder ein Content Delivery Network (CDN) ist oder ähnlich wie ein solches funktioniert. Während auch der Zugriff auf diesen Ort durch Werbeblocker blockiert werden kann, ist es wiederum ein Ort, der gesteuert werden kann. Sollte dieser einzelne Ort blockiert werden, kann die Einblendung des gewünschten (Video-)Inhalts ebenfalls blockiert werden.

Die allgemeinen Techniken zum Ausführen von Anfragen an Server, die durch Werbe-Blocker blockiert werden, sind vorstehend aufgeführt. Eine eingehende Beschreibung der Verwendung dieses oder eines anderen Kontexts bei VPAID-Javascript-Werbung (und anderer Javascript-Werbung) folgt hier.
Die Komplexität des Entblockens (d.h. des Einblendens trotz Vorhandensein eines Werbeblockers) einer Werbung, die auf VAST xml beruht, das ein VPAID-Javascript enthält, übersteigt die Komplexität des Anzeigens von VAST mit eingeblendeter Video-Werbung, wie in EP3016054A1 abgehandelt wird. Die Komplexität ergibt sich aus der Natur von VPAID, das jede Art von zusätzlicher Ressource (z.B. Scripts, Bilder, Videos, ...) laden und die DOM-Struktur manipulieren kann. Die dynamische Zuweisung dieser zusätzlichen Ressourcen erfordert eine neue Vorgehensweise beim Umgehen von Werbe-Blockern.
Der Ansatzpunkt bei VPAID-Werbung ist eine VAST xml, wie von dem IAB-Standard definiert. Eine VAST xml-Datei (z.B. eine VAST .xml-Rückmeldung) wird selbst bei Vorhandensein eines Werbeblockers durch die vorstehend und in EP3016054A1 , nachstehend als (1) bezeichnet, beschriebenen Mittel geladen. Während die in (1) beschriebene Werbungsübermittlung nur Videodateien abdeckt, erstreckt sich die hier beschriebene erweiterte Lösung auf JavaScript-Dateien, die jede für Werbungsübermittlung erforderliche Ressource dynamisch zuweisen kann. Die hier beschriebene Lösung erstreckt sich auch auf werbungsblockierende Verfahren, die wie vorstehend beschrieben auf Modifikation der DOM-Struktur setzen. Zum Beispiel VPAID, siehe Anhang.
Die Handhabung von VAST erfolgt typischerweise durch eine Javascript-Komponente, die Teil eines Videoplayers ist. Diese Komponente erhält typischerweise die URI, die auf eine VAST xml verweist. Die Komponente holt die VAST und befolgt das durch den IAB-Standard festgelegte Verhalten. Diese Komponente wird fortan als „Vast-Ad-Handler“ bezeichnet.
Der Vast-Ad-Handler muss alle Anfragen bezüglich VAST-Handling ausführen, einschließlich (aber nicht ausschließlich):

- Abrufen von VAST
- Abrufen von zusätzlichen VAST-Dateien, wie von so genannten „Wrapper“-VASTs, die von dem IAB-Standard definiert werden, vorhergesehen.
- Abfragen von Tracking-, Fehler-, Umfrage- und anderen Abrufen, die typischerweise als „Tracking-Abrufe“ bezeichnet werden und in dem IAB-Standard gut definiert sind.

Alle diese Anfragen sowie die folgende Handhabung der Mediumdatei im Fall von Nicht-VPAID-Werbung unterliegt dem vorstehend und in (1) beschriebenen Mechanismus.
Nach Abrufen der VAST xml, die auf eine VPAID-Javascript-Werbung verweist, (wie in dem vorherigen Abschnitt beschrieben) wird ein iframe-DOM-Element erzeugt, in dem das VPAID-Javascript auszuführen ist. Dieser iframe stellt einen isolierten Kontext für das VPAID-Javascript bereit, um zum Beispiel sicherzustellen, dass das VPAID-Javascript nicht andere Elemente auf der Website stört. Dieses Verhalten ist von dem IAB-Standard vorhergesehen.
Dieser iframe unterliegt Modifikationen, die Werbeblocker umgehen sollen.
Das VPAID-Javascript wird in diesem isolierten iframe ausgeführt. Das VPAID-Javascript wird die Browser-Funktionalität nutzen, um sowohl das DOM zu modifizieren als auch zusätzliche Ressourcen zu laden. Sowohl die DOM-Modifikation als auch das Laden der Ressourcen (einschließlich des Ladens des VPAID-Javascripts selbst) kann den vorstehend beschriebenen werbeblockierenden Techniken unterworfen sein. Diese beiden werbeblockierenden Techniken werden umgangen.
Das Umgehen der Blockierung von zusätzlichen Ressourcen wird wie folgt ausgeführt:
Das Laden von Ressourcen erfolgt durch verschiedene Javascript-Funktionen des Browsers. Diese beinhalten (ohne darauf beschränkt zu sein):

- createElement
- New Image
- Background url
- Xhr request
- Inline
- Fetch

Innerhalb von iframe werden alle diese Funktionen und Konstruktoren durch „Proxy-Funktionen“ von „Proxy-Konstruktoren“ ersetzt. Dies kann durch Überschreiben der Funktionen und Konstruktoren wie in Javascript geplant erfolgen.
Diese „Proxy-Funktionalität“ hat die folgenden Eigenschaften:

- Sie haben die gleiche API wie die Funktionen, die sie überschreiben
- Sie dienen dem gleichen Zweck, z.B. erzeugen sie immer noch ein Bildelement oder rufen eine Ressource ab
- Das tatsächliche Laden der Ressource erfolgt so, dass derzeitige werbungsblockierende Techniken nicht stören können, d.h. sie folgen der vorstehend beschriebenen Funktionalität.

Beispiel für einen createElement- und getElementByld-Konstruktor


 const nativeCreateElement = document.createElement;
 const idMapping = {};
 function generateld(setld) {
  return Math.random().toString(36).substring(7); }
 const hativeCreateElement = document.createElement;
 document.createElement = function(type) {

 if (type === ‚div‘) {

  const divNode = nativeCreateElement(‚div‘);
  let divld;
  Object.defineProperty(div, ‚id‘, {
     set(setld) {

      divld = generateld(setld);
      idMapping[id] = {

       id: divld,
       element: divNode
    };},
    get() {
      return divld;
    }

   });

  return divNode;

 }
 return nativeCreateElement(type); };
 const nativeGetElementByld = document.getElementByld;
 document.getElementByld = function(elementld) {
 const item = Object.keys(idMapping).find(id => id === idMapping[id].id);
 if (!item) {

  return nativeGelElementByld(elementld);

 }
 return item.element
 };
 const divNode = document.createElement(‚div‘);
 divNode.id = ‚vpaid-ad-container‘;
 const vpaidNode = document.getElementByld(‚vpaid-ad-container‘);

Beispiel für einen „Proxy-Konstruktor“:

/* eslint-disable no-param-reassign */

 export default (global, performFetch) => {

 const Nativelmage = global.Image;
 global.Image = function Image(src) {

  const image = new Nativelmage(src);
  if (src) {

   performFetch(src).then((error) => {
     if (error && image.onerror) {

      image.onerror(error);
    }

   });

  } else {

   Object.defineProperty(image, ‚src‘, {

    set(setSrc) {
      performFetch(setSrc).then(() => {
      }).catch((error) => {

       image.onerror(error);

      });

     },
     get() {
     },
  }});
  return image;
  };};

Von einem VPAID-Javascript erzeugte und modifizierte DOM-Elemente unterliegen den vorstehend beschriebenen blockierenden Techniken. Diese Blockierung beruht auf Eigenschaften an individuellen DOM-Knoten, z.B. dem Attribut „class“ oder „id“.

Die Attributeigenschaften eines DOM-Knoten dienen verschiedensten Zwecken:

- Sie werden für Styling genutzt (css Klassen)
- Sie werden zum Durchlaufen der DOM mittels eingebauter Browser-Funktionalität verwendet, um
- - das DOM zu manipulieren
- - In dem DOM-Knoten enthaltene Informationen abzufragen

Das Verwenden eines DOM-Knoten für den Zweck des Einblendens von Werbung muss somit einem Werbeblocker gegenüber verschleiert werden. Alle Eigenschaftswerte (z.B. „Banner-TOP“, „Ad-Container“), die zu Eigenschaften gehören, die typischerweise in Fällen von Werbungsblockierung betrachtet werden (z.B. „class“, „id“) müssen modifiziert werden.

Um dies zu verwirklichen, müssen alle vom Browser gelieferten Javascript-Funktionen, die DOM-Modifikation und Durchlaufen von DOM angehen, überschrieben werden, während ihr gewünschtes Verhalten noch beibehalten wird. Die allgemeine Vorgehensweise ist wie in dem vorherigen Abschnitt dargelegt.

Diese Funktionen beinhalten (ohne darauf beschränkt zu sein):

- getElementByld
- getElementsByClassName
- object.setAttribute()

Das Verhalten von Funktionen, die ein Attribut (z.B. setAttribute()) festlegen, muss so modifiziert werden, dass der verschleierte Wert, der tatsächlich gesetzt wird, aus dem gewünschten nicht verschleierten Wert abgeleitet werden kann. Dies erfolgt mittels eines Hash-Algorithmus und eines internen Tabellen-Mapping von den Ursprungswerten zu den Hash-Werten.

Als Beispiel wird die Funktion element.setAttribute() überschrieben. Die ursprüngliche Funktion wird zu element.originalSetAttribute() kopiert und somit bewahrt. Das Verwenden der überschriebenen Browserfunktion mit einigen Argumenten, z.B. element.setAttribute(‚id‘, ‚banner-top‘), würde intern die ursprüngliche Funktion aufrufen (Proxifizieren des Funktionsaufrufs zu dem ursprünglichen Verfahren), während die Argumenten zum Beispiel zu element.originalSetAttribute(‚id‘, ‚9d5f06927fe0a9ac06064ac166e549f0‘) modifiziert werden.

Dies bedeutet auch, dass die Funktion document.getElementByld() in gleicher Weise überschrieben werden muss, wobei bei Weiterleiten zu der ursprünglichen Funktion die Argumente zu den Hash-Werten ausgetauscht werden.

CSS-Dateien beschreiben die visuelle Darstellung von DOM-Elementen. Von dem Browser werden CSS-Stylesheets interpretiert, der Browser nutzt die detaillierten Styles gemäß den Klassen, die die Elemente haben.

Da alle Klassennamen wie in dem vorherigen Abschnitt beschrieben modifiziert wurden, müssen alle CSS-Stylingsheets entsprechend modifiziert werden. Diese Modifikation erfolgt an der Serverseite, d.h. dem Proxy-Ad-Server.

Wenn ein Javascript einen neuen Browserkontext in dem iframe erzeugt (d.h. Erzeugen von verschachtelten iframes), werden diese durch rekursives Anlegen der Proxy-Funktionen an allen verschachtelten iframes ebenfalls von den vorstehend definierten Proxy-Funktionen betroffen.

Sobald alle Modifikationen erfolgt sind, wird in dem modifizierten iframe ein Script-Tag erzeugt. Für dieses Script-Tag wird das Quellenattribut „scr“ auf das VPAID-Javascript gesetzt und dann wird das VPAID-Javascript in dem modifizierten iframe ausgeführt.

Während das Laden dieses Javascripts durch eine Werbeblocker blockiert werden könnte, würde es ohne die vorgesehenen Modifikationen geladen werden, stellen die Proxy-Funktionen das Laden des Javascripts sowie das Laden aller zusätzlichen Ressourcen, die von diesem Javascript ausgelöst werden, sicher.

Bei Liefern der Dateien mittels des Proxy werden Cookies gesetzt, die in einem alternativen AdBlocking-Cookie-Store gespeichert werden. Dies ist erforderlich, da ein Nutzer im Fall einer zusätzlichen Anfrage gegenüber Dritten identifiziert werden sollte. Dadurch wird die Standard-Funktionalität gesichert.

Bei Liefern von großen Dateien mittels CDN (Bilder/Videos) wird kein Cookie übertragen, da angenommen wird, dass bei diesen Ressourcen ein Nutzer nicht identifiziert werden muss.

Die Werbung wird eingeblendet, ohne dass der Werbeblocker eingreifen kann.

1 und 2 zeigen die vorstehend beschriebene Erfindung bildlich.

ZITATE ENTHALTEN IN DER BESCHREIBUNG

Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.

Zitierte Patentliteratur

EP 3016054 A1 [0023, 0026, 0027]

Claims

System zum Einblenden einer Werbung bei Vorhandensein eines Werbeblockers, welches einen Proxy-Werbe-Server umfasst, der Zugriff zu allen für Werbungsübermittlung erforderliche Ressourcen gewährt, wobei die url einer auf einem Drittserver gehosteten Datei kodiert und über Websocket oder ein gewünschtes Protokoll zu dem Proxy-Werbe-Server gesendet wird, wobei die url dann von dem Proxy-Werbe-Server dekodiert wird, wobei die von der url spezifizierte Ressource dann von dem Proxy-Werbe-Server abgefragt wird und die erforderliche Ressource dann kodiert und mittels Websocket oder ein erwünschtes Protokoll zu einem Webbrowser zurückgesendet wird.
System nach Anspruch 1, wobei der Proxy-Werbe-Server Funktionalität liefert, um jede Art von Ressourcen zu einem Ort hochzuladen, der entweder ein Content-Delivery-Network ist oder ähnlich wie ein solches funktioniert.
System nach Anspruch 1, welches ein Merkmal zum Laden von anfänglich blockierten Ressourcen umfasst.
Verfahren zum Einblenden einer Werbung bei Vorhandensein eines Werbeblockers, welches das Gewähren von Zugriff für einen Proxy-Werbe-Server auf alle für Werbungsübermittlung erforderlichen Ressourcen umfasst, wobei die url einer auf einem Drittserver gehosteten Datei kodiert wird und mittels Websocket oder eines gewünschten Protokolls zu dem Proxy-Werbe-Server gesendet wird, wobei die url dann von dem Proxy-Werbe-Server dekodiert wird, wobei die von der url spezifizierte Ressource dann von dem Proxy-Werbe-Server abgefragt wird und die erforderliche Ressource dann kodiert wird und mittels Websocket oder eines gewünschten Protokolls zu einem Webbrowser zurückgesendet wird.
Verfahren nach Anspruch 4, wobei der Proxy-Werbe-Server Funktionalität liefert, um jede Art von Ressourcen zu einem Ort hochzuladen, der entweder ein Content-Delivery-Network ist oder ähnlich wie ein solches funktioniert.
Verfahren nach Anspruch 4, welches ein Merkmal zum Laden von anfänglich blockierten Ressourcen umfasst.
Computerprogramm zum Einblenden einer Werbung bei Vorhandensein eines Werbeblockers, welches das Gewähren von Zugriff für einen Proxy-Werbe-Server auf alle für Werbungsübermittlung erforderlichen Ressourcen umfasst, wobei die url einer auf einem Drittserver gehosteten Datei kodiert wird und mittels Websocket oder eines gewünschten Protokolls zu dem Proxy-Werbe-Server gesendet wird, wobei die url dann von dem Proxy-Werbe-Server dekodiert wird, wobei die von der url spezifizierte Ressource dann von dem Proxy-Werbe-Server abgefragt wird und die erforderliche Ressource dann kodiert wird und mittels Websocket oder eines gewünschten Protokolls zu einem Webbrowser zurückgesendet wird.
Computerprogramm nach Anspruch 7, wobei der Proxy-Werbe-Server Funktionalität liefert, um jede Art von Ressourcen zu einem Ort hochzuladen, der entweder ein Content-Delivery-Network ist oder ähnlich wie ein solches funktioniert.
Verfahren nach Anspruch 7, welches ein Merkmal zum Laden von anfänglich blockierten Ressourcen umfasst.