- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 28 Apr 2010 16:53:05 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Michael Nordman <michaeln@google.com>, Dumitru Daniliuc <dumi@chromium.org>, Shawn Wilsher <sdwilsh@mozilla.com>, Nikunj Mehta <nikunj@o-micron.com>, Mike Clement <mikec@google.com>, public-webapps@w3.org
On Wed, Apr 28, 2010 at 4:32 PM, Jonas Sicking <jonas@sicking.cc> wrote: > On Wed, Apr 28, 2010 at 4:03 PM, Michael Nordman <michaeln@google.com> wrote: >> We have in mind that the incentives for developers to not always utilize the >> most permanent storage option are... >> 1) Non-permanent storage is accessible w/o explicit user opt-in, so less >> annoying UI. > > This is interesting. I think that we'll want to allow sites some > amount of permanent storage without explicit user opt-in. Though we > could allow much more for the "caching storage". This sounds like a > very good idea. The problems with allowing permanent no-user-ask storage have already been hashed out. It's impossible to do right - either you're too lenient (amount per subdomain) and malicious sites can fill up your permanent storage trivially by using iframes to subdomains, or you're too strict (amount per domain, or disallowing storage in nested browsing contexts) which kills a lot of legitimate and good use-cases. Tying permanence to user opt-in, and specifically to proactive user opt-in rather than a script-triggered dialog (modal or otherwise), appears to be the only way to chart the appropriate course between power and protection. >> 2) Less of a burden to 'manage' the data if the user-agent will clean it up >> for you. > > I'm not convinced this will be much of incentive. I think few sites > are as interested in cleaning up the users hard drive as the user is. > I can see many sites dropping data into the permanent storage and then > caring very little when that is cleaned up. I'd imagine many ad > networks would love it if it was never cleaned up. > > The incentive I had in mind was that if the UA decides it needs to > purge data for a specific site, for example due to hitting some global > quota, then we'd first clear out the data with the lowest level of > permanence first. So it wouldn't make a difference if all data for a > site is permanent, or if all of it is semi-permanent, in both cases > it'd all get nuked. > > However if the site has some permanent and some semi-permanent, then > we'd clear out the semi-permanent first and remeasure if we're up > against the global quota still. > > But I also really like the idea of having less UI for semi-permanent. Requiring a user to explicitly hit an <input> or similar to allocate permanent storage should be enough to make sites use volatile storage unless they really need permanence. Expiring permanent storage automatically, though, means that I can never be sure that my mail archives are actually secure on my computer, even though I told Gmail to save it to my hard drive. I can never be sure that my draft emails are really saved, and won't disappear. I have no problem with a browser simply not *exposing* permanent storage, and not allowing authors to request it. But if any major browser exposes a "permanent" storage that isn't actually permanent, then we app developers no longer have a permanent storage to rely on. It's simply gone, unless we put up a "Best viewed in anything but Firefox" sticker. On mobile platforms where storage is at a premium and it's much more difficult for users to manipulate the filesystem, just don't allow permanent storage. But don't lie to the application and say you support something that you explicitly don't. Lying browsers cause horrific confusion and bugs. >_< ~TJ
Received on Wednesday, 28 April 2010 23:53:58 UTC