Ungoogled-chromium: Proposal: exclusion of account/signin/gaia code

[csagan5]

In light of recent directions of upstream (1, 2) I would like to completely rip out the relative code, more as a statement than anything else (the relevant functions have been always dormant in Bromite, and I think it is not a supported feature of ungoogled-chromium as well?).

This should cause some more maintenance work (as this area I bet is one of the most active upstream), but on the other hand work as a sort of "preservation project" to let us understand how Chromium without cloud works/worked, and be capable of keeping it in this state for longer by learning more about the internals.

My idea would be to change chrome/browser/BUILD.gn this way:

--- chrome/browser/BUILD.gn 2018-09-23 17:16:40.264000000 +0200
+++ chrome/browser/BUILD.gn.new 2018-09-24 23:25:36.239894176 +0200
@@ -1366,50 +1366,10 @@
     "shell_integration_mac.mm",
     "shell_integration_win.cc",
     "shell_integration_win.h",
-    "signin/about_signin_internals_factory.cc",
-    "signin/about_signin_internals_factory.h",
-    "signin/account_consistency_mode_manager.cc",
-    "signin/account_consistency_mode_manager.h",
-    "signin/account_fetcher_service_factory.cc",
-    "signin/account_fetcher_service_factory.h",
-    "signin/account_investigator_factory.cc",
-    "signin/account_investigator_factory.h",
-    "signin/account_reconcilor_factory.cc",
-    "signin/account_reconcilor_factory.h",
-    "signin/account_tracker_service_factory.cc",
-    "signin/account_tracker_service_factory.h",
-    "signin/chrome_signin_client.cc",
-    "signin/chrome_signin_client.h",
-    "signin/chrome_signin_client_factory.cc",
-    "signin/chrome_signin_client_factory.h",
-    "signin/chrome_signin_helper.cc",
-    "signin/chrome_signin_helper.h",
-    "signin/gaia_cookie_manager_service_factory.cc",
-    "signin/gaia_cookie_manager_service_factory.h",
-    "signin/identity_manager_factory.cc",
-    "signin/identity_manager_factory.h",
     "signin/investigator_dependency_provider.cc",
     "signin/investigator_dependency_provider.h",
     "signin/local_auth.cc",
     "signin/local_auth.h",
-    "signin/profile_oauth2_token_service_factory.cc",
-    "signin/profile_oauth2_token_service_factory.h",
-    "signin/signin_error_controller_factory.cc",
-    "signin/signin_error_controller_factory.h",
-    "signin/signin_manager_factory.cc",
-    "signin/signin_manager_factory.h",
-    "signin/signin_promo_util.cc",
-    "signin/signin_promo_util.h",
-    "signin/signin_status_metrics_provider_chromeos.cc",
-    "signin/signin_status_metrics_provider_chromeos.h",
-    "signin/signin_tracker_factory.cc",
-    "signin/signin_tracker_factory.h",
-    "signin/signin_updater.cc",
-    "signin/signin_updater.h",
-    "signin/signin_updater_factory.cc",
-    "signin/signin_updater_factory.h",
-    "signin/signin_util.cc",
-    "signin/signin_util.h",
     "signin/unified_consent_helper.cc",
     "signin/unified_consent_helper.h",
     "site_details.cc",

And perhaps more, and then fix the breakage. For some similar work done by @thermatk see the patches at bottom here: https://github.com/bromite/bromite/tree/master/patches (with "kill" in the name).

I think upstream enabled the "account consistency mode" (which in hindsight sounds a lot like "this is not automatic signin", but it is) in this commit:

• https://github.com/chromium/chromium/commit/fc443126af3f424433b8d7c9b0194e83b6dba021

I think we make a service to the users by removing each and every bit of these dependencies, for the present and future/planned use of them.

[Eloston]

I like this idea. I've thought about this further by stripping out the directories dedicated to Google integration (it'll increase certainty that no communication is happening with Google beyond URLRequests, and also reduce dead code), but never had time to resolve all of the code that broke as a result. For now, just removing signin files should be good enough.

If you go through with it, feel free to submit a PR. :+1:

[csagan5]

I will have time to start working on this next week; I will report back my findings. My hope is that the impact in code changes is manageable.

[csagan5]

The most sane approach seems to be to use the "fake" gaia which is normally used for tests; perhaps a similar approach could be used for the account/signin part.

[csagan5]

In recent news: https://sector035.nl/articles/getting-a-grasp-on-google-ids