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

Describe when features should be limited to secure contexts. #75

Closed
wants to merge 15 commits into from
Closed

Describe when features should be limited to secure contexts. #75

Changes from 10 commits
Commits
Show all changes
15 commits
Select commit Hold shift + click to select a range
64e63a4
Describe when features should be limited to secure contexts.
dbaron Aug 23, 2017
fedee9d
Fix typo pointed out by annevk and jonathanKingston.
dbaron Aug 24, 2017
06189de
Change example about DOM events, per annevk.
dbaron Aug 24, 2017
29a876c
Make advice clearer and stronger in response to feedback, and restruc…
dbaron Aug 25, 2017
68a8522
Fix missing 'with'.
dbaron Aug 25, 2017
85009e1
Fix missing word pointed out by annevk.
dbaron Aug 25, 2017
ecb1acf
Remove paragraph that was too perscriptive.
dbaron Sep 30, 2017
9d9bb9c
Various edits to reflect the discussion in Nice.
dbaron Sep 30, 2017
0392c19
Merge 2 paragraphs that ended up nearly identical.
dbaron Sep 30, 2017
b465795
Wordsmith.
dbaron Sep 30, 2017
f7a2d20
Address @mikewest's concern that this sentence undercuts the prior on…
dbaron Oct 13, 2017
ee93b93
Cut down on feature detection prose, in favor of new section in #82.
dbaron Oct 13, 2017
6d90d7c
Reword to address @mikewest comment about features that depend on gua…
dbaron Oct 14, 2017
dfdd321
Move paragraph, per @mikewest suggestion.
dbaron Oct 14, 2017
a6cb3c3
Reword sentence on informing the TAG, again.
dbaron Oct 14, 2017
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
75 changes: 75 additions & 0 deletions index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -345,6 +345,81 @@ and on when to use promises and when not to use promises,
see <strong><a href="https://www.w3.org/2001/tag/doc/promises-guide">Writing
Promise-Using Specifications</a></strong>.

<h3 id="secure-context">Limit new features to secure contexts</h3>

New capabilities added to the Web should be available only in
<a href="https://w3c.github.io/webappsec-secure-contexts/">secure contexts</a>.
Exposing them in non-secure contexts
is discouraged and requires strong justification.
The TAG is interested in hearing about and discussing cases
where it is unclear whether exposing the capability
in non-secure contexts is justifiable.
Copy link

Choose a reason for hiding this comment

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

This sentence is odd, as it directly undercuts the rest of the paragraph. Have the courage of your convictions!

If y'all feel the need to weaken the claim that "New capabilities added to the Web should be available only in secure context", I'd suggest doing so weakly. Perhaps "There may be reasonable justification for exposing a given capability in non-secure contexts; the TAG is interested in hearing about those edge cases, and working to resolve them."?

Copy link
Member Author

Choose a reason for hiding this comment

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

How about just:

The TAG is interested in hearing about and working to resolve any cases where exposure in non-secure contexts is being seriously considered.

Copy link
Member Author

Choose a reason for hiding this comment

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

Or, simpler:

The TAG is interested in hearing about cases
where exposing new features in non-secure contexts is being considered.

