Archived web mining considerations

This section keeps the useful part of the old experiment: understanding what happens when a website runs expensive work in the browser. It should be read as an educational note, not as a recommendation to deploy a real miner.

When it could make sense

The original goal of this project was to explore an alternative to traditional monetization. In practice, the costs in consent, reputation, CPU usage and blocking by security tools make it a poor fit for normal websites.

A visitor arrives to read, compare or use a service, not to donate processor time without a clear agreement. Even a technically correct implementation can feel abusive if the page becomes slower, the laptop fan starts spinning or the phone battery drops. That perception is enough to damage trust.

What should be reviewed first

A safer modern approach is to simulate proof of work locally, explain the trade-offs and avoid connecting visitors to a real mining pool.

Explain what work will run before starting it.
Require explicit opt-in instead of automatic execution.
Show pause and stop controls that are always visible.
Limit CPU usage and never run in hidden tabs.
Avoid opaque third-party scripts that users and maintainers cannot audit.

Why this is archived instead of recommended

Browser mining became associated with malware, hidden monetization and unwanted resource consumption. That means browsers, antivirus tools, corporate proxies and ad blockers often treat it as suspicious. For most projects the operational cost is higher than the possible income.

If the goal is education, a proof-of-work simulator is cleaner: it explains hashes, nonce search and difficulty without sending real work to a pool. If the goal is monetization, subscriptions, sponsorships or clearly labeled ads are easier to defend.