Check whether it is possible to modify HTTP requests with OkHTTP Interceptor

[ekuller]

@bella-tassone, @kalicki1, and I discussed possibly using OKHttp Interceptor to intercept and rewrite outgoing HTTP requests. A possible next step we could take is implementing and testing this. Questions include:

• Does it stop all requests?
• Can it "see" requests made by APIs?

[SebastianZimmeck]

using OKHttp Interceptor to intercept and rewrite outgoing HTTP requests

@ekuller, you mean intercepting the HTTP requests sent from our library to the Firebase backend of the developer integrating our library? Or do you mean intercepting HTTP requests from any app installed on the device?

If this is about our library, I do not think we would need any HTTP interceptor. We would just send HTTP request ourselves. In other words, we are just sending a normal HTTP request whose body and header we can create ourselves. For example, here is a question on Stack Overflow of someone using Volley making an HTTP request.

(we can also discuss more on Monday about HTTP requests)

[SebastianZimmeck]

Two more thoughts:

• Maybe, you also meant something in between, @ekuller. That is, intercepting any HTTP request of the app that integrates our library (i.e., requests to the app developer and requests to third parties integrated in the developer's app). For this case an HTTP interceptor may be useful, indeed, and it is worth exploring.
• If we decide to send the Do Not Sell request just to the developer (and not any third parties in the app), I do not think we would need to address this at the level of the requests. We could just provide a little Firebase backend (including a database) and work on that level of abstraction (e.g., along those lines).

[SebastianZimmeck]

So, I would say the first point to find out is whether OkHTTP Interceptor can intercept requests made by third parties in an app. In other works we have a library with OkHTTP interceptor in the app, can we intercept other libraries requests?

[ekuller]

Sorry for the lack of clarity. @SebastianZimmeck, yes, the hope is that it would intercept any HTTP request of the app that integrates our library (hopefully including those made by 3rd parties), as an alternative to just sending the signal to the developer.

[SebastianZimmeck]

Great, worth exploring, indeed!

[ekuller]

We have discussed continuing to work on/perfect the simpler solution (just sending a request to a developer specified server) before we work on this more intricate one. This will allow us to have something tangible, regardless of whether the HTTP interceptor works. It will also give Bella and I time to become more comfortable with development. We will come back to this issue later.

[SebastianZimmeck]

While we are debating the mobile backend (issue #33) in parallel we still want to find out whether we are able to attach HTTP requests to all outgoing traffic from an app.

[SebastianZimmeck]

I received an extremely important piece of information that I did not know before: from the publishers' perspective, if they receive a user's signal to not track them on the web (e.g., via a GPC, IAB, or other privacy signal), they just append the privacy flag to the data, continue to send the data to ad networks, and trust that the ad networks and everybody else downstream are doing the right thing and do not store the data that comes with such flag.

For Android upon receiving a GPC signal the Washington Post would set the Restricted Data Processing (RDP) flag to true. The IAB's US Privacy string specifically mentions in-app support. So, there is a good chance that it works in the mobile ecosystem the same way as on the web: flags from privacy signals are appended to HTTP requests, and the downstream recipients have to observe those.

This practice makes this issue crucial because it means that the app developer does technically not need to concern themselves with which of their users has turned on GPC and what to do about it. This responsibility is passed on to the ad networks. The HTTP requests can stay as except we simply insert the flag upon a user turning GPC on. We would not need to worry about any backend storage for the app developer (issues #33 and #29). Now, the question is, can we insert the flag (i.e., GPC in the header of all ad requests) using an HTTP interceptor?

@bella-tassone, @kalicki1, @bella-tassone, before addressing any other issue, let's work on this.

[SebastianZimmeck]

I am assuming that work covered here is carried forward in issue #36. Otherwise, feel free to reopen, @bella-tassone, @ekuller, or @kalicki1.