diff --git a/index.bs b/index.bs
index 725913b..6a007aa 100644
--- a/index.bs
+++ b/index.bs
@@ -218,6 +218,11 @@ of a new feature must justify the additional burden on users
 to decide whether to grant permission for each feature
 whenever it's requested by a Web page.
 
+Refusal is most effective if the site cannot
+distinguish refusal from other, common situations.
+This can make it more difficult for a site to
+pressure users to grant consent.
+
 <p class="example">
 For example,
 the [Geolocation API](https://www.w3.org/TR/geolocation-API/)
@@ -558,11 +563,19 @@ in the language where it's used
 In some cases, it may **not** be appropriate to allow feature detection.
 Whether the feature should be detectable or not
 should be based on the <a href="#priority-of-constituencies">user need</a>
-for the feature:
-if there is a user need or design principle which would fail
+for the feature.
+If there is a user need or design principle which would fail
 if feature detection were available for the feature,
 then you should not support feature detection.
 
+Detecting the availability of a feature does not imply
+detecting whether <a href="#consent">consent</a> to use the feature
+has been granted.
+Generally, detecting whether the feature is implemented
+can be done separately from determining whether use of the feature has been authorized.
+In some cases, it might be necessary to disable feature detection
+in order to enable denying requests to use the feature.
+
 Also, if a feature is generally not exposed to developers,
 it is not appropriate to support feature detection.
 For example, private browsing mode is a concept
@@ -576,6 +589,7 @@ See also:
 * [[#do-not-expose-use-of-private-browsing-mode]]
 * [[#do-not-expose-use-of-assistive-tech]]
 * [[#secure-context]]
+* [[#consent]]
 
 <h3 id="secure-context">Consider limiting new features to secure contexts</h3>