pserwylo

> 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.

"Vim Exit% Speedrun [WR - 2.50:13]"

For those interested, I've documented the process I adopted to try to increase the bus factor beyond one [0]. I want people who download the game and open it to be able to find a public server instantly from the main menu, even if I am unable to maintain the main server myself. This is done via the game requesting a manifest containing public servers from a GitHub repo, which accepts PRs from those willing to maintain their own servers. Although I am the only one able to accept those PRs right now, it would be silly not to be liberal in onboarding others who show an interest in maintaining the list. That way the game lives on beyond just me.

I also make sure to offer local multiplayer, and in other games I've built I which don't need realtime multiplayer, I try to offer "Play against others by sending an SMS invite" or other novel approaches that don't even need a server.

It is a fun space to work on and try to come up with novel solutions to ensure games continue working into the future.

But yes, you are correct that they are indeed an inconvenient database abstraction.

The only thing I will say is that despite the crummy abstraction, we did put the effort in to have good test coverage of each ContentProvider. It took a while to get the infrastructure up and running so that we even could test them, but once the plumbing was added, it became simple to add new tests to ensure they worked as expected.

This is important when you need to take into account things like "Get me all the apps, but filter on category, and then also limit those Apps to ones for which they have at least one Apk which is installable on my hardware, meets my AntiFeatures requirements, and then also pull back data about whether there is a version that can be upgraded to or not based on currently installed apps. I fell in love with the SQLite explain output. I found it really good at explaining what was going on with these mildly complex joins - much easier than the MySQL explain output I was familiar with.