They've updated that documentation significantly since thousands of projects were issued automatically generated Firebase API keys, pre-Gemini. See this version from Oct 2022: https://web.archive.org/web/20221001052713/https://firebase....

Back then, they did not automatically restrict those keys to only Firebase-related APIs.

So yes, if you read the documentation as it exists today it's much more clear what they're trying to prevent, but this is only after this issue has become more apparent.

> Back then, they did not automatically restrict those keys to only Firebase-related APIs.

If that is the case, why is this also in the 2022 link?

The part about scoping links to the restrictions documentation.

"Understand API keys

API keys for Firebase services are not secret

Firebase uses API keys only to identify your app's Firebase project to Firebase services, and not to control access to database or Cloud Storage data, which is done using Firebase Security Rules. For this reason, you do not need to treat API keys for Firebase services as secrets, and you can safely embed them in client code. Learn more about API keys for Firebase.

Set up API key scoping

As an additional deterrent against an attacker attempting to use your API key to spoof requests, you can create API keys scoped to your app clients.

Keep FCM server keys secret

Unlike API keys for Firebase services, FCM server keys (used by the legacy FCM HTTP API) are sensitive and must be kept secret.

Keep service account keys secret

Also unlike API keys for Firebase services, service account private keys (used by the Admin SDK) are sensitive and must be kept secret. "

It's all about trade offs. No one is required to use all the latest tooling and frameworks, and writing things the 'good old way' still works, it'll just come with trade offs. Pick your poison.

Big fan of the Level 1 Tech KVMs, both the hardware and support are quite good. You're way more likely to run into issues with docks/monitors/usb devices etc than something actually wrong with the KVM itself.

And now Microsoft is going to solve all those problems? This'll be interesting to see how it plays out, but all of these issues are not confidence inspiring.

I think some skepticism is a healthy thing to have, especially with multi billion dollar acquisitions. It's a little surprising to me that there's been so much kool aid drinking in the open source community over this and a lot of "disappointment" with those who are not also drinking the kool aid.

At the end of the day, Microsoft, a huge billion dollar corporation, bought GitHub because it thinks it'll help its bottom dollar. And sure, of course I can see the business sense in the deal for both parties, but it's yet to be seen if it'll actually improve things for end users.

An interesting question might be, what other ways could you allow people in the queue to jump up in position, without requiring them to share with others?

Maybe a quick survey with questions like, - what email client do you use now? - what is your favorite/least favorite feature of said client? - how often do you check your email? etc

I was going to say this.

It's totally optional to invite more people, so if it goes against your ethical views, just don't.

Yeah, but by engaging in this behavior, the dev has convinced me this whole thing is click spam, so I’m done evaluating it before I even downloaded it.

*current thinkpads can also still do this.

I switched from a MBP to a ThinkPad because of Apple's decisions with product design; performance sacrificed for purely aesthetic reasons.

I highly doubt this, devices with batteries are near ubiquitous in many places and have been for decades now. "Electronics" knowledge or not, people have used batteries and will have noticed that over time its life goes down.