Let’s look a bit closer at the second mechanism: Whenever an AMP page loads any resource, such as images, videos, ads, analytics requests, tweets, or any of dozens of other types of resources, the associated network requests are controlled by a central resource management mechanism. This resource manager, in addition to performing many other functions, also ensures that requests that are not allowed during the prerendering phase of a document lifecycle are held back until the document learns that the user expressed intent to see the page.
Diagram of the process to load a resource in the AMP JS library.
This is the key architectural feature of AMP that makes it uniquely suited to implement more sophisticated privacy controls on top of this baseline mechanism.
The previous paragraph talks about how AMP controls resource request timing to ensure that certain requests made during the prerendering phase are only actually made after a user has expressed intent to visit a page. From a software architecture point of view, this introduces a central mechanism to control request timing, making it relatively easy to then introduce additional rules, including rules specified by the publisher of the page, for delaying requests on top of the pre-rendering specific rules.
For example, one such publisher-specified rule could be to delay any ad requests on an AMP page until the publisher has obtained sufficient user consent to make such ad requests or share ads-related data with an ad vendor.
For each AMP web component (such as the amp-ad and the amp-img elements), a publisher can specify that the associated resources should only be loaded if the user has provided consent that the publisher has determined is needed to load and display the respective resource.
Diagram of the process that determines the flow to requesting a resource in the AMP JS library.
While a publisher may still need to perform an audit of the types of AMP web components they load on their page and determine whether any form of user consent may be needed to display them, having a unified mechanism to control the behavior of all resource types that may be included in a page–from images, over ads, to analytics–should make it easier for a publisher to gain confidence that they applied the consent treatment to the full spectrum of resources and behaviors where it is needed.
This post looked at privacy-enhancing functionality from a software architecture point of view. For concrete steps to implement user choice flows in AMP documents, please check out this blog post.
Posted by Malte Ubl, Tech Lead of the AMP Project.
- + + diff --git a/scripts/update_blog_links.js b/scripts/update_blog_links.js index c707caab927..8e3a8ee214e 100755 --- a/scripts/update_blog_links.js +++ b/scripts/update_blog_links.js @@ -129,7 +129,7 @@ ${ body } /* Converts the provided RSS blog item into a consistent format. */ function onParseBlogPost(item) { var authorInBody = item.description.match(/\>Posted by ([^,]+),([^\<]+)/); - var author = authorInBody ? authorInBody[1] : item.author; + var author = authorInBody ? authorInBody[1].replace(/<[^>]+>/g, '') : item.author; var role = authorInBody ? authorInBody[2] : ''; return {