148
edits
Cookies:prompting ui: Difference between revisions
→How do we make it more better?
| Line 33: | Line 33: | ||
* Or we could blanket accept. We'd want to sandbox the cookies for the page (per tab), so each tab gets a "fresh" cookie store and there's little to no tracking going on. So we'd load the page with all its cookies, and if a user later decides to reject them we do nothing - they'll get thrown away with the sandbox. If they accept them (or it's whitelisted) then we unsandbox them and overwrite any duplicate cookie in the main cookie store. This would get around sites that like to give "you must turn on cookies" warnings, but would still suck for sites that want logins. There would also be ordering problems: say you load twenty tabs from the same site in the background, then click through accepting cookies randomly... the site could be trying to set the same session cookie twenty times, which one do we keep? This isn't any worse than the blocking dialog situation though, so a minor issue. If the user accepts a cookie and there's one already in the main cookie store, we probably want to throw away the new one and use the main one (e.g. logins). | * Or we could blanket accept. We'd want to sandbox the cookies for the page (per tab), so each tab gets a "fresh" cookie store and there's little to no tracking going on. So we'd load the page with all its cookies, and if a user later decides to reject them we do nothing - they'll get thrown away with the sandbox. If they accept them (or it's whitelisted) then we unsandbox them and overwrite any duplicate cookie in the main cookie store. This would get around sites that like to give "you must turn on cookies" warnings, but would still suck for sites that want logins. There would also be ordering problems: say you load twenty tabs from the same site in the background, then click through accepting cookies randomly... the site could be trying to set the same session cookie twenty times, which one do we keep? This isn't any worse than the blocking dialog situation though, so a minor issue. If the user accepts a cookie and there's one already in the main cookie store, we probably want to throw away the new one and use the main one (e.g. logins). | ||
Doing two pageloads some fraction of the time would use more bandwidth. It's better for the case where a user opens many tabs in the background, but probably worse for the case where they do all their browsing in one tab. (There's an extension called [http://www.umeshshankar.com/doppelganger/ doppelganger] that takes this one step further, and concurrently loads a link i) with cookies and ii) without cookies, compares the data served up, and enables or disables cookies based on whether the content differs.) | Doing two pageloads some fraction of the time would use more bandwidth. It's better UX for the case where a user opens many tabs that don't need cookies in the background, but probably worse for the case where they do all their browsing in one tab. (There's an extension called [http://www.umeshshankar.com/doppelganger/ doppelganger] that takes this one step further, and concurrently loads a link i) with cookies and ii) without cookies, compares the data served up, and enables or disables cookies based on whether the content differs.) | ||
Maybe we could use infobars in a sync way? Just make the dialog a nonmodal infobar instead so it's less intrusive? Not sure if this can be done, but basically falls under 1) and amounts to timeless' rant linked above. | Maybe we could use infobars in a sync way? Just make the dialog a nonmodal infobar instead so it's less intrusive? Not sure if this can be done, but basically falls under 1) and amounts to timeless' rant linked above. | ||