If one ignores 70% of the documentation, it makes for a demonizing blog post about it, sure.
"
API keys for Firebase services are not secret
API keys for Firebase services only identify your Firebase project and app to those services. Authorization is handled through Google Cloud IAM permissions, Firebase Security Rules, and Firebase App Check.
All Firebase-provisioned API keys are automatically restricted to Firebase-related APIs. If your app's setup follows the guidelines in this page, then API keys restricted to Firebase services do not need to be treated as secrets, and it's safe to include them in your code or configuration files.
Set up API key restrictions
If you use API keys for other Google services, make sure that you apply API key restrictions to scope your API keys to your app clients and the APIs you use.
Use your Firebase-provisioned API keys only for Firebase-related APIs. If your app uses any other APIs (for example, the Places API for Maps or the Gemini Developer API), use a separate API key and restrict it to the applicable API."
The only reasonable design is to have two kinds of API keys that cannot be used interchangeably: public API keys, that cannot be configured to use private APIs, and private API keys, that cannot be configured to use public APIs. There's no one who must use a single API key for both purposes, and almost all cases in which someone does configure an API key like that will be a mistake. It would be even better if the API keys started with a different prefix or had some other easy way to distinguish between the two types so that I can stop getting warnings about my Firebase keys being "public".
It'd be much better to call them something like "API usernames" or "API Client IDs". Though I also dislike the naming of "public keys" in asymmetric cryptography, for the same reasons, and I'm definitely not winning that fight!
that doesn't seem to be the case always, given the data on crime reporting:
"Patterns in police reporting for property crime during 2020–2023 were similar to those for violent crime. A quarter (25%) of all property victimizations in urban areas were reported to police, which was lower than the percentages in suburban (33%) and rural (36%) areas (figure 2).
Similar to overall property victimization, a lower percentage of other theft victimizations were reported to police in urban areas (20%) compared to suburban (28%) and rural (31%) areas."
"For violent crimes, in 1997, 7% of victims
stated that “Police wouldn’t help” as the reason they did not call the police. This more than
doubled to 16% by 2021. For property crimes, the corresponding rates were 12% in 1997 and 18% in
2021"
Look at the silver lining - once the paperclip maximizers have crashed both modern civilization and the biosphere, it will be easy for any survivors to find privacy amid the metaphorical and actual ruins.
Although I'm wrong about it being closely enough related to the Model Y's platform to really say "it's a Model Y," many of those stainless steel panels are absolutely secured with fasteners and glue.
The Artemis program has an estimated cost of 93B since 2012 [0].
As a comparison:
"Between 2020 and 2024, $771 billion in Pentagon contracts went to just five firms: Lockheed Martin ($313 billion), RTX (formerly Raytheon, $145 billion), Boeing ($115 billion), General Dynamics ($116 billion), and Northrop Grumman ($81 billion). In comparison, the total diplomacy, development, and humanitarian aid budget, excluding military aid, was $356 billion."[1]
Could be. The thing is, it kinda doesn't matter; what matters is, what will result in the least bugs/vulnerabilities now? To which I argue the answer is, keeping GNU coreutils. I don't care that they have a head start, I care that they're ahead.
That's short sighted. The least number of bugs now isn't the only thing that matters. What about in 5 years from now? 10 years? That matters too.
To me it seems inarguable that eventually uutils will have fewer bugs than coreutils, and also making uutils the default will clearly accelerate that. So I don't think it's so easy to dismiss.
I think they were probably still a little premature, but not by much. I'd probably have waited one more release.
reply