W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

Re: Proposal: Prefer secure origins for powerful new web platform features

From: Chris Palmer <palmer@google.com>
Date: Fri, 27 Jun 2014 16:50:25 -0700
Message-ID: <CAOuvq22HNT_gWBLQvqAktRt9NRrni8aRVh3Svf+FWbrk8rmTew@mail.gmail.com>
To: Michal Zalewski <lcamtuf@coredump.cx>, Alex Russell <slightlyoff@google.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, blink-dev <blink-dev@chromium.org>, security-dev <security-dev@chromium.org>, dev-security@lists.mozilla.org
On Fri, Jun 27, 2014 at 4:29 PM, Michal Zalewski <lcamtuf@coredump.cx> wrote:

> I think it's a reasonable proposal, provided that we apply the rules
> judiciously. This can be a tad tricky: credentials are listed as an
> example, but if we ever come up with an authentication API that offers
> better security properties than cookies, I do not think it would be
> wise to make it available only to HTTPS origins.

Agree. Let's imagine that I said "...handles credentials that are as
powerful as current ones like cookies, or moreso". If we get a *less*
powerful credential system, e.g. such that theft of it over non-secure
transport is not fatal, that'd be great and it might make perfect
sense to expose it to non-secure origins.

The whole idea is very case-by-case.

> Now, in some ways, it feels that the ship has sailed - microphone,
> camera, accelerometer, and geolocation APIs aren't HTTPS-only, and
> neither are password managers and cache manifests. This makes it a bit
> harder to draw the line: should we aim strictly not to make things
> worse, or to design a new breed of APIs that will hopefully one day
> make the legacy ones obsolete?

First, I dream of strictly not making things worse; and then perhaps
(over the course of eons) deprecating non-secure support for e.g.
cameras and mics. I have no illusions that rolling back existing
functionality will fly in the short term — nobody panic. :) And, yeah,
perhaps awesomer APIs will supercede existing ones. Time will tell.

> A somewhat tangential concern that I think we are neglecting with the
> ever-more-powerful privileged APIs is the near-certainty of XSS
> vulnerabilities; the platform offers a growing number of opportunities
> for origins to be persistently backdoored, and no clean way to recover
> from a transient XSS bug. I think that sooner or later, we will need a
> mechanism for servers to nuke or disavow any cached or currently
> running content associated with their origin, and start anew.

Indeed, there is a notion like that for Service Workers already, for
exactly this type of reason. Clients are to cache SW scripts, but are
required to re-check after a certain max-lifetime interval. Alex
(explicitly CC'd) can provide details.

> I think the inclusion of file:/// is somewhat problematic, since it is
> not implied that the content arrived over a secure channel,

Right. "But it's here now." Perhaps we should take file: off the list,
perhaps we should find some way to tag files as having come from
secure transport, or... People should feel free to comment on the
Chromium bug, too

> and the
> mixed-content behavior is also not well specified.

Right. mkwst, others, and tangentially me are working on tightening it
up for reasons like this.

> The localhost case
> may be also problematic because some quasi-popular software is known
> to set up webservers bound to (I think I've seen some
> anti-virus software, RAID tools, and print daemons do that).

Yes; those are similar to the file: case, but such a thing is
definitely already in a user's TCB (whether good or bad). I sort of
think that clarifies the issue somewhat. But also we definitely would
like to help developers running a local test server out, just a bit.
Received on Friday, 27 June 2014 23:50:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:39 UTC