Fight With Tools by AramZS

Here's how I know more people read my personal blog via RSS then any other platform

Wed, 25 Jun 2025 14:30:00 -0400

I want people to read my RSS feeds. but I also want to know how what my RSS readership is without breaching their privacy. RSS feed readership measurement is an… imperfect affair. Because it is a service that people generally charge for (or require you to give up audience data for) it isn’t well documented. Here’s how I did it.

I’m a big proponent of setting up fast, small, flat websites on the cheap. That means using free hosting and building services as much as possible. The goal is to put the tools for crafting the web in the hands of as many people as possible.

RSS feeds present a set of unique problems for measurement which is why many companies, including big ones, don’t do much to try and measure them.

The first big problem is that the big RSS readers cache your feed so they don’t have to ping it constantly. This means that requests to your RSS feed URLs aren’t really representative of the amount of readers you have.

Also a lot of RSS readers will cache the inside of the feed, so not just text but images will often get baked into the caching of a reader so that more complex reading applications don’t have to over-request your site. This is one of the big challenges of measuring podcast downloads as well, iTunes and Spotify will absolutely save local copies of your file and only the introduction of an intermediary service capable of authoring agreements with all the major players have kept podcast measurement fairly reliable and kept all entities involved agreeing on the same numbers.

As far as I can tell, only Feedburner came close to being the Podtrac of text RSS feeds and since then, no one has really emerged as the one true agreed upon analytics provider for feeds that feed services will ping. I think that’s good actually. One True services are generally a recipe for disaster.

By an apparent unwritten agreement, major feed services will tell you about the readership of your feed in the header of their requests apparently, this is visible in server logs as Darek Kay discovered in 2021. Though this isn’t particularly standardized (requests don’t seem to share a format) it seems useful… if you can get your server’s logged requests and generate reports based on them.

If you are building fast, cheap, free-hosted sites like mine however, that is not an option. Also, I’m too lazy to futz around in server logs right now, even if I had them at hand.

So I wanted to try some stuff. I tried sending up an SVG that had analytics embedded in it. That did not work. I didn’t bother with an old time pixel since I knew that trying to have an image on a server whose logs I did control wasn’t the solution I wanted, even if it worked.

Instead I looked at the feeds I read and realized something.

There are videos in there. All those videos are handled like modern videos mostly are, embeds via iframes.

Now, iframes are not technically allowed in feeds, but the modern blog will tend to use them a lot for stuff like video, social media embeds, etc… anyway and it looks to me like most feedreaders will render them!

This is great! Now I can deploy an iframe and a page with analytics running on it and see if it works and… it does!

So I put together an HTML page:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <title>Private Feed Tracker</title>
	<style>
		  * {
			box-sizing: border-box;
		  }

		  body {
			margin: 0;
			padding: 0;
			overflow: hidden;
			background: #03092c;
		  }

		 img {
			margin: 0 auto;
			display: block;
			padding: 0;
		 }
	</style>
	<script data-domain="aramzs.xyz" src="https://plausible.io/js/plausible.js"></script>
  </head>
  <body>
	<!-- Hi! This image is loaded in an iframe on my RSS feed as a way to try and measure how many people are reading me through RSS. The tracking is privacy respecting and your data will not be sold. I'm just curious.  -->
	<img src="/feed-img.svg" width="50" height="50" alt="Site logo">
  </body>
</html>

As you can see, I’ve created a standalone HTML page on my personal blog site that includes a simple call to my privacy-focused analytics provider Plausible.

Then my RSS NJK template gets the iframe that loads this file added to the end of every article’s content block:

set postContent = post.templateContent + '<br></br><iframe width="50" height="50" src="/some-url-with-that-html" title="Privacy-respecting tracker for feed readers" frameborder="0" allow="web-share" referrerpolicy="strict-origin-when-cross-origin"></iframe>' | htmlToAbsoluteUrls(absolutePostUrl)

And yeah, this works! Now maybe some services cache iFrames as well, and so what I’m really getting isn’t my full readership but a baseline of minimum-measurable-readers. This is very possible, but even the baseline is an exciting number to be able to get access to without enlisting anything other than my normal analytics provider!

It’s possible they’re getting pre-loaded in some contexts; but I suspect most applications won’t load iframes in a post until the post is opened by the user. It is also possible that this is only getting loaded because it is a visible image, but I didn’t test out a 1x1 version to verify. I didn’t want to seem sneaky here, I want to make it obvious that an asset is loading from my site.

I think this is a pretty reasonable number to work with!

And look at my past 28 days! It turns out that I am getting more traffic on my RSS posts than on any other individual page.

And when I break it out as a source it constitutes over a third of my traffic.

This is super exciting to me! I want people to consume the two RSS feeds I produce for aramzs.xyz. It looks like they are!

Some Interesting Information

I specifically use Plausible as my analytics provider because it is non-invasive, quick, and privacy preserving. I don’t want detailed user data, or even anything other than the most generic data about users. But I do like having referrer data and when I looked at Top Sources I was surprised to see a whole bunch of sites.

I am not sure what exactly is happening there, or how to figure out more information with my current setup, but I assume some of these are people flowing from those sites into my RSS feed when their browser has something that renders the feed directly. The presence of Inoreader makes me realize that readers will also show up as referrers in this process. I think this means that a bunch of these sites are running their own white-labeled in-house RSS readers for their employees or users, which is really cool!

What is next?

I have two RSS feeds for two very different purposes, one supplies my own writing, the other is an amplifeed of articles I want to amplify (like a retweet!). I might give those two different iFrames to see how the different feeds perform separately.

I would also like to know which specific articles are getting loaded by readers, it would be nice to combine into my metrics, but I just don’t think that’s possible with my current setup. What I might try is some link-decoration to track the article names/urls as setting up alternative URLs is just not desirable. I’ll have to see if that works or causes issues (since I know some applications and browsers will intercede against or strip out link decoration).

If you’ve tried this or have had some experience with this sort of thing, hit me up on BlueSky.

Comment on the IAB Tech Lab's Global Privacy Platform (GPP)

Fri, 02 Sep 2022 10:00:00 -0400

Summary

The Global Privacy Platform is intended to absorb the functionality of TCF and expand on it, as a consent-string-based privacy solution. While GPP expands the scope that the system can cover it does not resolve any of the intrinsic problems of the TCF approach. The result is a compounding of a deeply flawed system that, while it improves on the underlying concepts, does not resolve the core issues and therefore seems likely to face significant challenge from regulators and privacy advocates.

While this is a standing issue of TCF, it is extremely troubling that GPP seems like it wants to push the boulder down the road, creating adoption costs, compliance work, and additional technical overhead only to be eventually abandoned for not addressing most regulatory concerns. This would be less of a concern if GPP showed any way that it could be hooked into better solutions, or clear paths towards transformation into a system that would meet compliance expectations. However, GPP–in this draft–does not do that.