(I'm pulling the "working to resolve" because I suspect that much of what we hear about might qualify as "not a new feature".)


This restriction exists for two reasons.
First, it helps encourage Web content and applications
to migrate to secure contexts.
Second, some new features depend on authentication, integrity, or confidentiality
to prevent substantial increases to the privacy or security risks of using the Web.
For more detail, see the W3C TAG Finding on
<a href="https://www.w3.org/2001/tag/doc/web-https">Securing the Web</a>.

The most common justification that we expect
for supporting a new capability in non-secure contexts
is that the new capability is not recognizably separate
from an existing feature that is available in non-secure contexts.
In this case, limiting it to secure contexts could cause
developer confusion about where the boundaries are.
We also don't want to increase
the complexity of implementations of Web technology
by requiring tests for secure contexts in too many *types* of places.
Copy link

Choose a reason for hiding this comment

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

I don't really understand this claim. Can you help me out? What "types of places" do you mean? The example below didn't help me (but I'm also not really a CSS guy, so the distinction between the difficulty of detecting a new property vs new syntax isn't clear to me... it seems like the former would be easier, though?). :(

Copy link
Member Author

Choose a reason for hiding this comment

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

What I mean by this is that for [SecureContext] annotations in WebIDL, the annotation presumably gets stored as a bitflag or similar, and gets checked in a small set of places that implement [SecureContext]. Likewise for CSS properties, engines presumably have a set of data about each property, to which a secure-contexts-only bit could be added, and likewise tested in a small number of places. But it seems preferable to avoid littering IsSecureContext() tests through the CSS parser (or other language parsers), and I think this preference likely aligns with the previous justification.

Copy link

Choose a reason for hiding this comment

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

For WebIDL, Chrome checks when generating bindings for a given context (e.g. everything is wrapped up in the exposed checks). For deprecations or places where [SecureContext] isn't relevant, we do inline checks at the entry point to the API (e.g. https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/geolocation/Geolocation.cpp?rcl=2bd5f03512bcb0b0632366109612ea4e9c4b7ce2&l=220).

I think I agree with the thrust of your comments here, but I still don't really understand what this paragraph is telling feature designers. Does it boil down to "Use [SecureContext] when possible?"?

Copy link
Member Author

Choose a reason for hiding this comment

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

I think it boils down to "use [SecureContext] and equivalent things for other languages like CSS", and maybe be a little more hesitant about secure context restrictions that would need to be in other places.

Copy link

Choose a reason for hiding this comment

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

Can we make it a requirement for specs to have web platform tests so that all browsers are consistent in how these features are hidden/fail?

Such that "For deprecations or places where [SecureContext] isn't relevant, we do inline checks at the entry point to the API" behaves consistently?

For example, exposing to non-secure contexts a new CSS property
that adds support for a new line spacing model
cannot be justified on this basis,
but exposing the ability to omit the commas in the CSS ''rgb()'' function can.

The existence of new features should generally be detectable,
so that web content can act appropriately if the feature is present or not.
This applies both to features that are not present because they are not implemented,
and to features that are not present in a non-secure context because
they are limited to secure contexts.
Putting this another way,
a feature that is limited to secure contexts should, in non-secure contexts,
be indistinguishable from a feature that is not implemented.
However, if, for some reason
(a reason that itself requires serious justification),
it is not possible for developers to detect whether a feature is present,
limiting the feature to secure contexts
might cause problems
for libraries that may be used in either secure or non-secure contexts.
Copy link

Choose a reason for hiding this comment

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

This paragraph seems like a distinct design principle ("Thou shalt enable feature detection.") that you could discuss at length elsewhere, and reference here.

Copy link
Member Author

Choose a reason for hiding this comment

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

I moved this into #82 and revised the text.


If a feature depends on
the expectations of authentication, integrity, or confidentiality
that are met only in secure contexts,
then it must be limited to secure contexts,
even if the other factors above could justify exposing it in non-secure contexts.
Copy link

Choose a reason for hiding this comment

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

I don't see it as the feature depending on authentication, integrity, or confidentiality, but instead the feature posing some risk to user privacy or security which is mitigated only by requiring authentication, integrity, and confidentiality. I mean, at some level, all features depend on the page's integrity, right? :)

WDYT about something like "If a feature poses a risk to user privacy or security which can be mitigated by requiring authentication, integrity, and confidentiality, the feature must be limited to secure contexts, ..."?

Copy link
Member Author

Choose a reason for hiding this comment

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

To avoid the "poses a risk" in your wording that makes it sound like the feature is problematic, I think I'm going to try:

If a feature would pose a risk to user privacy or security without the authentication, integrity, or confidentiality that is present only in secure contexts, then the feature must be limited to secure contexts, ...

For example, a feature that communicates with USB devices
if those devices have allowed
Web content from the site's origin
to communicate with those USB devices
depends on the authentication of the origin
and the integrity of the data
sent to the USB device,
since sending untrusted data to a USB device could damage that device
or compromise computers that the device connects to.

Specification authors can limit most features defined in
<a href="https://heycam.github.io/webidl/">WebIDL</a>,
to secure contexts
by using the
<code>[<a href="https://w3c.github.io/webappsec-secure-contexts/#integration-idl">SecureContext</a>]</code> extended attribute
on interfaces, namespaces, or their members (such as methods and attributes).
Similar ways of marking features as limited to secure contexts should be added
to other major points where the Web platform is extended over time
(for example, the definition of a new CSS property).
However, for some types of extension points (e.g., dispatching an event),
limitation to secure contexts should just
be defined in normative prose in the specification.
Copy link
Member

Choose a reason for hiding this comment

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

If the new event comes with a new interface it's quite easy to restrict it though. Maybe you should clarify this by talking about "dispatching an event" instead.

Copy link

Choose a reason for hiding this comment

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

Nit: I'd suggest that you move this paragraph up above the "And here are some exceptions" bit. Then the structure would be something like:

  1. Y'all should do this thing.
  2. Here's why you should do this thing.
  3. Here's how you should do this thing.
  4. And if you really don't want to do this thing, here's some things to think about.

That seems like a clearer message to me.

Copy link
Member Author

Choose a reason for hiding this comment

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

I reordered the paragraphs.


<h2 id="event-design">Event Design</h2>

<h3 id="always-add-event-handlers">Always add event handler attributes</h3>
Expand Down