GSoC2k9 - Torbutton Feature Fulfillment - Kory Kirk
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 )
tor-protocol component 
Saturday, May 30, 2009, 02:18 PM
Posted by Administrator
For the tor-protocol component, I had the help of a confusing tutorial and its corrections. I have a good start on it, I believe everything I need for this component is there. I took the skeleton code from the example, appropriately changed variables - got a new CID and a few other tweeks. I also fixed some things in the code mentioned in the corrections. - here is my first version.

add comment ( 20 views )
Part 1: The plan 
Thursday, May 28, 2009, 03:21 PM
Posted by Administrator
Rough start, as I have been extremely busy with non-GSoC stuff the past few days, had to move out of my house and take care of some other stuff. But luckily from the depths of that business came the outline of the development plan for the feature that I am going to implement in Torbutton. That is the tor:// protocol association.

In order to do this, I am going to utilize the XPCom interface NSIProtocolHandler. Which is Mozilla's way of incorporating a protocol into its framework. So first of all I need to create a component that implements this interface.It seems I will only have to implement 3 methods from NSIProtocolHandler - newURI(), newChannel(), allowPort(). The implementation of this object seems pretty straight forward.

I will then make an observer to take action anytime the tor:// protocol is called. When it is called, we are going to have a dialogue box come up for confirmation. If the user says that it is okay to enable tor, then tor will start up, and after it has been enabled the extension will request and view the uri.

This is just a brief outline, and I imagine there will be many unforeseen complications - I will be filling in the gaps as I go along.

1 comment ( 23 views )

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