[tor-bugs] #7063 [Flashproxy]: Make a query parameter to control opt-in/opt-out
Tor Bug Tracker & Wiki
blackhole at torproject.org
Thu Dec 20 01:09:09 UTC 2012
#7063: Make a query parameter to control opt-in/opt-out
-------------------------+--------------------------------------------------
Reporter: dcf | Owner: dcf
Type: enhancement | Status: needs_revision
Priority: major | Milestone:
Component: Flashproxy | Version:
Keywords: | Parent: #7166
Points: | Actualpoints:
-------------------------+--------------------------------------------------
Comment(by dcf):
I pushed a copy of the branch with some changes to
https://git.torproject.org/user/dcf/flashproxy.git branch opt-in.
Replying to [comment:4 aallai]:
> Tested in Chrome, Safari, IE 9 and Firefox. I just remembered IE < 8
uses attachEvent instead of addEventListener, so we don't support them
yet. I should fix that up tomorrow.
Perhaps a `onload` and `onclick` handlers are better than
`addEventListener`? I hate to have compatibility code for something this
trivial.
> - Name and expiration date on the cookie. These are variables in
options.js.
Let's call the cookie `flashproxy-allow`. The value is `0` or `1`.
Expiration date should be never, or as close as we can get to it. If
someone opts out, they want to stay opted out. Same for opt-in.
> - Where the options page is hosted. Right now the link assumes it is in
the same directory as the embed.html/flashproxy.js files.
That's good, leave it there.
> - top-gradient.gif is an image used for the background of
crypto.stanford.edu. Don't know if we want non-essential images in the
repository.
I just deleted this file. You are right, I don't want files like this in
the repository.
> - Pop-up window. I noticed IE has a handy option to keep javascript from
opening windows. I don't know how many people have this turned on, but I
went for a regular link to be safe.
Okay, but how about linking with `target=_blank` to create a new window?
----
Other things to please do:
* The cookie needs to have three states: true, false, and unset. Clicking
"No" shouldn't delete the cookie; it should keep it but with a false
value. The reason for this is that I plan to change what the default is in
`flashproxy.js`. Currently, if no cookie is present, the proxy will run,
but that will probably change. However, if a "flashproxy=false" cookie is
present, the proxy won't run, regardless of what the default is.
* Put the options JavaScript code in `options.html` and delete
`options.js`. The code is simple enough that I think it's easier if it's
not in a separate file.
* Kill all the `disable_button` code. The options page is going to
replace it completely. Your commit should delete at least as much code as
[https://gitweb.torproject.org/flashproxy.git/commitdiff/008bc8013eb2db6d11e6ac4bf3e814b62c1a4a51
008bc801] added.
* Modify `flashproxy.js` to honor the cookie. If true: run. If false:
don't run. If cookie disabled or not present: run.
* Add an opt-in-only mode to `flashproxy.js`. Add a boolean query string
parameter `cookierequired`. If true, the rules become: If true: run. If
false: don't run. If cookie disabled or not present: don't run.
In general, I don't care very much about compatibility with old browsers.
IE 8 can't even be a flash proxy, so it's not worth doing anything to
support it. It's nice if it fails closed; i.e., doesn't say that you will
be a proxy when you can't, but it isn't critical. Certainly it's not worth
user-agent sniffing or anything like that.
This looks like a good link for safe cookie operations with escaping:
https://developer.mozilla.org/en-US/docs/DOM/document.cookie.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7063#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list