i also don't understand how this will help us in the situation of an XSS
where there's a SW and live tabs. I.e., where there's a compromised
document that stuffs crap values into storage to defeat a server or SW's
attempts to clean things up. Without a variant that pauses and forces
refresh of all documents at the origin, it doesn't solve my big problem.
On 12 Jun 2015 5:54 pm, "Jonathan Kingston" <jonathan@jooped.com> wrote:
> Does all data stored in the file system and IndexedDB count as a cache
> always? Would these be worthy exclusion directives?
>
> I'm also a little worried of giving this power to clear http only cookies
> and opaque data to a JavaScript API also.
>
> Can the specification have an advisory to add a console message or similar
> reporting to ease debugging. A post data clear event might be useful also
> so JavaScript can know to clean up interfaces to show the user is logged
> out.
>
> When all contexts are neutered how will they handle stale user input?
>
> Thanks
>
> On Fri, Jun 12, 2015 at 6:51 PM Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
>> On 12 June 2015 at 09:41, Mike West <mkwst@google.com> wrote:
>> > The spec does currently require HTTPS. I'm not sure we could reasonably
>> > relax that, for exactly the reasons you point to. It sounds like
>> exactly the
>> > kind of API for which we'd want to require an authenticated and
>> encrypted
>> > connection.
>>
>> I actually think that having this on cleartext connections is a
>> benefit. Unless there is persistent data that somehow prevents other
>> persistence from happening. I'm not aware of any such feature.
>>
>> Elsewhere, Henri Sivonen suggested that we make cookies on cleartext
>> origins less persistent by default. This is seems consistent with
>> that philosophy.
>>
>>