InformAction Forums

I set my cookie acceptance to session only and dump on close, never had issues. No third party and been pretty golden and save the annoyance of being asked all the time.

Thrawn wrote:OK, I've tried setting Cookies back to 'Always Ask', and it's not as bad as I recall; will probably leave it that way. The nuisance is when you tell the dialog box to always allow cookies for a site, and then it asks you again when the site wants to modify an existing cookie, and then again once the site has set about 10 of them...especially since the cookie dialog box is modal. But I'll see how I go.

Agreed. But at my frequent sites, such as Yahoo Mail, it pretty much seems to have all of these modification permissions, too. It's only at new sites that aren't yet configged that this annoyance happens, AFAICR.

Just want to point out that even in the case of session cookies and similar things the recent trend is clearly to move away from the coherence between the lifetime of a browser application and a "session".

Fitting quotes:

• From the Mozilla employee Dan Witte:

  https://bugzilla.mozilla.org/show_bug.cgi?id=471675#c3 wrote:Also, minor point -- the distinction between session cookies and persistent cookies is largely historical and doesn't have much meaning nowadays, with the advent of sessionstore and such.

• From the HTML5 or the HTML living standard spec:

  http://dev.w3.org/html5/webstorage/#the-sessionstorage-attribute[/url] or [url]http://www.whatwg.org/specs/web-apps/current-work/multipage/webstorage.html#the-sessionstorage-attribute wrote:The lifetime of a browsing context can be unrelated to the lifetime of the actual user agent process itself, as the user agent may support resuming sessions after a restart.

dhouwn wrote:Just want to point out that even in the case of session cookies and similar things the recent trend is clearly to move away from the coherence between the lifetime of a browser application and a "session".

Fitting quotes:

• From the Mozilla employee Dan Witte:

  https://bugzilla.mozilla.org/show_bug.cgi?id=471675#c3 wrote:Also, minor point -- the distinction between session cookies and persistent cookies is largely historical and doesn't have much meaning nowadays, with the advent of sessionstore and such.

• From the HTML5 or the HTML living standard spec:

  http://dev.w3.org/html5/webstorage/#the-sessionstorage-attribute[/url] or [url]http://www.whatwg.org/specs/web-apps/current-work/multipage/webstorage.html#the-sessionstorage-attribute wrote:The lifetime of a browsing context can be unrelated to the lifetime of the actual user agent process itself, as the user agent may support resuming sessions after a restart.

More good reasons to disable session store/restore, which I've been doing for years.
Also, using a sandbox that is emptied completely at the close of each *physical* browsing session, including the portion of the profile cloned for that session.

Thanks for pointing out more ways that MZ is continually eroding our privacy, the protection of which was one reason that many of us left IE.
Our "newer is not always better" discussion comes to mind here.

@ dhouwn:

Sudden afterthought: Would all of those "sessionstore" features mean that a NS Temp-Allow might *not* expire when the browser is closed?
I've never had those settings enabled, and so wouldn't know -- and don't care to reset them all, test, etc. You seem to have a handle on what MZ is doing in those "extended sessions", so maybe you'd know the answer?

If it turns out to be true, that they extend NS temp permissions beyond the physical browser session, then perhaps Giorgio could make a work-around that ensures that TA "literally" means Temp -- that they are auto-revoked upon physically closing the browser, regardless of MZ's notions of extended sessions etc.

Tom T. wrote:Would all of those "sessionstore" features mean that a NS Temp-Allow might *not* expire when the browser is closed?

Nope, it expires, but you might never knowwith what features they might come up in the future, but in the case of the add-on state then probably just as opt-in. Also, you have keep in mind that there are certain things that simply can't be saved and recovered like persistent connections.

dhouwn wrote:

Tom T. wrote:Would all of those "sessionstore" features mean that a NS Temp-Allow might *not* expire when the browser is closed?

Nope, it expires, but you might never knowwith what features they might come up in the future, but in the case of the add-on state then probably just as opt-in. Also, you have keep in mind that there are certain things that simply can't be saved and recovered like persistent connections.

The "nope" is reassuring, thanks. But the "you never know" and "probably* (opt-in) aren't so reassuring. To beat a dead horse, they don't opt you int to
geo.location enabled, and most users have no idea it's there.

So if they do save add-on state in the future, I hope they'll let us know in advance. (One more reason to vet each new version thoroughly, perhaps as a portable, before making a permanent install. )

Persistent connections: understood. But NS temp-permissions show in the GUI, so it certainly seems *feasible* to save them, although I hope they don't.

(What "tag" was GµårÐïåñ referring to? I don't see any tags.)

One more reason for frequent browser restarts, or clearing of all cache, history, cookies, etc.

The right bracket ] in the quote on the initial opening was missing making it all bunched into a blob of text, that's what I fixed, so the quote is separated.

Just came across this bug report that makes clear that I was apparently wrong about the Session Restore behavior in Firefox: https://bugzil.la/show_bug.cgi?id=345345. What I wasn't wrong about is that the meaning of a "session" has changed (as can be also seen by the bug tracker comments).

(is that the correct link?)