Re: Automatic private browsing upgrades

On Thu, Sep 3, 2015 at 11:59 AM, Mike West <mkwst@google.com> wrote:

> On Thu, Sep 3, 2015 at 5:25 PM, Richard Barnes <rbarnes@mozilla.com>
> wrote:
>
>> Well, this immediately runs into the problem that there's no
>> specification of what Private Browsing / Incognito mode actually does.
>> Even when it comes to basic things like cookie lifetime, there are
>> different behaviors among browsers.  There has been some effort to clean
>> this up, but AFAIK, not much progress.
>>
>
> I think mnot@ was looking at this.
>
> I agree that there's some value in trying to converge here, but I suspect
> there's not a lot of shared vision for the mode at the fringes. Tracking
> Protection, for instance, goes well beyond "Don't store data persistently.".
>
>
>> The long description (with mock-ups) is here:
>>> https://wiki.mozilla.org/Security/Automatic_Private_Browsing_Upgrades
>>>
>>> The above is a draft intended to start a discussion, but the main things
>>> I'm wondering about are:
>>>
>>> - Does it fit within our working group charter?
>>> - Is CSP the right delivery mechanism?
>>> - Should this be rolled into the clear-site-data spec instead?
>>>
>>
>> I feel like there are several current proposals dancing around a common
>> concept:
>>
>> - Auto-PBM
>> - Clear site data
>> - Suborigins
>>
>
Oh, and I forgot -- first-party cookies are also part of this.


(This also relates the the Containers work that's going on in Firefox right
>> now.
>> https://wiki.mozilla.org/Security/Contextual_Identity_Project/Containers)
>>
>> All of these things relate to the origin security model being too loose,
>> either in space (suborigins) or time (clear-site-data, auto-PBM).  Some of
>> them (containers, auto-PBM) also carry along a notion that whatever
>> constraints on the origin model are applied to the top-level site should
>> also be transitively applied to its dependencies.
>>
>> I would rather we get this overall concept right than chase after these
>> point solutions.
>>
>
> This sounds interesting, but also quite vague. What do you consider "this
> overall concept"? :)
>

Well, it's vague because I haven't figured out what the right concept is :)

Right now, browser state is separated by origin, with no explicit bounds on
duration.  (Aside from some user configuration options that browsers
expose.)  We say that a page belongs to an origin, and that determines its
scope.

We're talking about a different scoping model which is in some ways more
restrictive than the origin.  So we need to figure out what the elements of
that model are, what scope they provide, and how they relate to origins.  I
wonder if there's something like an "application" tag with properties like:
1. It is subsidiary to origin, i.e., state is double-keyed with origin and
apptag
2. It can be transitive or not
3. The site can specify when the application's data should be deleted
(across all origins)

This might not be quite the right set of properties.  (In particular, (2)
feels like it could result in *triple*-keying based on origin,
origin-asserting-application, and application)  But it seems like a model
that encompasses most of the proposals above.

--Richard




>
> -mike
>