Patent Application
20090299862
In a computing environment, websites and associated webpages often host online advertisements, intended to be viewed by online users of the respective websites. Online advertisements typically come from a different domain than that of the hosting website. Online advertisers and hosting websites typically work with an ad syndicator, which takes calls for ads from the host, pulls ads from the advertiser, and then directs the ads to the host's website. Often, online ads have rich functionality, including an ability to expand and/or move about a webpage.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key factors or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Typically, when a webpage wishes to display an online ad, the webpage (hosting webpage) can call to an ad syndicator, indicating specifications for an open ad-space in the host webpage. The ad syndicator can pull an ad from a catalogue of ads supplied by advertisers, which meets the specifications supplied by the host webpage. Typically, the ad syndicator will put the pulled ad directly into the host webpage, in such a way that the browser takes the ad as a part of the host webpage. When this occurs, the ad is often allowed to freely interact with the host webpage in order to provide for rich functionality, including changing its size and/or position on the host webpage. However, inserting the ad in this manner also grants the ad many if not all privileges that the host webpage may have in the browser. Unfortunately, malicious ads may also be inserted into the host webpage in this manner, creating an opportunity to damage a host website, or steal users' personal identifiable information. Additionally, a webpage host may be able to take advantage of an ad owner by manipulating the ad content inside the browser, such as by inflating the number of times an ad appears to have been clicked on by a user, for example.
As an example, it is not uncommon for a webmail system to host a third-party ad. The ad may be integrated by the ad syndicator in a way that allows the ad to freely expand out or fly around the host webpage. However, this ad also has a potential to view users' emails on the hosting page, and to steal user credentials from the host website's cookies, for example. From the perspective of protecting an ad owner, a host could charge an ad owner more where the host programmatically increases the number of times an ad appears to have been clicked on by a user.
Previous and current solutions to this ad serving security issue have limitations that may not make them as functional, or provide for extensive proprietary updates to user's, ad syndicator's, and advertiser's systems. In one such solution an ad created by the advertiser is sent by a third-party advertising vendor and put into a cross-domain frame or window of the host webpage, and the ad is isolated from the host webpage. However, there can be no client-side interaction with the host page, which may limit the ad's rich functionality. In another such solution, the ad created by the advertiser is pulled by the ad syndicator, transformed into pure text, and put into the host webpage. However, in this solution, the ad cannot contain executable code, which eliminates the ad's rich functionality. Other solutions utilize ad code scanning techniques, or “blacklisting” techniques that are designed to prohibit certain functions in the host webpage. However, these solutions may not be able to cover new malicious techniques, may block legitimate ads, and often require additional installs to browsers, or other ad syndication systems.
Techniques and systems are provided herein for securely serving online ads on a host webpage, while allowing for rich functionality of the online ads, but not the undesirable manipulation thereof by an unscrupulous host. The techniques and systems create a cross-domain frame in a host webpage (e.g., a cross-domain inline frame (IFrame)), which contains a secure environment by default (e.g., content inside the frame cannot interact with the host webpage). The host webpage comprises host ad-space, which can be of a size that accommodates an initial size of ad content inside the cross-domain frame (e.g., the host ad-space is the same height and width as the initial size of an ad to be inserted in the cross-domain frame). An inter-frame communications channel is created between the cross-domain frame and the host webpage. This channel can be used, for example, to send and receive messages, detect events inside the frame, and communicate requests from content inside the frame. An API may be utilized that communicates a host's parameters and restrictions for an ad to be hosted in the cross-domain frame.
To the accomplishment of the foregoing and related ends, the following description and annexed drawings set forth certain illustrative aspects and implementations. These are indicative of but a few of the various ways in which one or more aspects may be employed. Other aspects, advantages, and novel features of the disclosure will become apparent from the following detailed description when considered in conjunction with the annexed drawings.
The claimed subject matter is now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the claimed subject matter. It may be evident, however, that the claimed subject matter may be practiced without these specific details. In other instances, structures and devices are shown in block diagram form in order to facilitate describing the claimed subject matter.
In
However, using the techniques and systems described herein,
Because the ad content 106 is contained within the inline frame 212, for example, the ad may not be granted privileges of the host webpage102 in the browser, thereby providing a more secure environment for the host webpage 102. However, referring to
At 306, host ad-space is created in the host webpage to accommodate an initial size of a frame ad-space. The host ad-space comprises an initial height and width of the frame ad-space. As an example, the host webpage may create host ad-space comprising a specified width and height. In this example, the host webpage can call to an ad syndicator with the specified width and height, which can correspond to an initial width and height of an advertiser's ad content. In this way, the ad syndicator can pull only those ads that may have an initial width and height meeting the specifications of the host webpage. In this example, the host ad-space will not contain host content, so as to avoid conflicts with ad content. Further, the frame created at 304 to contain the ad content can initially be configured to the specified size of the host ad-space.
At 308, a communication channel is created between the cross-domain frame and the host webpage. As an example, a secure channel can be created between the cross-domain frame and the host webpage that allows the ad content in the frame to communicate requests to the host. In this example, if the ad content in the frame is configured to expand when a user moves a cursor over the ad content, a request can be sent to the host, over the secure channel, to expand the frame to accommodate the expanded ad content. Further, the host webpage may communicate with the frame's contents, over the secure channel, in order to configure display properties or other functionalities.
Having created a communication channel between the frame and the host webpage, the exemplary method 300 ends at 310.
In one aspect, isolating third-party online ads from a hosting webpage and/or website can provide security for the host webpage from malicious attacks, and provide users with a positive and secure online experience. In this aspect, for example, a floating transparent cross-domain frame can be utilized in the host web-page to isolate the ad content from the host web-page. The cross-domain frame may be inserted inline (e.g., an IFrame) in the host webpage, which has a default property of disallowing interaction between the content inside the frame and the ad hosting web page. Any necessary interaction between the ad content and the host webpage may be accomplished by means of a secure communications channel between the frame and the host webpage, as discussed later.
In this aspect, other related solutions to security of online ads (e.g., “BrowserShield,” “SafeScript,” “Google Caja”) utilize a “blacklisting” or a “whitelisting” method, whereby an ad is put into a same isolation boundary as a hosting webpage in a browser. In these related solutions, specified “unsafe” functionalities are then removed (blacklisted) from the ad content in the isolation boundary in the browser, or an ads' functionalities are restricted to a subset of what otherwise is provided by the browser to the ads by default (whitelisted). However, these solutions may not be attractive for ad syndicators, hosts and ad owners, as functionality can be reduced, and specific, proprietary updates may be necessary to the browser, and by the ad syndicator and ad owner.
Additionally, in this aspect, isolating third-party online ad content from a hosting webpage and/or website can provide security for the ad owner. The isolation techniques and systems, described herein, can inhibit the hosting website/webpage from programmatically manipulating the ad content inside the browser. For example, a webpage host may wish to forge user clicks (e.g., increase an amount of times user's (appear to) click on an ad) in order to increase an amount paid to the host by the ad owner (e.g., a type of click-fraud, whereby host's are paid more by ad owners when ads are clicked on more by users). In this way, a secure ad serving experience can be provided for both the host webpage and the ad owner or syndicator.
One embodiment of a use of a secure cross-domain frame (e.g., an IFrame) to isolate ad content is illustrated in
An ad owner 404 can generate ad content that is intended to be displayed on the host webpage 406. In this example, the ad content generated by the ad owner 404 is inserted into the IFrame 408 in the host webpage 406. In this way, the ad owner 404 may merely have access to content inside the IFrame 408, and can be barred from interacting with the host webpage 406. However, in this example, a communications channel 410 may be created between the IFrame 408 and the host webpage 406, to aid in ad functionality, as discussed below.
In another aspect, ad content inside a cross-domain frame (e.g., a cross-domain inline frame (IFrame)) may need to communicate with a host webpage. As an example, ad content that is configured to expand upon a specified event (e.g., a mouseover the ad content) may not be able to expand due to a fixed size of the cross-domain frame. However, in this example, if the ad content could communicate an intention to expand to the host webpage, the host webpage may programmatically expand the cross-domain frame to accommodate the expanded ad content. Additionally, the host webpage may wish to communicate across to the frame in order to control display properties or other functionalities inside the frame. As an example, the host webpage may wish to display a title bar in the frame that displays the origin of the ad content.
In this aspect, an inter-frame communications channel (e.g., a flash channel) may be created that allows direct communication between the contents of the frame and the host webpage. However, because security of the host webpage may still be a concern if the ad content is able to communicate with the host webpage, techniques can be employed that provide a secure inter-frame communications channel. As an example, additional code may be inserted on either side of the communications channel, both inside the cross-domain frame and outside the frame, in the host webpage, that provides specified security measures.
In one embodiment, the security measures may call for “white-listing” communication functionalities for content inside the cross-domain frame. In this embodiment, only those functions the code deems to be “safe” may be “white-listed” (allowed to run) in the frame. As an example, the additional code can make anonymous event handlers undetachable inside the frame, ensuring that they cannot be changed or removed by an ads' code although they run together with the latter inside the frame. Further, in this example, JavaScript closure objects and functions can be used inside the frame. The “white-listing,” in this example, has an advantage over “black-listing” of prior solutions, as there is less of an open surface (e.g., less potential methods for a malicious attack or unauthorized use of information) in “white-listing.” Using “white-listing,” the host webpage provides a limited list of allowable functions, whereas “blacklisting” provides a list of disallowed functions.
Additionally, in this embodiment, the additional code can provide security for determining which communications may be allowed across the intra-frame communications channel. As an example, secret tokens may be generated that are shared between the codes inside and outside the frame. In this example, the code inside the frame will provide the secret token to those “white-listed” actions, thereby preventing ads' code from sending forged messages to the host web-page. Further, as an example, the additional code can send heart-beat messages across the channel to monitor the condition of the frame, to determine if the security code or measures inside the iframe is deactivated (e.g., when ads' code maliciously navigate the iframe away to another webpage). It will be appreciated that, while several examples of security measures have been discussed herein, the techniques described in this embodiment are not limited to any particular security measures. Those skilled in the art may devise additional methods and means for providing security to the intra-frame communications channel.
One embodiment of the use of an intra-frame communications channel for communicating between an IFrame, for example, and a host webpage is illustrated in
In this exemplary embodiment 500, a user 412 may interact with the ad content (e.g., mouseover) in the IFrame 408, which causes the ad content to expand. However, because the IFrame 408 may have a size that limits the ad content's expansion, the ad content may send a message across the communications channel 410 requesting that the host webpage expand the IFrame to accommodate the expanded ad content. As an example, one of the “white-listed” functions may be communicating frame expansions to the host webpage 406. In this example, because the function called by the ad content is “white-listed” the code 502 inside the IFrame 408 attaches a secret token to the message sent by the ad content across the channel 410, and the code 504 outside the IFrame receives the message with the secret token, thereby allowing the message to be passed to the host webpage 406. When the host webpage 406 receives the message it can, for example, programmatically expand the IFrame 408 to accommodate the expanded ad content.
In another aspect, events inside a cross-domain frame inserted into a host webpage (IFrame) may be detected to determine functionality of the IFrame and its content. As an example, the additional code inserted inside the IFrame may be used to detect events inside an IFrame such as a user's cursor movements, cursor location, moving a cursor over an element in the IFrame (mouseover, or mouse hover), or interacting with an element in the IFrame. Additionally, the code in the IFrame may be used, for example, to detect an ad content's user interface properties, that is, what types of functionality, display and interactive properties the ad content may have.
In this aspect, the additional code inside the frame can, for example, send messages outside the frame using the inter-frame communications channel concerning events detected inside the IFrame. In this way, as an example, change requests from the ad content, in response to events inside the IFrame, may be communicated to the host webpage. As described above, the additional code on the host webpage side of the communications channel may receive the messages and institute appropriately requested changes to the IFrame's properties, for example.
As an example, a user may move a cursor (mouse) from a position outside the IFrame to a position over ad content inside the IFrame. In this example, the code inside the IFrame can detect the cursor movement and location over the ad content, and it may receive a message from the ad content that this event results in the ad content expanding (e.g., or it may be a predetermined quality of the ad content, not needing a message). The code inside the IFrame can send a message across the channel to the code outside the IFrame, which can, in turn, change the IFrame properties to accommodate the expanded ad content inside the IFrame.
It will be appreciated that, while mouse and cursor events have been described in this embodiment, the techniques and systems, described herein, are not limited to these events and actions. In a computing environment, there are many varied events and actions that can occur on a webpage, and those skilled in the art may devise ways to detect these events and actions.
In another aspect, typical ad content utilizes expansion down and/or to the right, when viewed by a user. However, using a cross-domain inline frame (IFrame) one may not be limited to expansion in these directions when viewed on a webpage. As an example, the properties of an IFrame may be managed by the host webpage, and can be manipulated so that the IFrame expands and moves. In this example, an ad may be configured to expand upward when a user moves a cursor over the ad's content. If the IFrame can only expand downward, the expanded portion of the ad will not be viewed by the user, as the IFrame limits the ad's interaction with the host webpage. However, the IFrame may be made to expand to a size that accommodates the expanded ad content, move the expanded ad content to fit into the expanded IFrame, then move the IFrame to a position that, when viewed by the user, has an appearance that shows the ad content expanding upward (e.g., move the IFrame up). It will be appreciated that, the properties of an IFrame are not limited to expanding to accommodate an ad's expansion, but may include movement about the host webpage. An IFrame's properties can be controlled by the host webpage, and is only limited by the host's determined limitations.
One embodiment of inter-frame event detection and frame expansion and movement is illustrated in
In this exemplary embodiment 600, as seen in the host webpage 606, the code inside the IFrame can detect the expansion event, and move the ad content 612 and 616 down, to accommodate the expanded ad content 616 within the now expanded IFrame 614. However, in 606, the user would not experience the ad content expanding upward, as intended by the ad's configuration, but a jumping down and expansion of the ad content 612 and 616. As seen in host webpage 608, the code inside the IFrame 614 can detect the intended configuration event of the expanded ad content 616, and send a message to the code outside the IFrame 614 that requests the IFrame 614 be moved upward to accommodate the intended expansion. In this way, as viewed by the user, the ad content expands upward 616 from the original ad content 612 when the cursor is moved 610 over the ad content 612. It will be appreciated that the expansion and movement of the IFrame, in this example, can occur rapidly so that, as viewed by the user, the ad content merely expands upward.
A source code interface (e.g., a set of application programming interfaces (APIs)) may be devised that provides an interface for a host webpage to communicate ad content parameters and restrictions to an ad syndicator.
In the exemplary embodiment 700, the source code interface 704 comprises a parent node property component 706, which is configured to direct an ad's parameters and/or restrictions to a parent node, for example, as provided by a host website. As an example, in order to configure child node elements of ad content one may use the parent node element (e.g., the parent element of the child elements) to enact configurations to the child node elements. The source code interface 704 further comprises a parameter set 708, which is configured to provide an ad's parameters and/or restrictions, for example, as provided by the host website. As an example, parameters comprising an ad's height, width, initial height, and minimum height may be provided by the host website, along with a restriction on whether the ad can expand inside an IFrame. In this example, the parameters and restrictions can be used when configuring the child node elements (e.g., those elements that correspond to the ad's parameters and restrictions) through the parent node element.
It will be appreciated that, while the exemplary embodiment 700 illustrates a use of a single API, comprising single instances of a parent node property component and a single instance of a parameter set component, the source code interface is not limited to this configuration. Multiple APIs may be utilized that contain one or more instances of parent node property components and one or more instances of parameter set components. As an example, there may be multiple elements that control parameters and configurations of an ad. Multiple instances of API may be used to, for example, describe the ad's authority to expand, it's orientation in an IFrame, and an extent the ad may be allowed to expand and/or move.
In this exemplary embodiment 700, a host 710 (e.g., a website that hosts an ad) can interact with the host webpage 702. The host can supply parameters and restrictions for an ad that may be hosted on the webpage 702, using the API 704. The parameters and restrictions, along with the parent node property, can be sent to the ad syndicator 712 where an ad, for example, can be configured to meet the requirements set forth by the host 710.
Still another embodiment involves a computer-readable medium comprising processor-executable instructions configured to implement one or more of the techniques presented herein. An exemplary computer-readable medium that may be devised in these ways is illustrated in
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
As used in this application, the terms “component,” “module,” “system”, “interface”, and the like are generally intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a controller and the controller can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.
Furthermore, the claimed subject matter may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed subject matter. The term “article of manufacture” as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. Of course, those skilled in the art will recognize many modifications may be made to this configuration without departing from the scope or spirit of the claimed subject matter.
Although not required, embodiments are described in the general context of “computer readable instructions” being executed by one or more computing devices. Computer readable instructions may be distributed via computer readable media (discussed below). Computer readable instructions may be implemented as program modules, such as functions, objects, Application Programming Interfaces (APIs), data structures, and the like, that perform particular tasks or implement particular abstract data types. Typically, the functionality of the computer readable instructions may be combined or distributed as desired in various environments.
In other embodiments, device 1012 may include additional features and/or functionality. For example, device 1012 may also include additional storage (e.g., removable and/or non-removable) including, but not limited to, magnetic storage, optical storage, and the like. Such additional storage is illustrated in
The term “computer readable media” as used herein includes computer storage media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions or other data. Memory 1018 and storage 1020 are examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by device 1012. Any such computer storage media may be part of device 1012.
Device 1012 may also include communication connection(s) 1026 that allows device 1012 to communicate with other devices. Communication connection(s) 1026 may include, but is not limited to, a modem, a Network Interface Card (NIC), an integrated network interface, a radio frequency transmitter/receiver, an infrared port, a USB connection, or other interfaces for connecting computing device 1012 to other computing devices. Communication connection(s) 1026 may include a wired connection or a wireless connection. Communication connection(s) 1026 may transmit and/or receive communication media.
The term “computer readable media” may include communication media. Communication media typically embodies computer readable instructions or other data in a “modulated data signal” such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” may include a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.
Device 1012 may include input device(s) 1024 such as keyboard, mouse, pen, voice input device, touch input device, infrared cameras, video input devices, and/or any other input device. Output device(s) 122 such as one or more displays, speakers, printers, and/or any other output device may also be included in device 1012. Input device(s) 1024 and output device(s) 1022 may be connected to device 1012 via a wired connection, wireless connection, or any combination thereof. In one embodiment, an input device or an output device from another computing device may be used as input device(s) 1024 or output device(s) 1022 for computing device 1012.
Components of computing device 1012 may be connected by various interconnects, such as a bus. Such interconnects may include a Peripheral Component Interconnect (PCI), such as PCI Express, a Universal Serial Bus (USB), firewire (IEEE 1394), an optical bus structure, and the like. In another embodiment, components of computing device 1012 may be interconnected by a network. For example, memory 1018 may be comprised of multiple physical memory units located in different physical locations interconnected by a network.
Those skilled in the art will realize that storage devices utilized to store computer readable instructions may be distributed across a network. For example, a computing device 1030 accessible via network 1028 may store computer readable instructions to implement one or more embodiments provided herein. Computing device 1012 may access computing device 1030 and download a part or all of the computer readable instructions for execution. Alternatively, computing device 1012 may download pieces of the computer readable instructions, as needed, or some instructions may be executed at computing device 1012 and some at computing device 1030.
Various operations of embodiments are provided herein. In one embodiment, one or more of the operations described may constitute computer readable instructions stored on one or more computer readable media, which if executed by a computing device, will cause the computing device to perform the operations described. The order in which some or all of the operations are described should not be construed as to imply that these operations are necessarily order dependent. Alternative ordering will be appreciated by one skilled in the art having the benefit of this description. Further, it will be understood that not all operations are necessarily present in each embodiment provided herein.
Moreover, the word “exemplary” is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as advantageous over other aspects or designs. Rather, use of the word exemplary is intended to present concepts in a concrete fashion. As used in this application, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or”. That is, unless specified otherwise, or clear from context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an” as used in this application and the appended claims may generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form.
Also, although the disclosure has been shown and described with respect to one or more implementations, equivalent alterations and modifications will occur to others skilled in the art based upon a reading and understanding of this specification and the annexed drawings. The disclosure includes all such modifications and alterations and is limited only by the scope of the following claims. In particular regard to the various functions performed by the above described components (e.g., elements, resources, etc.), the terms used to describe such components are intended to correspond, unless otherwise indicated, to any component which performs the specified function of the described component (e.g., that is functionally equivalent), even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated exemplary implementations of the disclosure. In addition, while a particular feature of the disclosure may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application. Furthermore, to the extent that the terms “includes”, “having”, “has”, “with”, or variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising.”
This application claims priority to and the benefit of U.S. Provisional Application Ser. No. 61/058,213 which was filed Jun. 3, 2008, entitled ONLINE AD SERVING, the entirety of which is hereby incorporated by reference as if fully set forth herein.
| Number | Date | Country | |
|---|---|---|---|
| 61058213 | Jun 2008 | US |
