Opened 7 months ago

Last modified 2 weeks ago

#28917 assigned enhancement

Delete the proxy opt-in cookie, don't set it to 0

Reported by: dcf Owned by: cohosh
Priority: Medium Milestone:
Component: Circumvention/Snowflake Version:
Severity: Normal Keywords:
Cc: dcf, arlolra, cohosh, phw Actual Points:
Parent ID: #27385 Points:
Reviewer: Sponsor:

Description

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".

Child Tickets

Change History (6)

comment:1 Changed 6 months ago by arma

Yes, this sounds like a smart thing to do.

comment:2 Changed 2 weeks ago by cohosh

Cc: cohosh phw added
Owner: set to cohosh
Parent ID: #27385
Status: newassigned

We refactored the proxy implementation in the process of adding a webextension (#23888, #30934). 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.

comment:3 in reply to:  2 ; Changed 2 weeks ago by dcf

Replying to cohosh:

We refactored the proxy implementation in the process of adding a webextension (#23888, #30934). 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.

comment:4 in reply to:  3 ; Changed 2 weeks ago by cohosh

Replying to dcf:

Replying to cohosh:

We refactored the proxy implementation in the process of adding a webextension (#23888, #30934). 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 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?

comment:5 in reply to:  4 ; Changed 2 weeks ago by dcf

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 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.

comment:6 in reply to:  5 Changed 2 weeks ago by cohosh

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.storage outside 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) using the design decisions made in the webextension
  • UI overhaul of the [snowflake.torproject.org] site
Note: See TracTickets for help on using tickets.