Explain the UI guidelines a little better

Fixes the “source” comment in #23.

storage.bs

@@ -173,14 +173,15 @@ and <a>permission</a> for "<code>persistent-storage</code>" can be used as indic
 
 User agents should not distinguish between network storage and <a>site storage</a> in their user
 interface. Instead user agents should offer users the ability to remove all storage for a given
-<a>site</a>. This ensures that storage from one source cannot be used to revive storage from another
-source. This also helps users avoid having to know about the different ways in which <a>sites</a>
-can store data.
-
-<p class=XXX>This is still a concern due to HTTP ETag...
-
-Credentials storage should still be separated however as it might contain data the user might not be
-able to revive, such as an autogenerated password.
+<a>site</a>. This ensures to some extent that network storage cannot be used to revive
+<a>site storage</a>. This also reduces the amount users need to know about the different ways in
+which <a>sites</a> can store data.
+<!-- To some extent, since HTTP ETag... And also, permissions/credentials, maybe? -->
+
+Credentials storage should be separated as it might contain data the user might not be able to
+revive, such as an autogenerated password. Since permissions storage is mostly simple booleans it
+too can be separated to avoid inconveniencing the user. Credentials and permissions are also
+somewhat easier to understand and differentiate from network storage and <a>site storage</a>.
 
 
 <h3 id=storage-pressure>Storage Pressure</h3>

storage.html

@@ -215,11 +215,12 @@ <h2 class="heading settled" data-level="5" id="usage-and-quota"><span class="sec
 "popularity". </p>
    <h2 class="heading settled" data-level="6" id="ui-guidelines"><span class="secno">6. </span><span class="content">User Interface Guidelines</span><a class="self-link" href="#ui-guidelines"></a></h2>
    <p>User agents should not distinguish between network storage and <a data-link-type="dfn" href="#site-storage">site storage</a> in their user
-interface. Instead user agents should offer users the ability to remove all storage for a given <a data-link-type="dfn" href="#site">site</a>. This ensures that storage from one source cannot be used to revive storage from another
-source. This also helps users avoid having to know about the different ways in which <a data-link-type="dfn" href="#site">sites</a> can store data.</p>
-   <p class="XXX">This is still a concern due to HTTP ETag... </p>
-   <p>Credentials storage should still be separated however as it might contain data the user might not be
-able to revive, such as an autogenerated password.</p>
+interface. Instead user agents should offer users the ability to remove all storage for a given <a data-link-type="dfn" href="#site">site</a>. This ensures to some extent that network storage cannot be used to revive <a data-link-type="dfn" href="#site-storage">site storage</a>. This also reduces the amount users need to know about the different ways in
+which <a data-link-type="dfn" href="#site">sites</a> can store data.</p>
+   <p>Credentials storage should be separated as it might contain data the user might not be able to
+revive, such as an autogenerated password. Since permissions storage is mostly simple booleans it
+too can be separated to avoid inconveniencing the user. Credentials and permissions are also
+somewhat easier to understand and differentiate from network storage and <a data-link-type="dfn" href="#site-storage">site storage</a>.</p>
    <h3 class="heading settled" data-level="6.1" id="storage-pressure"><span class="secno">6.1. </span><span class="content">Storage Pressure</span><a class="self-link" href="#storage-pressure"></a></h3>
    <p>When the user agent notices it comes under storage pressure and it cannot free up sufficient space
 by clearing network storage and <a data-link-type="dfn" href="#non-persistent-box">non-persistent boxes</a> within <a data-link-type="dfn" href="#site-storage">site storage</a>, then the