Exercise 3: Where Code Runs vs. Who Can Run It — Possible Solution
====================================================================

THE DISTINCTION EXPLAINED
------------------------------
Per this chapter, putting code inside a Cloud Function controls WHERE that code executes - on Firebase's own servers, rather than in the user's browser - which is exactly what's needed to keep a genuine secret safe, or to run code with more trust than the client should have. It says nothing at all about WHO is allowed to invoke that function in the first place. Those are two separate problems: one is about the execution environment, the other is about authorization.

WHY IT DOESN'T AUTOMATICALLY PREVENT ABUSE
------------------------------
Because Chapter 1 already established that Firebase's client-side config isn't secret, anyone outside this app who obtains that same public config could call lookupBarcode directly, as often as they like - the function itself has no built-in mechanism limiting who can trigger it or how frequently. Moving the code server-side protects a secret (if there were one) or centralizes logic, but it doesn't, by itself, add any authorization check.

WHAT WILL ACTUALLY ADDRESS THIS LATER
------------------------------
Firebase Authentication, covered in Chapter 11, is what this chapter points to as the actual mechanism for controlling who can call functions like this one (App Check is mentioned as another possible layer, but Firebase Authentication is the one this course's own later chapter actually builds).

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly separates "where code runs" from "who can invoke it," explains concretely why the function alone doesn't prevent abuse given the non-secret client config, and correctly names Chapter 11's Firebase Authentication as the mechanism that actually addresses authorization.