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

[clear-site-data] clearing information about URLs visited

From: Nick Doty <npdoty@w3.org>
Date: Mon, 14 Sep 2015 00:22:11 -0700
Message-Id: <60F8E652-A920-4AE3-83EC-82A77022BD1F@w3.org>
To: public-webappsec@w3.org
One motivating use case I've been thinking about recently is -- first in the current list -- logging out of your webmail or social network. Here's a version of this: a doctor uses their laptop at home to check their work email, which includes updates on their patients. When the doctor dutifully logs out of the webmail site, it would be preferable if any of the information in those emails was cleared locally, so that if someone else used the device, or if the device were lost or stolen, sensitive health information wouldn't be easily accessible.*

My concern is that the list of 8 data items in https://w3c.github.io/webappsec/specs/clear-site-data/#goals <https://w3c.github.io/webappsec/specs/clear-site-data/#goals> doesn't cover all the stored sensitive information. For example, a doctor might open a particular message with a URL that includes the patient's name or medical record number; or the title of a page might include the subject line of a message that includes the patient's name or diagnosis. Browsers typically cache not just the resources, but the URLs visited and their titles.

Could Clear Site Data include an additional parameter for browsing history? That would be URLs visited and associated metadata; it could be limited to certain sections of a site, but I'm not sure that level of complexity is necessary. Or is this something for the proposed Auto-Private Browsing Mode instead?


* This also gets to the concern over what level of assurance could be provided about clearing data, but it would still be a big improvement. https://w3c.github.io/webappsec/specs/clear-site-data/#remnants <https://w3c.github.io/webappsec/specs/clear-site-data/#remnants> describes this nicely, I think.

Received on Monday, 14 September 2015 07:22:23 UTC

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