Add sections on the Web being safe to browse, trusted user interface,…

… and asking users for consent.

Fixes w3ctag#146.

index.bs

@@ -44,6 +44,105 @@ url: https://dom.spec.whatwg.org/#ref-for-concept-getelementsbytagname; type: in
     }
 </style>
 
+<h2 id="api-principles">Principles behind design of Web APIs</h2>
+
+<h3 id="safe-to-browse">It should be safe to visit a web page</h3>
+
+Hyperlinks, links from one page to another, are one of the foundations of the Web.
+
+Following a link, or visiting a web page, should be safe.
+Users who are following a link to a web page they haven't seen before
+should not have to fear for the security of their computer
+or for essential aspects of their privacy.
+(One caveat here is that users of the Web
+should not assume that they are free from consequences
+if their use of the Web is harming others.)
+
+Saying “essential aspects” here skips over quite a bit of detail.
+The Web isn't perfectly private.
+But we can probably make it better than it is today.
+In doing so, we may want to focus on the cases where
+user expectations of what information is revealed when using the Web
+don't match the technical details.
+We might be able to use the design of user interfaces
+to make it clear what users of the Web should expect,
+since one aspect of privacy problems is when reality doesn't meet expectations.
+For example,
+a person walking down the street generally expects to be recognized by their friends,
+but depending on the country,
+may not expect that they were walking down that street to be recorded in a permanent government database.
+Online, people might have less understanding of what is or isn't possible,
+and their expectations might differ more widely.
+<!-- Can we cite research on this??? -->
+
+When we add new features to the Web
+that might weaken the security or privacy characteristics that the Web currently has,
+we should consider the tradeoffs involved in that particular feature.
+A new feature with security risks might still make users safer, for example,
+because they would download and run native binary software less often,
+and downloading and running binaries is much riskier than visiting a Web page.
+However, we should also consider the tradeoff
+against the *idea* that it is safe to visit Web pages:
+adding a risky feature to the Web teaches the Web's users that the Web is less safe,
+and this erodes one of the core values of the Web:  that it is safe to visit websites.
+We should seek to give users a true picture of the safety of the Web
+so that they can act based on that understanding of safety
+(in comparison to the safety of alternatives),
+and at the same time we should seek to keep the Web safe for its users.
+
+<h3 id="trusted-ui">Trusted user interface should be trustworthy</h3>
+
+Since users of the Web can follow links to sites they might not know already,
+software that lets them access the Web generally provides user interface
+to show the user who they're interacting with and how,
+such as by displaying part or all of the URL or other information about the site,
+or whether the connection is secure.
+Since users rely on this information to learn what site they're on
+and to make judgments about whether it is trustworthy,
+it is important that sites not be able to spoof or override this user interface.
+
+When we add new features to the web,
+we should consider whether they require new complexity in this user interface,
+and whether that complexity would reduce users' ability
+to make correct judgments about who they're interacting with
+and whether the user interface is trustworthy or spoofed.
+
+<h3 id="informed-consent">Ask users for informed consent when appropriate</h3>
+
+In some cases,
+we might add features to the Web that are not appropriate to allow for any website a user visits,
+but that are reasonable to have if the user gives informed consent.
+An example of such a feature might be support for location:
+many users seem likely to understand what it means to share their current location with a website
+and be able to consent to doing so
+(even though they might not fully understand the privacy implications of doing so).
+
+We should not depend on asking the user for consent
+(via a permission prompt or other mechanism)
+if we don't have a way to express that request in a way
+that users will understand what is being requested
+and the main implications of giving their consent.
+
+We should also not ask users to consent to something
+that can also happen if the user does not consent.
+The existence of prompts
+that request a user's consent for something
+(from trusted user interface in their browser or other user agent)
+imply that the thing for which consent is being requested
+will not happen if the user doesn't consent.
+Therefore we should not have user agents request consent
+for something that they can't effectively prevent.
+Doing so would send the wrong message about the safety characteristics of the Web
+and would lead users to be disappointed when the expectations of privacy,
+which they learned from trusted user interface,
+did not match reality.
+
+Asking users for consent via permission prompts
+can both reinforce the idea that the web is safe
+by showing the user that certain things won't happen without their permission,
+and can also show how scary a place the web is
+by showing how many sites are willing to ask for intrusive and unnecessary permissions.
+
 <h2 id="js">JavaScript Language</h2>
 
 <h3 id="js-only">Web APIs are for JavaScript</h3>