replaced anchor <a> tag with id= tag on /developer/hig/key-concepts/

test.commotion/_site/css/commotion.css

@@ -530,6 +530,7 @@ div.cck-download-pdf {
 .blog-index a:link,
 .blog-index a:visited {
   border-bottom: none;
+  font-size: 1.1em;
 }
 .blog-index a:hover {
   border-bottom: 3px solid #FF739C;

test.commotion/_site/developer/hig/key-concepts/index.html

@@ -177,7 +177,7 @@ <h2>Common language</h2><p>A successful UI running on multiple devices must shar
 	<li><strong>Help</strong></li>
 	<li><strong>Log</strong></li>
 	<li><strong>Quit</strong></li>
-</ol><p><a name='security' /></p><h2>Security, privacy and anonymity</h2><p>A significant challenge in developing Commotion is balancing ease-of-use and control over functionality. Different users will want Commotion to serve different purposes, and our choices in features and design will make some things easier and some things harder. Unfortunately, we cannot make a perfect package for all situations: we need to be clear about the limitations inherent in Commotion, especially regarding matters of security, privacy and anonymity. These three concepts are related through their importance to communities and people with “real life” concerns of oppression, surveillance, and other attacks.</p><p><strong>Warnings</strong></p><p>While Commotion software can’t be solely responsible for providing a definitive education on these topics, the software should make clear any risks or benefits of features that deal with security, privacy, or anonymity.</p><p>When a user takes an action that could affect their security, privacy or anonymity, they should see a simple warning message that invites them to learn more by linking to external documentation. Here's an example warning that could pop-up after a user changes the node name. It should include a "Don't warn me again" checkbox to disable this warning for the future. The Commotion website should offer details about potential risks and vulnerabilities related to using the tools in common scenarios.</p><p><img alt='' src='/files/security_0.png' style='height:392px; margin-bottom:0px; margin-top:0px; width:293px' /></p><p><strong>Security</strong></p><p>Within the context of Commotion, you should consider the information security of data on a network as well as the physical security of people using the network. Data security involves trust, fault tolerance, and integrity of connections between mesh nodes. Physical security overlaps with privacy in many ways: can the people who have created the network be identified based on visible hardware or detectable radio signals? We have the responsibility and ability to inform users of information security concerns, but how do we introduce the topic of physical security?</p><p>Commotion’s documentation should explain wireless network security concepts and how mesh networks and traditionally-routed networks differ with regards to security. This documentation should be referenced during the initial configuration of a network.</p><p><strong>Privacy and Anonymity</strong><br />
+</ol><h2 id='security'>Security, privacy and anonymity</h2><p>A significant challenge in developing Commotion is balancing ease-of-use and control over functionality. Different users will want Commotion to serve different purposes, and our choices in features and design will make some things easier and some things harder. Unfortunately, we cannot make a perfect package for all situations: we need to be clear about the limitations inherent in Commotion, especially regarding matters of security, privacy and anonymity. These three concepts are related through their importance to communities and people with “real life” concerns of oppression, surveillance, and other attacks.</p><p><strong>Warnings</strong></p><p>While Commotion software can’t be solely responsible for providing a definitive education on these topics, the software should make clear any risks or benefits of features that deal with security, privacy, or anonymity.</p><p>When a user takes an action that could affect their security, privacy or anonymity, they should see a simple warning message that invites them to learn more by linking to external documentation. Here's an example warning that could pop-up after a user changes the node name. It should include a "Don't warn me again" checkbox to disable this warning for the future. The Commotion website should offer details about potential risks and vulnerabilities related to using the tools in common scenarios.</p><p><img alt='' src='/files/security_0.png' style='height:392px; margin-bottom:0px; margin-top:0px; width:293px' /></p><p><strong>Security</strong></p><p>Within the context of Commotion, you should consider the information security of data on a network as well as the physical security of people using the network. Data security involves trust, fault tolerance, and integrity of connections between mesh nodes. Physical security overlaps with privacy in many ways: can the people who have created the network be identified based on visible hardware or detectable radio signals? We have the responsibility and ability to inform users of information security concerns, but how do we introduce the topic of physical security?</p><p>Commotion’s documentation should explain wireless network security concepts and how mesh networks and traditionally-routed networks differ with regards to security. This documentation should be referenced during the initial configuration of a network.</p><p><strong>Privacy and Anonymity</strong><br />
 <br />
 Commotion documentation should clearly discuss any issues of privacy and data retention. When Commotion generates and retains logs, it should provide options to anonymize the data, clear logs periodically, and disable logging. If the software collects metadata from the device, it should prompt the user to allow for this information to be spread across the network. If the platform allows it, Commotion software should allow for changing MAC addresses through the advanced settings.</p><p>In addition to abilities that Commotion can offer at the network level, the documentation should point to privacy and anonymity resources above the mesh network layer. While software can prevent some attacks against privacy and anonymity, the documentation should outline any vulnerabilities associated with traffic analysis and radio monitoring.</p><p><a href='https://wiki.commotionwireless.net/doku.php?id=commotion_architecture' target='_blank'>Read more about Commotion Security Architecture.</a></p><h2>Common footer</h2><p>A common footer menu should be available throughout the UI. This ensures that users have consistent access to standard functions of the software at all times. For web-based and desktop applications, create a common green footer in the UI.</p><p>In Android, use the native menu. The menu items can also be collapsed to the Android "action overflow" button in the navigation bar if needed.</p><p>The menu items are:</p><ol>
 	<li><strong>Advanced</strong> (Goes to a menu of advanced settings)</li>

test.commotion/developer/hig/key-concepts/index.md

@@ -55,9 +55,7 @@ lang: en
 	<li><strong>Quit</strong></li>
 </ol>
 
-<p><a name="security"></a></p>
-
-<h2>Security, privacy and anonymity</h2>
+<h2 id="security">Security, privacy and anonymity</h2>
 
 <p>A significant challenge in developing Commotion is balancing ease-of-use and control over functionality. Different users will want Commotion to serve different purposes, and our choices in features and design will make some things easier and some things harder. Unfortunately, we cannot make a perfect package for all situations: we need to be clear about the limitations inherent in Commotion, especially regarding matters of security, privacy and anonymity. These three concepts are related through their importance to communities and people with “real life” concerns of oppression, surveillance, and other attacks.</p>