While a publisher-based perspective doesn’t have leverage to turn this ship, I recommend against the IAB moving forward on the specification as it currently stands without a fundamental shift in methodology. If there was ever a time to significantly change our approach on consent management, it is now. GPP is not that change.

Table of Contents

System Assessment
GPP Principles
- A Note on UI
Notes on Compliance Issues and GPP’s Relation to EU Court Findings
Ways Forward

System Assessment

The Global Privacy Platform can be looked at as a four part system.

The first part is composed of the interactions with previous compliance APIs, including TCF and USPAPI. This has its own flaws, outside of the flaws of the underlying systems which will not be discussed on their own here.

The second part is the Accountability Platform (AP). While the AP is technically a different set of standards, it is both intended to interact with the GPP and is a fundamental part of supporting the concept of the GPP as an answer to the open legal challenges TCF faces.

The third part is the GPP API, this system is the technical means by which a user’s consent can be signaled and transmitted. GPP offers some new functionality over the TCF system on which it is modeled, but is mostly derived from TCF, as stated in the proposal: “this RFC builds so heavily upon TCF v2.0 technical design.

The fourth part of the system is the Consent String. This also has some technical improvements and changes over TCF but is identified by the proposal itself as being heavily derived from the TCF2 approach.

This section breaks down analysis and criticism over each section of the GPP proposal.

API Layering for GPP’s Technical System

Where GPP is intended to interact with OpenRTB, I agree with the authors that ext.gpp is the correct placement. Placing it on the user object would be confusing and the authors are correct to avoid it.

The GPP proposal would layer over existing APIs. This means that the specification expects that there would be at least 2 APIs preexisting on the page along with GPP instead of being supplanted (TCFv2 and USPrivacy). This is natural as a first step for deployment, I don’t want any gaps in coverage and can’t assume upgraders will do so evenly. However, the spec does not describe any future progression past this point. It is generally undesirable to have to maintain a growing list of window level objects, especially since the specification allows for the concept that other APIs might grow underneath GPP, creating situations where individual APIs multiply and increase complexity of compliance.

The system also creates a replica command API, to quote the spec:

a call to __gpp(‘iabtcfeuv2.getTCData’,myfunction) will be translated by the CMP to __tcfapi(‘getTCData’,2,myfunction).

My hope is that this is conceived as a path towards the eventual depreciation of underlying APIs. However, the spec does not make this clear and it is an unnecessary ballooning of on-page code to handle.

Even as a path towards depreciation of TCF and the other underlying APIs it seems overcautious. Systems could attempt to use __gpp commands first with the getSection argument and, if either the on page object or the command doesn’t work, they could then fall back to __tcf. In fact, almost every system is likely to do something very much like this anyway. It’s a great deal of unnecessary overhead on the publisher and CMP that will then almost certainly be replicated on the side of other systems. Additional complexity and code like this is undesirable and the spec does not seem to make sufficient arguments for its inclusion.

This additional complexity also makes the existing flows for the __gpp-level generic commands less clear. The most prominent example is addEventListener.

addEventListener

Is it expected that addEventListener will also be applied to all the underlying APIs so that every API, _gpp, __tcf, __uspapi, and others on page, will trigger the callback? If __gpp commands that can also apply to underlying APIs are intended to be generic instead of GPP-only this signature is poorly designed and should be reconsidered. Any commands intended to be generic should follow the pattern of the API-specific commands with a format like all.addEventListener or some other prefix that makes clear its intended execution.

“The addEventListener command returns an EventListener object immediately. It will then call the callback function every time the CMP detects a change (see events below).” should be rephrased for clarity. Suggested: “The addEventListener command returns an EventListener object immediately. The GPP script will then call the callback function and return a new EventListener object every time the CMP detects a change (see events below).”

Notes on Accountability and Signal Integrity

It is unclear if the Accountability Platform has made significant progress since the last RFC for it. At that time and on review of the accountability approach it was clear the proposals in that space are interesting for after-the-fact auditing. Some of the other proposals are interesting from the perspective of attempting to secure the bidstream data from alteration. None of the proposals seem to address the core problem at the heart of TCF and now GPP, which is that they do not create enforcement mechanisms to force particular data to flow or not flow; they do not guarantee that a single platform would be compliant with a consent signal as received; and they do little to secure the ad tech ecosystem against abuses by buy-side operators, such as misinformation or malware operators, anymore than the existing system does.

Further, the accountability systems do not empower users or organizations that might represent users, be they activist coalitions or individuals seeking to exercise their full rights under privacy regulations, to act to protect themselves.

Finally, an audit system as proposed means that bad actors are not held credible during a transaction, but after the fact. Existing reports of non-compliant actors in the ad tech ecosystem indicate that there is willingness, capability, and profitability for bad actors to manipulate the bidstream. This would just as easily extend to logs. The 2021 Accountability RFC suggests real-time hooks for accountability and it seems those should be a clear priority over non-real-time attempts at accountability and maintaining signal integrity.

While there might be some proposals, perhaps even stemming from those linked in the GPP RFC, that could solidify signal integrity of the GPP signal, the current presentation of solutions does not appear to do so. At the current state of the associated proposals there are no sufficient accountability or signal integrity guarantees.

GPP’s API

TCF2’s current state is faced with considerable objections from the EU courts. The fact that the GPP API seems to do very little other than replicate it is discouraging.

Promise operations on-page are a fingerprinting vector, as timing around the response could be used as part of a set of properties that could identify the user. This is an existing problem with TCF and promises are an existing browser-level privacy issue. However, it may be worthwhile to discuss, since GPP is a privacy-related technology, requiring some level of noise in promise return time. While this might be outside of the scope of the GPP specification, I think it would be worthwhile for the IAB to investigate both in terms of risk and the feasibility of avoiding that risk.

postMessage

There is no clear statement as to how or if postMessage use is intended to be extended from the IAB’s TCF2 API to GPP. Without notice otherwise, I assume so. postMessage is increasingly at risk for this use, FencedFrames may render it useless. Cross-domain operations with GPP should be explored more in depth in the specification.

Stub Code

I recommend that additional information be added to the spec for the _gpp “stub code”. In the wild under TCF this code is often lacking. Bad implementation causes compliance issues. Many CMPs do not have the stub as part of the default implementation. A stand-alone section should outline the expectations around stub code in more detail.

cmpId

cmpId is another carry over from TCF that is generally undesirable. It creates the problem of a centralized list of CMPs, over which gatekeeping can occur. That centralized list is also an obstacle for new entrants. And it is unclear why it is needed in any of the API responses? cmpId may be 0 in some responses, as noted by the specification. If the concern is allowing downstream or upstream systems to note a bad actor CMP, why would that system not just fake the CMP ID? What is this number intended to protect or accomplish? It seems like an addition of complexity, data, and oversight to no clear end.

