What is the path forward?

[SebastianZimmeck]

Per @bella-tassone's question in today's discussion. As the HTTP interceptor idea is hard to implement (issue #36), we now need to rethink our design. If anyone has ideas, let's discuss here ...

[ekuller]

I think the abstraction of ad requests will make it hard to implement a solution that isn't specific to which ad libraries and ad networks are being used. For example, if the developer is using Google AdMob, I think it would make sense to just add Google's RDP (Restricted Data Processing) flag to ad requests. However, I am not sure how we would do this through a library.

[SebastianZimmeck]

I think it would make sense to just add Google's RDP (Restricted Data Processing) flag to ad requests

Yes, indeed, we can add an RDP flag to the requests. Similarly, we can also add the IAB's US Privacy String and other privacy flags. These are essentially alternative takes by companies and industry organizations to accomplish the same goal as GPC. All those flags could be attached to all requests. If some are not applicable to a particular ad network, they would just go into nowhere and be ignored. But that it is OK. It would not cause any trouble for transmitting the requests.

@stanleymarkman and @kbeliauski are working on identifying the different flags to be used in our browser extension. Those exact same flags could be used for our mobile version as well.

Whatever it is --- our GPC flag, RDP, US Privacy String, ... --- the fundamental limitation remains: without having access to the OS it is hard to attach these flags to HTTP requests in a convenient way for ordinary users (i.e., without resorting to rooting the phone, VPNs, web proxies, ...).

I will try to touch base with Google. Maybe, they would be interested to have a conversation and say what they are working on. Though, I am not sure to which extent they would discuss.

[ekuller]

The reason I suggested using the RDP flag is because it can be added to ad requests made to Google (I think abstractly) through code that Google shares, if the developer is using the Ad Mob library. I am unsure of whether other flags (e.g. GPC) can be sent via the same method.

[SebastianZimmeck]

It is a good point and goes exactly to the core of the issue. We want to establish a generic opt out mechanism, that is, GPC. If our solution also enables RDP and other privacy flags, great! But that is a secondary goal and does not solve our problem: how can we get the GPC signal into an app?

[SebastianZimmeck]

We have hit a wall. The fundamental challenge is that the app level does not give us what we need, and there is no easy way for us to get onto the OS level. Here are some ideas:

• Our own app --- probably does not work: one idea is to just create our own app, hardcode all ad network server URLs, and upon the user making a selection in our app to which ad networks to send GPC signals send a one-time HTTP request with the GPC signal enabled. However, that is probably not going to work because the GPC spec does not require recipients of GPC signals to keep state on their end. In other words, for every request they receive that does not include the GPC flag they do not have to restrict their processing. So, the one-time sending of a request with GPC flag would not have any effect.

• Current HTTP interceptor/library approach --- probably does not work: We have pretty much found out over the last weeks that that does not work.

• VPN --- probably works but is complicated: We could set up a VPN, say OpenVPN for Android. Every request would be sent through it, and we can attach a GPC flag. One disadvantage is that average Android users would not set up a VPN as it is a bit complicated. Another point is that a VPN is much more powerful and users using a VPN are likely doing much more in terms of preventing tracking and hiding than just sending GPC flags would do. So, I am not sure whether any VPN user would be interested. Also, while it may not be strictly necessary, I would not want to maintain any VPN backend infrastructure.

• Setting up a database with AdIDs of opted out users --- probably works but is not great from a privacy perspective and has little chance of being adopted: One other option, as discussed with Robin Berjon on Keybase, could be to set up our own database that holds all opted out users' AdIDs. Then, just have our own app. If a user opts out, have their AdID stored in the database, and tell ad networks they should go there to check whether a user is opted out. One clear disadvantage here is that this idea approach requires storage of users' AdIDs thereby opening up another attack vector for compromising privacy. An open database of AdIDs on the Internet is just not great. This approach would also be different from the current GPC spec, which requires either transmitting GPC signals via headers of JS DOM property. It is hard to see that ad networks would make use of it as well.

• Work with Google to implement GPC on Android --- would work but is not in our hands: It would be the best solution if Google adopted GPC in Android. We have no control over that. I scheduled a call and will make the case for it. But more than suggesting, offering our expertise, and whatever else we can contribute from our end, is not possible.

• Work with the Lineage open source community to implement GPC in LineageOS --- would maybe work, though, is technically challenging and also not completely in our hands: Pretty much the only Android alternative, with about 2.5 million users, is Lineage OS (Wikipedia, GitHub, LineageOS site). LineageOS is like Android but more of a crowdsourced community. So, maybe, we can suggest and implement a GPC settings feature there. The first issue there is that the LineageOS community would need to agree that that this is worthwhile. And even if they agree that it is important, it would be up to us to implement it. I am not really a systems person and have next to no knowledge of the Android/Linux kernel. On the other hand, the summer is around the corner and with a strong effort we could learn. Also, adding a GPC flag to every outgoing request is a straightforward task and much much simpler to do than typical OS functionality, say, task scheduling. The bottom line is that I will try to touch base with the community, and let's see what they say.

• Our own Xposed Module --- would maybe work but would be a very specialized solution: On Android users who have rooted their phones can install the Xposed framework and use Xposed modules. These modules are essentially apps for the Xposed framework. Because phones are rooted, Xposed modules have much more access to OS functionality (e.g., Xprivacy is great analysis tool, for example, to see function calls any app on the device is making). Users going that route are sophisticated and only very few. So, while this may be an option, it would be only for a very narrow group of users. In addition, any solution may only last for a few weeks or months until something breaks due to Android and/or Xposed updates. Then again, that is probably true for the Lineage approach as well, though, Lineage is the more principled approach.

That's all I can think of at the moment ... . Thoughts?

(cc'ing @stanleymarkman and @kbeliauski)

[SebastianZimmeck]

Maybe, also worthwhile to think about, in-app support for the IAB US Privacy string. Can we do something similar for GPC?

[SebastianZimmeck]

Making a bit more concrete and expanding on what I said earlier, I can see two paths forward:

1. Starting to Implement GPC on LineageOS and other smaller Android-based Operating Systems

Essentially, the strategy is to get a foothold in the Android space. LineageOS is good starting point. There are more than four million LineageOS users, and getting GPC to them would be good progress. Here are a few other projects, some of which with a focus on privacy, that we could approach. Sailfish OS is another one.

Here is the LineageOS wiki on how to contribute (under For developers). On top of their version control, they are using Gerrit, which I am not familiar with. The bottom line is that we would need to learn how to contribute, and get the process going ... .

2. Add GPC to OkHttp, Volley, etc.

Based on the discussion so far it may be the case that even getting into the OS does not quite get us the functionality that we need, i.e., attaching GPC flags to every outgoing HTTP request. So, an obvious way would be to directly integrate GPC in OkHttp, Volley etc. The first thing to do here would be to just post an issue on GPC integration in their repos, and see whether that leads to any response. No idea how open they would be ... .

[SebastianZimmeck]

Google added some new safety information that app developers are required to provide. Not sure if this enforced technically or just via the developer agreement. If someone could dig more into this ...

[chunyuema]

Google added some new safety information that app developers are required to provide. Not sure if this enforced technically or just via the developer agreement. If someone could dig more into this ...

Did some quick readings on this. Based on what I saw, it seems that the developers are just required to declare how apps are using the data and Google will reflect this on the Play Store. I read something about monitoring whether the app follows what the devs declare. It was also mentioned that Google will require the devs to disclose full information / label the app as containing ads / take down the app as enforcement measures. Currently not seeing how this is enforced on a technical level but will keep looking... if they follow the timeline (Q2 2022), we might start to see more information soon too.

Some more info here...

[SebastianZimmeck]

I opened an issue at the OkHttp repo.

[SebastianZimmeck]

I opened an issue at the Volley repo. I did not realize that Volley is supported by Google.

[SebastianZimmeck]

A few other privacy focused OS's that we may want to contact at some point:

• GrapheneOS
• CalyxoOS
• Replicant

I got those from the awesome-privacy list.

[SebastianZimmeck]

Putting this repo on ice. We may pick up the work again at a later time ...