fix(security): replace Learn Hub and wiki links with internal references

docs/guides/security/canister-control.md

@@ -28,12 +28,11 @@ In the following list, we first provide recommendations for centralized canister
     - 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.
-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).
+3. **Full community governance**: The app is controlled by a governance framework such as ICP's [Service Nervous System (SNS)](../../concepts/governance.md#the-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](../../concepts/governance.md#neurons).
     - 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 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).
 
 An alternative to community governance (3. above) would be to create an immutable canister by removing the canister controller completely. This can be achieved by setting the controller to a [black hole canister](https://github.com/ninegua/ic-blackhole). However, note that this implies that the canister can **never** be upgraded, which may have severe implications in case a bug is found. The complexity of ICP apps and the fact that complex frontends are hosted as canisters means that black holed canisters are rarely the right solution. The option to use a governance framework and thus being able to upgrade canisters is a big advantage of the ICP ecosystem compared to other chains.
 

docs/guides/security/canister-upgrades.md

@@ -21,8 +21,6 @@ If a canister traps or panics in `pre_upgrade`, this can lead to permanently blo
 
 - See also the section on upgrades in [how to audit an Internet Computer canister](https://www.joachim-breitner.de/blog/788-How_to_audit_an_Internet_Computer_canister) (though focused on Motoko).
 
-- See [current limitations of the Internet Computer](https://wiki.internetcomputer.org/wiki/Current_limitations_of_the_Internet_Computer), section "Bugs in `pre_upgrade` hooks."
-
 ## Reinstantiate timers during upgrades
 
 ### Security concern

docs/guides/security/data-integrity-and-authenticity.md

@@ -612,7 +612,7 @@ function bigEndian(n) {
 
 ### Security concern
 
-Apps on ICP can use [asset certification](https://learn.internetcomputer.org/hc/en-us/articles/34276431179412-Asset-Certification) to make sure the HTTP assets delivered to the browser are authentic (i.e., threshold-signed by the subnet). If an app does not do asset certification, it can only be served insecurely through `raw.icp0.io`, where no asset certification is checked. This is insecure since a single malicious node or boundary node can freely modify the assets delivered to the browser.
+Apps on ICP can use [asset certification](../frontends/certification.md) to make sure the HTTP assets delivered to the browser are authentic (i.e., threshold-signed by the subnet). If an app does not do asset certification, it can only be served insecurely through `raw.icp0.io`, where no asset certification is checked. This is insecure since a single malicious node or boundary node can freely modify the assets delivered to the browser.
 
 If an app is served through `raw.icp0.io` in addition to `icp0.io`, an adversary may trick users (phishing) into using the insecure `raw.icp0.io`.
 

docs/guides/security/data-storage.md

@@ -49,8 +49,6 @@ Canister memory is not persisted across upgrades. If data needs to be kept acros
 
 - A commonly used library for stable memory is [stable-structures](https://github.com/dfinity/stable-structures).
 
-- See [current limitations of the Internet Computer](https://wiki.internetcomputer.org/wiki/Current_limitations_of_the_Internet_Computer), sections "Long running upgrades" and "\[de\]serializer requiring additional Wasm memory."
-
 - For example, [Internet Identity](https://github.com/dfinity/internet-identity) uses stable memory directly to store user data.
 
 ## Consider encrypting sensitive data on canisters

docs/guides/security/inter-canister-calls.md

@@ -324,8 +324,6 @@ When making inter-canister calls, always handle the error cases (rejects) correc
 
 - See the "Talking to malicious canisters" section in [how to audit an ICP canister](https://www.joachim-breitner.de/blog/788-How_to_audit_an_Internet_Computer_canister).
 
-- See [current limitations of the Internet Computer](https://wiki.internetcomputer.org/wiki/Current_limitations_of_the_Internet_Computer), section "Calling potentially malicious or buggy canisters can prevent canisters from upgrading."
-
 
 ## Make sure there are no loops in call graphs
 
@@ -337,6 +335,5 @@ Loops in the call graph (e.g., canister A calling B, B calling C, C calling A) m
 
 - Avoid such loops, or rely on bounded-wait calls instead, since these provide timeouts.
 
-- For more information, see [current limitations of the Internet Computer](https://wiki.internetcomputer.org/wiki/Current_limitations_of_the_Internet_Computer), section "Loops in call graphs."
 
 <!-- Upstream: informed by dfinity/portal building-apps/security/inter-canister-calls.mdx; dfinity/icskills skills/canister-security/SKILL.md -->