Manifest Issues

The documentation of the Manifest is extremely unclear and requires additional details. Is it expected that every participant would have a manifest including CMPs and Publishers? Published as a JSON or on a simple web page by whom? Where? To what end? Is the manifest expected to just be within the API or the GPP string? Is it expected to be encoded? How is it expected to be used? The specification needs to answer these questions.

Both the dataUses and possibleStates are poorly documented in this specification. The final specification should be clearer about the intent and use of these fields. They are getting their values from the preceding tables but it is unclear what their use is. Presumably regulatory requirements are understood by all parties? If so why would these fields ever differ between participants? Why would they differ between publishers or CMPs? If so, how are readers of the manifest expected to take that information and use it?

The Global Vendor List

The Manifest lists a gvlUrl property, GVL presumably indicates the “Global Vendor List”, an IAB-maintained list. Does that mean that property will always be the GVL for the particular compliance framework? Or is it intended that it could be filled by one of the other vendor lists the spec notes.

As the specification notes, some vendors are on more than one Vendor List. Some vendors are on only one Vendor List. Should the gvlUrl be an array to support multiple lists? The GPP specification suggests that all build on the IAB’s Global Vendor List… but the IAB has not gotten even some major advertising systems to sign on to their TCF2 list, which contains a mere 1,142 vendors at last check, a miniscule number compared to the count of overall ad tech operators. As a result it isn’t uncommon for sites to need to reference both the IAB’s list and Google’s ATP list under TCF. Major ad tech vendors have also failed to sign the LSPA. This seems unlikely to change under GPP but this is not acknowledged. Suggesting everyone use the IAB’s GVL is clearly unrealistic. There does not appear to be effective solutions designed for this problem beyond the already insufficient solutions in TCF2, which are overly complex and require significant transmission of data that can max out headers and URLs for ad requests. The discussion about the GPP Identifier in the specification is not a sufficient answer to these questions.

The Registry API

The Registry API discussion appears to be an extension of the GVL conversation above it. Beyond the existing functionality of the GVL being questionable, if the specification proposes that there might be use of other vendor lists and the capability to point to them as the primary vendor list in the use of the specification, it should go further and propose a common format, API, and method of access that can be expected by any list that is intended to interact with the GPP and Accountability system. These and future vendor lists are, of course, not bound by any IAB suggestions, but it is ludicrous to propose that vendors might be identified by significantly different IDs across different CMPs or maybe even different GPP calls, without specifying the format by which those vendor lists might be accessed to resolve those IDs. A finalized specification should include the expected format for Vendor Lists and the expected access methods.

Without specific information about the expected format of vendor lists why wouldn’t bad actors simply specify different vendor lists that are harder to access or audit.

Mobile SDKs

It seems that there is likely to be a great deal of overlap between existing TCF key values in the app and new GPP key values. It’s hard to tell right now since “A full list of all the names will be published in the final specification.” GPP should create more documentation around how the existing values might overlap, what could be an eventual path towards depreciation of replica values, and how that can be minimized. Attaching more and more consent data to users in the app will significantly increase the risk of it becoming a fingerprinting vector, especially when dealing with uneven depreciation of fields, and should be avoided.

Much of the consent string generation process is replicated wholesale from TCF, including its problems and concerning processes, many of which are already well-detailed by the EU’s courts. This is highly concerning and seems to indicate that work on GPP should be paused.

Putting that aside for now, GPP has brought forward some useful innovations. After technical testing it appears that the approach of Fibonacci Encoding does not require much additional code and executes quickly. In running an initial test using the most popular encoding algorithm I found that this required less than 2kbs of additional code and was able to execute at a speed ranging from sub-millisecond to 2ms, both server and client side. There are indications that encoding can be handled even faster and with less code. I found this way forward highly effective for compression of data in the way the GPP RFC proposes.

One of the subsections handles Legitimate Interest. It seems clear from recent EU court cases that this is not possible to claim against a users’ consent and as a methodology it does not seem likely to be replicated by future privacy laws. It should be noted as depreciated or perhaps fully removed from the spec. This also opens up the question of what happens to depreciated data uses or states, which it might be useful to explore in the spec.

Finally, I really appreciate the un-encoded iteration of the USPrivacy String attached to the end of the GPP string. I believe that the USPrivacy approach represents a clear, transparent, and easy for users to understand methodology that I wish was more broadly applied.

Vendor Consents

At the end of the day however, GPP, even with the improvements like Fibonacci Encoding, represents an unbound string that could theoretically expand forever, getting larger and more difficult to manage as the number of privacy laws and vendors increase. Per-vendor consents represent significant problems: the EU courts have challenged them, they are the biggest source of consent string bloat, vendor registry and identification issues plague both TCF and this proposal. It seems impossible to continue with this process, and unrealistic to expect users to dig into those nuances.

So many problems that GPP faces would be resolved by removing this concept. Vendor consents do not reflect regulator or user expectations for a system like GPP. They encourage the creation of dark patterns and bad UX. Worse they increase the fingerprinting risk for users and the overhead for transmission for publishers and all participants.

Server to Server operations are not fully explored in this specification beyond use of OpenRTB. However, consent states apply to all sorts of other data transactions including the growing use of 2nd party data trading and clean rooms for targeting. It would be useful for the specification to include a section that addresses how, if at all, it might be used in these contexts.

GPP Principles

I generally agree with the GPP principles. I’m especially interested in the ideas around converging regional- and country-level laws into standard compliance signals (“jurisdictional overlap”) that understand rights as overlapping and capable of being commonly represented. I think these are good principles. However, they do not seem to broadly inform the specification.

The existing GDPR purposes are just added to by the CCPA purpose instead of specifying some sort of overlap or understanding of the CCPA’s opt out as a compounding of other signals or–more usefully–visa versa. In fact the generalized opt-out specified by the USP API is so much more useful because of its generalness it has become a way to specify privacy in other situations. It would be great to see a deeper exploration of the GPP principles in the GPP specification; especially when leveraging a concept like jurisdictional overlap could result in significant simplification.

A Note on UI

The GPP specification does not explore the user interfaces that might support it. In the case of a privacy tool that is irresponsible, especially considering the IAB is facing legal action over encouraging ineffective and misleading user experiences through TCF’s design. Without express guidance around UI, participants have to assume that systems will default to the TCF UI recommendations and patterns. These UIs are not as effective as they should be, are perpetually under challenge in courts and the loose rules around them allow the creation of outright anti-user designs. The GPP should not repeat the mistakes of TCF here and make clear specific user flows, especially where the API identifies interactions with specific screens as it extends from TCF.

Notes on Compliance Issues and GPP’s Relation to EU Court Findings

