Comment by tr3ntg 10 months ago
As someone with an app built on firebase, yes. As the author rightly points out, it's very easy to misconfigure, but basic security practices like these are highlighted in bright, bold warning text in the Firebase docs.
Security rules are meant to be taken seriously, and it's your only line of defense.
Reading/watching random tutorials and asking basic questions on SO __instead of reading the official docs__ is a trend I've observed for the last 10 years. Even for stuff pretty well documented like Python, Postgres, React, etc.
Most official documentation is awful, and just an API reference. It's (almost) like asking someone to learn english and then pointing them to a dictionary.
And that's because a lot of devs think it's perfectly dandy to just put perfunctory docstrings in their methods, point it at whatever "doc generation" tool, wire it up to a github.io domain and call it a day.
There is a reason people crave, want and seek things like SO and blog-posts. They're packed full of insight, working examples and just plain old "how TF do you use this thing". Oh and of course, the "this problem A didn't work when using setup B and C, and that's because of reasons X,Y,Z. Here, try H,I & K and it'll work.
For many years entire sections across multiple pages of firebase's documentation were missing after the site contents had been migrated from one system to another.
Multiple years of sample code and examples just cut out from the middle of pages.
When I was building on firebase it took me a long time to reconstruct exactly how certain aspects of the system were supposed to work just because of those missing docs.
I remember writing a Twitter library when that was a thing, and being severely disappointed at the quality of the API documentation. There seemed to be little choice other than to experiment to see what responses you’d receive (and hope that it wouldn’t change underneath you). Same was often true with some of the GitHub APIs, although it’s been a few years since I’ve spent time with them.
I often wonder how much this can be attributed to the pretty awful SEO of most documentation. I write mostly Python at work and it's infuriating how often GeeksForGeeks, W3Schools, Programiz, or RealPython pop up when I'm just trying to reference like, the arg order of a builtin, or the particular behavior. Django is worse, I often feel like I can't even find the doc when I know it's there and read it before.
Documentation is largely static content. It isn't their job to play SEO games to convince search engines to surface it in the query results. Documentation is not a revenue generator for Google so it gets buried below the sites with Doubleclick ads.
For native documentation, why not just search the official docs at https://docs.python.org/ ?
I find it to be very discoverable if you are looking for docs about a specific function or module.
People have already given many ideas, but if you use DuckDuckGo they have bangs for searching various python docs. Here's a page that lets you search which ones are available: https://duckduckgo.com/bangs
Google is really good at surfacing random blogs and SO questions instead of the official docs.
For sure, I think the issue is – at what point in an engineer's development is that fact hammered home? For me it was hanging out with friends and learning fundamentals together, and then even more reinforced in the security course I took in college. For others, they might skip that elective in school (or their bootcamp will gloss over it), and they learn it the hard way later on the job?
That said, ideally code review/peer review/design review would catch things like this. If this was a feature implemented by an engineer that wouldn't know any better, they should have at least some help from others around them.
The issue is not about supporting engineers, this isn’t a pile-on to some poor engineer. It’s about choosing secure software, and avoiding software (particularly critical and vulnerable software like a web browser) from orgs that have built severe vulnerabilities into their software by incorrectly implementing something foundational to computer security.
There are many smart engineers who I would not trust to build my web browser because they lack the domain knowledge to do so. That’s not a slight on them. But if a company hired those people to make a web browser, I wouldn’t trust that org’s software.
This wasn't really a problem that required domain-specific knowledge to get right. Whoever designed an API that allows the client to bypass auth like that can't be trusted to design software that takes user input. At least not without some additional training that was missed along the way.
It points to a deeper issue in the Browser Company imo. Clearly, an inexperienced dev wrote that api, a senior approved the PR and no one in the wider team picked it up. And that's a team building the fundamental unit of your digital experience. If they failed at something this basic, I would be terrified to know what else they are missing in terms of security
I am glad to put engineers in quotes because many people here and elsewhere will use that word with a straight face while also believing that you can call yourself that while learning your job from watching youtube vids and pasting code you don't understand. We need to stop using the word "engineer" for "software developer".
I shall watch the downvotes come from these so called "engineers".
ChatGPT would have probably parrotted the bold text. It is always super concerned about risks.
> it's very easy to misconfigure, but basic security practices like these are highlighted in bright, bold warning text in the Firebase docs.
I'm sorry but if the whole design is "one big database shared with everyone and we must manually configure the database for auth" there is a problem that's deeper than just having to read the doc. It means the basic understanding of what it means to keep data as private as possible is not understood. A shared database only works when the server accesses it, not when client has direct access.
What Arc needs is to segregate each user's data in a different place, in the design of the database, not as part of configuration of custom code. Make it impossible to list all user's data, or even users. When, not if, an id is guessed, related data becomes accessible by someone else; make it so that someone else still can't read it, or can't replace it.
Maybe docs should try to be consistently more accurate, up to date, and legible than (even) stack overflow answers ¯ \ _ ( ツ ) _ / ¯
I have heard this said by many people: “I don’t look at documentation because it usually is inaccurate/out of date”
There’s plenty of people sharing anecdata about bad docs, and I’ve dealt with my fair share. But my anecdata is that engineers who habitually go to the docs directly and read them gain a better understanding and write better software than those who do not. I believe that most software for engineers has documentation that is more informative than stack overflow and blog posts.
I support reading docs first for questions, but man some truly are terrible.
Like cmake. This just vomits a dissertation at you for each function without really ever saying what it does or how to use it. That’s why there’s so many different sites and GitHub repos with samples. 95% of which are completely out of date (which is a problem cause people looking for these samples probably aren’t on the ups with being able to tell if they’re out of date)
None of that matters if it doesn't show up first or second in Google results.
> bold warning text in the Firebase docs.
Unfortunately, we currently have an industry where highly paid "engineers" unironically believe that their job can be done by reading/watching random tutorials, googling for StackOverflow answers, and pasting code from gists.
Attentively reading documentation or developing a mental model of how your tools work so that you know how they are built to be handled does not make it on to any job listing bullet points. It presumably fell off the bottom in favor of team spirit or brand enthusiasm or whatever.
How many tutorials, community answers, and gists do you think conveyed that warning?