Mobile apps, ads and consent

Oliver Brown
— This upcoming video may not be available to view yet.

I’ve recently spent some time adding the Google User Messaging Platform (UMP) to Tic-tac-toe Collection. The motivating factor was needing to support App Tracking Transparency in iOS 14 when using AdMob, but more generally, due to the GDPR, apps have significant requirements around consent and data management (especially with ads) and my haphazard custom implementation was a pain and probably not entirely compliant.

My effort to do this led me to learning quite a bit about the current state of this in apps and on the web.

Aside - Technical implementation

UMP is provided as a native library for both Android and iOS. There are official Xamarin bindings available for each (they are very new, and for a while I had to bind the iOS implementation myself).

I created a cross-platform wrapper to make using it easier in a Xamarin Forms app.

Google UMP is an implementation of a Consent Management Platform (CMP) as defined by the IAB (I tried to find a link to a neutral definition, but if you search Google for “Consent Management Platform”, you get a whole load of ads for companies wanting to help you).

This will look very familiar to most European users (and probably others) since most websites display a popup with a similar setup. What I did not realize until investigating this is that the information and settings it contains (down to the exact wording in some cases) is very proscribed and there it not much leeway about how the information is presented (possibly explaining why they all feel so universally unpleasant to use).

More surprising, at least initially, is that the way this information is stored is actually really well defined as part of shared API - the Transparency & Consent Framework by the International Advertising Bureau Europe. The popup which you provide consent through makes the information available to the hosting site (as well as advertising components on the page) in a predictable way.

A lot of the information is contained in this GitHub repo, with the API defined here.

The web API is really well specified and provides a JavaScript object available for anything on the page to query to get current consent status. The mobile API is a bit less so. Basically the data is stored in the shared preferences for the app (SharedPreferences on Android and NSUserDefaults on iOS) with well known keys you have to query yourself.

(Mainly just for fun, I created a package for querying this data with Xamarin.)

There a few things about the spec that I found interesting:

  • The “purposes” for which data can be used are very specifically defined, and numbered. Many things refer to them by number.
  • The list of vendors is also centrally determined and numbered.
  • There is what appears to be a typo in the spec: property names include VendorConsents, PurposeConsents and then PublisherConsent. This last one is structured the same as the others, but named in the singular. And since, like HTTP referer, it wasn’t caught before publication, it is now set in stone.

Some problems

There are some problems with this system. Some are general and some are specific to Google’s implementation.

The biggest is the language presented to the user is still very verbose. The whole point of the GDPR was to give users more insight and control about how their data is used. I seriously doubt many people will actually make an effort to understand all the purposes and the consequences of them.

One weird limitation of Google’s implementation is that it is impossible for the user to see their previous consent status and to tweak it slightly. When you first display the form, everything is turned off. The user can select to accept everything or dig through and accept individual permissions. If the form is presented again, everything is turned off again. If the user wanted to revoke or grant a specific permission, they’d have to remember themselves what they chose last time.

Even worse, there is no way to exit the form without making changes. If you launch them form, and select “Manage options”, your only way out saves the “everything off” state.

Purpose one

The first numbered purpose is “Store and/or access information on a device”. This is essentially a technology agnostic way of referring to a cookie. It doesn’t actually allow an app or website to do anything itself, it has to be combined with another purpose. And interesting things happen if the user does not grant it.

Most significantly, Google Mobile Ads (whether using AdMob or Google Ad Manager) will refuse to display any ads at all. In theory any app using Google Ads should be using a system that checks if the user is subject to the GDPR, request consent for purpose one and then respect it in this way.

The new update to Tic-tac-toe Collection does that. Which means European users who refuse consent will disables ads completely, for free. Since my ad revenue is low, and I’m already not a big fan of how mobile advertising tends to work… I’m kind of okay with it.

Interestingly, there is some debate about whether the GDPR actually requires this. If an app requires ads to be financially viable, and storing cookies is required to technically deliver ads (say for basic stats tracking or fraud prevention - not personalisation) that sounds very much like a legitimate interest, which means it can be done without consent. Google does address this here with the following quote

Google uses cookies or mobile ad identifiers to support ads measurement. Existing ePrivacy laws require consent for such uses, for users in countries where local law requires such consent. Accordingly, our policy requires consent for ads personalisation and ads measurement where applicable, even if ads measurement can, for GDPR purposes, be supported under a controller’s legitimate interests.

New site for my music YouTube channel

Oliver Brown
— This upcoming video may not be available to view yet.

