It's not uncommon that we stumble across a new thread asking how to hide source code. And, out of curiosity, I've been playing with some strategies and pondering to what extent client-side code can be hidden. I've made more progress than I expected, but I also see pretty clearly where the journey ends (customized browser). So, I've become curious as to what strategies other developers have been using to address some of the concerns that source-hiding might be used to address:

API Protection
If you can hide an API key in the source, you can use it to sign requests and ensure that they originate from your code, which can be tied to a domain or page, theoretically without relying on the HTTP referer header, which I'm lead to believe is pretty unreliable. (Does anyone know if the FB API, for instance, required a referer header alongside the API key when used client-side?)

Three general concerns here: hiding "the goal" when "the goal" can't realistically be checked on the server due to the frequency of the check; protecting the game logic from tampering; protecting the API from spoofed events (same as API protection above).

Internal Property Protection
Most "owned" algorithms [or data] should simply be operated [on] server-side. But, if one such set of algorithms [or data] is useful only at a high frequency of use (tens, hundreds, thousands, millions of times per second, etc.), it may need to operate client-side. But, your business may be built on creating and maintaining those algorithms and/or data. And if they're trivial to siphon off the site, as JavaScript usually is, your clients may feel they only need to pay for a month's subscription.

Copy Protection
An application built on the KISS principle is often easy to steal, in part or entirely. There may be very few individual scripts and images involved. Thus, the application may simply be lifted and dropped on another site. It may be modified and used to spoof the original site or steal business.

User Data Protection
As a curtesy to visitors, you may want to project against aggressive script/request caching by sending a user's more sensitive information in a hidden format, one that is later un-usable after the page is not active in the browser.

What methods are currently in play to address these sorts of concerns? If your answer entails legal action or cautions, please describe the theft/cheat/scam-detection methods you'd use to catch your TOS infringers.

Are there any other concerns you would add to the list? How do you currently address them?

Is anyone of the mindset that scripts should all be as open and obvious as possible, so that if anyone can cheat/hack the system, everyone can, ensuring that no one has special privileges on account of their hacking skills?

Is anyone of the mindset that any or all of the above concerns are best protected by "keeping things fresh?" I.E., that keeping the site/application updated on a regular basis discourages theft, cheating, hacking, etc.?

Anyone interested to see, test, and criticize my feeble educational pursuits in the matter?