GPP does not appear to address any of the standing objections by EU courts around TCF. In fact the specification makes it very clear that it is pulling from TCF wherever possible, repeating many of its mistakes. It is hard to see any entity getting behind adoption of GPP while the fundamental underlying assumptions of TCF which it replicates continue to be under threat of being declared illegal.

It was my hope that GPP would represent a progression, a resolution of some of the problems TCF presents for compliance.

It does not.

GPP’s transmission of consent strings downstream still presents a fingerprinting risk through their complexity. GPP does not provide active enforcement mechanisms. The system does not do anything meaningful to assure that individual users’ choices are respected throughout the ecosystem.

GPP’s continuation of vendor-level consents is overwhelmingly complex, unfair to users, and creates unnecessary technical complications. It also encourages difficult or bad user interfaces in order to handle compliance on top of GPP; ones that would seem to be only more complex than TCF.

With the potential for endless expansion, both on-interface and on-string, is unbound and could grow infinitely over time. This also compounds the risk of the GPP string being useful in fingerprinting users, and perhaps even becoming a fingerprint in-and-of-itself.

Considering the objections that TCF faces, an attempt to present GPP as an evolution of TCF that would address TCF’s problems–when it does not truely address those problems–is a threat to the continuing existence of Open RTB. The real time bidding ecosystem is desperately in need of an effective consent system.

Without a reliable consent system RTB may be declared fully illegal by regulators, lawmakers or courts. GPP is not a reliable or effective consent system and pretending otherwise only puts the entire ecosystem at further risk.

Ways Forward

It is time to go back to the drawing board on the parts of GPP that replicate the flaws of TCF.

GPP should consider enforcement mechanisms, real time hooks, active script control on the page, and active protection of users who do not consent to tracking. It is within GPP’s scope to build and standardize such systems.

GPP should remove the concept of vendor-level consents. Expecting vendor-level consents is not consistent with user behavior and, while I previously had no data to back that assumption up, years of TCF shows vendor-level consent to be pointless. No significant number of users is going to go through even the smaller list of over one thousand ad tech entities and make specific consents for one of them outside of their choice for the other. That is even less likely should vendor lists expand to encompass more and more vendors, which is likely to happen as additional ad tech operations become relevant to privacy regulators. It’s time for the IAB Tech Lab to drop vendor-level consents. Anything less would give us an insufficient specification.

The IAB’s work on the USPrivacy API should be taking the lead here: simple, human-readable, privacy signals. The IAB Tech Lab’s excellent work on understanding jurisdictional overlap can be used to support simpler, better and more straightforward privacy strings that operate along those lines.

Cover image is “portrait of a confused person at a computer” generated by Midjourney

Topics API Review

Thu, 04 Aug 2022 13:00:00 -0400

With the Topics API now in origin tests, it has been interesting to see just how the web gets categorized. I do see a lot of potential in the technology and I can’t argue with the privacy promise being a significant improvement over third party cookies. The biggest issue with Topics is how it will exist within the larger network of advertising technology entities and the market mechanics of the ecosystem.

Topics might provide useful transitional technology to move off third party cookies and create privacy improvements, but the ad tech marketplace provides a clear history of such technologies becoming used in problematic ways: to enrich middlemen, confuse and mislead buyers, and disempower the site owners on which the associated ads would be run.

Qualities of Concern

I make some assumptions in this assessment that may be less common among others examining Topics API.

1: Topics will become the system of highest trust. Trust between participants in the ad tech ecosystem is extremely low. At the same time, almost all participants are seeking the “surest thing” within ad tech. Or at least the capacity to represent themselves as providing the “surest thing” to buyers. This includes metrics, anti-fraud and, perhaps most of all, tracking. While other systems operate mostly on a closed basis and provide tracking and tagging of users through black box systems of decreasing (if ever successful) accuracy, Topics would provide a transparent system of user categorization, based on open source technology, created through insights generated though a browser’s full access into users’ history online. As buyers flock towards accuracy, Topics will–if released to all Chrome users–quickly become the most desired dimension of user tracking. I therefore assume buyers will assign Topics high value.

2: Inevitable Commoditization of Topics within Blackbox Systems. Because Topics will become the most trusted property for defining users, Topics will quickly become integrated in multiple other systems where it will become mixed with other signals as part of a way to keep these systems’ proprietary user signals competitive with Topics. Pressure to activate Topics will become increasingly high as requests by buyers’ for this targeting are paired with 3rd party ad tech systems’ pressure to activate them as well. Ad tech intermediaries will consider the ability to collect Topics to be of high value, and the wider variety of Topics the better. It is inevitable that the launch of Topics will be followed by the emergence of a market in closed-source Topics prediction and Shadow Topics that will become of high value because of the borrowed trust from the browser system.

3: Sites will bend towards optimizing for Topics. Because Topics will be of high value for ad pricing and ad tech intermediaries will consider access to a variety of Topics to be of high value, I believe that their entry into the ecosystem will inevitably push to alter the web publishing ecosystem back towards single-topic-per-domain sites with narrow focus. Small, focused sites that can acquire large audiences will find ecosystem-level advantages over large general-focus sites and gain high value CPMs through arbitrage. This is not the first time the advertising ecosystem has encouraged this exact change and it was not advantageous long-term in the past, not to mention: potentially misleading users, encouraging spammy sites, and forcing sites into configurations that will become extremely disadvantageous after third-party cookies are entirely eliminated. Some sites will debundle into networks of topically focused sites in order to acquire users with the particular Topics that mark them as high CPM opportunities. Only the general news sites that are already part of a large ranging network of smaller Topically-focused properties with which they share an internal ad tech domain will see the monetary benefits of Topics without altering their behavior. Other large general coverage sites will be forced to load a large variety of third party scripts to participate effectively in Topics and will lose any potential gains to ad tech tax, performance decreases, and arbitrage behavior. In any case this will replicate and worsen the phenomenon of ad systems deforming the behavior of publishers.

Privilege of Large Scope Systems

I believe that the objections to FLoC on the basis of creating an even playing field for all systems that query the API were incorrect. If there is to be any access to these types of tracking terms, as decided by a browser, privileging that access to only those systems with the widest scope of domains on which they have a presence replicates, solidifies and may even worsen the worst behavior of the ad tech ecosystem. It will further discourage new entrants and competition while solidifying the status of current ad tech participants who run scripts across a wide range of domains. If large ad tech participants are the only participants to have broad access to Topics, the privacy risks are just as great, if not greater, because of their capacity to record a wide variety of user behavior. Solidifying the ecosystem around these participants also increases privacy risk as it empowers them to further attempt to breach users’ privacy using their preexisting massive tracking apparatus and capacity to join data with other systems through data purchases and corporate mergers. At the same time it lacks the capacity to keep such ad tech systems honest by giving other participants the capacity to check big systems’ Topics reporting with their own.