I created a new website to go with the music visualization YouTube channel I launched.

There is not much content there yet, besides details of everything that is on the channel. But those details are probably the most interesting part.

I created a tool using the YouTube data API that generates Hugo content based on the channel.

The process started simple and got more sophisticated over a few days. First I generate a page for each video. Then I get a list of all the channel playlists, and add a tag to each video page for each playlist. I also create a page for the tag that links to the actual YouTube playlist. Finally, for each video I parse the description adding YouTube chapter links where appropriate.

It highlights another interesting advantage of static site generators. It is really easy to create content with external tools. You don’t need to access any kind of API, you just generate text files.

Interacting with this video is done so under the Terms of Service of YouTube
View this video directly on YouTube

Blog moved to Hugo

Oliver Brown
— This upcoming video may not be available to view yet.

After spending most of its time on Wordpress (initially a self-hosted version and then Wordpress.com), the blog is now a static site generated with Hugo and running as an Azure Static Web App.

Ever since I created the Tic-tac-toe Collection site on Hugo I’ve wanted to move the blog, but I never had the time. The recent events related to COVID-19 have, however, given me random bits of free time, so here we are.

Tic-tac-toe Collection is being run as a static website on Azure Blob Storage, which is a way of connecting various bits of Azure together to host a static site. The new Azure Static Web App Service joins them all for you in a much more straightforward fashion.

Under ideal circumstances, the minimal steps to set up a static web app are:

  • Upload your site to Github.
  • Create a new Static Web App pointing at your Github.

And, if you’re lucky, that’s it. It generates a GitHub action for you that does the actual building, and it’s based on Microsoft Oryx. Oryx is a slightly magical, slightly scary tool designed to auto-detect and then build static web apps using a range of different technologies.

Unfortunately, for me, the auto generated Hugo script did not actually work. I ultimately used the GitHub action from here.

Theme for 2020 - Land of Shame and Despair

Oliver Brown
— This upcoming video may not be available to view yet.

One of the reasons I started retuning pieces to different modes was the hope that something good might come out of it by chance. One example has appeared. I don’t think “good” is the right word, but it at least sounds intentional (most pieces just sound accidentally out of tune).

Interacting with this video is done so under the Terms of Service of YouTube
View this video directly on YouTube

Land of Hope and Glory retuned into Ultra Locrian.

It is dark and disharmonious. Hitting a note on nearly every beat combined with a lack of any real resolution gives it an unrelenting monotony. And somehow, halfway through when the higher octave repeat starts you still end up with the feeling of: “It’s still going? And somehow it’s worse?”.

I would like to end on a cheerful note. Nothing with “Locrian” in the name really does that. So instead, have some Sonic the Hedgehog music:

Interacting with this video is done so under the Terms of Service of YouTube
View this video directly on YouTube

Visualization of the Duke Nukem 3D theme

Oliver Brown
— This upcoming video may not be available to view yet.
Interacting with this video is done so under the Terms of Service of YouTube
View this video directly on YouTube

One big advantage of doing this to the Duke Nukem 3D theme is that the original was already a MIDI file. That means people familiar with it are already used to hearing slightly different versions, and the version I generate is no more or less authentic than any of the others.

Although I have to admit I do not remember hearing good quality tubular bells on the computer I first played it on (but they have since grown on me while making this).

The future of Xamarin Forms

Oliver Brown
— This upcoming video may not be available to view yet.

Microsoft have just announced the future of Xamarin and Xamarin forms - the .NET Multi-platform App UI (or MAUI for short). As a name, it’s not great. The highlights are as follows:

  • It’s an evolution of Xamarin Forms. It basically is Xamarin Forms, but finally accepting some breaking changes. To be honest, I’m hoping for a lot since there is a lot of weirdness in Xamarin Forms that has been holding it back.
  • Single project, multi-targeted. It took a long time to get to the point where this was possible. From shared projects, to PCL projects, through .NET Standard. This should make things a lot easier.
  • Still based on platform renderers using native controls. This is a mixed bag. Using native controls has long been a selling point of Xamarin (with or without Forms). With the rise of Flutter this has been shown to be less important. Many people have been asking for consistent platform agnostic renderers instead.
  • The end of “Xamarin” as a name. Some time in the .NET 6 timeline (end of 2021) Xamarin.iOS will become .NET for iOS and Xamarin.Android will be .NET for Android. I have mixed feeling about this since this was a fairly succinct way to describe by top skillset.

I also already have my own enhancement issue submitted.