On Mon, 31 Aug 2009, Jens Alfke wrote:
On Aug 31, 2009, at 3:11 AM, Ian Hickson wrote:
We can't treat cookies and persistent storage differently, because
otherwise we'll expose users to cookie resurrection attacks.
Maintaining the user's expectations of privacy is critical.
The fact
On Thu, Sep 3, 2009 at 7:56 AM, Ian Hicksoni...@hixie.ch wrote:
On Mon, 31 Aug 2009, Jens Alfke wrote:
On Aug 31, 2009, at 3:11 AM, Ian Hickson wrote:
We can't treat cookies and persistent storage differently, because
otherwise we'll expose users to cookie resurrection attacks.
On Thu, Sep 3, 2009 at 8:56 AM, Ian Hicksoni...@hixie.ch wrote:
The fact that local storage can be used for cookie resurrection means we
have to make sure that clearing one clears the other. Anything else would
be a huge privacy issue (just as Flash has been).
The *only* reason Flash is a
On Thu, 3 Sep 2009, Tab Atkins Jr. wrote:
On Thu, Sep 3, 2009 at 7:56 AM, Ian Hicksoni...@hixie.ch wrote:
On Mon, 31 Aug 2009, Jens Alfke wrote:
On Aug 31, 2009, at 3:11 AM, Ian Hickson wrote:
We can't treat cookies and persistent storage differently, because
otherwise we'll expose
On Thu, Sep 3, 2009 at 6:49 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
You could just *not* specify that LocalStorage is worthless for
anything but a cache.
This seems like a severe overstatement given the current spec. It's not
worthless. It won't be guaranteed to be thrown away all
On Thu, Sep 3, 2009 at 5:33 PM, Ian Hicksoni...@hixie.ch wrote:
On Thu, 3 Sep 2009, Tab Atkins Jr. wrote:
On Thu, Sep 3, 2009 at 7:56 AM, Ian Hicksoni...@hixie.ch wrote:
On Mon, 31 Aug 2009, Jens Alfke wrote:
On Aug 31, 2009, at 3:11 AM, Ian Hickson wrote:
We can't treat cookies and
On Thu, Sep 3, 2009 at 3:44 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
And more-than-a-cache-Storage can be explicitly turned off or have its
quota dropped to zero. If that's important, the browsers will make it
easy. And more importantly, they'll make it *consistent* (within the
On Thu, Sep 3, 2009 at 5:48 PM, Peter Kastingpkast...@google.com wrote:
On Thu, Sep 3, 2009 at 3:44 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
And more-than-a-cache-Storage can be explicitly turned off or have its
quota dropped to zero. If that's important, the browsers will make it
On Thu, Sep 3, 2009 at 3:55 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Again, this is precisely what we as UA authors can do now, with the
current
spec. I'm not sure what you're arguing. Our job is to make sure users
whose philosophy is like Ian's are as well-served as users whose
On Thu, Sep 3, 2009 at 5:59 PM, Peter Kastingpkast...@google.com wrote:
On Thu, Sep 3, 2009 at 3:55 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
You may have missed the part where Ian said that, to protect their
user's privacy, browsers *must* clear cookies and LocalStorage at the
same time.
On Fri, Sep 4, 2009 at 12:33 AM, Ian Hicksoni...@hixie.ch wrote:
Flash's privacy problem can be removed by uninstalling Flash. They're not
a license to add more privacy problems to the platform.
And a permanent's storage potential privacy problems could also be
removed by having separate Delete
On Thu, Sep 3, 2009 at 4:08 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
10 hours ago, Hixie said:
The fact that local storage can be used for cookie resurrection means we
have to make sure that clearing one clears the other. Anything else would
be a huge privacy issue (just as Flash has
On Fri, 4 Sep 2009, Eduard Pascual wrote:
Now, this question is mostly addressed to Ian, as the only one who can
provide a 100% accurate answer: based on the spec text intent, would the
idea of having separate Delete cookies and Delete everything buttons
side by side be conformant?
Yes.
On Thu, Sep 3, 2009 at 7:12 PM, Eduard Pascualherenva...@gmail.com wrote:
The problem is not what the spec says, or is supposed to say, but how
does it say it. This long discussion seems to be mostly around the
point that the current wording is too likely to be miss-interpreted as
The delete
On Thu, 3 Sep 2009, Aryeh Gregor wrote:
I think this is too specific -- it should say something more like User
agents should make it clear to the user that to ensure privacy from
sites, he must delete persistent storage as well as HTTP session
cookies. But the current wording doesn't
On Thu, Sep 3, 2009 at 7:26 PM, Ian Hicksoni...@hixie.ch wrote:
There's more wording in a later section on cookie resurrection which gives
more background. Does that satisfy your request?
Not really. You still have the sentence User agents should present
the persistent storage feature to the
On Thu, Sep 3, 2009 at 4:26 PM, Ian Hickson i...@hixie.ch wrote:
There's more wording in a later section on cookie resurrection which gives
more background. Does that satisfy your request?
I think that later section actually muddies the waters.
Something like this would be more clear: If
On Fri, Sep 4, 2009 at 1:23 AM, Ian Hicksoni...@hixie.ch wrote:
On Fri, 4 Sep 2009, Eduard Pascual wrote:
If it would (and a lot of people here seem to be arguing that it would),
then this discussion could be easily be put to an end by tweaking the
wording in a way that makes this more
On Thu, Sep 3, 2009 at 6:31 PM, Peter Kastingpkast...@google.com wrote:
On Thu, Sep 3, 2009 at 4:26 PM, Ian Hickson i...@hixie.ch wrote:
There's more wording in a later section on cookie resurrection which gives
more background. Does that satisfy your request?
I think that later section
On Thu, 3 Sep 2009, Aryeh Gregor wrote:
On Thu, Sep 3, 2009 at 7:26 PM, Ian Hicksoni...@hixie.ch wrote:
There's more wording in a later section on cookie resurrection which gives
more background. Does that satisfy your request?
Not really. You still have the sentence User agents should
On Thu, 3 Sep 2009, Peter Kasting wrote:
On Thu, Sep 3, 2009 at 4:26 PM, Ian Hickson i...@hixie.ch wrote:
There's more wording in a later section on cookie resurrection which gives
more background. Does that satisfy your request?
I think that later section actually muddies the waters.
On Thu, Sep 3, 2009 at 5:17 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 3 Sep 2009, Peter Kasting wrote:
On Thu, Sep 3, 2009 at 4:26 PM, Ian Hickson i...@hixie.ch wrote:
There's more wording in a later section on cookie resurrection which
gives
more background. Does that satisfy your
On Aug 31, 2009, at 12:04 PM, Peter Kasting wrote:
If you combine that statement with section 6.1's User agents should
present the persistent storage feature to the user in a way that
does not distinguish them from HTTP session cookies, then the
result is that, when the user requests to
On Wed, Sep 2, 2009 at 11:08 AM, Jens Alfke s...@google.com wrote:
On Aug 31, 2009, at 12:04 PM, Peter Kasting wrote:
If you combine that statement with section 6.1's User agents should
present the persistent storage feature to the user in a way that does not
distinguish them from HTTP
On Sep 2, 2009, at 11:36 AM, Peter Kasting wrote:
It still seems like you are interpreting this statement as saying
that the UA must not allow users to keep/clear cookies separately
from Local Storage data.
Yes; that seemed the most direct interpretation of its language.
While on the
On Thu, Sep 3, 2009 at 4:50 AM, Jens Alfke s...@google.com wrote:
On Sep 2, 2009, at 11:36 AM, Peter Kasting wrote:
It still seems like you are interpreting this statement as saying that the
UA must not allow users to keep/clear cookies separately from Local Storage
data.
Yes; that
On 01/09/2009 00:14, Tab Atkins Jr. jackalm...@gmail.com wrote:
Sure, the ones using it for tracking that care *that much* will use
other solutions anyway. But people who just want some persistent
storage as part of their app, because it's useful to their users, will
use the browser-native
On Sep 1, 2009, at 12:11 AM, Adrian Sutton wrote:
On 01/09/2009 00:14, Tab Atkins Jr. jackalm...@gmail.com wrote:
Sure, the ones using it for tracking that care *that much* will use
other solutions anyway. But people who just want some persistent
storage as part of their app, because it's
On Tue, Sep 1, 2009 at 3:11 AM, Adrian Suttonadrian.sut...@ephox.com wrote:
Besides which, there are already very popular UAs that have no support for
Flash and thus no Flash LocalStorage. It would be nice to not create the
same privacy hole on those platforms.
What's the privacy hole, if
Please take in to account that email is asynchronous but spam is still
annoying.
Linus
On Mon, Aug 31, 2009 at 3:11 AM, Ian Hickson i...@hixie.ch wrote:
In addition, I'd like to see the pop-up dialogs for the location API
removed. I find the Can I know where you are? dialogs on the iPhone
On Tue, 25 Aug 2009, Jens Alfke wrote:
I've just noticed an apparent self-contradiction in the Web Storage spec (24
August draft).
Section 4.3 states:
Data stored in local storage areas should be considered potentially
user-critical. It is expected that Web applications will use the
On Aug 31, 2009, at 3:11 AM, Ian Hickson wrote:
We can't treat cookies and persistent storage differently, because
otherwise we'll expose users to cookie resurrection attacks.
Maintaining
the user's expectations of privacy is critical.
The fact that local storage can be used as a type of
On Mon, Aug 31, 2009 at 11:12 AM, Jeremy Orlow jor...@chromium.org wrote:
Yes, this is pretty disconcerting since there's been OVERWHELMING support
for LocalStorage being treated as user-critical on this thread.
The spec says basically what you want except that it uses should. It
seems like
On Mon, Aug 31, 2009 at 11:18 AM, Peter Kasting pkast...@google.com wrote:
On Mon, Aug 31, 2009 at 11:12 AM, Jeremy Orlow jor...@chromium.orgwrote:
Yes, this is pretty disconcerting since there's been OVERWHELMING support
for LocalStorage being treated as user-critical on this thread.
The
On Aug 31, 2009, at 11:18 AM, Peter Kasting wrote:
The spec says basically what you want except that it uses should.
It seems like UAs and authors would both be satisfied with this; I
don't expect any UA vendor to wantonly discard local storage data.
By encouraging the UI to treat local
On Aug 31, 2009, at 11:35 AM, Peter Kasting wrote:
Again, the spec now says in 4.3: User agents should expire data
from the local storage areas only for security reasons or when
requested to do so by the user. The only stronger statement you
could get would be by changing this to a must.
Jens Alfke wrote:
Local storage is a significant change from the browser's current data
model, and I think that (no offense) browser developers are not used to
taking care of user-critical data for longer than the duration of a DOM
tree or POST request. It's a change in perspective. Coming as
On Mon, Aug 31, 2009 at 11:50 AM, Jens Alfke s...@google.com wrote:
On Aug 31, 2009, at 11:35 AM, Peter Kasting wrote:
Again, the spec now says in 4.3: User agents should expire data from the
local storage areas only for security reasons or when requested to do so by
the user. The only
On Mon, Aug 31, 2009 at 6:11 AM, Ian Hicksoni...@hixie.ch wrote:
We can't treat cookies and persistent storage differently, because
otherwise we'll expose users to cookie resurrection attacks. Maintaining
the user's expectations of privacy is critical.
By that reasoning we can't treat cookies
On Aug 31, 2009, at 11:58 AM, Boris Zbarsky wrote:
It's controversial because, no offense, browser developers don't
trust the website author, nor should the users. At least to a first
approximation.
Over on another thread of this list we've already been talking about
the need to get
Quoting Ian Hickson i...@hixie.ch:
On Tue, 25 Aug 2009, Jens Alfke wrote:
Potential result: I was having trouble logging into FooDocs.com,
so my friend
suggested I delete the cookies for that site. After that I could log in, but
now the document I was working on this morning has lost all
On Mon, Aug 31, 2009 at 2:01 PM, Jens Alfkes...@google.com wrote:
The fact that local storage can be used as a type of super-cookie doesn't
mean the two are the same thing. Yes, obviously if I give a website
permission to put 50MB of stuff on my disk, it can use 1k of that as a type
of cookie
On Mon, Aug 31, 2009 at 6:08 PM, Aryeh Gregorsimetrical+...@gmail.com wrote:
On Mon, Aug 31, 2009 at 2:36 PM, Tab Atkins Jr.jackalm...@gmail.com wrote:
Outlawing persistent storage in HTML5 as a privacy mechanism does
*nothing* for privacy. There are numerous methods, Flash LocalStorage
in
Michael Nordman wrote:
And to confound the problem further, UAs dont have meta-data on hand with
which to relate various pieces of local data together and attribute them to
a specific user-identifiable 'application'. Everything is bound to a
security-origin, but that doesn't clearly identify or
On Aug 27, 2009, at 5:53 PM, Dirk Pranke wrote:
Would you hold a different opinion for different types of HTML5-based
applications (like the TiddlyWiki app that gets copied locally)? Or
would you require that all apps go through an install process that
acquires quota, permissions, etc.?
Speaking up as an application developer ;-) here, I think the evict data at
browser's choice route is fatal for new inventions in app development. I've
been hoping that WebStorage and Offline together with other new APIs could
provide a platform that allows us to build applications free from
On Aug 26, 2009, at 4:51 PM, Jens Alfke wrote:
To repeat what I said up above: Maybe the local storage API needs a
way to distinguish between cached data that can be silently thrown
away, and important data that can't.
That makes sense to me. There might even be more than two
On 27/08/2009 15:47, Maciej Stachowiak m...@apple.com wrote:
- Cached for convenience - discarding this will affect performance but not
functionality.
- Useful for offline use - discarding this will prevent some data from being
accessed when offline.
- Critical for offline use - discarding
Adrian Sutton said:
On 27/08/2009 15:47, Maciej Stachowiak m...@apple.com wrote:
- Cached for convenience - discarding this will affect performance but not
functionality.
- Useful for offline use - discarding this will prevent some data from being
accessed when offline.
- Critical for
To: Linus Upson li...@google.com
Cc: Brady Eidson beid...@apple.com, WHATWG List wha...@whatwg.org,
Jeremy Orlow jor...@chromium.org, Jens Alfke s...@google.com,
Aaron Boodman a...@google.com
Subject: Re: [whatwg] Web Storage: apparent contradiction in spec
Message-ID
Adrian Sutton wrote:
On 27/08/2009 15:47, Maciej Stachowiak m...@apple.com wrote:
- Cached for convenience - discarding this will affect performance but not
functionality.
- Useful for offline use - discarding this will prevent some data from being
accessed when offline.
- Critical for offline
And to confound the problem further, UAs dont have meta-data on hand with
which to relate various pieces of local data together and attribute them to
a specific user-identifiable 'application'. Everything is bound to a
security-origin, but that doesn't clearly identify or label an
'application'.
On Thu, Aug 27, 2009 at 10:47 AM, Maciej Stachowiakm...@apple.com wrote:
That makes sense to me. There might even be more than two categories:
- Cached for convenience - discarding this will affect performance but not
functionality.
- Useful for offline use - discarding this will prevent some
On Thu, Aug 27, 2009 at 11:14 AM, Schuyler Duveenwha...@graffitiweb.org wrote:
1. To run Doom requiring 500M of localStorage sounds like an
'application'--both users and developers currently have the expectation
that users have to approve something like that before being installed to
their
Aryeh Gregor wrote:
On Thu, Aug 27, 2009 at 11:14 AM, Schuyler Duveenwha...@graffitiweb.org
wrote:
1. To run Doom requiring 500M of localStorage sounds like an
'application'--both users and developers currently have the expectation
that users have to approve something like that before being
On Thu, Aug 27, 2009 at 11:53 AM, Schuyler Duveenwha...@graffitiweb.org wrote:
If it's user-specific, then why not just use sessionStorage?
Hmm. You're right, there's a lot of overlap there. sessionStorage
might be sufficient for caching, for most applications. If not,
localStorage could be
On Aug 27, 2009, at 7:47 AM, Maciej Stachowiak wrote:
On Aug 26, 2009, at 4:51 PM, Jens Alfke wrote:
To repeat what I said up above: Maybe the local storage API needs a
way to distinguish between cached data that can be silently thrown
away, and important data that can't.
That makes sense
I don't think there is consensus at Google yet.
I'm not saying that UAs shouldn't provide file-like lifetime semantics for
storage. I'm just saying the user should decide, not the web page.
Here's one way such a thing could be achieved:
input type=storage src=button.png quota=20GB /
When the
On Wed, Aug 26, 2009 at 8:23 PM, Linus Upsonli...@google.com wrote:
I simply want clicking on links to be safe. In a previous thread I wrote
safe and stateless but I'm coming to the opinion that stateless is
a corollary of safe. Clicking on links shouldn't, either by filling my disk
or hitting
There should also be a way to ask for more quota (from the user) without
losing user data.
The API via a form element is a little odd--generally forms are for
submitting information to the site. Historically, all of these kinds of
things are done via javascript:
* cookies
* opensearch additions
On Wed, Aug 26, 2009 at 8:23 PM, Linus Upsonli...@google.com wrote:
The
candidate delete list will be thousands long and hidden in that haystack
will be a few precious needles.
While that is certainly one of the outcomes, and I agree a bad one, I
am not sure that the user experience needs to
On Thu, Aug 27, 2009 at 10:33 AM, Linus Upsonli...@google.com wrote:
I don't think there is consensus at Google yet.
I'm not saying that UAs shouldn't provide file-like lifetime semantics for
storage. I'm just saying the user should decide, not the web page.
Linus, are you only considering
My concerns are around browser UAs. AIR, Dashboard, XULRunner, Extensions,
etc. can have different policies. I simply want clicking on links in my
browser to be safe.
Linus
On Thu, Aug 27, 2009 at 5:53 PM, Dirk Pranke dpra...@chromium.org wrote:
On Thu, Aug 27, 2009 at 10:33 AM, Linus
On Wed, 26 Aug 2009 00:59:31 +0200, Aaron Boodman a...@google.com wrote:
On Tue, Aug 25, 2009 at 3:51 PM, Jeremy Orlowjor...@chromium.org wrote:
I still don't understand what use local storage has outside of 'cloud
storage'. Even in the extensions use case (which I think is out of
scope for
On Aug 26, 2009, at 3:10 AM, Anne van Kesteren wrote:
Indeed. It would be nice to be able to write simple applications
that do not require the cloud at all and basically consist of a set
of static documents distributed over HTTP.
TiddlyWiki is a perfect example of this, if anyone's
As an offline cloud-app developer, I've got these three kinds of data:1)
Data from the cloud that's cached locally on a best-effort basis, that can
be thrown out if we start running out of space.
2) Data from the cloud that the app needs in order to keep functioning at
all.
3) Locally created data
On 26/08/2009 18:36, Jens Alfke s...@google.com wrote:
I think there are lots of other use cases for web apps that would use local
storage without ever syncing it to the cloud, simply because it's vastly
easier to do. I can write such an app and host it on my cheapo personal
website without
On Wed, Aug 26, 2009 at 4:01 PM, Linus Upson li...@google.com wrote:
The analogy was made comparing a user agent that purges local storage to an
OS throwing out files without explicit user action. This is misleading since
most files arrive on your computer's disk via explicit user action. You
At a minimum the HTML 5 spec should be silent on how user agents implement
local storage policies.
+1 linus
The sort of 'policies' being discussed are feeling 'out-of-scope' for the
HTML5 spec. The practical realities are that eviction needs to be there in
some form w/o an explicit user
On Wed, Aug 26, 2009 at 4:31 PM, Michael Nordman micha...@google.comwrote:
A mandate from on high that says 'shall store forever and ever' will be
promptly ignored because its impossible to make that guarantee.
That's not the proposed mandate. The proposed mandate is thou shalt not
discard
On Aug 26, 2009, at 4:01 PM, Linus Upson wrote:
The analogy was made comparing a user agent that purges local
storage to an OS throwing out files without explicit user action.
This is misleading since most files arrive on your computer's disk
via explicit user action. You copy files to
Ok... I overstated things ;)
What seems inevitable are vista-like prompts to allow something (or prods to
delete something) seemingly unrelated to a user's interaction with a site...
please, oh please, lets avoid making that part of the web platform.
I'm assuming that UA will have out-of-band
Maybe the local storage API needs a way to distinguish between cached data
that can be silently thrown away, and important data that can't.*
*
*What if instead of the storage APIs providing a way to distinguish things,
UA's provide a way for users to indicate which applications are important,
and
On Aug 26, 2009, at 4:55 PM, Michael Nordman wrote:
What seems inevitable are vista-like prompts to allow something (or
prods to delete something) seemingly unrelated to a user's
interaction with a site... please, oh please, lets avoid making that
part of the web platform.
Doesn't Gears
On Thu, Aug 27, 2009 at 1:55 AM, Michael Nordmanmicha...@google.com wrote:
Ok... I overstated things ;)
What seems inevitable are vista-like prompts to allow something (or prods to
delete something) seemingly unrelated to a user's interaction with a site...
please, oh please, lets avoid making
On Wed, Aug 26, 2009 at 5:08 PM, Remco remc...@gmail.com wrote:
As far as I know, cookies work the same way as the proposed local
storage policy: once a cookie is created, the browser won't delete it
when space becomes a problem. The site controls the expiration date of
the cookie, and it can
I started writing a detailed rebuttal to Linus's reply, but by the
time I was finished, many others had already delivered more targetted
replies.
So I'll cut the rebuttal format and make a few specific points.
- Many apps act as a shoebox for managing specific types of data,
and users
On Wed, Aug 26, 2009 at 5:08 PM, Remco remc...@gmail.com wrote:
On Thu, Aug 27, 2009 at 1:55 AM, Michael Nordmanmicha...@google.com
wrote:
Ok... I overstated things ;)
What seems inevitable are vista-like prompts to allow something (or prods
to
delete something) seemingly unrelated to a
My suggestion to have separate 'important' and 'cache' local storage areas
would provide such a mechanism in a standard way. The first time an app
tried to put stuff in the 'important' area, you'd be asked for approval. And
'important' stores wouldn't be deleted
without your consent.
I think you
On Wed, Aug 26, 2009 at 4:55 PM, Michael Nordman micha...@google.comwrote:
What seems inevitable are vista-like prompts to allow something (or prods
to delete something) seemingly unrelated to a user's interaction with a
site... please, oh please, lets avoid making that part of the web
On Thu, Aug 27, 2009 at 2:26 AM, Peter Kastingpkast...@google.com wrote:
On Wed, Aug 26, 2009 at 4:55 PM, Michael Nordman micha...@google.com
wrote:
What seems inevitable are vista-like prompts to allow something (or prods
to delete something) seemingly unrelated to a user's interaction with
On Wed, Aug 26, 2009 at 5:14 PM, Brady Eidson beid...@apple.com wrote:
I started writing a detailed rebuttal to Linus's reply, but by the time I
was finished, many others had already delivered more targetted replies.
So I'll cut the rebuttal format and make a few specific points.
- Many
On Wed, Aug 26, 2009 at 5:14 PM, Brady Eidson beid...@apple.com wrote:
I started writing a detailed rebuttal to Linus's reply, but by the time I
was finished, many others had already delivered more targetted replies.
So I'll cut the rebuttal format and make a few specific points.
- Many
On Wed, Aug 26, 2009 at 5:42 PM, Michael Nordman micha...@google.comwrote:
In addition to the key/value pair storage apis, i think we'd need to make
this distinction for databases and appcaches too. This distinction may be
better handled in a way not tied to a particular flavor on storage. Or
On Wed, Aug 26, 2009 at 8:58 PM, Peter Kastingpkast...@google.com wrote:
I think having authors choose between permanent and purgeable storage types
adds complexity to the implementation and usage that is not desirable from
either an authoring or a UX perspective.
This complexity already
I simply want clicking on links to be safe. In a previous thread I wrote
safe and stateless but I'm coming to the opinion that stateless is
a corollary of safe. Clicking on links shouldn't, either by filling my disk
or hitting my global quota, someday lead to a dialog which reads, Please
choose
This is one of those times when I *really* wish that the application
developer community was more active on this list. I absolutely understand
Linus' point of view, but I also feel like we are really hamstringing
applications when we make choices like this and I wish that those developers
were
I understand you want the web to be safe. I do too, and I think we
all do.
It never has been, it currently isn't, but it's better. The situation
has been improving for many years.
I'm not convinced that the idea of guaranteed persistent storage
inherently takes us backwards.
I think
I've just noticed an apparent self-contradiction in the Web Storage
spec (24 August draft).
Section 4.3 states:
Data stored in local storage areas should be considered potentially
user-critical. It is expected that Web applications will use the
local storage areas for storing user-written
On Aug 25, 2009, at 1:38 PM, Linus Upson wrote:
It is important that all local state be treated as a cache. User
agents need to be free to garbage collect any local state. If they
can't then attackers (or the merely lazy) will be able to fill up
the user's disk. We can't expect web sites
On Tue, Aug 25, 2009 at 2:09 PM, Brady Eidson beid...@apple.com wrote:
On Aug 25, 2009, at 1:38 PM, Linus Upson wrote:
It is important that all local state be treated as a cache. User agents
need to be free to garbage collect any local state. If they can't then
attackers (or the merely lazy)
It is important that all local state be treated as a cache. User agents need
to be free to garbage collect any local state. If they can't then attackers
(or the merely lazy) will be able to fill up the user's disk. We can't
expect web sites or users to do the chore of taking out the garbage.
On Aug 25, 2009, at 2:16 PM, Jeremy Orlow wrote:
On Tue, Aug 25, 2009 at 2:09 PM, Brady Eidson beid...@apple.com
wrote:
On Aug 25, 2009, at 1:38 PM, Linus Upson wrote:
It is important that all local state be treated as a cache. User
agents need to be free to garbage collect any local
On Tue, Aug 25, 2009 at 2:16 PM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Aug 25, 2009 at 2:09 PM, Brady Eidson beid...@apple.com wrote:
On Aug 25, 2009, at 1:38 PM, Linus Upson wrote:
It is important that all local state be treated as a cache. User agents
need to be free to garbage
On Tue, Aug 25, 2009 at 2:40 PM, Brady Eidson beid...@apple.com wrote:
On Aug 25, 2009, at 2:16 PM, Jeremy Orlow wrote:
On Tue, Aug 25, 2009 at 2:09 PM, Brady Eidson beid...@apple.com wrote:
On Aug 25, 2009, at 1:38 PM, Linus Upson wrote:
It is important that all local state be treated as
Interesting comments. Linus and Jeremy appear to be coming at this
from a pure cloud perspective, where any important or persistent
data is kept on a remote server and the browser, so local storage can
be treated as merely a cache. That's definitely a valid position, but
from my
On Aug 25, 2009, at 3:09 PM, Jens Alfke wrote:
Interesting comments. Linus and Jeremy appear to be coming at this
from a pure cloud perspective, where any important or persistent
data is kept on a remote server and the browser, so local storage
can be treated as merely a cache. That's
The statement in section 4.3 doesn't appear to specify any behavior... its
just an informational statement.
The statement in section 6.1 suggests to prohibit the development of a UI
that mentions local storage as a distinct repository seperate from cookies.
This doesn't belong in the spec imho.
On Tue, Aug 25, 2009 at 3:19 PM, Aaron Boodman a...@google.com wrote:
On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlowjor...@chromium.org wrote:
Ok, well I guess we should go ahead and have this discussion now. :-)
Does
anyone outside of Apple and Google have an opinion on the matter (since
On Tue, Aug 25, 2009 at 3:51 PM, Jeremy Orlowjor...@chromium.org wrote:
I still don't understand what use local storage has outside of 'cloud
storage'. Even in the extensions use case (which I think is out of scope
for this spec), there's no reason you can't sync user preferences and such
to
1 - 100 of 105 matches
Mail list logo
