W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2015

Re: CLEAR: Moved to WebAppSec repository.

From: Jonathan Kingston <jonathan@jooped.com>
Date: Wed, 15 Jul 2015 22:50:16 +0000
Message-ID: <CAKrjaaVX76pmFZPjB03r=jhB6dbjhEK1+n-+fkPwhAbP5wZykA@mail.gmail.com>
To: Mike West <mkwst@google.com>, Alex Russell <slightlyoff@google.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Dan Veditz <dveditz@mozilla.com>, Brad Hill <hillbrad@gmail.com>, Wendy Seltzer <wseltzer@w3.org>, Jake Archibald <jakearchibald@google.com>, "Eduardo' Vela" <evn@google.com>
It's not immediately clear how the browser would handle safely letting the
client side control the timing of the clear. However I can see syncing of
user data that is important to the application(for example user created
documents in offline mode) and unrelated to perhaps user credentials
something a developer would wish to control somewhat.

On Wed, 15 Jul 2015 at 20:11 Mike West <mkwst@google.com> wrote:

> Do you want to control timing? When would you want to do this on something
> other than a response? Sorry, the use case just isn't clear to me.
>
> -mike
>
> --
> Mike West <mkwst@google.com>, @mikewest
>
> Google Germany GmbH, Dienerstrasse 12, 80331 München,
> Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
> Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
> Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>
> On Wed, Jul 15, 2015 at 2:03 PM, Alex Russell <slightlyoff@google.com>
> wrote:
>
>> If you want to control timing, an API to do this would be useful.
>>
>> On Wed, Jul 15, 2015 at 10:20 AM, Mike West <mkwst@google.com> wrote:
>>
>>> On Wed, Jul 15, 2015 at 10:11 AM, Alex Russell <slightlyoff@google.com>
>>> wrote:
>>>
>>>> This looks great! In particular, the sandboxing looks like absolutely
>>>> the right thing.
>>>>
>>>> I didn't see anything in the draft about an API for this capability.
>>>> Have we thought about adding one?
>>>>
>>>
>>> Is it necessary? Happy to add something if there's clarity around use
>>> cases that we can't otherwise serve.
>>>
>>> -mike
>>>
>>
>>
>
Received on Wednesday, 15 July 2015 22:50:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:13 UTC