fix(security): remove onchain/offchain labels; tamper-resistant -> tamperproof

Per updated brand voice rules:
- offchain components -> external components/infrastructure (decentralization.md)
- tamper-resistant -> tamperproof (observability-and-monitoring.md)

Author: marc0olo

docs/guides/security/decentralization.md

@@ -17,21 +17,21 @@ Dapps are commonly reachable over their own custom domain name instead of ic0.ap
 
 An app might have privileged features that are only accessible to principals that are on an allow list. For example, minting new tokens, debugging functions, managing permissions, removing NFTs for digital rights violations, etc. This means that whoever controls that principal (such as the app developers) may have central control over these privileged features.
 
-For performance or privacy reasons, some components of an app may be hosted offchain. These offchain components often control principals used to interact with the canisters and are usually controlled by a developer holding credentials to the offchain cloud environment. On top of that, third party offchain entities such as cloud providers can inspect and manipulate data in this environment if they choose. They could take ICP principal private keys out of this environment and call privileged operations on the canisters. Offchain components can quickly lead to many additional centrally trusted parties. Depending on the value managed by an app, these parties could be tempted to act maliciously.
+For performance or privacy reasons, some components of an app may be hosted on external infrastructure. These external components often control principals used to interact with the canisters and are usually controlled by a developer holding credentials to the cloud environment. On top of that, third parties such as cloud providers can inspect and manipulate data in this environment if they choose. They could take ICP principal private keys out of this environment and call privileged operations on the canisters. External components can quickly lead to many additional centrally trusted parties. Depending on the value managed by an app, these parties could be tempted to act maliciously.
 
 ### Recommendations
 
 In the following list, we first provide recommendations for centralized canister control and then move to recommendations for increasingly decentralized settings. From a security perspective, more decentralization is favorable. The following list could also be used as a basis for assessing an app's level of decentralization. This is just a set of recommendations and may be incomplete.
 
-1. **The app uses central, offchain components:** The application makes use of centralized components such as those running in the cloud. The owners of these cloud services have full control over the application and assets managed by it. Your application should likely be further decentralized by avoiding central components. But while you have them, [securely manage your keys in the cloud](https://cloudsecurityalliance.org/research/topics/cloud-key-management/).
+1. **The app uses central, external components:** The application makes use of centralized components such as those running in the cloud. The owners of these cloud services have full control over the application and assets managed by it. Your application should likely be further decentralized by avoiding central components. But while you have them, [securely manage your keys in the cloud](https://cloudsecurityalliance.org/research/topics/cloud-key-management/).
 2. **The app is controlled by the developer team:** Your project is not under decentralized control, for example, because it is in an early development stage or does not (yet) hold significant funds. In that case, it is recommended to manage access to your canisters securely and ideally not let individuals control the application. To achieve that, consider the following:
     - Require approval by several individuals or parties to perform any canister controller operations.
     - Require approval by several individuals or parties for any security-sensitive changes at the application level that are restricted to privileged principals, such as admin operations including permissions management, minting new tokens, removing NFTs for digital rights violations, etc.
     - A helpful tool to achieve either of the above two points is the [orbit station canister](https://github.com/dfinity/orbit) which allows you to configure intricate policies for canister control. [Orbit](https://orbit.global/) also serves as an enterprise wallet where token funds are governed using policies. Ideally, individuals also manage their key material using hardware security modules, such as [YubiHSM](https://www.yubico.com/ch/store/yubihsm-2-series/) and physically protect these through methods such as using safes at different geographical locations. Some of HSMs support threshold signature schemes, which can help to further secure the setup. To increase transparency about the changes made to an app, consider using a tool like [LaunchTrail](https://github.com/spinner-cash/launchtrail).
 3. **Full community governance**: The app is controlled by a governance framework such as ICP's [Service Nervous System (SNS)](https://learn.internetcomputer.org/hc/en-us/articles/34084394684564-SNS-Service-Nervous-System), so that any security-sensitive changes to the canisters are only executed if the SNS community approves them collectively through a proposal voting mechanism. If an SNS is used:
     - Make sure voting power is distributed over many independent entities such that there is not one single or a few entities that can decide by themselves how the [community governance evolves](https://learn.internetcomputer.org/hc/en-us/articles/34088279488660-Tokenomics#voting-power-and-decentralization).
     - Ensure all components of the app are under SNS control, including the canisters serving the web frontends; see [SNS asset canisters](../governance/managing.md).
-    - Consider the [SNS preparation checklist](../governance/launching.md). Important points from a security perspective are tokenomics, disclosing dependencies to offchain components, and performing security reviews.
+    - Consider the [SNS preparation checklist](../governance/launching.md). Important points from a security perspective are tokenomics, disclosing dependencies to external components, and performing security reviews.
     - Rather than self-deploying the SNS code or building your own governance system, consider using the official SNS on the SNS subnet, as this guarantees that the SNS is running an NNS-blessed version and maintained as part of ICP.
     - See also [verification and trust in a (launched) SNS](https://wiki.internetcomputer.org/wiki/Verification_and_trust_in_a_(launched)_SNS) and [SNS decentralization swap trust](https://wiki.internetcomputer.org/wiki/SNS_decentralization_swap_trust).
 

docs/guides/security/observability-and-monitoring.md

@@ -15,7 +15,7 @@ Without monitoring, it can be hard to detect attacks or vulnerabilities that are
 
 - Monitor your canister's cycles balance regularly, set up alerts for sudden changes in cycles consumption, and add an endpoint to expose health indicators. See the [DoS prevention best practices](./dos-prevention.md) for more context on cycles monitoring.
 
-- Consider emitting logs for security-relevant events (e.g., access control failures, unexpected state transitions). Since logs are stored in the canister, they provide a tamper-resistant audit trail.
+- Consider emitting logs for security-relevant events (e.g., access control failures, unexpected state transitions). Since logs are stored in the canister, they provide a tamperproof audit trail.
 
 - See [effective Rust canisters](https://mmapped.blog/posts/01-effective-rust-canisters.html) for general patterns on canister observability.