Why is a unique user-agent string used by Blokada?

Hi guys,
Thank you so much for maintaining Blokada - I really appreciate it and rely on it.

I recently read through the concerns posted by the F-Droid maintainers (here). While I do not want to go over that discussion (as it had some emotion) I’d like to ask why Blokada changes the user-agent string as it does?

I’m referring to lines 37 to 40 in https://github.com/blokadaorg/blokada/tree/5/android5/app/src/main/java/service/EnvironmentService.kt

Why were changes made only to the F-Droid build please?

They argue that the user-agent (for non F-Droid builds) stands out. Logically isn’t it better to avoid such a unique user-agent string in a privacy product? I’m curious.

Thank you!

I should start off by saying that I’m simply a list maintainer and long time user of Blokada, but I believe that I can offer a bit of insight here. There has been some - IMHO - overstated concern about the use of an installation ID / user-agent string in the vanilla version of Blokada (to facilitate easier purchasing of the plus features, and to more easily understand potential device-specific issues). The general reasoning of some F-Droid contributors is that such a string could make it easier for users to be identified. Personally, I would be concerned about software which stores sensitive data (such as passwords) generating a user-agent or installation ID, and if Blokada was an affiliate or subsidiary of a massive corporation like Google, Microsoft, Amazon, Apple etc… I would be doubly concerned.

The fact is that Blokada is not associated with any megacorps, and the Blokada application does not store any sensitive data about its users, so the concern is largely based on principle, as opposed to reasonable suspicion (in that Blokada has a very long, and very clean, track record in the FOSS community, as a reliable and privacy-respecting ad-blocking application).

There is also a dev from an application which serves a similar purpose, who has been - for lack of better terms - obsessively and aggressively focused on Blokada (to the point of making a bevy of bad faith arguments), which is a significant factor of the emotional character you picked up on in the discussion. If this was an exchange solely between the Blokada team and members of the F-Droid project, I am sure that it would not have spiraled out like it did. All of that being said, I think the Blokada team is taking the right approach with an F-Droid-specific build, and has handled the situation in an admirably tactful fashion, given how heated things have gotten. AFAICT, the changes in question have been made to the F-Droid build in order to address the priorities of the F-Droid project.

I would chalk up the bulk of the drama to what I believe are growing pains related to the increasing popularity and user base of Blokada, along with a dev from another project with some overwhelmingly obsessive tendencies that he’s battling. Again, I do not speak for the Blokada team, but can see both sides of the issue here, and how tensions have been exacerbated to an enormous degree by a third party. For the sake of everyone involved, I hope that tempers will cool, and that the F-Droid specific build currently being worked on will resolve the situation.

2 Likes

Well said.

I may add that the changes were introduced to quickly address fdroid concerns. Rolling out changes to all our userbase takes quite more effort and testing.

It’s worth pointing out that the user agent is used only for the internal communication with our servers, not with the entire web, so the claims about it standing out are questionable.

We are considering however to drop the user agent altogether though. It’s useful for us to know where to put our development efforts, but it’s not super important.

2 Likes

Thank you both for the excellent explanations!

2 Likes