However, broad access to Topics gives an opportunity for smaller participants to act competitively on the open market and potentially refuse to participate with large ad tech systems that wish to mix Topics into proprietary black-box targeting. If, as I assume, Topics becomes the user property of highest value, then sites willing to transmit Topics in clear text will be able to avoid the market dynamics that pressure them to implement third party scripts, by making the highest value property available directly to the buyer.

There has been some discussion of a large-scope publisher consortium to share and retransmit Topics, but this does not solve the problem of running such a script on non-publisher sites where users are likely to obtain valuable topics (like advertisers’ pages). Further, the costs involved in running such a system would seem to inevitably force it into replicating the exact undesirable models of behavior publishers would see from other participants, in order to compete and cover costs.

Large, Multi-topic, Reputable domains

Large general topic news and information sites will not contribute meaningfully to the generation of high-value user Topics. Considering that Topics will be considered high value and mixed into black box ad tech systems, a shadow market of Topics prediction will almost certainly arise and be given value. This market will generate Shadow Topics on the basis of particular domains seeing Topics commonly held by multiple users over multiple Topics generation epochs. This will mean that Shadow Topics will be more likely to appear within predictive ad tech systems (especially the blackbox systems that claim to pass along Topics, who can treat predicted and actual topics the same) on small topically-focused sites. The result will disadvantage large generally-focused sites from participating within the Shadow Topic ecosystem and disadvantage them in CPMs. It will also increase incentives for dishonest user categorization by ad tech ecosystem middlemen who maintain these Shadow Topic systems.

Arbitrage and “Drive to the Bottom” Pricing

The per-domain classification process that Topics currently uses will generate significant incentives in user valuation towards driving users towards topically focused sites and therefore attaching Topics to them. This will further increase those sites that see common participation among users in high value topics incentive to participate in a Shadow Topic ecosystem which will reward them with high CPMs. This will replicate, worsen, and calcify the current system of ad arbitrage to the advantage of sites that can be spun up quickly, generate content that will focus users into specific Topics, send those users through a funnel of well-known Topic sites, buy a great deal of traffic, and then resell that traffic on their own site for high CPMs. This will drive CPMs down on reputable sites while encouraging the creation of low-quality but topically focused sites. It will also force large general-coverage sites to spend more money on arbitraging users with specific Topics, paying to have them come to the reputable site to sell ads against them and also to increase bids on the reputable site by training predictive systems systems to include high value Topics for a domain in that domain’s Shadow Topics. This is a cycle that already exists because of third party cookies and does not advantage users, buyers, legitimate operators of ad tech or the health of the web. If Topics replicates it as is and does not provide a way to curtail this cycle (which I cannot see it doing in its current format) then it is reinforcing one of the very negative outcomes of third party cookies I had hoped to see ended.

Ad Safety Risk

While the limited set of Topics is relatively unlikely to trigger negative targeting, it is easy to see a future expanded Topics set where a Topic will cause a user to be negatively targeted in a way that could be dangerous. Even among the current topic set there are risks. 243. News could become a negative targeting vector for buyers who wish to spread misinformation. 140. Software could become a positive targeting vector for crypto currency scams. While these are dangers intrinsic to any tagging system, including contextual, an inability to block specific Topics could leave a site vulnerable to malicious buyers who would pay higher sums for highly accurate Topics, while the pressure from good buyers will leave legitimate publishers with little choice but to participate. All user-based tracking presents this risk, but the inevitable buyer preference for Topics increases this pressure.

Sites who Cannot Exclude a Low Value Topic will be at a Disadvantage

Sites may find themselves commonly attracting users with low value Topics, or potentially seeing an attack by user agents who intentionally acquire low value Topics and go to the site in order to train ad tech middlemen running Shadow Topic systems to believe that the site attracts low-valued Topics traffic. These sites will find themselves having to choose between the pressure of buyers and buy-side systems who want Topics and turning it off entirely. This risks the entire Topics ecosystem as some high value sites may find it more advantageous to turn off the Topics system. Alternatively, sites may find themselves unable to withdraw from Topics due to market pressure and see their CPM values slowly drop with no clear solution. It is clear that individual domains should have the capability to have more nuanced options than Topics being active or inactive. Sites should have the capability to block any Topics-consumer operating on their domain from receiving specific Topic terms.

Privacy Promise

Outside of the larger ecosystem impact I foresee Topics could have, user privacy here is well preserved. I have been impressed by the privacy improvements and believe that Topics presents a privacy improvement over both FLoC and third party cookies. Obviously some users will not want to be tracked at all, and others will continue to find the idea of being ‘followed’ by interest-based advertising unsettling. Topics is not perfect for privacy for these reasons and I’m sure for others that more focused privacy advocates may discover. Implied decisionmaking on the basis of Topics and their ability to contribute towards more indirect algorithmic redlining and discrimination is still a risk. However, I recognize that there is some privacy risk that has been determined to be desirable in exchange for the wider functioning and profitability of the web, especially in a time of transition.

Additionally there will be periods of higher and lower risk for Topics use. It may be worthwhile for Chrome, or any implementer, to consider agreeing on block-out dates for Topics epochs. It would be wise to define sensitive periods where any additional user tracking has a higher risk of being used maliciously and the need for user privacy has an increased societal weight, like elections.

A High Risk of Reversal on Performance

The past few years have seen an increasing focus on site performance, in part led by Google’s introduction of Core Web Vitals as a Search Optimization signal. Increased performance has benefited the users of the web and digital publishers. Because Topics assignments are only visible to those systems that are on the page when a Topic is assigned, it is likely to reverse the recent trend towards moving ad tech systems to small-script or no-script approaches that keep third parties’ scripts off domains. Because of the high desirability of Topics and the high desirability of Topics-mixed products every ad tech system will want to have a script on-page and they will want to participate in as many domains as possible. This is not a desirable outcome for users or site performance.

Assessment:

At this time I do not find Topics a desirable proposal. While I have made some suggestions here that could lead to improvement, perhaps drastic, I believe that Topics’ capacity to impact the larger ad tech ecosystem in a negative way and to solidify some of the existing problems within that ecosystem, presents a high risk to the health of the web, even looking at Topics as a temporary measure. There was significant feedback on FLoC from privacy advocates around the question of access, but Topics particular approach to limiting access means that the pressures and mechanics of the ad tech ecosystem would damage improvements in privacy that Topics’ current construction around limiting access could create. If this system were to go forward it is more desirable that Topics be broadly accessible. Especially because doing otherwise will inevitably become a false privacy promise when ad tech systems will predict and trade in Topics information the same way they have with other user data. This type of access limitation is fundamentally not maintainable when the rest of the ad tech ecosystem comes into play, even if accuracy is lower. Privacy for users is further threatened by how Topics is likely to be rolled into the larger ecosystem.

