Programmer Humor

Terrible analogy. A webserver is not at all like a door. It doesn't block or allow traffic to and from your file system.

A web server is more like a receptionist. It handles requests. "Can I have your basic catalog?" "Certainly, here you go."

"Can I get this item from your basic catalog?" "Certainly."

"I don't see it in your catalog, but my buddy said he got this other item from you. Can I have this other item too?" "Absolutely."

"Can I borrow your stapler?" Sure. "How about a pad of paper?" "Of Course". "Can I just have the contents of your supply closet?" "Here you go." "How about your accounting files, can I get those?" "No problem!" "How about your entire customer list?" "Consider it done!"

When you hire a receptionist and specifically tell them to give customers anything they request, that's entirely on you. You have to at least make a token effort to restrict access to only authorized users before you can even claim that a particular user was unauthorized.

This wasn't burglary. This was putting up signs that say "come in" and labeling everything in your house with "free" stickers.

@SpaceCowboy @JackbyDev

In a legal context there's also the concept of a "reasonable expectation of privacy". The computer abuse and fraud act defines hacking as accessing data or systems you are not authorized to access.

A better analogy is putting your journal in a public library and getting mad when somone reads it.

I'm not saying what these ass holes did was right, I'm saying that the company weakened their legal position by not protecting the data.

Thank you! I feel like I'm taking crazy pills reading people's reactions to this. And if it was a business instead of your house and it was customer data you weren't protecting you should still be in trouble too. It's like people think only one side can be in the wrong in this or that because the data wasn't secured and in the public that gives them free reign to post it everywhere. I wonder how those people would feel if their addresses were leaked. Afterall, if you're a homeowner your name is attached to the property and is publicly accessible.

It can be both. The company can be at fault for not keeping something secure while the people who steal the data are at fault for stealing data. Data leaks and hacks are not mutually exclusive.

You know that's not the Tea code, but the downloader, right?

There's nothing wrong with manually breaking a loop.

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.

Be the change you want to see in the world.

Wow what a fuckin shitshow. I have so many follow-up questions