- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Wed, 25 Aug 2010 18:25:00 -0400
On Tue, Aug 24, 2010 at 7:13 PM, Ian Hickson <ian at hixie.ch> wrote: > It would also be good to document the reasons why people want to expire > data. It's presumably not security -- you'd want to expire the authority > of any credentials on the server side long before it became an issue to > have them stored on the client side. It's presumably also not just wanting > to clean things up -- browsers are going to have to deal with expiring old > storage data that the user hasn't used anyway, whether we let the site > clean up after themselves or not. 1) Even though browsers might have to do forcible cleanup once in a while, if sites can ask for certain things to be expired, this will reduce the frequency with which browsers need to delete sites' data without permission (ideally to zero in most cases). 2) If a site allocates small amounts of data on a regular basis for various types of caching, and it doesn't expire, it will accumulate over time and eventually hit the site's quota. This will be hard to predict and won't show up in testing, since it might only happen after months or years of regular use. Providing a built-in expiration mechanism will help authors to avoid this mistake. 3) If client-side data becomes obsolete in a predictable timeframe, like server-side expiration of the corresponding credentials, then it shouldn't be used after that date (since it's known that the use will fail). Client-side expiration is a convenient way to model this situation. Those are off the top of my head. I don't know if they're compelling enough to add the feature, compared to all the other features that might be desired, but it certainly seems fairly useful.
Received on Wednesday, 25 August 2010 15:25:00 UTC