Cross checking IAB’s numbers

It looks like on Mobile the numbers  IAB’s reports are based on mostly reflect the dynamic of Google and Facebook advertising revenues, not those of average App developpers.

 

Like many people interested by privacy, I keep an eye on #ePrivacy on Twitter. This hashtag, is used by both people advocating for more privacy (consent as the main legal basis, stronger default settings, no cookie walls) and those pushing for legitimate interest, cookie walls, no default settings,…. Both sides have arguments and I’m obviously more receptive to the former group of people but I try to look at the argument of the other side as well. During the last few weeks, IAB Europe representatives quoted several reports that, according to them, show the importance of the ‘data-driven’ advertising in Europe  (I put ‘data-driven’ into quotes because this refers in fact to almost any type of advertising)

I wanted to analyze the number behind the reports, especially behind the report called “The economics of contribution of digital advertising in Europe”. I tried couple of times to get more info about some of these numbers but did not get a response so far. So I had a closer look to the document. It is an update of a previous 2015 IHS report . Interestingly, in this report the definition of publisher is very broad:

”Publishers, or media outlets, who serve audiences by providing them with content, and serve advertisers by supplying them with audiences. In this report, ‘publisher’ includes any type of company where audience attention and content meet.”

So publisher includes search engines (Google , Yahoo, Bing) and social networks (Facebook, Twitter and Linked). It means that the figures showing the publisher revenues are likely to include the revenues of this company which are largely higher than average publisher revenues.

The mobile ecosystem

While the figures are not false, these figures will certainly not correspond to the revenues of average European publishers or app developper. For instance when reading the figure on mobile advertising revenue, the reader may not be aware that Facebook advertising in Europe is 5,4 €bn (see 2016 Facebook earnings) and that during the 4th quarter of 2016, 84% of its revenues comes from mobile. Meaning that Facebook mobile advertising revenue in Europe is about 4.5 €bn, more than a third of the mobile advertising revenue estimated by IAB.

Facebook advertising revenues (source: https://s21.q4cdn.com/399680738/files/doc_presentations/FB-Q4%2716-Earnings-Slides.pdf)

 

Google’s share is even bigger. So it is likely that if your remove Facebook and Google revenues from the figure, you will be left with at most a third of the 11 €bn made in 2016. And so  mobile advertising will not be the main revenue on mobile. As far as I know, there is no such dominant players in the app ecosystem, so app revenues made of paid apps and in-app purchase will be more equally spread.

What’s behind these numbers

I should add that it’s not simple to know what these numbers reflect from an app developer point of view as it just compares the global revenue without show the cut that the developer receive. Considering the number of intermediates, the global market revenue tells little about the revenue received by the developer.

Finally, it’s hard to get more details on these number and to know exactly what they reflect as there several revenue sources for app developpers. For instance a 2014 GigaOM report shows that added In-App purchase and Paid App revenues make up 4,5 €bn  when the IAB report shows that, during the same year, these revenue sources were neck and neck with mobile advertising.

Revenues charts from different sources shows significantly different revenues in 2013

Final words

These reports are quite opaque so it’s complicated to know where these numbers come from. I’m not arguing that IAB Europe numbers are wrong but they may be misunderstood and as probably do not reflect the reality of average app developers who  probably get more revenues from paid-app and in-app purchases than from advertising.

A list of Google services vulnerable to Session hijacking

After finding an information leakage in Google Search, I’ve been curious to see if there were no other pieces of information that could be gleaned from other Google services. To verify this, I visited my Google Dashboard, replaced my SID cookie and clicked on all the HTTP services that were listed.
My first attempt failed as I was systematically redirected to the account page where I was asked to enter my password. I then tried to also spoof the HSID cookie — also sent clear text — but because HSID cookie is an HTTPOnly cookie [1], it cannot be modified by a script or by the user: the cookie can only be modified by the server.

Spoofing HTTPOnly cookie

The best solution I found was to install a local proxy to intercept the HTTP traffic and then modify the cookies (I recommend Burp free edition which does a good job). It is then quite simple to replace the HSID cookie in the sent requests.
This time it worked, I was able to log into two services under with the spoof account:

  • Google Alerts: I was able to view and edit the mail alerts that were configured for the spoofed account.
  • Google Social Content: This service lists all your Gtalk contacts (that means most of the people you chatted with a couple of times).
  • Google Contacts: This is the Gmail contacts manager, it allows you to view, edit and create Gmail contacts. Quite useful if you want to get a list of persons to spam. An attacker could also attempt to replace the mail address of a contact with its own mail address.
  • Google Reader: You could see and edit RSS subscription.
  • Google Maps : You could see the maps associated to the spoof account.

There might be other vulnerable services but I think this list is already quite exhaustive and each of the listed service is likely to provide sensitive information.

Design flaws

Spoofing an unsecured cookie to hijack a session is nothing new. Nevertheless, there are two design flaws that HSID and SID cookies spoofing more critical:

  • These cookies can be used to provide an access to multiple services: when Google created these services, it did not assign a specific cookie for each of them. Therefore a single pair of cookies provides an access to all these services.
  • SID cookies are still valid even after the user logout: if a user thinks his session has been compromised, there is nothing he can do to revoke it. It seems that this was already pointed out 4 years ago .

Conclusion

Google is working on these issues and they should be fixed soon (users are already redirected to encrypted search [2]). Therefore, a next step would be to check if other major Web service providers have a better cookie policy.

Reference:
[1] Jeff Atwood, “Protecting Your Cookies: HttpOnly”, http://www.codinghorror.com/blog/2008/08/protecting-your-cookies-httponly.html
[2] Evelyn Kao, “Making search more secure”, http://googleblog.blogspot.com/2011/10/making-search-more-secure.html