Patent Application
20140180835
Advertisements are often delivered with a web service as a way of monetizing the web service. The provider of a web service may include an iframe within the content that is delivered to a user. The iframe retrieves an ad from an ad server and renders the ad while the user is viewing the service's content. For example, the user may visit the service's web page, or may invoke the service's smart phone application, and an ad may be rendered on the user's device along with the service's content.
Typically, the ad is chosen dynamically rather than being a fixture of the service's content. Thus, it is often the case that neither the provider of the web service, nor the end user of that service, knows what ad content is going to be rendered when the user downloads the service's web page or invokes the service's application. Downloading unknown content may present security issues.
Certain web pages provide an iframe element in which an ad is rendered. Since the iframe provides some measure of isolation, ads that can be rendered only within an iframe mitigate some of the security concerns associated with rendering arbitrary, unknown content. However, there are certain contexts where an iframe is not used to isolate the ad content.
Ads may be verified for security prior to being rendered. A content provider may put an ad control into content, where the ad control retrieves and renders an ad while the user is using the content. The ad is digitally signed. When the ad control receives the ad, it verifies the digital signature before rendering the ad.
If the digital signature on the ad verifies, then the ad control renders the ad. If the digital signature does not verify, then the ad control determines that the ad is not safe to render and requests another ad.
Advertisers may submit their ads to a verification service before those ads can be served and rendered. The verification service may be the same entity that delivers the ads to the ad control, or may be a third-party service. The verification service may perform various tests on the ad to determine its safety. For example, the verification service may check the specific components of the ads (e.g., videos, animations, scripts, etc.) for malware. Additionally, if the ad contains a Uniform Resource Locator (URL) that points to a landing page, the advertiser may verify the security of the landing page. (Since the landing page may change even if its URL does not change, the verification service may continue to check the landing page even after the ad has been verified.) If the ad is determined to be safe, the verification service creates a certificate for the ad and signs the certificate. The ad is then entered into an ad repository, where it is available to be served.
The ad control may maintain a certificate revocation list (CRL). If an ad that has been certified becomes unsafe, its certificate is revoked. For example, if the landing page changes and becomes unsafe, then any ad that points to that landing page may have its certificate revoked. If an ad control receives an ad whose certificate is on the CRL, the ad control does not render the ad.
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 features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Online services often render advertisements (“ads”), along with the content that the services provide, as a way of generating revenue. Services such as weather reports, television listings, or online board games may generate revenue by allowing ads to be rendered along with the content that the user wants to see. For example, the user of an online board game may see both the game and a third-party ad for a retail site. An ad typically generates revenue for the service operator when a user clicks on the ad (although other business models—such as cost per thousand (CPM) advertising—may be used).
When online services are delivered through a web site, typically the web page served by the web site contains a location in which advertising content may be rendered. For example, the page generated by the service may contain the service's content on the left side of the page, with a rectangle on the right side reserved for advertising content. The rectangle reserved for advertising is often implemented as a Hypertext Markup Language (HTML) iframe. The iframe calls an ad server, and the browser renders the ad inside the iframe.
But many web services are being provided in a way that is not amenable to the above model. For example, many users access online services on their smart phones or tablets through the service's application (“app”). Apps can have ad controls that cause ads to be displayed while the user is using the app. These apps typically are not implemented with HTML iframes, and often give the app developer relatively free reign to affect the user experience of his or her app on the device by deciding where to place the ad control. An ad contains content that is likely to be unknown both to the provider of the online service and the user of that service. Allowing such content to be rendered presents a risk to the quality of the user experience and, in many cases, a security risk.
The subject matter herein provides a way to verify ad content, so that ads are rendered only after they have been verified to meet certain conditions. In order to provide ads with content, the content provider (e.g., the operator of an online service) includes an ad control with the content. The ad control typically takes the form of code to be included within an app or web page. When the content is loaded, the ad control causes an ad to be retrieved and rendered. Typically, the ad control is provided by the service that will be used to place ads. E.g., Google may provide one ad control that retrieves ads from Google's advertising servers, and Microsoft may provide a different ad control that retrieves ads from Microsoft's advertising servers. The content provider decides which entity it wants to place ads with its content, and includes that entity's ad control in its content. Ad control may also be “universal” and may call an exchange for the highest value offer for the impression.
Ads that are to be served are certified after meeting certain security and content tests. An advertiser may submit an ad for verification. The ad may then be tested in various ways. For example, the various components in the ad (videos, images, scripts, etc.) may be verified to ensure that they are free of malware. There may be certain content limits on the ad—e.g., a service that places ads might place constraints on the type of content that may be in the ads (e.g., banning Flash scripts), even if the content in question does not contain malware. The landing page for the ad may be verified to ensure that the landing page is free of malware. Once the ad has been verified, a certificate for the ad is issued, and the certified is signed. The certified and signature may be created by the entity that operates the ad service, or may be created by a third-party entity that has been recognized to work with the ad service's ad control.
At some point during the viewing of content on the user's device, ad control contacts the appropriate ad server to request an ad. When the ad is received, the ad control verifies the certificate for the ad. The ad control may first verify that the certificate is not on a Certificate Revocation List (CRL). If the certificate is not on a CRL, then the ad control verifies the signature in the certificate. If the certificate verifies and has not been revoked, then the ad control determines that the ad is safe to render, and renders the ad. Otherwise, if the certificate does not verify for any reason (e.g., the certificate is on the CRL, the certificate is expired, or the signature cannot be validated against the ad's content), then the ad control determines that the ad is not safe to render and requests a new ad.
Turning now to the drawings,
In the example shown, an app 108 called “Checkers for WINDOWS PHONE” is running on device 102. App 108 is an example of an app that facilitates the use of an online service. An opponent in the checkers game shown may be played by a server computer operated by an online game service. Or, the online game service may facilitate game play between human opponents who are distant from each other. In either case, app 108 is facilitating the use of an online service, and the operator of that service might want to monetize the service through the use of ads. While a game service is shown in the example of
In order to monetize the underlying service through the use of ads, the provider of app 108 may include an ad control within app 108. Ad control causes app 108 to display ads on device 102. Ad 110 is an example of such an ad. In the example shown, ad 110 has a text message 112 (“Get classic video games”), a video 114 (showing the classic game “pong” being played), and a link 116, which points to a “landing page” for the ad. In the example of
It will be understood that app 108 is an example of content that may contain an ad control that delivers an ad. A web page that is rendered by a browser is also an example of such content. Thus, ad 110 might be rendered as part of a web page. Moreover, all of the discussion herein concerning ad controls that operate with apps applies equally to ad controls that operate with web pages.
When an ad is to be rendered, ad control 202 causes ad requestor 204 to submit a request 210 for an ad to ad provider 208. Ad provider 208 may use any type of underlying infrastructure to provide an ad. One example infrastructure is shown in
In response to request 210, ad provider 208 provides an ad 110 to ad control 202. The ad 110 is received by ad control 202's verification component 206. Verification component 206 may verify ad 110 by verifying the certificate and signature associated with ad 110. Verification component 206 may also check whether the certificate associated with ad 110 is on the certificate revocation list (CRL) 224. Verification component may periodically receive a new CRL 224 from ad provider 208, or from another entity, so that it can determine whether any previously certified ads have been “de-certified.” For example, as noted above, an ad that points to a landing page may have its certified revoked if the landing page becomes unsafe sometime after the certificate was issued. In addition to determining whether the certificate associated with an ad is on CRL 224, verification component 206 may also determine whether the certificate for an ad has expired. Additionally, the certification may contain the identities of the advertisers and the certification authority, and verification component 206 may determine whether an advertiser has been blacklisted or if the certification authority's ability to issue certificates has been revoked.
Once verification component 206 has determined that the certificate associated with ad 110 is not on CRL 224 and is not expired, that the signature in the certificate validates, and that the advertiser has not been blacklisted, and that the certification authority's ability to issue certificates has not been revoked, verification component indicates to ad control 202 that the ad is safe to render. Ad control 202 then renders the ad. If the ad is not deemed to be safe to render, then ad control 202 may request another ad from ad provider 208, which it may then verify again in the manner described above. It is noted that
At 302, the use of a service is started. The service may be an online service, such as a game, weather reporting service, flight status service, or any other type of service. Starting the use of a service may be performed by invoking the app that is used to access the service, or may be performed by visiting the service's web page through a browser.
At some point during the use of the service, a decision may be made to render an ad (at 304). This decision may be made by the ad control that is incorporated into the app or web page through which the user is accessing the service. A request for an ad is made to an ad provider (at 306), and the ad provider responds by serving an ad to the requestor (at 308). The ad may be chosen based on the type of content with which the user is interacting (e.g., serving an ad for a game while a user is playing a different game), based on the user's history, or based on any other appropriate considerations. (If the ad is chosen based on information specific to the user, appropriate permission may be obtained in order to protect the user's interest in privacy.)
The process then proceeds to verify the certificate of the ad. At 310, a determination may be made as to whether the ad's certificate is on the current CRL. At 312, a determination may be made as to whether the ad's certificate is expired. At 314, the signature on the certificate may be verified. The result of these checks determines whether the ad is acceptable to render. These checks may also include a determination as to whether the certification authority's ability to issue certificates has been revoked, or if the advertiser has been blacklisted.
If the result indicates the ad is acceptable (as determined at 316), then the ad control renders the ad at 318. If the result indicates that the ad is not acceptable, then the process returns to 306, so that the ad control may request another ad.
If the ad passes all of the verifications performed at 404-408, then the ad is certified at 410. The result of the certification is an ad 110, which includes the ad's content 414 and a certificate 416. The certificate, in one example, may include a hash 418 of the ad's content, the identifier (ID) 420 of the ad provider, the ID 422 of the certifier, and a digital signature 424.
Once the ad has been certified, the ad (at 426) may be placed in an ad repository 428. After the ad has been placed in an ad repository, the landing page may be verified recurrently (at 430). The reason to verify the landing page recurrently is that the landing page may change even after the ad is certified. The ad itself (including the Uniform Resource Locator (“URL”) of the landing page) is fixed at the time of certification, since hash 418 in certificate 416 ensures that verification of the certificate would fail if the URL (or any other content included in the ad itself) were to change after the certificate issues. (In this way, any change to the URL itself that occurs after the ad is certified would effectively necessitate re-certification of the ad so that a new digital signature could be calculated.) However, the landing page pointed to by the URL can change even if the URL itself does not change. Therefore, to ensure that a user will not be exposed to a landing page that becomes infected with malware after the certificate for the ad has been issued, the landing page may be continually verified, and the ad's certificate may be revoked (at 432) if, at some point, the landing page fails to pass an evaluation. Revoking the ad's certificate may be accomplished by placing the ad's certificate on a CRL, and either making that CRL available in the cloud to instances of the ad control, or by promulgating the CRL to the instances of the ad control.
Device 500 includes one or more processors 502 and one or more data remembrance components 504. Device 500 may be any type of hardware with some computing power. A smart phone is one example of device 500, although device 500 could be a desktop computer, laptop computer, tablet computer, server computer, set top box, or any other appropriate type of device. Processor(s) 502 are typically microprocessors, such as those found in a personal desktop or laptop computer, a server, a handheld computer, or another kind of computing device. Data remembrance component(s) 504 are components that are capable of storing data for either the short or long term. Examples of data remembrance component(s) 504 include hard disks, removable disks (including optical and magnetic disks), volatile and non-volatile random-access memory (RAM), read-only memory (ROM), flash memory, magnetic tape, etc. Data remembrance component(s) are examples of computer-readable (or device-readable) storage media. Device 500 may comprise, or be associated with, display 512, which may be a cathode ray tube (CRT) monitor, a liquid crystal display (LCD) monitor, or any other type of monitor. Display 512 may be an output-only type of display; however, in another non-limiting example, display 512 may be (or comprise) a touch screen that is capable of both displaying and receiving information.
Software may be stored in the data remembrance component(s) 504, and may execute on the one or more processor(s) 502. An example of such software is search and ad rendering and/or reputation software 506, which may implement some or all of the functionality described above in connection with
The subject matter described herein can be implemented as software that is stored in one or more of the data remembrance component(s) 504 and that executes on one or more of the processor(s) 502. As another example, the subject matter can be implemented as instructions that are stored on one or more device-readable media. Such instructions, when executed by a phone, computer, or other machine, may cause the phone, computer, or other machine to perform one or more acts of a method. The instructions to perform the acts could be stored on one medium, or could be spread out across plural media, so that the instructions might appear collectively on the one or more computer-readable (or device-readable) media, regardless of whether all of the instructions happen to be on the same medium. The terms “computer-readable media” and “device-readable media” do not include signals per se. Additionally, it is noted that “hardware media” or “tangible media” include devices such as RAMs, ROMs, flash memories, and disks that exist in physical, tangible form; such “hardware media” or “tangible media” are not signals per se. Moreover, “storage media” are media that store information. The term “storage” is used to denote the durable retention of data. For the purpose of the subject matter herein, information that exists only in the form of propagating signals is not considered to be “durably” retained. Therefore, “storage media” include disks, RAMs, ROMs, etc., but does not include information that exists only in the form of a propagating signal because such information is not “stored.”
Additionally, any acts described herein (whether or not shown in a diagram) may be performed by a processor (e.g., one or more of processors 502) as part of a method. Thus, if the acts A, B, and C are described herein, then a method may be performed that comprises the acts of A, B, and C. Moreover, if the acts of A, B, and C are described herein, then a method may be performed that comprises using a processor to perform the acts of A, B, and C.
In one example environment, device 500 may be communicatively connected to one or more other devices through network 508. Device 510, which may be similar in structure to any of the examples of device 500, is a kind of device that can be connected to device 500, although other types of devices may also be so connected.
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.
