F-Droid has spent many years trying to step out of the "only for technical/power users" into the "This is a tool that normal phone users should have and use". A one time 24hr wait moves back to the "F-Droid is only for technical users" big time.
Bought a new phone? Moved from iPhone to Android? Want help from your friend/family member/librarian/other to setup your new phone for getting apps? Sorry, you need to come back a day later before you can actually use it.
Guess what the normal/non-tech user does in this 24hr period? Go to Play Store, install a bunch of apps, forget that you had the desire to use an alternative.
This indeed does make F-Droid no longer a tool for normal people, but only a tool for those willing to do a bunch of "Advanced" things on their phone. By definition, not regular users.
And just like that, another major policy statement from the Android team that is completely devoid of actionable information for those impacted:
> Our new Registered App Stores program will provide a more streamlined installation flow for Android app stores that meet certain quality and safety benchmarks.
As with Developer Verification, I hold little confidence that the criteria for "certain quality and safety benchmarks" will be specified before this is rolled out (or even after).
Many people online and in person telling me "Google backed down" or "Google has an advanced flow" are typically referring to these two statements from Google staff:
> Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. [0]
> Advanced users will be able to"Install without verifying," but expect a high-friction flow designed to help users understand the risks. [1]
Firstly - I am yet to see "ongoing conversations with the community" from Google. Either before this blog post or in the substantial time since this blog post. "The community" has no insight into whether any such "advanced flow" is fit for purpose.
Secondly - I as an experienced engineer may be able to work around a "high-friction flow". But I am not fighting this fight for me, I am fighting it for the billions of humans for whom smart phones are an integral part of their daily lives. They deserve the right to be able to install software using free, open, transparent app stores that don't require signing up with Google/Samsung/Amazon for the privilege of: Installing software on a device they own.
One example of a "high friction flow" which I would find unacceptable if implemented for app installation on Android is the way in which browsers treat invalid SSL certificates. If I as a web developer setup a valid cert, and then the client receives an invalid cert, this means that the browser (which is - typically - working on behalf of the customer) is unable to guarantee that it is talking to the right server. This is a specific and real threat model which the browser addresses by showing [2]:
* "Your connection is not private"
* "Attackers might be trying to steal your information (for example, passwords, messages or credit cards)"
* "Advanced" button (not "Back to safety")
* "Proceed (unsafe)" link
* "Not secure" shown in address bar forever
In this threat model, the web dev asked the browser to ensure communication is encrypted, and it is encrypted with their private key. The browser cannot confirm this to be the case, so there is a risk that a MITM attack is taking place.
This is proportionate to the threat, and very "high friction". I don't know of many non-tech people who will click through these warnings.
When the developer uses HSTS, it is even more "high friction". The user is presented all the warnings above, but no advanced button. Instead, on Chromium based browsers they need to type "thisisunsafe" - not into a text box, just randomly type it while viewing the page. On Firefox, there is no recourse. I know of very few software engineers who know how to bypass HSTS certificate issues when presented with them, e.g. in a non-prod environment with corporate certs where they still want to bypass it to test something.
If these "high friction" flows were applied to certified Android devices each time a user wanted to install an app from F-Droid - it would kill F-Droid and similar projects for almost all non-tech users. All users, not just tech users, deserve the right to install software on their smart phone without having to sign up for an "app store" experience that games your attention and tries to get you to install scammy attention seeking games that harvest your personal information and flood you with advertisements
Hence, I don't want to tell people "Just install [insert non-certified AOSP based project here]". I want Android to remain a viable alternative for billions of people.
While this is true of many projects, F-Droid has a track record of sourcing funding for security audits. To date there have been at least three audits, in 2015, 2018, and 2022.
I was involved in addressing in issues identified in the first one in 2015. It was a great experience, much more thorough than the usual "numerous static analysers and a 100 page PDF full of false positives that you often receive.
I'm surprised that several audits didn't uncover this signing issue. GrapheneOS devs do not recommend f-droid. Instead, Play Store is the safest option for now, after Aurora Store
The last two places I've worked I added a custom "debug bar" of sorts. We typically use in dev and lower QA environments, and they quickly become indespensible to help answer questions like "which version of service X is deployed", something that may be easy for a dev to answer as they can look at what is deployed on the server, but harder for a tester who can only access the frontend.
Other useful environmental information we find useful includes "which DB is being used", which OpenShift namespace (with a link to the console), traceability for the deployed artifact (e.g. links to the GitHub release tag, CI pipeline which built the artifact, docker registry with the correctly tagged image). Especially useful if you have downstream or upstream services, is to have colour coded status info about whether the services are up.
For the few days investment getting this up and running, it pays itself back in terms of time gained answering questions such as "Why doesn't this feature work? Oh, after investigation, this service was down during testing".
Also handy (regardless of framework, language, etc) is if you use feature flags, if you're using actual valid credentials against a service or a local testing service (eg S3 vs minio, etc).
Enabling this for non-technical users really helped also report any issues they would see, it was great for testing environments.
Plus you would probably end up needing all this information anyway if you do any error tracking, so it probably exists somewhere already :-).
I find a good IDE that you are already familiar with from other languages/environments goes a long way. Pick your poison, but for me because I'm already using IntelliJ for Java at work and Android Studio for open source projects, I was able to get into Go relatively easily recently using IntelliJ.
The linter/autocompletion/auto-fix/refactoring/etc made it much simpler to a avoid having to rote-learn the syntax for functions, lambdas, structs, etc. To go with that, the error handling becomes much easier to learn because the editor is able to tell you when you've got the wrong number of return values / wrong type of values.
Yes, the compiler does all of this, but the way it happens in real time using the same keybindings/UI/UX that I use for my day job makes it all that much easier.
I love this so much. I remember reading about this game in a PS1 magazine as a kid, but I could never get my hands on it. For some reason, it stuck with me for all these years until I finally got around to making an open source Android game inspired by it: https://github.com/beat-feet/beat-feet. The idea of loading up your own MP3 files and playing levels is something I think should get a lot more mileage.
The Centennial Light mentioned in this article also features in a later chapter of the wonderfully written 17776 [0]. It will take a while to get through it, but very much worth the time.
Bought a new phone? Moved from iPhone to Android? Want help from your friend/family member/librarian/other to setup your new phone for getting apps? Sorry, you need to come back a day later before you can actually use it.
Guess what the normal/non-tech user does in this 24hr period? Go to Play Store, install a bunch of apps, forget that you had the desire to use an alternative.
This indeed does make F-Droid no longer a tool for normal people, but only a tool for those willing to do a bunch of "Advanced" things on their phone. By definition, not regular users.
reply