Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add some nuance to 'drop the feature' #72

Merged
merged 2 commits into from
May 6, 2020
Merged

Add some nuance to 'drop the feature' #72

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ce34f29
Capture some of the nuance from the 'drop the feature' discussion in …
hober May 4, 2020
daa8451
Regenerate from 9748ebb.
hober May 4, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 31 additions & 10 deletions index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ Former Editor: Lukasz Olejnik, Independent researcher, https://lukaszolejnik.com
Former Editor: Mike West, Google Inc., [email protected]
Group: tag
Indent: 2
Markup Shorthands: css no
Markup Shorthands: css no, markdown yes
Abstract:
This document provides help in considering the privacy impact of
a new feature or specification as well as common mitigation strategies for
Expand Down Expand Up @@ -870,18 +870,39 @@ The audience of this document is general:
Drop the feature
</h3>

The simplest way to mitigate potential negative security or privacy impacts
of a feature is to drop the feature.
Every feature in a spec should be seen as potentially adding security and/or
privacy risk until proven otherwise.
Discussing dropping the feature as a mitigation for security or privacy
impacts is a helpful exercise as it helps illuminate the tradeoffs between
the feature, whether it is exposing the minimum amount of data necessary,
and other possibly mitigations.
Possibly the simplest way
to mitigate potential negative security or privacy impacts of a feature
is to drop the feature,
though you should keep in mind that some security or privacy risks
may be removed or mitigated
by adding features to the platform.
Every feature in a spec
should be seen as
potentially adding security and/or privacy risk
until proven otherwise.
Discussing dropping the feature
as a mitigation for security or privacy impacts
is a helpful exercise
as it helps illuminate the tradeoffs
between the feature,
whether it is exposing the minimum amount of data necessary,
and other possible mitigations.
Comment on lines +888 to +889
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder a little bit whether it's good to focus particularly on data minimization rather than all the other points in the mitigations section other than this one. (Although "default privacy settings" and "making a privacy impact assessment" don't really feel like mitigations, the others do...)


Consider also the cumulative effect
of feature addition
to the overall impression that users have
that [it is safe to visit a web page](https://w3ctag.github.io/design-principles/#safe-to-browse).
Doing things that complicate users' understanding
that it is safe to visit websites,
or that complicate what users need to understand
about the safety of the web
(e.g., adding features that are less safe)
reduces the ability of users
to act based on that understanding of safety,
or to act in ways that correctly reflect the safety that exists.

Every specification should seek to be as small as possible, even if only
for the reasons of reducing and minimizing security/privacy attack surface(s).

By doing so we can reduce the overall security and privacy attack surface
of not only a particular feature, but of a module (related set of
features), a specification, and the overall web platform.
Expand Down
49 changes: 35 additions & 14 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1223,7 +1223,7 @@
</style>
<meta content="Bikeshed version a33f8714, updated Thu Apr 23 16:21:43 2020 -0700" name="generator">
<link href="https://www.w3.org/TR/security-privacy-questionnaire/" rel="canonical">
<meta content="5e24389503651b7bc4d8158150981afa15761ec6" name="document-revision">
<meta content="ce34f29ed40f1cafed98a0bf3530f3d4040b07e5" name="document-revision">
<style>/* style-autolinks */

.css.css, .property.property, .descriptor.descriptor {
Expand Down Expand Up @@ -1412,7 +1412,7 @@
<div class="head">
<p data-fill-with="logo"></p>
<h1>Self-Review Questionnaire: Security and Privacy</h1>
<h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Editor’s Draft, <time class="dt-updated" datetime="2020-05-04">4 May 2020</time></span></h2>
<h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Editor’s Draft, <time class="dt-updated" datetime="2020-05-05">5 May 2020</time></span></h2>
<div data-fill-with="spec-metadata">
<dl>
<dt>This version:
Expand All @@ -1437,7 +1437,7 @@ <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="cont
<div data-fill-with="warning"></div>
<p class="copyright" data-fill-with="copyright"><a href="http://creativecommons.org/publicdomain/zero/1.0/" rel="license"><img alt="CC0" src="https://licensebuttons.net/p/zero/1.0/80x15.png"></a> To the extent possible under law, the editors have waived all copyright
and related or neighboring rights to this work.
In addition, as of 4 May 2020,
In addition, as of 5 May 2020,
the editors have made this specification available under the <a href="http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0" rel="license">Open Web Foundation Agreement Version 1.0</a>,
which is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0.
Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document. </p>
Expand Down Expand Up @@ -1770,7 +1770,7 @@ <h3 class="heading settled" data-level="2.9" id="string-to-script"><span class="
risk, and ensured that they required reasonable interactions with Content
Security Policy’s <code>script-src</code> directive.</p>
<li data-md>
<p>New string-to-script mechanism? (e.g. `eval()` or `setTimeout([string], ...)`)</p>
<p>New string-to-script mechanism? (e.g. <code>eval()</code> or <code>setTimeout([string], ...)</code>)</p>
<li data-md>
<p>What about style?</p>
</ul>
Expand Down Expand Up @@ -2239,17 +2239,38 @@ <h3 class="heading settled" data-level="4.5" id="secure-contexts"><span class="s
privacy risks or even security risks from other threat actors than active
network attackers.</p>
<h3 class="heading settled" data-level="4.6" id="drop-feature"><span class="secno">4.6. </span><span class="content"> Drop the feature </span><a class="self-link" href="#drop-feature"></a></h3>
<p>The simplest way to mitigate potential negative security or privacy impacts
of a feature is to drop the feature.
Every feature in a spec should be seen as potentially adding security and/or
privacy risk until proven otherwise.
Discussing dropping the feature as a mitigation for security or privacy
impacts is a helpful exercise as it helps illuminate the tradeoffs between
the feature, whether it is exposing the minimum amount of data necessary,
and other possibly mitigations.</p>
<p>Possibly the simplest way
to mitigate potential negative security or privacy impacts of a feature
is to drop the feature,
though you should keep in mind that some security or privacy risks
may be removed or mitigated
by adding features to the platform.
Every feature in a spec
should be seen as
potentially adding security and/or privacy risk
until proven otherwise.
Discussing dropping the feature
as a mitigation for security or privacy impacts
is a helpful exercise
as it helps illuminate the tradeoffs
between the feature,
whether it is exposing the minimum amount of data necessary,
and other possible mitigations.</p>
<p>Consider also the cumulative effect
of feature addition
to the overall impression that users have
that <a href="https://w3ctag.github.io/design-principles/#safe-to-browse">it is safe to visit a web page</a>.
Doing things that complicate users' understanding
that it is safe to visit websites,
or that complicate what users need to understand
about the safety of the web
(e.g., adding features that are less safe)
reduces the ability of users
to act based on that understanding of safety,
or to act in ways that correctly reflect the safety that exists.</p>
<p>Every specification should seek to be as small as possible, even if only
for the reasons of reducing and minimizing security/privacy attack surface(s).</p>
<p>By doing so we can reduce the overall security and privacy attack surface
for the reasons of reducing and minimizing security/privacy attack surface(s).
By doing so we can reduce the overall security and privacy attack surface
of not only a particular feature, but of a module (related set of
features), a specification, and the overall web platform.</p>
<p>Examples</p>
Expand Down