4 ms·

Well, trackers will just switch to using localstorage instead since the preference doesn't affect it [1] and it pops up no permission dialog. [1] https://bugzi

by ferongr 14y ago

Well, trackers will just switch to using localstorage instead since the preference doesn't affect it [1] and it pops up no permission dialog. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=536509 https://bugzilla.mozilla.org/show_bug.cgi?id=536509

derefr 14y ago
It really seems like all the things browsers do to allow sites to persist data on your computer (cookies, client certificates, localStorage, WebSQL/IndexedDB, the FileSystem storage API, HTML5 Application Caching...) should all be controlled by a single set of preferences/request dialogs. They wouldn't even need to break down the requests by type; it's pretty irrelevant to a user which kind of storage is going on. Combining this with a "forgiveness is better than permission" principle (which seems to be sorely lacking in web browsers, other than a few just-plain-strange places like alert() dialogs), the best UX might just be a warning bar stating "Example.com has reserved 1KB/5MB of your disk so it can remember its place. [Disallow]" Disallowing would make the site think it still has a permanent store, but internally replace it with an ephemeral one (FS::TEMPORARY, session cookie, etc.) This also might make browser makers get off their lazy butts and make ephemeral versions of the rest of these mechanisms, to make this work ;)
- ihsw 14y ago
  What's wrong with a whitelist? "Example.com has requested 1KB/5MB of your disk so it can remember its place. [Allow]"
  - derefr 14y ago
    Because almost every site uses cookies, and almost all cookies are friendly (not "tracking cookies.") It would be a large decrease in user convenience to make them have to accept every cookie ever. Not only that, website owners are incentivized to actively subvert whitelist-based policies: shady sites would paint arrows up to the "Allow" button saying "click this to continue!", doing iframe AJAX ping-pong to verify you've given them the persistence they want before they let you through, and so forth. And even if they didn't, the request would still become one of those things naive users think you just "have to click OK to if you want the computer to keep doing the thing"--like Windows UAC elevation. On the other hand, giving users an equivalent option to a "hellban" on a website--the ability to make the website think it's persisting, but then it turns out not to be--has far fewer incentives. It only ends up being something you click for a reason, rather than a "mother may I" you have to just click all the time, and since getting off the blacklist wouldn't be exposed directly through the browser chrome, there'd be nowhere for a malicious site to "point an arrow."
    - Nursie 14y ago
      "almost all cookies are friendly" I would really dispute this. Compare the number of sites visited to the number of ad-tracking cookies stored in the average browser, I think you'll find a very different answer.
      - derefr 14y ago
        If you consider ad-tracking cookies set by sites {A,B,C} to be read by ad-provider X all "one cookie", then the numbers balance out. (Which I would--tracking cookies, semantically, should be considered to be stored in the ad-provider's "bucket", as far as allowing them/purging them goes.
        Nursie 14y ago
        If you consider ad-tracking cookies set by sites {A,B,C} to be read by ad-provider X all "one cookie" I'm not really sure what you mean by this. You said "almost all cookies are friendly" and I'm pretty sure you're wrong. Even if the numbers 'balance out' (which I doubt very much) that's still not close to 'almost all cookies are friendly'. The pro-cookie side of the privacy debate really needs to just admit there's a problem here, then we can work together to try and ensure privacy and functionality, without making reckless assumptions that somehow tracking is sanctioned or providing value to the user without even the courtesy of asking.
        deleted 14y ago
        [deleted]
      - lowboy 14y ago
        How about "almost all first-party cookies are friendly"?
- magic_haze 14y ago
  This is pretty much what Chrome does, grouping everything under "site data". It also shows you flash cookies, though as far as I know, it doesn't show you its contents and doesn't let you block them through the third-party controls. A rather strange system.
  - derefr 14y ago
    Chrome gets about a 6/10 for this. Client certs, for at least one thing, aren't included in "site data" (it needs to be everything or it stops being an abstraction!); and for the mechanisms it does prompt for (only a few--again, making the abstraction leak), Chrome uses a whitelisting rather than blacklisting approach, which has the failure modes I mentioned in my other comment below.
- mike-cardwell 14y ago
  You could still use the plain old browser web cache to track users. Send a unique image to each user with a long expiry time with an id embedded in it somewhere, then on the page, simply read the image using javascript/canvas to get the id.
  - derefr 14y ago
    > send a unique image ... with a long expiry time For any given mechanism, if it has different behavior between an ephemeral session and a regular, persistent one, it should trigger the warning bar. Browser caching with distant Expires is definitely one of those. In this case, disallowing the persistence would make all the retrieved resources instead have session-length cache expiry. Think of the full effect of the warning bar + "Disallow" button as going back and pretending you had opened the page in an Incognito/Private Browsing mode tab from the start--and then making that also happen automatically for any further pages from that domain. It session-isolates caching, cookies, and basically any other form of persistence except explicit bookmarking.
jlebar 14y ago
Merely making an HTTP request to a site -- any HTTP request, as far as I'm aware -- is sufficient for that site to set a cookie on your machine. If on the other hand the site wants to store something in localstorage, the site has to run JS on your machine. That's a much higher bar.
- ferongr 14y ago
  It's a bit disingenuous to make such a claim. The bar is essentially the same since browsers execute all, 1st and 3rd-party JS by default. Loading a document is enough. For a web-browser it's quite rare to make requests without completing the transfer. The bar is essentially the same and the changes that privacy-invading 3rd party scripts have to do to bypass the Firefox's implementation are minimal, so Mozilla may as well not make any triumphant claims until this glaring issue is fixed.
  - jvm 14y ago
    > The bar is essentially the same since browsers execute all, 1st and 3rd-party JS by default. Not mine :-) (But point taken)

