Delete the proxy opt-in cookie, don't set it to 0
When someone clicks the "Yes" button, we set a never-expiring cookie with snowflake-allow=1.
When someone clicks the "No" button, we do the same, except with snowflake-allow=0.
We should instead delete the cookie when someone clicks "No".
Activity
We refactored the proxy implementation in the process of adding a webextension (#23888 (moved), #30934 (moved)). A part of this refactor was to not rely on the use of cookies for the webextension. We can probably just apply that refactor here, along with other changes to spruce up the look of the snowflake badge.
Trac:
Owner: N/A to cohosh
Cc: dcf, arlolra to dcf, arlolra, cohosh, phw
Status: new to assigned
Parent: N/A to #27385 (moved)Replying to cohosh:
We refactored the proxy implementation in the process of adding a webextension (#23888 (moved), #30934 (moved)). A part of this refactor was to not rely on the use of cookies for the webextension. We can probably just apply that refactor here,
The original idea behind the badge (and why it's called a "badge") was that would be an unobtrusive iframe posted on various web pages that you would just activate incidentally while browsing. In that model, I don't see how you can dispense with a cookie. You would have to click and reactivate something on every page the badge might be on.
But I'm also fully prepared to believe that the many-sites "badge" model, while it may have made sense for the opt-out flash proxy, doesn't make sense for the opt-in Snowflake. The number of third-party sites hosting the Snowflake badge is approximately zero, and if you intersect that with the number of users who have (1) opted in and (2) are currently incidentally browsing one of those sites, the number is not even approximately zero. Therefore I don't think there's a problem with hosting a single web page with a toggle (and removing the iframe instructions), and instructing people to visit the page and click the toggle. Just pointing out that it's a change from how the system has been assumed to work until now.
-
Replying to dcf:
Replying to cohosh:
We refactored the proxy implementation in the process of adding a webextension (#23888 (moved), #30934 (moved)). A part of this refactor was to not rely on the use of cookies for the webextension. We can probably just apply that refactor here,
The original idea behind the badge (and why it's called a "badge") was that would be an unobtrusive iframe posted on various web pages that you would just activate incidentally while browsing. In that model, I don't see how you can dispense with a cookie. You would have to click and reactivate something on every page the badge might be on.
But I'm also fully prepared to believe that the many-sites "badge" model, while it may have made sense for the opt-out flash proxy, doesn't make sense for the opt-in Snowflake. The number of third-party sites hosting the Snowflake badge is approximately zero, and if you intersect that with the number of users who have (1) opted in and (2) are currently incidentally browsing one of those sites, the number is not even approximately zero. Therefore I don't think there's a problem with hosting a single web page with a toggle (and removing the iframe instructions), and instructing people to visit the page and click the toggle. Just pointing out that it's a change from how the system has been assumed to work until now.
Ah that explains a few things. I'm happy to leave the badge as a cookie-based "opt-in once for everywhere" way of participating in snowflake. I think the UI changes in #27384 (moved) would help users remain reasonably informed by their participation across various sites.
Overall though, the webextension seems to have a lot more potential for longer-lived, more stable, and more informed user participation... do we even want to keep the badge around?
Replying to cohosh:
Ah that explains a few things. I'm happy to leave the badge as a cookie-based "opt-in once for everywhere" way of participating in snowflake. I think the UI changes in #27384 (moved) would help users remain reasonably informed by their participation across various sites.
Overall though, the webextension seems to have a lot more potential for longer-lived, more stable, and more informed user participation... do we even want to keep the badge around?
I think there's value in having a web page that people can visit to become a proxy without having to install an extension. The distributed-badge thing is comparatively much less useful. I agree that of the possibilities, the WebExtension has the most promise and should be prioritized.
-
Replying to dcf:
I think there's value in having a web page that people can visit to become a proxy without having to install an extension. The distributed-badge thing is comparatively much less useful. I agree that of the possibilities, the WebExtension has the most promise and should be prioritized.
Okay after looking at this a bit, I'm not sure we can use
local.storageoutside of the extension context so we'll probably have to use cookies anyway. I'll see what I can do to apply the refactors that were used in the webextension implementation to the badge with the only difference being checking the cookies instead of storage.And then the next steps are:
- UI overhaul of the badge (#27385 (moved)) using the design decisions made in the webextension
- UI overhaul of the [snowflake.torproject.org] site
-
Trac:
Parent: #27385 (moved) to N/A 
This was fixed in #27385 (moved)
+// Defaults to opt-in. +var COOKIE_NAME = "snowflake-allow"; +var COOKIE_LIFETIME = "Thu, 01 Jan 2038 00:00:00 GMT"; +var COOKIE_EXPIRE = "Thu, 01 Jan 1970 00:00:01 GMT"; + +function setSnowflakeCookie(val, expires) { + document.cookie = `${COOKIE_NAME}=${val}; path=/; expires=${expires};`; +} ... + document.getElementById('enabled').addEventListener('change', (event) => { + if (event.target.checked) { + setSnowflakeCookie('1', COOKIE_LIFETIME); + } else { + setSnowflakeCookie('', COOKIE_EXPIRE); + } + update(); + })Trac:
Resolution: N/A to fixed
Status: assigned to closed
