feat: Disable analytics

[saschpe]

Avoid metrics collection by default as this lacks consent required by the GDPR in Europe. It most likely violates Californian privacy laws as well. Additionally, metrics collection on dependencies might expose sensitive information in proprietary projects. Finally, those additional network requests have an impact on overall build-time, especially for CocoaPods.

Resolves #5191

[saschpe]

@jcesarmobile A review would be appreciated. Thanks in advance.

[thomasvidas]

Changing the analytics defaults of the projects is something that we're not going to do since its modifying the environment of a tool we don't control. Based on your PR, its easy to opt out of and I'm not opposed to adding a snippet in the Capacitor docs on how to opt out of analytics for third party tooling. If this is actually a GDPR or CCPA problem, then you should open issues with the upstream tools of Cocoapods and Gradle and not Capacitor.

[saschpe]

The problem is that each and every capacitor plug-in sends analytics data ATM and this is beyond control of apps utilizing those plugins. Worse, this currently happens without consent nor any way to opt out.

Yes, an app can choose to opt out in their Podfile and build.gradle files. But this doesn't propagate up to capacitor's build.gradle.it's not Podfiles.

I'm happy to add a configuration option but simply opting out felt the most straightforward. Especially since it does not affect functionality but (slightly) improves build performance.

Those upstream projects are already compliant by providing a way to opt out.

[saschpe]

Maybe It's worth discussing on what exactly happens at built-time. I'm gonna pick Android and just focus on Gradle. The build.gradle files shipped with capacitor and plugins are evaluated at compile-time in the app that includes this NPM module. That means metrics collection happens in your customer's project. However, they can only disable it in their own Gradle files or those generated by the project template. However, gradle files included from node_modules (from capacitor and plugins) are read-only. Your customer can't modify those and has to live with the metrics collection that happens there.

[thomasvidas]

Right. To disable from Cocoapods, you just need to set the COCOAPODS_DISABLE_STATS variable in your environment to opt-out. That is something that is not Capacitor controls or should overwrite. Since we are only invoking pod commands this shouldn't be an issue since pod would read from the system's environment.

For the AndroidJUnitRunner analytics, you can modify the test config in Android Studio or adb to include the additional flags -e disableAnalytics true as specified here. Plus, I believe that the analytics portion for Android only called when running a test runner and not on install like Cocoapods; and since a test runner on an app wouldn't call test runners on a plugin, it shouldn't be an issue anyway (but I haven't actually tested that, could be wrong).

Again, I'm not opposed to adding a page/snippet in the Capacitor docs telling people how to opt out, but having Capacitor opt out of third party tools automatically rather than reading settings from the developers environment is the way to go. Capacitor provides developers platforms and tooling on top of a native XCode or Android Studio project; we aren't trying to control the entire build stack like how Cordova does.

[saschpe]

Right. To disable from Cocoapods, you just need to set the COCOAPODS_DISABLE_STATS variable in your environment to opt-out. That is something that is not Capacitor controls or should overwrite. Since we are only invoking pod commands this shouldn't be an issue since pod would read from the system's environment.

That's indeed an option. It requires all developers in a project that uses Capacitor to understand CocoaPods and set their environment accordingly. I have a particular case where a client company desires to enforce all metrics to be disabled. It can be easily done on CI but advocating to a 20+ web development team that has little to no experience with iOS development... It's all too easy for humans do make mistakes. A simple default would have prevented that.

For the AndroidJUnitRunner analytics, you can modify the test config in Android Studio or adb to include the additional flags -e disableAnalytics true as specified here. Plus, I believe that the analytics portion for Android only called when running a test runner and not on install like Cocoapods; and since a test runner on an app wouldn't call test runners on a plugin, it shouldn't be an issue anyway (but I haven't actually tested that, could be wrong).

Yes, it only occurs when integration tests are invoked in a downstream ionic app, so it's less likely to happen all that often. It's a similar case here, it means teaching the ins and outs of adb and Android Studio to a crowd that is used to using VS Code or WebStorm and never heard of adb.

Again, I'm not opposed to adding a page/snippet in the Capacitor docs telling people how to opt out, but having Capacitor opt out of third party tools automatically rather than reading settings from the developers environment is the way to go. Capacitor provides developers platforms and tooling on top of a native XCode or Android Studio project; we aren't trying to control the entire build stack like how Cordova does.

How about adding a configuration flag to capacitor.config.json? That could be set once for a customer project and it would work for all their developers and CI environments alike.