While this assessment is generally negative on Topics, it is not intended to be a discouraging one. Topics does show many interesting properties and I would like to see this style of browser mediation of advertising potentially built upon further in privacy-preserving ways. With the addition of more nuanced controls given to domain-owners/publishers, I see a potential compromise in the future of such systems. As long as users can make the choice of if they trust their browser with these operations, there is potential to create a smooth offramp from third party cookies towards better privacy across the web with these methods.

Cover image is “people being categorized” generated by Midjourney

On the Characteristics of an Effective Consent Signal

Thu, 05 May 2022 16:00:00 -0400

What follows is the written copy of my comments to the California Privacy Protection Agency. I spoke to the CPPA on behalf of The Washington Post about privacy law and rights to opt out.

Hello, I am Aram Zucker-Scharff, the Lead Privacy Engineer for The Washington Post and Senior Solutions Engineer for our Zeus advertising technology group, which serves over 100 news sites. I also co-chair the W3C’s Community Group focused on Private Ad Technology and contribute to other groups to speak on issues relating to the intersection of business, privacy and advertising. I led and lead The Washington Post’s technical work around complying with California Privacy regulations. Today I’m speaking on behalf of The Washington Post.

The Washington Post was able to seamlessly roll out CCPA compliance for our California customers. When it became clear that the United States Privacy API (or USP API), as defined by the Interactive Advertising Bureau (the IAB), would become the industry standard for publishers and advertising systems we were quick to adopt it. It is encouraging that a user with a little technical experience can interact with and understand the output of the USP API in clear text.

The idea of the technical signal warrants further exploration as it could have an adverse effect on businesses. Advertising is one of the main streams of revenue at The Washington Post. In the world of digital display advertising we count load times and the time to first-ad-shown in milliseconds, and have found that every millisecond counts, and adding extra loading time can have significant cost implications. Handling multiple technical signals, not having a single standard and instead processing multiple such signals, any of which could be built on technology that itself introduces a delay, would be a significant burden for publishers. It would mean extra code on page, engineering hours to build and maintain that code, and–depending on the shape of that technology–additional delay as we waited on a response from the system.

This is why it was crucial for me to be involved with the group that created the Global Privacy Control. So many of the potential pitfalls and problems that could come out of a technology-based control were avoided in its creation. It does not require complex negotiation with an API, it does not deliver a Promise–a technical concept in Javascript which would cause us to anticipate a delay in response–and it does not require complex calculation or decoding.

When the GPC specification was ready it was easy and straightforward for us to implement it. The entire change that was needed to support GPC on The Washington Post was 7 lines of code, less than One Hundred and Sixty Characters.

I’m prepared to show the actual code we have actively on our website to make clear the low lift for implementation:

When this code runs it sets the response in our systems to follow the user’s opt-out preference and is picked up by every relevant piece of ad and tracking technology on the page and either alters their behavior or is passed downstream the same as a manual opt out process.

The Washington Post takes these 7 lines of code and has them integrated into our CCPA compliance mechanism that processes user status with the USP API. This happens on every applicable page of our website. Once this code runs and processes the signal it is available for any other system that might need to know about a user opt out. The setting of the USP API in this way passes the signal to all downstream providers who then can comply with it. This code easily alters the state of the toggle we provide for California users, to display that they have selected Do Not Sell mode, making it visible that the user has selected it. We think of it as a robot for clicking that toggle.

With GPC, the opt out process actually occurs even faster than it would normally. Of the ways we handle compliance, GPC, in our engineering experience, has proven the fastest and most straightforward. We can also see the GPC HTTP header on any request where the user has it on and make a decision about how to handle it before the page even loads.

Our experience shows it is important to have clear, fast and transparent ways for a user to opt out and for a site to receive that opt out.

Because the user’s privacy setting and the GPC signal itself are available on every page it can be easy to note to the user it is detected, and we have a variety of options to act on that: we can restrict particular technologies, display the user’s opt out status, and make privacy-compliant ad calls as close to instantly as we can get.

Our hope in speaking here is to make clear our experience implementing California privacy law and the ease of use of the Global Privacy Control for opt-out. As rulemaking is being considered we think that what we have described is the required characteristics for a technologically appropriate signal: fast, clear, and easily integrated into existing practices. We believe these properties make GPC a signal in the best interest of our readers, ourselves as a publisher, and the ad technologies we collaborate with; one that can be used to understand an opt out under CPRA; and we wanted to make our experience of early adoption clear and urge continued support of this methodology.

We appreciate the opportunity to speak here.

I wrote this on behalf of The Washington Post, who is my employer, and it is published here with their permission and review.

The third-party cookie delay: nothing changes fast, but still it changes

Thu, 12 Aug 2021 18:20:00 -0400

Google recently announced they are delaying their plan to disable third-party cookies in Chrome, along with their Privacy Sandbox initiative. It’s tempting to look at this as a reprieve, a little extra time to relax and move post-cookie efforts into low gear, hoping the additional time will be enough to find better solutions. However, it’s important to recognize that nothing has really changed.

The end of third-party cookies is still advancing, and all the reasons for that happening are still valid and very much real. Readers are still concerned about being tracked and having their data leaked into an uncontrolled ad tech marketplace. They still look to publishers to act on their behalf. Buyers also continue to question the efficacy of the current 3p-data-driven marketplace. Regulators still seek to protect user data. Technology is still being transformed by engineering-based privacy efforts, and an increasing number of companies — with Apple leading the charge — are marketing themselves and their products on privacy quality.

For forward-looking publishers, nothing has changed. It still benefits us to act as strongly as possible on behalf of privacy-seeking readership by leaning into privacy. The deadline may have moved, but the future is still an increasingly private one and the market, as ever, favors early adopters.

Until the end of third-party cookies, there are plenty of old technologies we can’t compete without, as well as new ones that seek to build a platform for advertising, free of third-party cookies. Zeus Technology isn’t waiting. We will continue to innovate, test and collaborate with partners in the ad tech ecosystem who bring performance, both in eCPMs and speed on-page, on behalf of our customers. Through Zeus, our publishers will find both the resources to maintain their momentum through the end of 3p’s status quo, and the runway to continue to operate and expand via experimentation in the future of ad tech.

I originally wrote this on behalf of The Washington Post for their Zeus Technology Blog. The original post can be found here.

The Web is For People Not Just Professionals

Fri, 06 Aug 2021 16:05:00 -0400

A really great post by Jeremy Keith:

You can choose to make it really complicated. Convince yourself that “the modern web” is inherently complex and convoluted. But then look at what makes it complex and convoluted: toolchains, build tools, pipelines, frameworks, libraries, and abstractions. Please try to remember that none of those things are required to make a website.

This [the web] is for everyone. Not just for everyone to consume, but for everyone to make.

