Re: [Bug 11606] New: wanted: awareness of non-persistent web storage
On Mon, Dec 27, 2010 at 8:43 PM, Glenn Maynard gl...@zewt.org wrote: On Mon, Dec 27, 2010 at 10:55 PM, Drew Wilson atwil...@google.com wrote: FWIW, the Chrome team has come down pretty hard on the side of not ever leaking to apps that the user is in incognito mode, for precisely the reasons described previously. Incognito mode loses much of its utility if pages are able to screen for it and block access. A similar argument can be made for ad blockers, and in my opinion much more convincingly: ad blockers very directly (even measurably) mean sites make less money. Yet, in my years of using ABP, I've never once encountered in the wild a site that refused to work because of it, despite the fact that they're trivial to detect. You haven't looked widely enough. There was a fad for a little while of doing precisely that - hiding the content if the page detected that an adblocker was in use, and showing an explanation of why the content was hidden. This fad died out, though, because it's pretty rude and most users don't know how to turn off their adblockers anyway. Note, though, that turning off your adblocker doesn't really open you up to privacy violations. Switching out of incognito (when you don't really understand the distinction in the first place, and just want things to work) does. If ad blockers had been designed to hide their activity from pages, the end result would have been much worse. Images would have to be marked visibility: hidden rather than display: none, since the changes in layout are detectable. A huge amount of bandwidth would be wasted, since the server can check to see that a banner is actually being downloaded. This just has the feel of those theoretical problems that are easy to argue for, but are unlikely to ever actually surface. I agree that making adblockers undetectable would have been a huge problem, and almost certainly not worth the trouble. On the other hand, making incognito mode undetectable is very easy - just act like a normal, fresh invocation of the browser, then silently throw away all the data you've stored at the end of the session. The page has no way to tell you apart from any other new user. I do think there's a user education burden that isn't entirely being met yet, though - the Chrome documentation doesn't really talk about local storage, for example. But I don't think that pushing this responsibility onto individual web applications is the right solution. My experience suggests that most users will never know the difference between local and server-side storage, and probably don't want to; most designs that require that much user education don't work. The most likely end result is ignoring the issue: let a few people lose data, and if they complain, tell them it's your fault for using incognito mode, and your browser's fault for preventing us from warning you. Not ideal, but pushing the blame onto the browser is likely to be the path of least resistance. I agree that it's the path of least resistance. I also believe it's the best solution overall. ~TJ
Re: [Bug 11606] New: wanted: awareness of non-persistent web storage
On Tue, Dec 28, 2010 at 4:20 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: I agree that it's the path of least resistance. I also believe it's the best solution overall. It's true that an ugly solution is still the best one, but note that the likely end result seems very similar: discouraging people from using incognito mode. -- Glenn Maynard
Re: [Bug 11606] New: wanted: awareness of non-persistent web storage
Both Firefox and Chrome offer users privacy features which will cause Web Storage to be non-persistent across browser restart. For example Firefox has a Never remember history option, and Chrome has a clear cookies and other data when I close my browser option. For an application developer, it would be helpful to know when such features have been enabled, so that the application can inform the user, assist in troubleshooting, or disable features that depend on persistent storage. Hi. Although I understand the reasoning, I strongly disagree with the request. When the user open a tab in private mode, he/she knows that data will not be stored, therefore there is no need for the webpage to reiterate that. It would be awkward to expect each and every webpage that requires storage to warn the user, while it should be the user agent that would properly help the user manage his/her data. There should be no way for a webpage to sniff if private mode is enabled: an advertiser could block users because it wouldn't be able to set tracking cookies for instance, like many of those sites that say Enable cookies to continue, but in this case applied to Storage. Specifying that an API can change its behavior radically solely based on a user preference goes completely against the principle of interoperability: same code running everywhere unchanged. The last thing the user needs is the webpage breaking because there are unexpected exceptions being thrown. By mentioning private tabs, the same applies to other features that remove data. So, +1 to transparency.
Re: [Bug 11606] New: wanted: awareness of non-persistent web storage
(Note that this is from a ticket; the OP probably won't see replies here.) On Mon, Dec 27, 2010 at 7:46 PM, João Eiras joao.ei...@gmail.com wrote: When the user open a tab in private mode, he/she knows that data will not be stored, therefore there is no need for the webpage to reiterate that. It would be awkward to expect each and every webpage that requires storage to warn the user, while it should be the user agent that would properly help the user manage his/her data. Users won't completely understand what privacy mode does; what data can't be stored and what can. If you log into Gmail in privacy mode, does that mean that your saved drafts will be stored, or lost? That depends on whether they're stored on the server or in (for example) localStorage, a distinction no ordinary user can be expected to understand. If Gmail uses localStorage to save drafts (it doesn't), it should definitely be able to tell the user: warning, your saved drafts will be lost at the end of your browser session because your browser is configured not to keep this data around, or to change storage mechanisms. The alternative is ugly--users spending half an hour writing a mail, saving a draft, and having it silently lost, because they expected privacy mode to prevent their login cookie to be discarded, not their drafts. This means that even if localStorage is appropriate for a particular use, the dangers of angry, confused users may make it unacceptable. I don't like the idea of a not persistant attribute: although I don't personally find the transparency argument convincing, I'm pretty sure that even if the spec requires having such an attribute, browsers will ignore it. That seems worse than not having it at all. My first impression was that privacy mode should simply disable these interfaces (as the current Web Storage editor's draft seems to require, though as I mentioned before it's unclear), but that's no good for IndexedDB, which is very useful even if it's not persistant. I don't know the right answer in general. -- Glenn Maynard
Re: [Bug 11606] New: wanted: awareness of non-persistent web storage
FWIW, the Chrome team has come down pretty hard on the side of not ever leaking to apps that the user is in incognito mode, for precisely the reasons described previously. Incognito mode loses much of its utility if pages are able to screen for it and block access. I do think there's a user education burden that isn't entirely being met yet, though - the Chrome documentation doesn't really talk about local storage, for example. But I don't think that pushing this responsibility onto individual web applications is the right solution. -atw On Mon, Dec 27, 2010 at 5:45 PM, Glenn Maynard gl...@zewt.org wrote: (Note that this is from a ticket; the OP probably won't see replies here.) On Mon, Dec 27, 2010 at 7:46 PM, João Eiras joao.ei...@gmail.com wrote: When the user open a tab in private mode, he/she knows that data will not be stored, therefore there is no need for the webpage to reiterate that. It would be awkward to expect each and every webpage that requires storage to warn the user, while it should be the user agent that would properly help the user manage his/her data. Users won't completely understand what privacy mode does; what data can't be stored and what can. If you log into Gmail in privacy mode, does that mean that your saved drafts will be stored, or lost? That depends on whether they're stored on the server or in (for example) localStorage, a distinction no ordinary user can be expected to understand. If Gmail uses localStorage to save drafts (it doesn't), it should definitely be able to tell the user: warning, your saved drafts will be lost at the end of your browser session because your browser is configured not to keep this data around, or to change storage mechanisms. The alternative is ugly--users spending half an hour writing a mail, saving a draft, and having it silently lost, because they expected privacy mode to prevent their login cookie to be discarded, not their drafts. This means that even if localStorage is appropriate for a particular use, the dangers of angry, confused users may make it unacceptable. I don't like the idea of a not persistant attribute: although I don't personally find the transparency argument convincing, I'm pretty sure that even if the spec requires having such an attribute, browsers will ignore it. That seems worse than not having it at all. My first impression was that privacy mode should simply disable these interfaces (as the current Web Storage editor's draft seems to require, though as I mentioned before it's unclear), but that's no good for IndexedDB, which is very useful even if it's not persistant. I don't know the right answer in general. -- Glenn Maynard
Re: [Bug 11606] New: wanted: awareness of non-persistent web storage
On Mon, Dec 27, 2010 at 10:55 PM, Drew Wilson atwil...@google.com wrote: FWIW, the Chrome team has come down pretty hard on the side of not ever leaking to apps that the user is in incognito mode, for precisely the reasons described previously. Incognito mode loses much of its utility if pages are able to screen for it and block access. A similar argument can be made for ad blockers, and in my opinion much more convincingly: ad blockers very directly (even measurably) mean sites make less money. Yet, in my years of using ABP, I've never once encountered in the wild a site that refused to work because of it, despite the fact that they're trivial to detect. If ad blockers had been designed to hide their activity from pages, the end result would have been much worse. Images would have to be marked visibility: hidden rather than display: none, since the changes in layout are detectable. A huge amount of bandwidth would be wasted, since the server can check to see that a banner is actually being downloaded. This just has the feel of those theoretical problems that are easy to argue for, but are unlikely to ever actually surface. I do think there's a user education burden that isn't entirely being met yet, though - the Chrome documentation doesn't really talk about local storage, for example. But I don't think that pushing this responsibility onto individual web applications is the right solution. My experience suggests that most users will never know the difference between local and server-side storage, and probably don't want to; most designs that require that much user education don't work. The most likely end result is ignoring the issue: let a few people lose data, and if they complain, tell them it's your fault for using incognito mode, and your browser's fault for preventing us from warning you. Not ideal, but pushing the blame onto the browser is likely to be the path of least resistance. -- Glenn Maynard
Re: [Bug 11606] New: wanted: awareness of non-persistent web storage
This made me wonder about this: When support for a feature is disabled (e.g. as an emergency measure to mitigate a security problem, or to aid in development, or for performance reasons), user agents must act as if they had no support for the feature whatsoever, and as if the feature was not mentioned in this specification. For example, if a particular feature is accessed via an attribute in a Web IDL interface, the attribute itself would be omitted from the objects that implement that interface — leaving the attribute on the object but making it return null or throw an exception is insufficient. vs. this: 4.3 1. The user agent may throw a SECURITY_ERR exception instead of returning a Storage object if the request violates a policy decision (e.g. if the user agent is configured to not allow the page to persist data). If localStorage is disabled due to user configuration, which rule applies? The former (remove the feature entirely) is much better for me as a developer. I've already had to write code to test putting data in localStorage and see if it throws an exception, on top of simply saying 'localStorage' in window. On Sun, Dec 26, 2010 at 11:58 AM, bugzi...@jessica.w3.org wrote: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11606 Summary: wanted: awareness of non-persistent web storage Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Web Storage (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: w3@mukesh.agrawals.org QAContact: member-webapi-...@w3.org CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org Both Firefox and Chrome offer users privacy features which will cause Web Storage to be non-persistent across browser restart. For example Firefox has a Never remember history option, and Chrome has a clear cookies and other data when I close my browser option. For an application developer, it would be helpful to know when such features have been enabled, so that the application can inform the user, assist in troubleshooting, or disable features that depend on persistent storage. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Glenn Maynard
