You can check out current progress here. Notice the top toolbar (which looks great in my opinion) and beginnings of the HerdictWeb plugin. After some talks with the Berkman Center, we are finally moving forward with the HerdictWeb plugin. We are going to adapt an existing tor connection class we've previously made to allow for HerdictWeb reporting over Tor. On top of this, we are going to give an interactive, side-by-side comparison of the website over Tor and the website over the regular internet connection. In my opinion this is a large security risk (because for Tor, it is) but this is what they want, so this is what they get.
The toolbar may look nice, but its causing a few problems of its own. This is me moving the tabs. Notice the toolbar icons painting over the tab bar? This is a bug in Qt (we assume) involving the use of the setUnifiedTitleandToolBaronMac function for windows. By setting that function to true, we get the chrome statusbar and toolbar. But, when that function is set to true the tabbar gets a fresh coat of toolbar icons painted over it. As far as we can tell, outside of reimplementing parts of patching Qt there is nothing we can do about this. So, mac users can't move tabs! On top of this, when the user stops tor and the toolbar message changes, this happens. Where'd help go? The MainWindow apparantly picks a size for the ToolBar and sticks to it no matter how much space remains in the ToolBar space. Resizing it does nothing to stop this. So, mac users get only icons in the toolbar! And all this only happens if setUnifiedTitleandToolBaronMac is set to true. If this is set to false, these bugs don't occur but the window looks uglier. Decisions, decisions.
Thats all for updating right now. More coming soon!
Wednesday, July 22, 2009
Thursday, July 9, 2009
Significant progress
Its been about a month since I last posted so naturally there are a plethora of updates. As far as the interface goes, it is nearly at the point where it can be pushed aside to worry about other parts of the project. You can view a screen shot of it here. All of the tabs are plugins and the home interface is completely dynamic. The file menu and tray menu also allows plugins to have their own entries meaning the gui interface API is nearly feature complete. Remaining issues as far as that goes include allow plugins to have their own translation files (and subsequently implementing the re-translation API for the plugins) and figuring out how dynamic plugins will link their own platform independent resources.
As far as the API goes, we've had a number of significant design decisions we didn't originally know we were going to have to. Plugins as they stand are hubs for functionality. The home plugin for example includes a panel for viewing the home plugin with the tabbed interface, tray and file menus for quick access to functionality as well the catching and sending of a number of signals to and from the plugin manager. This requires for example the home panel object to be seperate from the home plugin object. Thus, when the home panel wants to send a torStart signal to the Plugin Manager (who handles such requests), the panel calls a function in the home plugin, who calls a function in the plugin manager. Even more awkward, since we want to seperate all of the plugin logic from the main vidalia logic (since we intend on shipping a plugin library to allow for dynamic plugin creation), the plugin manager can't send any messages to MainWindow since they are seperate. However, MainWindow can send messages to the plugin manager. Thus, in order to send a message to MainWindow, the plugin manager needs to emit a Qt signal which MainWindow catches. Any response from MainWindow is done by MainWindow calling a plugin manager function. At first I thought this reeked of terrible design, but then I realized its not too different from the system used by OS's for system calls.
At this point going forward myself and the Vidalia Project will be working on the plugin API and the HerdictWeb plugin simultaneously. There are enough pieces in place that this is easily doable. Hopefully within the next two weeks the HerdictWeb plugin will be nearly complete. Check back in to find out!
As far as the API goes, we've had a number of significant design decisions we didn't originally know we were going to have to. Plugins as they stand are hubs for functionality. The home plugin for example includes a panel for viewing the home plugin with the tabbed interface, tray and file menus for quick access to functionality as well the catching and sending of a number of signals to and from the plugin manager. This requires for example the home panel object to be seperate from the home plugin object. Thus, when the home panel wants to send a torStart signal to the Plugin Manager (who handles such requests), the panel calls a function in the home plugin, who calls a function in the plugin manager. Even more awkward, since we want to seperate all of the plugin logic from the main vidalia logic (since we intend on shipping a plugin library to allow for dynamic plugin creation), the plugin manager can't send any messages to MainWindow since they are seperate. However, MainWindow can send messages to the plugin manager. Thus, in order to send a message to MainWindow, the plugin manager needs to emit a Qt signal which MainWindow catches. Any response from MainWindow is done by MainWindow calling a plugin manager function. At first I thought this reeked of terrible design, but then I realized its not too different from the system used by OS's for system calls.
At this point going forward myself and the Vidalia Project will be working on the plugin API and the HerdictWeb plugin simultaneously. There are enough pieces in place that this is easily doable. Hopefully within the next two weeks the HerdictWeb plugin will be nearly complete. Check back in to find out!
Saturday, June 6, 2009
The past week has been filled with design decisions and UI mockups galore. Check out UI Ideas page for some of the excitement. I've about finished the UI concept and am going to do the UI creation and initial coding in the next week. The plugin API has been thought out sufficiently well. Essentially there will exist interfaces for:
- Tray context menu entries
- Panel entries
- Widgets
- File menu entries
- Preference menus
- Weeks 1 -- 4 (May 4 through May 31)
- May 4 -- Rensselaer Center for Open Software officially begins
- Weeks 5 -- 6 (June 1 through June 14)
- Lay out revised UI to support extensions with visible interfaces
- Move existing UI elements into the new format
- Weeks 7 -- 9 (June 15 through July 5)
- Specify extension API
- Determine if any changes to existing torcontrol library need to be made
- Implement initial extension API support
- Document the API both in Doxygen and on this wiki page
- Specify extension API
- Week 10 (July 6 through July 12)
- Herdict Plugin
- Tray icon menu entry for "Report blocked URL"
- Dialog to enter URL
- Submits to HerdictWeb via Tor
- Need to work with the Herdict folks to determine correct API
- Anything else the Herdict folks would like to see? They seemed to have pretty minimal ambitions here.
- Herdict Plugin
- Week 11 (July 13 through July 19)
- Move existing Windows TBB functionality into a plugin
- Weeks 12 -- 13 (July 20 through August 2)
- Add OS X support to the TBB plugin
- Week 14 (August 3 through August 9)
- Analyze for traces left behind on an OS X system
- Minimize any traces found
- August 7 -- Rensselaer Center for Open Software summer program ends
- Analyze for traces left behind on an OS X system
Wednesday, May 20, 2009
Starting things off
It's great to be a part of RCOS (http://rcos.cs.rpi.edu/) for another summer! First I just want to say thank you to Sean O'Sullivan '85 . Without his support none of the projects this year would be possible. Furthermore, I would also like to thank Professor Moorthy for my selection.
As far as a schedule goes, a tentative one would be:
Completion of UI Design for Plugin System display: Mid June
Completion of Plugin API design decision: End of June
Completion of Plugin System: End of July
Completion of HerdictWeb plugin: End of August
Speaking with the people from the Berkman Center (http://cyber.law.harvard.edu/), it seems that although many ideas have been thrown out there, a simple reporting system is all that is requested. Such a system would still drastically increase the security of reporting especially when combined with https. Thus this plugin shouldn't take much time. To compensate, I will also be working on the extension of Vidalia for the purpose of a Tor browser bundle for Mac OSX. Such a bundle would allow tight integration of anonymity into the browsing experience to allow for deployment on thumb drives everywhere.
Anyway, I'm excited to get the project done with the help of the Vidalia project. Check back for updates!
As far as a schedule goes, a tentative one would be:
Completion of UI Design for Plugin System display: Mid June
Completion of Plugin API design decision: End of June
Completion of Plugin System: End of July
Completion of HerdictWeb plugin: End of August
Speaking with the people from the Berkman Center (http://cyber.law.harvard.edu/), it seems that although many ideas have been thrown out there, a simple reporting system is all that is requested. Such a system would still drastically increase the security of reporting especially when combined with https. Thus this plugin shouldn't take much time. To compensate, I will also be working on the extension of Vidalia for the purpose of a Tor browser bundle for Mac OSX. Such a bundle would allow tight integration of anonymity into the browsing experience to allow for deployment on thumb drives everywhere.
Anyway, I'm excited to get the project done with the help of the Vidalia project. Check back for updates!
Subscribe to:
Posts (Atom)