by ferongr 14y ago

derefr 14y ago

It really seems like all the things browsers do to allow sites to persist data on your computer (cookies, client certificates, localStorage, WebSQL/IndexedDB, the FileSystem storage API, HTML5 Application Caching...) should all be controlled by a single set of preferences/request dialogs. They wouldn't even need to break down the requests by type; it's pretty irrelevant to a user which kind of storage is going on. Combining this with a "forgiveness is better than permission" principle (which seems to be sorely lacking in web browsers, other than a few just-plain-strange places like alert() dialogs), the best UX might just be a warning bar stating "Example.com has reserved 1KB/5MB of your disk so it can remember its place. [Disallow]" Disallowing would make the site think it still has a permanent store, but internally replace it with an ephemeral one (FS::TEMPORARY, session cookie, etc.) This also might make browser makers get off their lazy butts and make ephemeral versions of the rest of these mechanisms, to make this work ;)

ihsw 14y ago
What's wrong with a whitelist? "Example.com has requested 1KB/5MB of your disk so it can remember its place. [Allow]"
- derefr 14y ago
  Because almost every site uses cookies, and almost all cookies are friendly (not "tracking cookies.") It would be a large decrease in user convenience to make them have to accept every cookie ever. Not only that, website owners are incentivized to actively subvert whitelist-based policies: shady sites would paint arrows up to the "Allow" button saying "click this to continue!", doing iframe AJAX ping-pong to verify you've given them the persistence they want before they let you through, and so forth. And even if they didn't, the request would still become one of those things naive users think you just "have to click OK to if you want the computer to keep doing the thing"--like Windows UAC elevation. On the other hand, giving users an equivalent option to a "hellban" on a website--the ability to make the website think it's persisting, but then it turns out not to be--has far fewer incentives. It only ends up being something you click for a reason, rather than a "mother may I" you have to just click all the time, and since getting off the blacklist wouldn't be exposed directly through the browser chrome, there'd be nowhere for a malicious site to "point an arrow."
  - Nursie 14y ago
    "almost all cookies are friendly" I would really dispute this. Compare the number of sites visited to the number of ad-tracking cookies stored in the average browser, I think you'll find a very different answer.
    - derefr 14y ago
      If you consider ad-tracking cookies set by sites {A,B,C} to be read by ad-provider X all "one cookie", then the numbers balance out. (Which I would--tracking cookies, semantically, should be considered to be stored in the ad-provider's "bucket", as far as allowing them/purging them goes.
      - Nursie 14y ago
        If you consider ad-tracking cookies set by sites {A,B,C} to be read by ad-provider X all "one cookie" I'm not really sure what you mean by this. You said "almost all cookies are friendly" and I'm pretty sure you're wrong. Even if the numbers 'balance out' (which I doubt very much) that's still not close to 'almost all cookies are friendly'. The pro-cookie side of the privacy debate really needs to just admit there's a problem here, then we can work together to try and ensure privacy and functionality, without making reckless assumptions that somehow tracking is sanctioned or providing value to the user without even the courtesy of asking.
        deleted 14y ago
        [deleted]
    - lowboy 14y ago
      How about "almost all first-party cookies are friendly"?
magic_haze 14y ago
This is pretty much what Chrome does, grouping everything under "site data". It also shows you flash cookies, though as far as I know, it doesn't show you its contents and doesn't let you block them through the third-party controls. A rather strange system.
- derefr 14y ago
  Chrome gets about a 6/10 for this. Client certs, for at least one thing, aren't included in "site data" (it needs to be everything or it stops being an abstraction!); and for the mechanisms it does prompt for (only a few--again, making the abstraction leak), Chrome uses a whitelisting rather than blacklisting approach, which has the failure modes I mentioned in my other comment below.
mike-cardwell 14y ago
You could still use the plain old browser web cache to track users. Send a unique image to each user with a long expiry time with an id embedded in it somewhere, then on the page, simply read the image using javascript/canvas to get the id.
- derefr 14y ago
  > send a unique image ... with a long expiry time For any given mechanism, if it has different behavior between an ephemeral session and a regular, persistent one, it should trigger the warning bar. Browser caching with distant Expires is definitely one of those. In this case, disallowing the persistence would make all the retrieved resources instead have session-length cache expiry. Think of the full effect of the warning bar + "Disallow" button as going back and pretending you had opened the page in an Incognito/Private Browsing mode tab from the start--and then making that also happen automatically for any further pages from that domain. It session-isolates caching, cookies, and basically any other form of persistence except explicit bookmarking.

jlebar 14y ago

Merely making an HTTP request to a site -- any HTTP request, as far as I'm aware -- is sufficient for that site to set a cookie on your machine. If on the other hand the site wants to store something in localstorage, the site has to run JS on your machine. That's a much higher bar.

ferongr 14y ago
It's a bit disingenuous to make such a claim. The bar is essentially the same since browsers execute all, 1st and 3rd-party JS by default. Loading a document is enough. For a web-browser it's quite rare to make requests without completing the transfer. The bar is essentially the same and the changes that privacy-invading 3rd party scripts have to do to bypass the Firefox's implementation are minimal, so Mozilla may as well not make any triumphant claims until this glaring issue is fixed.
- jvm 14y ago
  > The bar is essentially the same since browsers execute all, 1st and 3rd-party JS by default. Not mine :-) (But point taken)