I agree that this is ultimately a problem with developers lacking security knowledge and general understanding, but my issue with Firestore specifically is that it is a powerful tool that, while it can be adopted as part of a carefully considered tech stack, lends itself most naturally towards being a blunt force instrument used by these kinds of developers.

My main criticism of Firestore is that it offers a powerful feature set that is both extremely attractive to amateur or constrained developers while simultaneously doing a poor job of guiding said amateurs towards creating a secure and well designed backend. In particular, the seemingly expected use case of the technology as something directly interfaced with by apps and other clients, as evidenced by the substantial support and feature set for this use case, is the main issue. This no-code no-management client driven interaction model makes it especially attractive to these developers.

This lack of indirection through an API Gateway or service, however, imposes additional design considerations largely delegated to the security rules which can easily be missed by a beginner. For example:

1. Many examples of amateurs take an open-by-default approach, only applying access and write restrictions where necessary and miss data that should be restricted
2. Some amateurs deploy databases with no access or write restrictions at all
3. There is no way to only allow a "view" of a document to a request, instead a separate document and security rules containing the private fields needs to be created. This can be fairly simple to design around but seems to be a bit of a "gotcha", plus if you have similar but non identical sets of data that needs to be accessible by different groups it must be duplicated and manually synchronized.
4. Since there is no way to version data models, incompatible changes require complicated workarounds or an increasingly complicated deserialization process on the client side (especially as existing clients continue to write outdated models).
5. Schema validation of data written by clients to the database is handled by security rules, which is seemingly unintuitive or missed by many developers because I've seen plenty of projects miss it
6. If clients are writing data directly, it can become fairly complex to handle and subsequently maintain their contributions, especially if the aforementioned private data documents are required or the data model changes.

All of these pitfalls can be worked around (although I would still argue for some layer of indirection at least for writes), but at this point I've been contracted to 2 or 3 projects worked on by "professionals" (derogatory) that failed to account for any of these issues and I absolutely sick to death of it. I think a measure of a tools quality is whether it guides a developer towards good practices by design and I have found Firestore to completely fail in that regard. I think it can be used well, and it is perfectly appropriate for small inconsequential (as in data leaks would be inconsequential) single developer projects, but it almost never is.

I absolutely despise Firebase Firestore (the database technology that was "hacked"). It's like a clarion call for amateur developers, especially low rate/skill contractors who clearly picked it not as part of a considered tech stack, but merely as the simplest and most lax hammer out there. Clearly even DynamoDB with an API gateway is too scary for some professionals. It almost always interfaces directly with clients/the internet without sufficient security rules preventing access to private information (or entire database deletion), and no real forethought as to ongoing maintenance and technical debt.

A Firestore database facing the client directly on any serious project is a code smell in my opinion.

I think, for me, owning a printer is like owning a van. You're the only person your friends know who has one, so every time someone needs it you're the one they ask.

I've experienced this exact issue with the Google Play Store with some clients and it's just the worst. This kinda thing happens because Google is essentially half-arsing an Apple-style comprehensive review of apps. For context, Apple offers thorough reviews pointing to exactly how the app violates policy/was rejected, with mostly free one-on-one support with a genuine Apple engineer to discuss or review the validity of the report/how to fix it. They're restrictive as hell and occasionally make mistakes, but at the end of the road there is a real, extremely competent human able to dedicate time to assist you.

Google uses a mix of human and automated reviewers that are even more incompetent than Apple's frontline reviewers. They will reject your app for what often feels like arbitrary reasons, and you're lucky if their reason amounts to more than a single sentence. Unlike Apple, from that point you have few options. I have yet to find an official way to reach an actually useful human unless you happen to know someone in Google's Android/Developer Relations team.

I'm actually certain that the issues facing Nextcloud are not some malicious anti-competitive effort, but yet more sheer and utter incompetence from every enterprise/business facing aspect of Google.

Fifth, they could simply write checks to Treasury that help us finance global public goods.

You have to be fucking kidding me.

Why is astroturf "woke"?

Bofa deez nuts

It's not impossible, just very labour intensive and difficult. Compiling an abstract, high level language into machine code is not a reversible process. Even though there are already automated tools to "decompile" machine code back to a high level language, there is still a huge amount of information loss as nearly everything that made the code readable in the first place was stripped away in compilation. Comments? Gone. Function names? Gone. Class names? Gone. Type information? Probably also gone.

Working through the decompiled code to bring it back into something readable (and thus something that can be worked with) is not something a lone "very smart person" can do in any reasonable time. It takes likely a team of smart people months of work (if not years) to understand the entire structure, as well as every function and piece of logic in the entire program. Once they've done that, they can't even use their work directly, since to publish reconstructed code is copyright infringement. Instead, they need to write extremely detailed documentation about every aspect of the program, to be handed to another, completely isolated person who will then write a new program based off the logic and APIs detailed in the documentation. Only at that point do they have a legally usable reverse engineered program that they can then distribute or modify as needed.

Doing this kind of reverse engineering takes a huge amount of effort and motivation, something that an app for 350 total sneakers is unlikely to warrant. AI can't do it either, because they are incapable of the kind of novel deductive reasoning required for the task. Also, the CarThing has actually always been "open-source", and people have already experimented with flashing custom firmware. You haven't heard about it because people quickly realised there was no point - the CarThing is too underpowered to do much beyond its original use.

The computer is probably locked down and all software/os provisioned by their IT department

Go to your local transfem meetup

Naming your chatbot Arya(n) is a red flag

Cool party, stand for a lot of good things, including sex workers. I think they're called "reason" now