Re: [whatwg] Proposal for Web Storage expiration
On Tue, Aug 24, 2010 at 7:13 PM, Ian Hickson i...@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.
Re: [whatwg] Proposal for Web Storage expiration
On Wed, 25 Aug 2010, Aryeh Gregor wrote: On Tue, Aug 24, 2010 at 7:13 PM, Ian Hickson i...@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). This relies on sites actually using this feature. I don't see any reason to believe sites would use this enough to make a dent here. 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. If an author is aware enough to do this, then he's presumably also aware enough to just crawl through the existing keys, nuking the ones that are no longer in use. 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. That can easily be done without UA support. I'm not saying there are no use cases here, but the ones listed above aren't very compelling in practice, I think. It would be good to know what use cases exist that don't have simple workarounds or alternatives. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for Web Storage expiration
On Wed, Aug 25, 2010 at 6:33 PM, Ian Hickson i...@hixie.ch wrote: This relies on sites actually using this feature. I don't see any reason to believe sites would use this enough to make a dent here. A lot of sites set expiration dates for cookies, don't they? If an author is aware enough to do this, then he's presumably also aware enough to just crawl through the existing keys, nuking the ones that are no longer in use. . . . That can easily be done without UA support. Yes, this would just be a convenience. I don't see anything you could do with built-in expiration that you couldn't do without. You could always emulate it by storing the last-modified date, and then wrapping every access in a function that checks the last-modified date and deletes it if it's too old.
Re: [whatwg] Proposal for Web Storage expiration
On Wed, 25 Aug 2010, Aryeh Gregor wrote: On Wed, Aug 25, 2010 at 6:33 PM, Ian Hickson i...@hixie.ch wrote: This relies on sites actually using this feature. I don't see any reason to believe sites would use this enough to make a dent here. A lot of sites set expiration dates for cookies, don't they? Based the list of cookies on my browser, not enough of them do to make a dent here. Yes, this would just be a convenience. I don't see anything you could do with built-in expiration that you couldn't do without. You could always emulate it by storing the last-modified date, and then wrapping every access in a function that checks the last-modified date and deletes it if it's too old. Well, the one thing you can't do that way is expire data even without revisiting the site. I just don't know if that's especially useful. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for Web Storage expiration
On Thu, 29 Jul 2010, Nicholas Zakas wrote: The Web Storage specification provides two ways for web applications to store key-value data in the browser, effectively replacing cookies for cases when the server doesn't need the information. For a lot of web application needs, sessionStorage and localStorage (or some combination of the two) can be used to effectively reduce the number of cookies used. Cookies do have one advantage over these APIs: the ability to specify an expiration period after which the data is removed. Right now, if a web application developers wish to have expiration of key-value pairs, he/she must manually implement such expiration on their own. An example of an API that already does this is XAuth (xauth.org). Proposal: Adding the ability to optionally define an expiration date for each key-value pair would bring sessionStorage/localStorage closer the capabilities of cookies today and provide useful control over the length of time that certain data can live in the browser. This becomes especially important if any authentication-related data is to be stored in Web Storage. I'm reluctant to add new features right now to this API, since there's so much other stuff for browser vendors to implement and bug fix, but expiring data is something that's been on the list of v2 features for Web Storage for some time, so I'm sure we'll add it eventually. On Thu, 5 Aug 2010, Jeremy Orlow wrote: As far as I can see, the next steps are (roughly in order): 1) Figure out whether it should be an origin wide setting or not. In order to prove that it needs to be a per LocalStorage bucket setting, its on you to come up with use cases where an origin wide setting is not enough. By use cases, we mean specific examples of stuff that clearly happens in reality today or would happen in reality if this was added. 2) Come up with a concrete proposal for what be added to the spec. 3) Find a UA willing to prototype such a new feature. That is indeed a good route to follow. 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for Web Storage expiration
As far as I can see, the next steps are (roughly in order): 1) Figure out whether it should be an origin wide setting or not. In order to prove that it needs to be a per LocalStorage bucket setting, its on you to come up with use cases where an origin wide setting is not enough. By use cases, we mean specific examples of stuff that clearly happens in reality today or would happen in reality if this was added. 2) Come up with a concrete proposal for what be added to the spec. 3) Find a UA willing to prototype such a new feature. At any point, it's possible Ian may be interested in adding it to the WebStorage spec and/or others could follow your lead. But if I were you, I'd start down the road I just described. J On Thu, Aug 5, 2010 at 1:55 AM, Nicholas Zakas nza...@yahoo-inc.com wrote: So given no strenuous objections, can we make expiration for Web Storage real? :) -Nicholas __ Commander Lock: Dammit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Wednesday, August 04, 2010 10:26 AM To: Jeremy Orlow Cc: Nicholas Zakas; Scott Hess; Alexandre Morgaut; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal for Web Storage expiration On Wed, Aug 4, 2010 at 2:14 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 3, 2010 at 1:51 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas nza...@yahoo-inc.com wrote: Yes, for IndexDB I think having a per-storage area expiration date completely makes sense. Do you expect that IndexedDB will become a successor to sessionStorage/localStorage? No. I think LocalStorage will stick around since it's just so simple to use and a lot of people just need to store a tiny bit of data here or there--much like cookies. IndexedDB will be used for structured data, so I don't see many people using it for things they one used (abused) cookies for. My belief is that the simple key-value store paradigm would still end up being the default client-side data storage utility, and would therefore benefit from having a per-key expiration time to mimic cookie usage. I suspect it will be much easier to add to IndexedDB than to localStorage/sessionStorage. I don't expect the latter to go away, though generally it seems like people are disliking localStorage enough that it's hard to get any changes made to it. Jonas, are you against the expiration feature proposal for LocalStorage? Because no one else has voiced the typical we should just leave LocalStorage alone concerns. So if you're not, I think we can assume that such types (me included) aren't going to raise such a concern. I'm actually much less enthusiastic about expiration for IndexedDB as I don't see very compelling use cases. I'm definitely for expiration of localStorage values. Though I think it also makes sense to do for IndexedDB. Especially if it can be done on a per-objectStore basis as that makes it very low overhead. / Jonas
Re: [whatwg] Proposal for Web Storage expiration
On Tue, Aug 3, 2010 at 1:51 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas nza...@yahoo-inc.com wrote: Yes, for IndexDB I think having a per-storage area expiration date completely makes sense. Do you expect that IndexedDB will become a successor to sessionStorage/localStorage? No. I think LocalStorage will stick around since it's just so simple to use and a lot of people just need to store a tiny bit of data here or there--much like cookies. IndexedDB will be used for structured data, so I don't see many people using it for things they one used (abused) cookies for. My belief is that the simple key-value store paradigm would still end up being the default client-side data storage utility, and would therefore benefit from having a per-key expiration time to mimic cookie usage. I suspect it will be much easier to add to IndexedDB than to localStorage/sessionStorage. I don't expect the latter to go away, though generally it seems like people are disliking localStorage enough that it's hard to get any changes made to it. Jonas, are you against the expiration feature proposal for LocalStorage? Because no one else has voiced the typical we should just leave LocalStorage alone concerns. So if you're not, I think we can assume that such types (me included) aren't going to raise such a concern. I'm actually much less enthusiastic about expiration for IndexedDB as I don't see very compelling use cases. J
Re: [whatwg] Proposal for Web Storage expiration
On Wed, Aug 4, 2010 at 2:14 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 3, 2010 at 1:51 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas nza...@yahoo-inc.com wrote: Yes, for IndexDB I think having a per-storage area expiration date completely makes sense. Do you expect that IndexedDB will become a successor to sessionStorage/localStorage? No. I think LocalStorage will stick around since it's just so simple to use and a lot of people just need to store a tiny bit of data here or there--much like cookies. IndexedDB will be used for structured data, so I don't see many people using it for things they one used (abused) cookies for. My belief is that the simple key-value store paradigm would still end up being the default client-side data storage utility, and would therefore benefit from having a per-key expiration time to mimic cookie usage. I suspect it will be much easier to add to IndexedDB than to localStorage/sessionStorage. I don't expect the latter to go away, though generally it seems like people are disliking localStorage enough that it's hard to get any changes made to it. Jonas, are you against the expiration feature proposal for LocalStorage? Because no one else has voiced the typical we should just leave LocalStorage alone concerns. So if you're not, I think we can assume that such types (me included) aren't going to raise such a concern. I'm actually much less enthusiastic about expiration for IndexedDB as I don't see very compelling use cases. I'm definitely for expiration of localStorage values. Though I think it also makes sense to do for IndexedDB. Especially if it can be done on a per-objectStore basis as that makes it very low overhead. / Jonas
Re: [whatwg] Proposal for Web Storage expiration
So given no strenuous objections, can we make expiration for Web Storage real? :) -Nicholas __ Commander Lock: Dammit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Wednesday, August 04, 2010 10:26 AM To: Jeremy Orlow Cc: Nicholas Zakas; Scott Hess; Alexandre Morgaut; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal for Web Storage expiration On Wed, Aug 4, 2010 at 2:14 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 3, 2010 at 1:51 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas nza...@yahoo-inc.com wrote: Yes, for IndexDB I think having a per-storage area expiration date completely makes sense. Do you expect that IndexedDB will become a successor to sessionStorage/localStorage? No. I think LocalStorage will stick around since it's just so simple to use and a lot of people just need to store a tiny bit of data here or there--much like cookies. IndexedDB will be used for structured data, so I don't see many people using it for things they one used (abused) cookies for. My belief is that the simple key-value store paradigm would still end up being the default client-side data storage utility, and would therefore benefit from having a per-key expiration time to mimic cookie usage. I suspect it will be much easier to add to IndexedDB than to localStorage/sessionStorage. I don't expect the latter to go away, though generally it seems like people are disliking localStorage enough that it's hard to get any changes made to it. Jonas, are you against the expiration feature proposal for LocalStorage? Because no one else has voiced the typical we should just leave LocalStorage alone concerns. So if you're not, I think we can assume that such types (me included) aren't going to raise such a concern. I'm actually much less enthusiastic about expiration for IndexedDB as I don't see very compelling use cases. I'm definitely for expiration of localStorage values. Though I think it also makes sense to do for IndexedDB. Especially if it can be done on a per-objectStore basis as that makes it very low overhead. / Jonas
Re: [whatwg] Proposal for Web Storage expiration
Is it easier in terms of implementation issues or general consensus? -Nicholas __ Commander Lock: Dammit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Monday, August 02, 2010 5:51 PM To: Nicholas Zakas Cc: Scott Hess; Alexandre Morgaut; whatwg@lists.whatwg.org; Jeremy Orlow Subject: Re: [whatwg] Proposal for Web Storage expiration On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas nza...@yahoo-inc.com wrote: Yes, for IndexDB I think having a per-storage area expiration date completely makes sense. Do you expect that IndexedDB will become a successor to sessionStorage/localStorage? My belief is that the simple key-value store paradigm would still end up being the default client-side data storage utility, and would therefore benefit from having a per-key expiration time to mimic cookie usage. I suspect it will be much easier to add to IndexedDB than to localStorage/sessionStorage. I don't expect the latter to go away, though generally it seems like people are disliking localStorage enough that it's hard to get any changes made to it. / Jonas
Re: [whatwg] Proposal for Web Storage expiration
If a site could create multiple Storage areas, then I would agree that per-item expiration wouldn't be necessary and we could get along fine with per-storage expiration. However, that's not the case, and the expiration use case is clearly already present. Having every developer that wants to expire data write his or her own code seems extremely wasteful to me. Why ask people to reinvent the same functionality over and over again? Whether or not cookies are a good model to follow, the expiration functionality is what makes auth sequences using them feasible. I'd defer to those who know on implementation details, but this doesn't seem like a very hard problem to solve in a performant way. -Nicholas __ Commander Lock: Dammit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Scott Hess [mailto:sh...@google.com] Sent: Friday, July 30, 2010 5:05 PM To: Nicholas Zakas Cc: Jeremy Orlow; Alexandre Morgaut; whatwg@lists.whatwg.org; Jonas Sicking Subject: Re: [whatwg] Proposal for Web Storage expiration On Fri, Jul 30, 2010 at 11:51 AM, Nicholas Zakas nza...@yahoo-inc.com wrote: And I totally agree, this is not a strong security feature, and that's not the intent. The intent is just to give an extra measure of control of the lifetime of the data to bring Web Storage closer to being a replacement for a wider range of functionality that currently uses cookies. I don't think this really follows. Cookies were invented quite awhile ago, and may not be a good model for development. A reasonably small dataset allows the client to expire cookies aggressively. With large local storage, doing per-item expiration is not a good idea - you do not want your UA groveling through a gig of data you are not otherwise using to expire a couple dozen items. Per-database expiration might make sense, because the expiration information could be stored in a central location as a hint to the UA (if the site isn't going to use the data after two weeks, might as well delete it). Sites could segment their expiration needs by using multiple data stores. That said, idle storage is eventually going to be reclaimed anyhow, so you could just ignore the problem. Current storage proposals are much richer than cookies, so the developer could just store dates alongside their other data and make the decisions directly, no need for the system to help. Since the JavaScript accessing the data is executing right next to the data, you don't have the latency issues client/server communication introduces. So long as expiration is a SHOULD, its not clear to me that this idiom is powerful enough to deserve footprint in the spec. -scott
Re: [whatwg] Proposal for Web Storage expiration
On Mon, Aug 2, 2010 at 11:23 AM, Nicholas Zakas nza...@yahoo-inc.com wrote: If a site could create multiple Storage areas, then I would agree that per-item expiration wouldn't be necessary and we could get along fine with per-storage expiration. However, that's not the case, and the expiration use case is clearly already present. If we add this to IndexedDB then there are certainly multiple storage areas. You can have any number of objectStores inside any number of databases. Having every developer that wants to expire data write his or her own code seems extremely wasteful to me. Why ask people to reinvent the same functionality over and over again? Whether or not cookies are a good model to follow, the expiration functionality is what makes auth sequences using them feasible. I'd defer to those who know on implementation details, but this doesn't seem like a very hard problem to solve in a performant way. If we add expiration to IndexedDB on an objectStore level, then the page author doesn't need to do anything beyond setting an expiration date, right? / Jonas
Re: [whatwg] Proposal for Web Storage expiration
Yes, for IndexDB I think having a per-storage area expiration date completely makes sense. Do you expect that IndexedDB will become a successor to sessionStorage/localStorage? My belief is that the simple key-value store paradigm would still end up being the default client-side data storage utility, and would therefore benefit from having a per-key expiration time to mimic cookie usage. To be clear, I think there should be expiration for all forms of client-side data storage, and adding it to one doesn't seem like a reason to not add it to all. -Nicholas __ Commander Lock: Dammit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jonas Sicking Sent: Monday, August 02, 2010 2:10 PM To: Nicholas Zakas Cc: Scott Hess; Alexandre Morgaut; whatwg@lists.whatwg.org; Jeremy Orlow Subject: Re: [whatwg] Proposal for Web Storage expiration On Mon, Aug 2, 2010 at 11:23 AM, Nicholas Zakas nza...@yahoo-inc.com wrote: If a site could create multiple Storage areas, then I would agree that per-item expiration wouldn't be necessary and we could get along fine with per-storage expiration. However, that's not the case, and the expiration use case is clearly already present. If we add this to IndexedDB then there are certainly multiple storage areas. You can have any number of objectStores inside any number of databases. Having every developer that wants to expire data write his or her own code seems extremely wasteful to me. Why ask people to reinvent the same functionality over and over again? Whether or not cookies are a good model to follow, the expiration functionality is what makes auth sequences using them feasible. I'd defer to those who know on implementation details, but this doesn't seem like a very hard problem to solve in a performant way. If we add expiration to IndexedDB on an objectStore level, then the page author doesn't need to do anything beyond setting an expiration date, right? / Jonas
Re: [whatwg] Proposal for Web Storage expiration
On Mon, Aug 2, 2010 at 5:24 PM, Nicholas Zakas nza...@yahoo-inc.com wrote: Yes, for IndexDB I think having a per-storage area expiration date completely makes sense. Do you expect that IndexedDB will become a successor to sessionStorage/localStorage? My belief is that the simple key-value store paradigm would still end up being the default client-side data storage utility, and would therefore benefit from having a per-key expiration time to mimic cookie usage. I suspect it will be much easier to add to IndexedDB than to localStorage/sessionStorage. I don't expect the latter to go away, though generally it seems like people are disliking localStorage enough that it's hard to get any changes made to it. / Jonas
Re: [whatwg] Proposal for Web Storage expiration
On Thu, Jul 29, 2010 at 10:57 AM, Nicholas Zakas nza...@yahoo-inc.comwrote: setter creator void setItem(in DOMString key, in any data, [Optional] in unsigned long ttl); The third argument is a TTL specifying how long, in milliseconds, the data should be stored in sessionStorage/localStorage. Some proposed implementation details: * A TTL of 0 is considered invalid and ignored, as is any value less than 0. If you want to immediately remove a key, it should be done via removeItem(). * The TTL for a key may be changed each time setItem() is called, with the new TTL overwriting the old one. * If a TTL was previously set, and then a new TTL is not provided on a subsequent call to setItem(), then the original TTL remains. * If a TTL was previously set, and another call is made to setItem() that contains an invalid TTL (= 0), then the original TTL remains. * To remove a previously set TTL, you must call removeItem() to completely remove the key and then re-add using setItem(). * Adding a third argument means the length property of setItem will be 3, so developers can check for support of this feature using (localStorage.setItem.length 2). * The TTL is valid for both sessionStorage and localStorage, but more important for localStorage. I like this idea. It would help deal with orphaned data that was written by a site, but was never removed or used after a change in the site. It seems that there should be a way to change a TTL without having to load and set the value data again, or remove a TTL without having to remove the key and re-add it. While it might not be too bad to remove a single key and re-add it, it becomes a nuisance to remove the TTL on many keys by loading, removing, and re-adding each key. I'm thinking of scenarios where localStorage may be used to locally cache data for a user (e.g. an email client) where the user may have the option to choose to keep the data for 1 week, 1 month, etc. If the user choose to change the caching duration then the browser may have to load and set 5MB of data, just to update the TTLs. My thought is that to remove a TTL we could either pass -1 (any negative number perhaps) to the function to reset the TTL, or use an empty value (null or ). To just change a TTL without changing the key/value we may consider making the second parameter optional as well, although I'm not in love with that idea. Paul Ellis
Re: [whatwg] Proposal for Web Storage expiration
On Thu, Jul 29, 2010 at 8:57 PM, Nicholas Zakas nza...@yahoo-inc.com wrote: setter creator void setItem(in DOMString key, in any data, [Optional] in unsigned long ttl); * If a TTL was previously set, and another call is made to setItem() that contains an invalid TTL (= 0), then the original TTL remains. As you've specified ttl as unsigned, the callee will not see your 'invalid' ttl, it will see a 'very large' ttl.
Re: [whatwg] Proposal for Web Storage expiration
On Jul 29, 2010, at 7:57 PM, Nicholas Zakas wrote: Proposed Interface Change: The easiest way to include such a change would be to augment the Storage::setItem() method with a third optional argument. So change from: setter creator void setItem(in DOMString key, in any data); To: setter creator void setItem(in DOMString key, in any data, [Optional] in unsigned long ttl); I think too that being able to specify the end of life of stored data can be useful I also think, like Paul Ellis it might be frustrating to have too set again the value of an item to update its TTL value (all the more on very large Objects) Another frustration for me is to have to set a TTL value when the value I want to defined is a fixed expiration date and not a Time To Live value. I'd prefer then: - to call this third argument expires - make this argument considered as a TTL value if it is a number - make this argument considered as an expiration date if it is a Date Object - it might also be considered as an expiration Date if it is a ISO Date String (often used in JSON string) - it might then be considered as a TTL if it is not an ISO Date String but a string that can be converted into a valid number About negative, null value of a value equal too 0 assigned to this third argument: - I agree with Paul that it could be interpreted to remove this expiration setting About interpreting no value to the second argument as a TTL update - I find it kind of weird What is the expected behavior when setting an item value to undefined ? I find it unclear in the specification. It says setItem fix a structured clone value... - will it throw an exception for undefined - will it remove the item as we could expect using the alternative way to set the value (localStorage.myItem = undefined) Thinking about JSON stringification, setting a property to undefined makes it disappear while null preserves its existence. Thinking about Objects, assigning null would is often used to delete an instance (even if I semantically prefer the delete JavaScript instruction) To update this expires or TTL attribute of this item, I would consider Storage::setExpiration(in DOMString key, in TTL or expiration Date) (or Storage::setTTL() if you guys don't agree on the Date option) By the way, I often figure out that one on the goals to define good APIs is to Keep It Stupid Simple ;-) So I could live, maybe a bit sadly, without the support of Dates... Alexandre.
Re: [whatwg] Proposal for Web Storage expiration
It might be worth integrating this into IndexedDB as it seems like people are more reluctant to add additional features to localStorage for various reasons. One key question is if expiration needs to happen on a per-value basis. Or if per-storage-area (per objectStore) is enough? / Jonas On Thu, Jul 29, 2010 at 10:57 AM, Nicholas Zakas nza...@yahoo-inc.com wrote: Background: The Web Storage specification provides two ways for web applications to store key-value data in the browser, effectively replacing cookies for cases when the server doesn’t need the information. For a lot of web application needs, sessionStorage and localStorage (or some combination of the two) can be used to effectively reduce the number of cookies used. Cookies do have one advantage over these APIs: the ability to specify an expiration period after which the data is removed. Right now, if a web application developers wish to have expiration of key-value pairs, he/she must manually implement such expiration on their own. An example of an API that already does this is XAuth (xauth.org). Proposal: Adding the ability to optionally define an expiration date for each key-value pair would bring sessionStorage/localStorage closer the capabilities of cookies today and provide useful control over the length of time that certain data can live in the browser. This becomes especially important if any authentication-related data is to be stored in Web Storage. Proposed Interface Change: The easiest way to include such a change would be to augment the Storage::setItem() method with a third optional argument. So change from: setter creator void setItem(in DOMString key, in any data); To: setter creator void setItem(in DOMString key, in any data, [Optional] in unsigned long ttl); The third argument is a TTL specifying how long, in milliseconds, the data should be stored in sessionStorage/localStorage. Some proposed implementation details: * A TTL of 0 is considered invalid and ignored, as is any value less than 0. If you want to immediately remove a key, it should be done via removeItem(). * The TTL for a key may be changed each time setItem() is called, with the new TTL overwriting the old one. * If a TTL was previously set, and then a new TTL is not provided on a subsequent call to setItem(), then the original TTL remains. * If a TTL was previously set, and another call is made to setItem() that contains an invalid TTL (= 0), then the original TTL remains. * To remove a previously set TTL, you must call removeItem() to completely remove the key and then re-add using setItem(). * Adding a third argument means the length property of setItem will be 3, so developers can check for support of this feature using (localStorage.setItem.length 2). * The TTL is valid for both sessionStorage and localStorage, but more important for localStorage. Thoughts? -Nicholas __ Commander Lock: Dammit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to.
Re: [whatwg] Proposal for Web Storage expiration
On Fri, Jul 30, 2010 at 12:20 PM, Jonas Sicking jo...@sicking.cc wrote: It might be worth integrating this into IndexedDB as it seems like people are more reluctant to add additional features to localStorage for various reasons. I have expressed this opinion quite vocally in the past, but given that expiration is an ability of cookies, cookies suffer from the same race conditions localStorage does [1], and giving people fewer reasons to depend on cookies is definitely good for the web (in terms of bandwidth and latency), I actually think we should go ahead with something like this. The main thing is that it'd need to be specced as a MAY condition. I.e. the browser MAY delete the content once it expires. After all, if the user never turns on the computer, there's no possible way for the UA to delete the data. It'd then be up to the UAs to decide how agressive they'd like to be about deleting it. I'd suggest moving forward looking at expiration for WebStorage first and then evaluate it for IndexedDB later on (since there's still a lot of more important stuff in the air with that spec right now). One key question is if expiration needs to happen on a per-value basis. Or if per-storage-area (per objectStore) is enough? Good point. Several of the use cases I can think of seems as though they might be solvable with just a global setting. Unless there's a couple use cases where this seems fairly compelling, maybe we should concentrate on such a solution. On Fri, Jul 30, 2010 at 9:07 AM, Alexandre Morgaut alexandre.morg...@4d.com wrote: To update this expires or TTL attribute of this item, I would consider Storage::setExpiration(in DOMString key, in TTL or expiration Date) (or Storage::setTTL() if you guys don't agree on the Date option) This might make sense, but I'm also not sure it's worth the additional API surface area. Plus I kind of like the idea of making it difficult for people to detect whether the browser even supports expiration since we don't people to ever assume they can count on it. (Since once again, what if the user doesn't turn on their computer or the UA doesn't delete expired data unless it's running?) J [1] Yes, I know it's specced to be non-racy, but no one implements it that way.
Re: [whatwg] Proposal for Web Storage expiration
Storage::setExpiration(in DOMString key, in TTL or expiration Date) (or Storage::setTTL() if you guys don't agree on the Date option) This might make sense, but I'm also not sure it's worth the additional API surface area. Plus I kind of like the idea of making it difficult for people to detect whether the browser even supports expiration since we don't people to ever assume they can count on it. (Since once again, what if the user doesn't turn on their computer or the UA doesn't delete expired data unless it's running?) Well, as Nicholas said, the important thing is that the User-Agent makes its best to remove the items ASAP once they expired. Sure some of these items could remain on disk while they expired until the UA start again. This is absolutely not a strong security feature. The user still should be able to remove manually the storages content, or disable access to the storage objects, from the User-Agent menus/preferences. I'm not confortable into hiding User-Agent capabilities from the API. Smart people like John Resig recommend to check the available API instead of looking after the User-Agent name and version to detect them, and I kind of like this approach.
Re: [whatwg] Proposal for Web Storage expiration
To answer a few of the questions brought up in this thread all in one bang: 1) TTL vs. Date - I originally was going to propose a date, but the more I dug in and around uses cases for cookies, the more frequently I found people setting dates based on a TTL (i.e., I want this to expire in one year, so I add one year to the current date and set that as the expiration). It seemed that the TTL case was more common, and you could easily set an actual date via (new Date(January 1, 2011) - new Date()) if that's what you really want. 2) Expiration for the entire data store vs. individual keys - Funny enough, my original proposal was for the entire data store, but then I went back and looked at cookies again to try to find the analogy. It seemed to me that, in the current localStorage, each key is analogous to a single cookie. Since each single cookie has an expiration, it seemed like letting each key have a separate TTL would provide parity. 3) MAY vs. SHOULD - I could be convinced either way. The important thing, in my mind, is that the browser makes its best attempt to remove the data when specified. -Nicholas __ Commander Lock: Dammit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jeremy Orlow Sent: Friday, July 30, 2010 8:22 AM To: Jonas Sicking Cc: whatwg@lists.whatwg.org; Nicholas Zakas Subject: Re: [whatwg] Proposal for Web Storage expiration On Fri, Jul 30, 2010 at 12:20 PM, Jonas Sicking jo...@sicking.cc wrote: It might be worth integrating this into IndexedDB as it seems like people are more reluctant to add additional features to localStorage for various reasons. I have expressed this opinion quite vocally in the past, but given that expiration is an ability of cookies, cookies suffer from the same race conditions localStorage does [1], and giving people fewer reasons to depend on cookies is definitely good for the web (in terms of bandwidth and latency), I actually think we should go ahead with something like this. The main thing is that it'd need to be specced as a MAY condition. I.e. the browser MAY delete the content once it expires. After all, if the user never turns on the computer, there's no possible way for the UA to delete the data. It'd then be up to the UAs to decide how agressive they'd like to be about deleting it. I'd suggest moving forward looking at expiration for WebStorage first and then evaluate it for IndexedDB later on (since there's still a lot of more important stuff in the air with that spec right now). One key question is if expiration needs to happen on a per-value basis. Or if per-storage-area (per objectStore) is enough? Good point. Several of the use cases I can think of seems as though they might be solvable with just a global setting. Unless there's a couple use cases where this seems fairly compelling, maybe we should concentrate on such a solution. On Fri, Jul 30, 2010 at 9:07 AM, Alexandre Morgaut alexandre.morg...@4d.commailto:alexandre.morg...@4d.com wrote: To update this expires or TTL attribute of this item, I would consider Storage::setExpiration(in DOMString key, in TTL or expiration Date) (or Storage::setTTL() if you guys don't agree on the Date option) This might make sense, but I'm also not sure it's worth the additional API surface area. Plus I kind of like the idea of making it difficult for people to detect whether the browser even supports expiration since we don't people to ever assume they can count on it. (Since once again, what if the user doesn't turn on their computer or the UA doesn't delete expired data unless it's running?) J [1] Yes, I know it's specced to be non-racy, but no one implements it that way.
Re: [whatwg] Proposal for Web Storage expiration
On Fri, Jul 30, 2010 at 7:09 PM, Alexandre Morgaut alexandre.morg...@4d.com wrote: Storage::setExpiration(in DOMString key, in TTL or expiration Date) (or Storage::setTTL() if you guys don't agree on the Date option) This might make sense, but I'm also not sure it's worth the additional API surface area. Plus I kind of like the idea of making it difficult for people to detect whether the browser even supports expiration since we don't people to ever assume they can count on it. (Since once again, what if the user doesn't turn on their computer or the UA doesn't delete expired data unless it's running?) Well, as Nicholas said, the important thing is that the User-Agent makes its best to remove the items ASAP once they expired. Sure some of these items could remain on disk while they expired until the UA start again. This is absolutely not a strong security feature. The user still should be able to remove manually the storages content, or disable access to the storage objects, from the User-Agent menus/preferences. I'm not confortable into hiding User-Agent capabilities from the API. Smart people like John Resig recommend to check the available API instead of looking after the User-Agent name and version to detect them, and I kind of like this approach. My point was that a programmer really shouldn't do anything differently whether or not the API is available. But you're probably right that it'd only push such an author towards user-agent sniffing which is of course worse. I just had another thought. Although I strongly feel that the spec shouldn't guarantee when the data is deleted (and should probably have some non-normative text explaining why) we could (if we wanted to) guarantee that data won't be available to the page after that time. (Of course subject to run to completion constraints--if the user calls localStorage.length, we can't delete the item until they leave the scripting context. Also there's a question of whether we'd fire StorageEvents while something's timed out. Maybe we should just expire stuff when navigating to a page and not while the page is running?) J
Re: [whatwg] Proposal for Web Storage expiration
I'm also not keen on UA sniffing for the determination of features, which is why I mentioned using localStorage.setItem.length to determine if the TTL parameter is valid for the browser. IMO, it's fine not to delete the data while the page is loaded, but I would like to ensure that the data isn't able to be read if the expiration time is reached during the page lifecycle. And I totally agree, this is not a strong security feature, and that's not the intent. The intent is just to give an extra measure of control of the lifetime of the data to bring Web Storage closer to being a replacement for a wider range of functionality that currently uses cookies. -Nicholas __ Commander Lock: Dammit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jeremy Orlow Sent: Friday, July 30, 2010 11:18 AM To: Alexandre Morgaut Cc: whatwg@lists.whatwg.org; Nicholas Zakas; Jonas Sicking Subject: Re: [whatwg] Proposal for Web Storage expiration On Fri, Jul 30, 2010 at 7:09 PM, Alexandre Morgaut alexandre.morg...@4d.commailto:alexandre.morg...@4d.com wrote: Storage::setExpiration(in DOMString key, in TTL or expiration Date) (or Storage::setTTL() if you guys don't agree on the Date option) This might make sense, but I'm also not sure it's worth the additional API surface area. Plus I kind of like the idea of making it difficult for people to detect whether the browser even supports expiration since we don't people to ever assume they can count on it. (Since once again, what if the user doesn't turn on their computer or the UA doesn't delete expired data unless it's running?) Well, as Nicholas said, the important thing is that the User-Agent makes its best to remove the items ASAP once they expired. Sure some of these items could remain on disk while they expired until the UA start again. This is absolutely not a strong security feature. The user still should be able to remove manually the storages content, or disable access to the storage objects, from the User-Agent menus/preferences. I'm not confortable into hiding User-Agent capabilities from the API. Smart people like John Resig recommend to check the available API instead of looking after the User-Agent name and version to detect them, and I kind of like this approach. My point was that a programmer really shouldn't do anything differently whether or not the API is available. But you're probably right that it'd only push such an author towards user-agent sniffing which is of course worse. I just had another thought. Although I strongly feel that the spec shouldn't guarantee when the data is deleted (and should probably have some non-normative text explaining why) we could (if we wanted to) guarantee that data won't be available to the page after that time. (Of course subject to run to completion constraints--if the user calls localStorage.length, we can't delete the item until they leave the scripting context. Also there's a question of whether we'd fire StorageEvents while something's timed out. Maybe we should just expire stuff when navigating to a page and not while the page is running?) J
Re: [whatwg] Proposal for Web Storage expiration
On Fri, Jul 30, 2010 at 11:51 AM, Nicholas Zakas nza...@yahoo-inc.com wrote: And I totally agree, this is not a strong security feature, and that’s not the intent. The intent is just to give an extra measure of control of the lifetime of the data to bring Web Storage closer to being a replacement for a wider range of functionality that currently uses cookies. I don't think this really follows. Cookies were invented quite awhile ago, and may not be a good model for development. A reasonably small dataset allows the client to expire cookies aggressively. With large local storage, doing per-item expiration is not a good idea - you do not want your UA groveling through a gig of data you are not otherwise using to expire a couple dozen items. Per-database expiration might make sense, because the expiration information could be stored in a central location as a hint to the UA (if the site isn't going to use the data after two weeks, might as well delete it). Sites could segment their expiration needs by using multiple data stores. That said, idle storage is eventually going to be reclaimed anyhow, so you could just ignore the problem. Current storage proposals are much richer than cookies, so the developer could just store dates alongside their other data and make the decisions directly, no need for the system to help. Since the JavaScript accessing the data is executing right next to the data, you don't have the latency issues client/server communication introduces. So long as expiration is a SHOULD, its not clear to me that this idiom is powerful enough to deserve footprint in the spec. -scott
[whatwg] Proposal for Web Storage expiration
Background: The Web Storage specification provides two ways for web applications to store key-value data in the browser, effectively replacing cookies for cases when the server doesn't need the information. For a lot of web application needs, sessionStorage and localStorage (or some combination of the two) can be used to effectively reduce the number of cookies used. Cookies do have one advantage over these APIs: the ability to specify an expiration period after which the data is removed. Right now, if a web application developers wish to have expiration of key-value pairs, he/she must manually implement such expiration on their own. An example of an API that already does this is XAuth (xauth.org). Proposal: Adding the ability to optionally define an expiration date for each key-value pair would bring sessionStorage/localStorage closer the capabilities of cookies today and provide useful control over the length of time that certain data can live in the browser. This becomes especially important if any authentication-related data is to be stored in Web Storage. Proposed Interface Change: The easiest way to include such a change would be to augment the Storage::setItem() method with a third optional argument. So change from: setter creator void setItem(in DOMString key, in any data); To: setter creator void setItem(in DOMString key, in any data, [Optional] in unsigned long ttl); The third argument is a TTL specifying how long, in milliseconds, the data should be stored in sessionStorage/localStorage. Some proposed implementation details: * A TTL of 0 is considered invalid and ignored, as is any value less than 0. If you want to immediately remove a key, it should be done via removeItem(). * The TTL for a key may be changed each time setItem() is called, with the new TTL overwriting the old one. * If a TTL was previously set, and then a new TTL is not provided on a subsequent call to setItem(), then the original TTL remains. * If a TTL was previously set, and another call is made to setItem() that contains an invalid TTL (= 0), then the original TTL remains. * To remove a previously set TTL, you must call removeItem() to completely remove the key and then re-add using setItem(). * Adding a third argument means the length property of setItem will be 3, so developers can check for support of this feature using (localStorage.setItem.length 2). * The TTL is valid for both sessionStorage and localStorage, but more important for localStorage. Thoughts? -Nicholas __ Commander Lock: Dammit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to.