Read the rest: “Foundations”

How Spotify asks listeners to hack its algorithm

Mon, 09 Nov 2020 10:05:00 -0500

I listen to a lot of music and one of the things I noticed over the years is that I got stuck in a rut. Listening to the same things over and over again and not really picking up anything new. A problem with algorithmic recommendations, of music, or anything really, is that they can trap you with more and more specificity, narrowing around your interests instead of broadening horizons.

This narrowing has become even more difficult to escape now that my entire music experience is filtered through a streaming service, there’s no longer any time to trip over a song on the radio or even stumble over a recommendation on a pirating site. Even if someone was going to lend me a CD, I don’t have anything to play it anymore. Taking a single recommendation often isn’t enough to break out of the effect of my overall listening pattern. If I do nothing but passively consume music via a streaming service, I’ll likely never be pushed to the edge, much less out, of my comfort zone.

This problem isn’t just one of music recommendations. Only, I think there’s a solution that leverages the algorithmic recommendation process to broaden, instead of limit, us and we can see it already in Spotify.

The Sweet Escape

A brief guide to breaking your way out of your musical comfort zone.

Leveraging Organic encounters

In the world of the web, the term “organic” is used for a piece of content we find through actively searching for it, when it comes to music there is a similar process. I’m always fast on the Shazam trigger if I hear a song I like in a restaurant, movie or film. In the days I went outside (because we weren’t in a pandemic) I’d find a lot of very different songs that way. I also like Sofar Sounds concerts, I go in not knowing what music I’m going to get and potentially find something very different to enjoy.

Once I get a song I like, that doesn’t really sound like anything else to which I listen, the first thing I do is head to the artist’s About page on Spotify. From there I can follow links to Discovered On, a set of playlists that include the artist. While one song isn’t enough to escape the reinforcement of listening to the same music on loop, a whole new playlist of similar music starts to open things up.

A good example is the time I stumbled across Los Ángeles Azules’ “Amor A Primera Vista” in a restaurant. Their About page led me to a Spotify-created playlist around Cumbia Sonidera and checking through their Fans Also Like page let me dive into some similar bands.

Stealing from Friends

As you dig into these different playlists, you’ll find that listening impacts your Discovery playlist, which uses similar algorithmic tools to generate suggestions. If you go wild in your journeys outside your comfort zone you may find it becomes a little less useful.

I’m pretty sure I’ve broken my Discover playlist because it seems to often be filled with stuff I don’t particularly like. One time it was filled with bitcoin rap about “lambos”, which was the worst. If I’m looking for an antidote, but with nothing particular in mind, I also look for new music by finding other people’s Discovery playlists in the Friend Activity feed. Now I have a folder entirely composed of other people’s Discovery playlists. It’s great because some of my friends have better and sometimes very different musical tastes than I. Hopping into a friend’s Discover playlist is a lot of fun, as it puts you outside your comfort zone, and is also a great exercise in listening to entirely different kinds of music.

Occasionally there will be something great in my Discovery playlist, even now, so you can make mine the first you explore.

This just scratches the surface of how you can dig into the algorithm for more musical variety.

Using the Relationship Graph

Every Noise at Once is an algorithmic attempt to categorize music by genre and then place those genres and the bands that play them in relationship to each other. The project emerged from trying to understand what a musical genre even is and how one could even recommend songs on that basis and is part of a system that was purchased by Spotify to help run the recommendation system you encounter in their app today.

Here’s what the ENaO graph looks like for Classic Rock, one example of a genre I frequency listen to:

In the description of how this algorithmic sorting came to be engineer Glenn McDonald notes:

The approach allows us (or our customers) to seed, and then organically grow, a new genre or style from essentially any inspiration. In a couple peculiar cases, we’ve gathered an initial artist list, let the computers give us some songs, and only then listened to those songs to find out what kind of music we were even talking about.

By creating a system which can organically enter into a genre and essentially reverse engineer it, Spotify has a tool that lets me easily break out of any musical bubble and find my way–wikipedia-effect-style–into entirely new universes of music.

ENaO brings forth the ability to see the relationship graph of a genre. Here’s Classic Rock’s closely related genres (based on how listeners act, not on any historical reasoning).

Now if I want to make a small move, say I want to still get some of the sound of classic rock but move away from the core music of the genre I might choose to move towards psychedelic rock, traditional folk, or art rock. The position tells me a little about the genre in relation to Classic Rock: “down is more organic, up is more mechanical and electric; left is denser and more atmospheric, right is spikier and bouncier.” But ENaO gives me another option, the inverse graph:

Now, if I’m feeling like I really want to flip my listening on my head I can pick something totally opposite of my normal genre. Perhaps Fluxwork or some Montreal Indie?

From the Map area of ENaO I can expand the playlists I might explore based on a particular genre. The map shows a set of bands that I can try exploring individually. I can also head to one of the playlist links:

playlist sends me to “The Sounds of [Genre]” playlists on Spotify. When I stumble across an interesting genre I will often save the Sounds Of playlist for later when I’m in the mood to explore it a bit deeper. As a result I have a whole bunch of these playlists which essentially act as up-to-date overviews to the genre I can dive into at any time.
intro is essentially an ‘introduction’ to this genre with music that represents the core sound and is most popular among listeners of the genre.
pulse is an interesting look at which songs listeners of this genre currently prefer.
edge is a fun one that shows you songs that people who like this genre currently enjoy outside the genre itself. It’s another great tool for pulling yourself out of a listening rut.

I might go to one or all of those playlists depending on how curious I am in order to find new music and save it to my liked songs.

Don’t Stop the Music

Once I find a song or genre I like, of course not every related song is my cup of tea, in the same way I like some classic rock bands, but not others. This is the part where I can “hack” the algorithm to help me develop an ear for a particular genre without knowing much about it. This is especially useful for me when I, an English-speaker, explore non-English genres. Here’s how it works:

My neighborhood Vietnamese restaurant plays really great Thai music. Of course, I didn’t know what type of music it was or even what language it was in when I first heard it, I had to Shazam it. The nature of exploring music this way is sort of naive so please excuse any factual errors to follow. Over the course of one dinner I had a few songs that I could explore. “โคตรเลวในดวงใจ” by Takkatan Chollada is classified as Thai pop country. “เสียเวลาว่ะ” by electric.neon.lamp is in Thai pop indie playlists while “เสพติดความเจ็บปวด” by The Yers appears to be Thai pop rock. These are assumptions I make by looking at the Discovered On playlists and translating the names.

Judging on these three songs it looks like I would enjoy Thai Pop music. Now I can throw these songs together into a playlist. When I create a Spotify playlist around songs from a new genre, it only takes a few entries before I can scroll to the bottom and use the Recommended Songs area.

