Subject: [Wpack] Security, authority, and privacy

From: Ben Schwartz <[email-masked]>
Date: Wed, 25 Mar 2020 18:06:31 -0400

It seems to me that there are two main kinds of permission that concern us
here.

1. Permission to display content as the origin.
2. Permission to perform I/O while acting as the origin.

I think we should accept signed exchanges as sufficient for #1 before
online verification completes, but require online verification for #2.
This tightly limits any stolen key or stale content attack: the attacker
can impersonate the origin until online verification completes, but cannot
do much damage during that period.

(This is not a comment on implementation, which could be similar to Martin
Thomson's proposal, or not.)

In this model, we would queue all pending I/O until verification
completes.  (The relevant APIs should all be asynchronous).  This isn't
compatible with every use case we have, but it covers most of them.

"Early actions" and the corresponding state transfer could be added later
if needed, but I think tackling that topic now would likely delay the
standards process considerably.  I also think most use cases would prefer
that I/O simply be queued, so the state-transfer system should be clearly
opt-in, only for the most sophisticated developers.

--Ben Schwartz

---

From: Jeffrey Yasskin <[email-masked]>
Date: Thu, 26 Mar 2020 11:43:07 -0700

> opt-in, only for the most sophisticated developers.

I like the general suggestion to avoid side-effects on the origin's online
state until the client has checked with the online origin, if we can make
the transfer work, but I'm wary of a couple aspects of this implementation:

A) I'm not sure what "I/O" means here. One could make a small
camera-effects website that works entirely offline, but that does Input
through the camera and Output by, perhaps, being able to let the user save
files (aside from the obvious one of drawing to the screen). You seem to
mean writing to local storage and fetching remote resources with a
particular value in the Origin header. Is that all?

B) Having all writes to storage queue instead would break offline use of
content-authoring sites, which is something I wouldn't want to lose. I
think use cases where a user wants to avoid expensive data transfer but
still has a connection, still work, but as Ted Hardie has described, there
are lots of cases where people actually can't connect to the global
internet for periods of time, and I think we'd lose all of their use cases
except for pure content consumption.

Jeffrey

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 26 Mar 2020 15:45:10 -0400

On Thu, Mar 26, 2020 at 2:43 PM Jeffrey Yasskin <[email-masked]>
wrote:

>> It seems to me that there are two main kinds of permission that concern
>> us here.
>>
>> (This is not a comment on implementation, which could be similar to
>> Martin Thomson's proposal, or not.)
>>

I think fetching any remote resource would have to be delayed, if stolen
key attacks are in-scope.  Imagine a package (signed with a stolen key)
that presents a login screen, collects user passwords, and sends them as
"anonymous" GET requests to the attacker's server.

Local filesystem reads should be OK, but filesystem writes would have to
wait.  Otherwise, a package (signed with a stolen key) could "download" a
.exe that is malware.

> except for pure content consumption.

I agree with this analysis, but I think the potential "offline webapp"
users are vastly outnumbered by the potential offline content readers, so
we should focus on the larger, easier case first, and add optional complex
features for the fancier use cases later.

---

From: Jeffrey Yasskin <[email-masked]>
Date: Mon, 30 Mar 2020 14:46:17 -0700

On Thu, Mar 26, 2020 at 12:45 PM Ben Schwartz <[email-masked]> wrote:

>>> "Early actions" and the corresponding state transfer could be added
>>> later if needed, but I think tackling that topic now would likely delay the
>> I like the general suggestion to avoid side-effects on the origin's
>> online state until the client has checked with the online origin, if we can
>> make the transfer work, but I'm wary of a couple aspects of this
>> implementation:
>>

I think you've accurately described the implications of the threat model in
which an off-path attacker who steals a key must not be able to harm a user
(using the user's trust in that key) in any way except to put incorrect
information in their brain. I'm not sure that's the right threat model, but
it's possible.

We should start writing down a sketch of the plausible threat models here.

> features for the fancier use cases later.

I mostly agree with your estimate of the relative popularity of these two
use cases, but I'm still uncomfortable focusing on content consumption over
content creation. We'd effectively be saying that low-income people and
people living under restrictive governments are less worth hearing from. If
I only cared about AMP, this would probably be fine (although I defer to
Devin on that question), but our goals are broader than that.

That said, I'm curious what non-Google people think of this question. :)

Jeffrey

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 31 Mar 2020 15:04:58 +1100

On Tue, Mar 31, 2020, at 08:46, Jeffrey Yasskin wrote:
> I think you've accurately described the implications of the threat 
> model in which an off-path attacker who steals a key must not be able 
> to harm a user (using the user's trust in that key) in any way except 
> to put incorrect information in their brain. I'm not sure that's the 
> right threat model, but it's possible.

If publisher.example have a key compromised, then phishing is a real concern.  If we insist on having the ability to say "publisher.example as of time X" in UX, then people will expect that typing their publisher.example password will not result in that information ending up anywhere else.

I don't see any way out of this, but there might be a few things that make this less scary:

1. Password managers won't offer to autofill.  So people would have to type the string in.  But the expectation is that they haven't visited this site before (or else there would be a service worker instead), so why does the user have a password to enter?  I don't think that we can stop sites from taking keyboard input and spoofing password fields, but this does imply some possibility that the browser might detect bad behaviour and block further input.

2. As suggested, if the user agent truly is offline, then there might be no harm in blocking access to the network (and postMessage, and ...) until a transfer is successful.  And to delete or quarantine information if the transfer fails.  (The question of recovering state from quarantine is fraught, but we might work something out eventually.)

I don't know what I think about all of this.  It seems like this more motivates display of a garbage origin than it does trying to find a way to have the "true" origin displayed.