148
edits
Cookies:prompting ui: Difference between revisions
→How do we make it more better?
| Line 29: | Line 29: | ||
2) Switch to an async approach, like infobars. We could have a single dropdown infobar that appears in the tab during pageload, listing all the cookie requests and offering checkboxes for which ones you want to allow or block, and a button to apply those choices. This would let us do some nice display magic too, since we now have knowledge of all the cookies at once and we can collapse/group/nest the display as appropriate. The big problem with async is that we're doing the pageload without knowing the user's choices, so we have to assume something, and then reload the page when the user has made them (if they differ from our assumptions). | 2) Switch to an async approach, like infobars. We could have a single dropdown infobar that appears in the tab during pageload, listing all the cookie requests and offering checkboxes for which ones you want to allow or block, and a button to apply those choices. This would let us do some nice display magic too, since we now have knowledge of all the cookies at once and we can collapse/group/nest the display as appropriate. The big problem with async is that we're doing the pageload without knowing the user's choices, so we have to assume something, and then reload the page when the user has made them (if they differ from our assumptions). | ||
For instance, we could assume a blanket reject: load the page without any cookies, make a list of all the requests, and let the user twiddle them. This would work great for sites that don't really need cookies, but would suck for sites that require logins. (Whitelisting can kick in here though, and allow those cookies during initial pageload.) It's also good from a privacy perspective, since the user that uses prompting probably would prefer blanket reject to begin with. | * For instance, we could assume a blanket reject: load the page without any cookies, make a list of all the requests, and let the user twiddle them. This would work great for sites that don't really need cookies, but would suck for sites that require logins. (Whitelisting can kick in here though, and allow those cookies during initial pageload.) It's also good from a privacy perspective, since the user that uses prompting probably would prefer blanket reject to begin with. | ||
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. | * 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. | 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. | ||
Maybe we could use infobars in a sync way? Just make the dialog an infobar instead so it's less intrusive? Not sure if this can be done, but basically falls under 1). | Maybe we could use infobars in a sync way? Just make the dialog an infobar instead so it's less intrusive? Not sure if this can be done, but basically falls under 1). | ||