By hopping into that section and listening further for what I enjoy, I can pretty quickly develop a playlist of my favorite parts of this genre I’m newly exploring, without knowing a lot except the particular sound that appeals to me.

This is sort of similar to the framework of Pandora, but is far more interesting because your seeding of the playlist can be a lot more focused and the way Spotify handles it gives you more transparency and control.

Getting a Taste

Once I do this for long enough, I start to develop a better ear for the subtleties of a specific genre. I may not have the tools of a music academic, so excuse my lack of proper terminology, but I will start to hear particular sounds or auditory themes that I groove to. I start by adding those into the playlist, but when I can start to differentiate the sub-genres by ear there comes a time to subdivide.

When I started, I saw all three of those songs above as “Thai Pop”, but by looking at what playlists they are in and listening to them and any of the recommended songs I enjoy, I start to get a sense of what differentiates them.

I’ll act on my new understanding of those differences by splitting the playlist into the three genres of Thai music that I perceive. Thai Pop, Thai Rock, and Luk thung (please excuse my ignorance as there is not a lot easily translatable or in English about most non-English music genres, but a rough description of this genre–as I understand it–is Thai Folk Country music. I highly recommend the Luk thung Wikipedia article).

Every Day I’m Shuffling

The key to this process is the Recommended Songs list at the end of every playlist. It’s a particularly fascinating piece of the user interface for Spotify. The section represents a radically different way of interacting with a recommendation algorithm, one that differs from other social platforms. It is the difference between being directed by the algorithm as a subject vs you directing the algorithm as a tool.

McDonald (still a few years from his employer being acquired by Spotify and this Recommendation mechanic becoming part of the app) states the core approach that creates this difference:

The point of the map, as with the genres, is not to resolve disputes but to invite you to explore music. It is an attempt – however uneven, idiosyncratic, and incomplete – to embrace this new state of the world, in which nearly all of humanity’s recorded music is streamable or downloadable, and give you a way to find out what you don’t know you don’t know.

All it takes is a few small changes in the user experience to make an algorithm that is a tool for exploration, expanding your view instead of narrowing it. I’m not saying that Spotify or this approach is perfect, but it is worlds different from using an algorithmically sorted platform like Facebook or Twitter because, with the exception of a few auto-generated playlists, Spotify has made the choice to give users the tools to “hack” the algorithm to explore new things, instead of trapping them in an ever narrowing funnel from the initial preferences they had when they started.

Editor’s Note - Podcasts

It’s worth noting that I wrote this before a well-earned explosion of controversy around Spotify royalty rates and podcasts. The podcasts question is especially interesting because all this awesome stuff that works well with music doesn’t work at all for podcasts (podcast recommendations seem to be a mystery in comparison). It’s a whole other essay, but I wonder if part of the problem is trying to run a whole new type of content without any of the tools that make Spotify, as an experience for music fans, work.

You should read more about what’s going on here:

"It is indefensible to lack morals in software"

Fri, 08 Nov 2019 17:05:00 -0500

A great interview in VICE today with an engineer who quit GitHub over their ICE contract.

Sophie Haskins:

It certainly frustrates me how apolitical tech is. It’s so individualistic and siloed. It’s unacceptable. The idea of tech for its own sake, and tech on its own terms makes me angry to no end.

Technology should be tools to help people, to enable humans. Even beyond moral questions, many engineers just make bad technology because they don’t think about humans when they’re making it. They’re obsessed with the technical details— but you have to start to realize your actions have consequences. It is indefensible to lack morals in software when we have such a huge impact.

Read the rest: “Why I Quit GitHub”

“GitHub Octocats Animation” by Shauna Keating is licensed under CC BY-NC-ND 4.0

A Presentation to Watch - Mike Monteiro: Let's Destroy Silicon Valley

Wed, 16 Oct 2019 15:55:00 -0400

A presentation on our responsibility of designers and by association technologists to change the world. This is a great presentation by Mike Monteiro which is well worth watching.

The presentation appears to have occurred at Joint Futures recently.

via: https://twitter.com/JanKorsanke/status/1184534571951575040

The Ad Performance and Safety Protocol: Cleaner, better, safer ad experiences on iOS

Wed, 28 Aug 2019 18:20:00 -0400

The Washington Post is taking a proactive approach to digital display advertising issues with a new project that is set to fix bad code, while saving brands from code errors and cross-platform bugs in ad code. The Ad Performance and Safety Protocol (APSP) focuses on accidentally harmful ad behaviors to ensure a better user experience for all readers on The Post’s Classic iOS App.

Ad safety has become a major issue for publishers over the last few years. Most solutions that have approached the issue have done so with a fundamentally reactive mindset. The assumption is that the majority of ad problems experienced by users are malicious actors in the landscape. This approach is one that is needed, but it does make an incorrect assumption: that users’ bad experiences with ads are only found in malicious events.

While malicious events stand out to users and need to be secured, bad performing advertisements is a highly common experience users have with ads. The advertising technology landscape is filled with badly performant, slow, and malfunctioning advertisement code. While the largest impact this has is on slowing websites down, the issue became far more urgent for our Classic App when we determined users were experiencing two major problems at a high frequency. The first was a flaw in a common iOS package that was causing video to accidentally pop out of the ad frame. The second was a common script used to build ad animations that had a flaw causing an impact on iOS device performance. After testing and review, the iOS and RED teams at The Washington Post determined a fundamentally different approach was in order.

To supplement our existing anti-fraud and anti-malicious-ad measures, we needed a proactive approach that worked with ad code to alter it for better performance. The solution was the Ad Performance and Safety Protocol, a set of checks and responses that actively scanned ad code coming into the app and determined a way to increase ad performance and decrease cross-platform bugs that were causing a worse ad experience for users.

Changes to HTML specification a few years ago encouraged developers to replace common gif-style animation with background video elements. These elements are intended to be part of the ad’s overall presentation but a bug in some of the underlying standard code used to display ads in iOS can cause these videos to ‘pop out’. This is not an experience we or users want and because the video is intended to be background animation it is usually unbranded and strange to users. We resolve this issue with proactive code insertion.

Additionally, a few very common ad scripts used by auto-generating design tools have issues we have diagnosed as causing infinite looping of code functions. These excessively overuse device CPU long after they have completed doing anything for the ad itself. APSP will stop these loops at the point we have decided to no longer allow any type of ad animation, when the scripts no longer have any use for the ad. This should have no impact on well-implemented analytics and viewability tools within the ads themselves.

We have deployed this solution successfully, intervening in ads that would otherwise have negatively impacted reader devices and improving system performance for over a third of ads displayed. The result is faster ads, a better user experience and a safer overall environment for Washington Post iOS users.

I originally wrote this on behalf of The Washington Post for their Engineering Blog. The original post can be found here.

“Safety Key” by Got Credit is licensed with CC BY 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by/2.0/