Blokada: GDPR/DSGVO: "Send reports" might send ppersonal data

[g6094199]

Steps to reproduce

1. Go to Blokada settings. Sending reports is enabled by default. Since GDPR/DSGVO sending personal data must be an opt-in, not opt-out.

Expected behaviour

There are several way to fix this.

1. ask the user on install to allow sending reports to the devs
2. simply disable the option oper default, but i do understand that infos on problems are very welcome.
   so
3. don't collect users and/or trackable data and (important) inform the user about it in the options description, which isn't done right now. So users must see this option as an GDPR violence right now, even it isn't so. So plz talk to us. ;-)

Configuration

1. Blokada version 3.7

[peterroth]

Hi,
Thanks for bringing it up. The report sends only the Blokada log, when it crashes. It is not a periodic upload, not an automated task. At crash, when you restart the application, you can confirm you want to send the log file.
You can take a look in it (what is sent) if you grant permission for Blokada to access external storage and you export the configuration. The file is in the /Downloads/Blokada sub-directory.

Therefore, point 1.) is already done, the user is asked if s/he wants to share the log.
Point 2 is addressed and will be off by default in v4.
Point 3 is understandable, but let me share some history here, and how we got to this point (we, at Blokada, believe in transparency, we have nothing to hide): A year ago, when we started to invest more time into Blokada, and the Telegram group was opened, we faced 20-30 issues day by day. The only thing we could do back then, is to guess. We didn't have logs, we didn't have anything to get that could help us to investigate what's going on. The solution was obvious: Blokada should generate some logs that can be shared to see what caused crashes, malfunctions. The upload wasn't automatic, it asked if you want to report it, however, it wasn't clear if it is automatic or not. Therefore, recently, with Blokada 3.7, you have the ability to turn off this function. Completely. This is the opt-out. In this case, logs won't be shared, even at crash. You still can analyse them, though.

We can understand our users' concerns, and we are taking steps to help you get a clear picture what is shared, if you do, and why that needs.

As I stated before, you can access the log and read it, that's a normal text file, so you can check what it contains. No user or usage data is collected.

[Thomas499]

The report sends only the Blokada log, when it crashes. It is not a periodic upload, not an automated task
My interpretation of the description below is that it will happen once daily even if there is no crash, and will also happen each time there is a crash.

Perhaps the description should be re-worded to be more clear. Maybe reword it to say "This will only happen if the app crashes" or "This will only happen once at the end of the day, if the app crashes on that day.

Current wording is confusing because it says will happen once per day or when app crashes. As programmers, we interoperate or as meaning there are at least _two variables_ and _only one_ must be true to execute the report. I personally would have said and which programmers would be more likely to interoperate as there are at least two variables and all the variables described must be true to execute the report.

My users only care about sending the log if it could potentially show that they are doing something that could potentially cause them trouble. For example, consider clarifying "Note: will not collect any potentially incriminating data such as your IP address, location, or collect data on what website you were on, app you were using (kodi for example) or tv shows, movies, you were watching etc."

We didn't have logs, we didn't have anything to get that could help us to investigate what's going on.

Firebase Crashlytics is a pretty awesome tool that makes debugging much easier. Pretty sure crashlytics is blocked on a few of the block list host though.

[peterroth]

I'm afraid most, if not all analytical hosts are blocked on the blacklists, which means, we will drive blindly.
The current idea is to have logs that users can analyse, copy to a PC or share (e-mail it, upload on Telegram, etc) if needed. If logging is completely turned off by default, most of the users won't have anything to provide after a crash, because they go with the default setting.

[Thomas499]

I am a little familiar with the debugging process of phone apps and how valuable Firebase Crashlytics is. I'd like to make a recommendation on how I would approach this:

1. Consider if it is possible to identify when app crashes and then have it whitelist the required sites for 30 seconds. The user will decide to send the report or not within 30 seconds for most of the use cases. It would only whitelist the specific required sites if the user enabled the option to send reports which was off by default. - If this won't work for reason that app crashing means it can't run the protocol to enable the whitelist for a pre-set time then you actually have it easy because during that time it probably won't be able to block the blacklisted host either.

2. In the event that #1 isn't feasible, simply consider making a link on the github page that will be included as an option in the whitelist. For example, there is currently an option in the blacklist section that is disabled by default called Goodbye Ads by Jerryn70. But the option is there so user can easily enable it if they wish. Create a similar function for the whitelist section which user can enable if they want which includes a custom list of all the host needed for Firebase Crashlytics to work. In the description explain that the list is needed to be whitelisted only if user wishes to report detailed crashes which will make it easy to prioritize what bugs are causing the most trouble and to identify what is actually causing the crash. - You already include a link called download manager in the whitelist might as well add another default option.

Either way, you should give the user the option if they want to send the report that includes the custom debugging file that they can analyze themselves, or a more advanced report that includes the firebase analytics which they may not be able to see themselves but will give you the data you need to fix the problem more efficiently so that their devices experience less crashes. Most people who are familiar with firebase would probably not have a problem with enabling the option.

[Tobias-B-Besemer]

When no privat data is saved at all, what is the user benefit of have a option to turn crash logs off?

[kar]

Reports are off by default, and ACRA is gone from v4.