GSoC2k9 - Torbutton Feature Fulfillment - Kory Kirk
Two link context options 
Sunday, July 19, 2009, 04:08 PM
Posted by Administrator
Today I committed some code for two link context menu options. The first one copies the url of the link to the clipboard and changes the scheme to tor. The second opens the url with the tor scheme in a new tab. Both of these are additions to the tor:// protocol implementation.

The next step is for the implementation of finer cookie control. This also begs the question of separate identities and a person can choose what cookies stay in an identity. As for the finer cookie control, I am going to look towards the CookieCuller code, and modify the UI for our purposes.
add comment ( 18 views )
Midterm Update 
Wednesday, July 8, 2009, 12:50 PM
Posted by Administrator
I filled out my midterm evaluation form a few days ago. From my original plan, I am on track with my progress. Today I committed the initial release of the referer spoofing feature. I implemented it as I had described in the previous entry.

note: "referer" is actually spelled referrer, according to US English, but in http headers it is spelled referer. Spelling fail?

I still have some things to work out with both the tor/s:// protocols and ref spoofing before they can be released. And I am hoping to have time to do a few bug fixes and maybe a another feature or two.
add comment ( 18 views )
Front end and refresh spoofing 
Sunday, June 28, 2009, 12:01 PM
Posted by Administrator
For the preferences, I have added a radio button group to the headers tab of the security settings tab of the preferences. This group contains options for different modes of referer spoofing, the four modes available are:
- Spoof root of the site (spoofs the referer as the directory the page your are accessing it from)
- Spoof site's domain (spoofs just the domain part not the path)
- Spoof no referer
- No spoofing

I am thinking that the default will be spoof site's domain. I am also adding a feature called "fake refresh," which is a check box that will spoof every request as if you were already on the page and calling a refresh. This sends the basic get request to the server, but we include an additional "is modified" header which has a time value. I will need to work out a time value that will not break pages, and I am not sure if that parameter really matters with refreshes, but we shall see.

add comment ( 20 views )
Referer Spoofing and more 
Monday, June 22, 2009, 03:12 PM
Posted by Administrator
I can't believe it has been 20 days since I have last updated this blog. I feel like a bad GSoC'er. But, can't be helped. Firstly I have my own SVN branch now, that I use to update my code - you can see it here. I have added the tor:// and tors:// protocols and their handling, although there are a number of instances which enable Tor that I want to get rid of. I made some tests here, I am going to assimilate some of cssblocker's code to find the origin of the protocol calls and then disable it.

Most recently, I have been working on the referer spoofer. In extension development, a lot of functional code is available from other extensions. But for this one, I tried to start from the ground up. I used some code in the extension RefControl as a guideline, but mainly based my code around an http-on-modify-request observer example that I found from MDC. Anyway, the basic functionality is now working, after a few days of trying to pinpoint some silly bugs. I am going to add a few more things to it and then add it to the svn later today.
add comment ( 24 views )
nsIProtocolHandler and nsIIOService correct implementation for Torbutton 
Tuesday, June 2, 2009, 03:19 PM
Posted by Administrator
Thanks to some direction from my mentor, Mike, I feel much more comfortable with this step of the project. I have rewritten the newURI and newChannel functions:

newURI: function(spec, charset, baseURI)
const nsIStandardURL = Components.interfaces.nsIStandardURL;
var uri = Components.classes[";1"].createInstance(nsIStandardURL);
uri.init(nsIStandardURL.URLTYPE_STANDARD, 80, spec, charset, baseURI);

return uri.QueryInterface(Components.interfaces.nsIURI);


newChannel: function(aURI)
/*The protocol has been called, therefore we want to enable tor, wait for it to activate return the new channel with the scheme of http.*/
var ios = Components.classes[kIOSERVICE_CONTRACTID].getService(nsIIOService);
if (!ios.allowPort(aURI.port, aURI.scheme))
throw Components.results.NS_ERROR_FAILURE;

//this is where I need to turn tor on, I am going to wait to talk to Mike a little to add these parts

//if tor is turned on then, else we should throw exception of some sort.
aURI.scheme = "http";
return ios.newChannelFromURI(aURI);

Instead of parsing the uri by hand, nsIStandarURL does that for us. The nsIURI MDC page says that the proper way to parse a uri is through the IOService function, newURI(), but that method just calls the newURI() function from the scheme's protocol handler, so it would have caused an infinite loop. The newChannel code is not finished, I want to learn a little bit more about the 3 step Tor activation process that Torbutton uses before I go ahead and fill that part in. But the channel just makes sure that the scheme allows the port, and then changes the scheme to http and creates the channel based upon that. I believe this will work, because the newChannelFromURI uses the newChannel method for the scheme's protocol handler - which in this case will be http.

The updates are reflected in

p.s. the format of that code is ugly, sorry
1 comment ( 19 views )

<Back | 1 | 2 | Next> Last>>