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.
I always loved over-the-top, somewhat impractical visual effects like this. Reminds me of growing up playing with Compiz Fusion.
For a retro Android game I maintain, I use the term "Gratuitous Eye Straining Effects" in the settings page. It needs to be toggleable, because I can only tolerate it for a short period. My naming was inspired by k9mail's settings called "Gaudy visual effects". May as well have some fun with words when implementing such effects.
But Compiz Fusion wasn’t all about impractical visual effects: wobbly windows was seriously useful, and rather popular, perhaps the one thing that people would leave enabled after playing with all the fun ridiculous stuff for a bit.
When you have things that move or resize windows instantaneously, e.g. snapping to one side of the screen, the wobble in the windows was a transition, one that helped you keep track of elements rather than everything just… changing.
Seriously, so useful for floating window managers, it’s a simple and obvious form of transition, significantly better than what window managers have ended up at these days (if anything).
(Then I switched to i3, and more recently Sway. Not sure I’d appreciate wobbly windows in tiling window managers, though maybe with gaps (… which I’ve never understood the appeal of) it might be better.)
When you say "gaps", do you mean space between windows? I do that. Seeing a bit of the wallpaper is like seeing a bit of your desk between papers. Helps with mental context switching. Window borders probably serve the same function, but they've never worked as well for me.
> 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).
reply