mobile/security.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Security and Privacy</title>
  </head>
  <body>
    <header>
      <h1>Security and Privacy</h1>

      <p>Mobile devices follow their users everywhere, and hold some of their most private or confidential data (contacts, pictures, calendar, etc.) As a result, it is critical for users to be able to rely on their phones to keep that data safe from attackers.</p>

      <p>W3C specifications are reviewed for their security and privacy impact as part of their progress through the Recommendation track; the <a href="https://www.w3.org/Privacy/">Privacy Interest Group</a> and the <a href="https://www.w3.org/Security/wiki/IG">Web Security Interest Group</a> in particular are coordinating reviews on their respective fields.</p>

      <p>Security and privacy technologies listed below have a particular resonance in a mobile context. Please check the <a href="https://w3c.github.io/web-roadmaps/security/">Security roadmap</a> document for a more comprehensive overview of security on the Web.</p>
    </header>
    <main>
      <section class="featureset well-deployed">
        <h2>Well-deployed technologies</h2>

        <div data-feature="Strengthened security">
          <p>The first line of defense for users, and the unit of isolation for Web apps is the same-origin policy that roughly limits what a Web application can access to content and data hosted on the same origin, i.e. the combination of URL scheme, domain name and port.</p>

          <p>For legacy reasons, this policy is not as stringent on some parts of the Web platform, exposing users to greater attack surface via cross-site scripting or cross-site request forgery. To enable Web application authors to reduce the attack surface beyond what legacy requires, the <a data-featureid="csp">Content Security Policy</a> offers hooks that severely limits damages that an attacker could hope to achieve. An application delivered over a secure channel with CSP enabled can assure that users receive it as it was intended to be executed.</p>

          <p>To further strengthen the integrity of their applications, Web developers can make use of the proposed <a data-featureid="sri">Subresource integrity</a> mechanism that makes it possible to block man-in-the-middle attacks or compromised third-parties providers.</p>

          <p>The <a data-featureid="mixedcontent">Mixed Content specification</a> helps to migrate the Web toward being secure by default, by setting clear rules as to when content that is not served over HTTPs can or cannot be loaded from an HTTPs page.</p>

          <p>In applications that aggregate content from multiple (possibly untrusted) sources, the <a data-featureid="html5-sandbox">HTML5 <code>iframe</code> <code>sandbox</code> attribute</a> makes it possible to restrict the kind of interactions third-party embedded content can make use of.</p>
        </div>

        <div data-feature="Encryption">
          <p>The <a data-featureid="crypto">Web Cryptography API</a> provides the necessary tools to encrypt data for storage and transmission from within Web applications, with access to pre-provisioned keys via the <a data-featureid="cryptokey">WebCrypto Key Discovery</a> API.</p>
        </div>

        <div data-feature="Authentication">
          <p>Building on the passwordless and multi-factor authentication work of the FIDO Alliance, <a data-featureid="webauthn">Web Authentication</a> standardizes strong authentication for the Web, using a combination of "something you have" (e.g. an authentication key) coupled with "something you know" (e.g. a PIN code) and/or "something you are" (e.g. a fingerprint), so that hacking a password database is no longer sufficient to hijack user accounts.</p>
        </div>
      </section>

      <section class="featureset in-progress">
        <h2>Technologies in progress</h2>

        <div data-feature="Strengthened security">
          <p>Cross-site scripting (XSS) is considered to be one of the major attack vectors on the Web. <a data-featureid="trusted-types">Trusted Types</a> allows applications to lock down DOM-based XSS injection sinks  (e.g. <code>Element.innerHTML</code>, or <code>Location.href</code> setters) to only accept non-spoofable, typed values in place of strings.</p>
        </div>

        <div data-feature="Permissions">
          <p>Many sensitive APIs, e.g. those that expose mobile device sensors, are gated by a request for user consent; while these requests give control to the user, they can be sometimes hard to integrate in the overall user experience without visibility on which permission has been granted or denied. The <a data-featureid="permissions">Permissions API</a> aims at fixing this.</p>
        </div>

        <div data-feature="Identity Management">
          <p>To facilitate the authentication of users to on-line services, the <a href="https://www.w3.org/2011/webappsec/">Web Application Security Working Group</a> is proposing a <a data-featureid="credential-management">Credential Management API</a> that lets developers interact more seamless with user-agent-managed credentials.</p>
        </div>

        <p data-feature="Secure contexts"><a data-featureid="securecontexts">Secure Contexts</a> recommends that powerful features of the Web platform, including application code with access to sensitive or private data, be delivered only in secure contexts, over authenticated and confidential channels that guarantee data integrity. As the draft indicates, "delivering code securely cannot ensure that an application will always meet a user's security and privacy requirements, but it is a necessary precondition."</p>

        <p data-feature="HTTPs adoption">Web sites with a lot of existing content set up to use resources loaded over HTTP can find the task of migrating that content to HTTPs daunting. The <a data-featureid="uir">Upgrade Insecure Requests specification</a> helps that migration by instructing the browser to load these resources over HTTPs.</p>

        <p data-feature="Referrer Policy"><a data-featureid="referrer-policy">Referrer Policy</a> helps web developers control the amount of information present in the <code>Referer</code> HTTP header or even whether the header is sent at all.</p>

        <p data-feature="Sandboxing">The <a data-featureid="uisecurity">User Interface Security and the Visibility API</a> document proposes to eliminate clickjacking by assuring element visibility at the graphics rendering level. For instance, a developer deploying it can assure that users clicking their site's "pay" button aren't being tricked into transferring their bank balances to an imposter instead.</p>

        <div data-feature="Permissions policy">
          <p>As more powerful features keep being exposed to applications, site authors need more fine-grained control over features that are enabled/disabled in their application as well as in own or third-party content that their application may embed (in iframes), to reinforce security. The <a data-featureid="permissions-policy">Permissions Policy</a> defines mechanisms (the <code>Permissions-Policy</code> HTTP header and the <code>allow</code> attribute on an <code>iframe</code> element) to selectively enable and disable use of various browser features and APIs. Developers may also use the policy to assert a promise to a client or an embedder about the use — or lack of thereof — of certain features and APIs.</p>
        </div>
      </section>

      <section class="featureset exploratory-work">
        <h2>Exploratory work</h2>
        <div data-feature="Permissions">
          <p>Different APIs use different mechanisms to grant permission to use or access an underlying powerful feature. To ease design of permission-related code, the <a data-featureid="permissions-request">Requesting permissions</a> and <a data-featureid="permissions-revoke">Relinquishing permissions</a> proposals extend the <a href="https://www.w3.org/TR/permissions/">Permissions API</a> to provide a uniform function for requesting and revoking permission to use powerful features.</p>
        </div>
      </section>

      <section>
        <h2>Discontinued features</h2>
        <dl>
          <dt>HTTP request filtering</dt>
          <dd>The <a data-featureid="epr">Entry Point Regulation</a> specification provided another layer of strengthening security. It defined a mechanism to filter the type of HTTP requests that can be made from external sites, reducing risks of cross-site script and cross-site request forgery. Work on this specification has been discontinued for the time being.</dd>

          <dt>Tracking preference expression</dt>
          <dd>For users that wish to indicate their preferences not to be tracked across Web applications and sites, the <a data-featureid="dnt">Tracking Preference Expression (also known as Do No Track)</a> enabled browsers to communicate explicitly their wish to content providers, and for servers to communicate their own tracking behavior, request consent and store user-granted exceptions. Not all content providers honor users' expressed preferences though, and lack of deployment of these extensions (as defined) led the Tracking Protection Working Group to stop work on the specification.</dd>

          <dt>Access to hardware security services</dt>
          <dd><a data-featureid="hbss">Hardware Based Secure Services</a> aimed to improve the levels of assurance to which users and application providers are able to protect their online accounts and communications, by making hardware security services available to the Web. The creation of a working group in that space was proposed but the idea was dropped for lack of implementation support.</dd>
        </dl>
      </section>
    </main>
    <script src="../js/generate.js"></script>
  </body>
</html>