In a literal sense, it very well may have been trivial, even if neither you nor the professor would have been able to easily show it.

The only other provider known to work that way is NearlyFreeSpeech.NET, which serves a completely different market segment (so much so that it might as well not even be considered the same kind of product/service).

How?

"Firebase AI Logic"

Is this a Firebase service or not?

And "Firebase AI Logic" sure sounds like something easy to confuse with a Firebase service...

<https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...>

> tl;dr Google spent over a decade telling developers that Google API keys (like those used in Maps, Firebase, etc.) are not secrets. But that's no longer true: Gemini accepts the same keys to access your private data. We scanned millions of websites and found nearly 3,000 Google API keys, originally deployed for public services like Google Maps, that now also authenticate to Gemini even though they were never intended for it. With a valid key, an attacker can access uploaded files, cached data, and charge LLM-usage to your account. Even Google themselves had old public API keys, which they thought were non-sensitive, that we could use to access Google’s internal Gemini.

From Google themselves, in the Firebase docs:

> 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.

<https://firebase.google.com/support/guides/security-checklis...>

... or at least that's what it used to say, until they quietly updated the docs to say this:

> 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.

Followed later by (in different section):

> 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 problem is that despite using the same DVCS for source code management, other projects insist on a hub-and-spokes development model, which does not scale.

Projects would be a lot more productive (and a lot more resilient) if they also followed a model where "The maintainer hasn't accepted my pull request" just wasn't a big deal.

https://dreamm.aarongiles.com/docs/v40/#intro-games

It doesn't list any Barbie titles. It's not the project that I'm thinking of.

I'm looking for that blog post, the list of titles, and the short subthread about it that I mentioned not being able to find.

I thought I remembered a recent update from one of the various API/engine re-implementation projects (e.g. something like but not necessarily ScummVM, Wine/Proton, or something associated with archive.org's Emularity project) that included a list of new titles that had become playable due to some recent fixes, and among those titles were (I thought) a bunch of Barbie and other low-budget franchise games in that vein. There wasn't any particular focus on these outside any of the other games listed—they were just mentioned in passing. Someone did bring it up in the comment section—maybe here on HN—but searching around didn't turn anything up.

Any ideas?

At the end of a talk about Oauth 2.0 at some indie or fediverse conference during lockdown, Aaron Parecki, who was then and still is employed at Okta, was asked if it might not be worth isolating the parts of the protocol/flow that actually requires a service (i.e. protocol-aware server in the loop) from those that don't, so that you could still get limited authentication/identity-tagging if your "provider" is your personal domain where you're just hosting static site. He immediately acted like he was addressing the dumbest person in the virtual room (it was a remote conference), telegraphing through his response that he might actually be on the verge of physical pain having to deal with such an imbecilic question.

GitHub customers really are willing to do anything besides coming to terms with the reality confronting them: that it might be GitHub (and the GitHub community/userbase) that's the problem.

To the point that they'll wax openly about the whole reason to stay with GitHub over modern alternatives is because of the community, and then turn around and implement and/or ally themselves with stuff like Vouch: A Contributor Management System explicitly designed to keep the unwashed masses away.

Just set up a Bugzilla instance and a cgit frontend to a push-over-ssh server already, geez.