Hi Garrett, hi Tails/Tor/EFF folks, Garrett, here is my first bunch of questions to you. I aim at helping you improve your proposal during the very small amount of time that's left.
> 2. Research existing tools the are used to edit metadata. There are > numerous proprietary tools designed for lawyers, law enforcement > and so on. Some open source tools that I found through research > are Phil Harvey’s ExifTool, Sounds like you did not finish this sentence. What do you think of the Hachoir [0] library? [0] http://bitbucket.org/haypo/hachoir/wiki/hachoir-parser > 3. Identify a set of file formats the will be processed by the > project by the end of the summer. Current ideas are: Office > document formats, PDF, Image Formats (jpg, png, gif, tiff, > raw) and Camera Formats (many are proprietary). I mostly agree with this list of file formats; can you please state in what order you plan to implement those? I'd like to read your goals as part of your proposal. > 4. Design an API or similar framework to allow new file formats to > be supported by the program without needing to add to the source > code. I do appreciate you take at heart the future extensibility of the program. But... I am unsure about the "without needing to add to the source code" part. I might be misunderstanding what you mean. On the one hand, you're talking of an API; which is by definition intended to be used by other programs. On the other hand, I more or less understand an implicit "adding features without programming" behind some parts of your proposal. Can you please expand a bit on this topic? In case you really mean "adding features without programming", as the "specification for file metadata" + "rules" parts of your proposal seem to indicate, I think it is a bit over-engineered. Don't you fear designing and implementing this can eat a bit too much of the three months? Do you really think you can achieve that during the first three weeks? Your code samples don't display the kind of experience I think is needed to attack this problem is such an abstract way with confidence the results will be practically useful. > 5. Write the code. I envision this program being available both > as a command line tool and as a simple GUI. Focus on the > command line program first, and build the GUI on top of it. Do you really mean building the GUI on top of the command-line program? In my experience, doing so is pretty hard and inelegant once you take error handling into account, considering the limitations a command-line program encounters when it needs to express in a structured way how/why a failure happened. If the command-line tool was already existing, I may agree the design you are proposing is the way to go. But this is not the case, and you are given the chance to e.g. put most of the code into a library that could be used by both the command-line tool and the GUI, which would probably make your code much easier to unittest and the GUI much easier to implement. What do you think? > Timeline: > Pre-SoC: Research identifying issues with metadata. Pick a few key > formats to focus on and research them, find specifications, figure > out how they store metadata and how it can be safely altered or > removed. Pick one random format and write a program to clear its > metadata, to get an idea of the challenges and process involved. Ok. I'll add some notes bellow on other things that you may want to deal with at this time. > Week 1-2: Design a specification for file metadata. How can we > create “rules” for locating and removing metadata depending on > filetype? I already expressed my bad gut feelings about the "filetype specification + rules" thing so I won't repeat myself here. > Week 3: Begin writing a command line program that can use a filetype > specification to clean metadata from documents of that type. Focus on > getting this to work with one filetype specification and just a > handful of essential command line options. Also investigate > verification - how can I be confident there is no metadata left in the > file, or that the program has worked? Initial focus on supporting one file format to start with: great. Great to see you thought of verification; however, when do you plan do go further than "investigate" on this topic? > Week 4: Expand command line options to include useful features like > batch processing, verbose/force options, and viewing of metadata as > well as deleting it. Deleting or replacing it with a common data set shared by all users of this toolkit, so that the biggest possible Anonymity Set is created? See the tails-dev mailing-list archives in the last few days for recent discussion about this topic. > Week 5-6: Add more filetype specifications to the program, and test > them on a variety of inputs. Focus on a few core document types: > Office Documents, PDF, and Image Files seem to be the most important. > Week 7-8: Develop a GUI for the software that will make it accessible > to those not working on the command line. The GUI should allow files > to be selected, metadata to be viewed, and then cleared, with various > options such as choosing a location for the cleared copy, etc. > Week 10: Address portability and packaging. I'm not comfortable with addressing such matters this late. Portability (quoting myself - tails-dev, few days ago): "[...] for the Windows and OSX support: in my humble opinion, if you really want this requirement to be part of your project, you need to carefully choose the libs you use with this in mind right from the start. Starting to port the code to these platforms after 1.5 months spent writing it is, IMHO, very much optimistic." Anyway. I'd like to read what your portability and packaging plans are. I'll quote myself on the packaging topic too, since I explained this to another student on the tails-dev mailing list a few days ago. Please note that this GSoC project idea was submitted by Tails; if your proposal is accepted, your mentor will be a Tails developer; a goal could be to write a tool that we can install into Tails at the end of the summer. So: 1. In order to be properly installable in Tails, your set of tools will need to be packaged for Debian, i.e. we should at least be able to prepare custom .deb packages from your code. You do not necessarily need to plan preparing the Debian packages yourself, especially if you don't know Debian packaging yet (do you?). Nor do you need to care that much about having the software uploaded to Debian: filing a RFP bug should be enough from your side. Well, I'd be delighted if you would integrate these tasks as part of your summer schedule if you feel this is realistic, but don't worry too much if you feel you can't. 2. In order to make sure your code can be used in Tails, making sure you pick tools and libraries that are available in Debian Squeeze (+ squeeze-backports) is a must and should not be a late requirement. Also, when do you plan to start testing your code inside of Tails? I suggest doing this on a regular basis, e.g. once a week or once every two weeks, to make sure you don't go a wrong way for too long. > Week 11: Hunt down bugs and squash them. > Week 12: Documentation, specification, plan for future maintenance. Design and/or end-user documentation? Specification == ??? (the only way I understand it, it does not make sense, so I am probably misunderstanding). > 1. Project status after the summer > My goal for the summer is to have the command line version of the > program complete and ready to use. I also plan to have made serious > progress on the GUI - an ideal goal would be to complete one, but in > my experience there are a lot of kinks to be worked out when > designing effective GUIs for cross-platform applications. I'd rather see you give up a few tasks (e.g. supporting less file formats initially, less operating systems, or giving up the "adding support for new formats without programming feature") in order to have enough time to deliver a GUI we can ship in Tails at the end of the summer. To be honest, a common pitfall of GSoC projects is to be left in a promising but not practically usable state at the end of the summer. While you seem eager to go on working on this toolkit after the GSoC period is over, I'd rather not depend on this. > After the summer, the program will probably benefit from > improvements to the GUI and adding support for additional file types > (via the API, so anybody can easily contribute). I would be happy to > continue to work on and maintain the project for as long as it is > useful - I really want to get it out there and into the community if > there is a desire to see something like this! Glad to hear this! > 1. Mentoring and Management > I forsee this project as being a relatively independent endeavor. Of > course I would highly value the guidance of a mentor, but I do not > think I would need to be closely supervised. I am highly motivated, > a dedicated worker, and a careful and thorough problem solver. There > is also no existing code base, which would ease some of the > difficulties and requirements for oversight related to working on an > existing project. I fully understand you were not aware this was a project idea proposed by Tails. I'd now like to know how much you are interested into taking into making the "be installable in Tails at the end of the summer" goal part of your proposal, as I have been suggesting in different places of this email. Time for random questions. What language do you intend to use to implement this project? All of your code samples are in Python, so I guess this is it, but IMHO it should be made explicit. Is this the language you are the most at ease with? Have you ever written (or participated in writting) bigger Python programs than the ones you mentioned? (I could understand many reasons why you could be unwilling / unable to show such programs to us, but I'd like to know a bit more about your past programming experience if you don't mind.) What toolkit do you intend to use for the GUI? Please note that using PyGTK would ease integrating it into Tails. You don't mention l10n/i18n as part of your proposal. Could you please consider making it explicit the code will be l10n/i18n-ready? Do you plan to write unittests during the development process? If so, when? Bye, -- intrigeri <[email protected]> | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | So what? _______________________________________________ tails-dev mailing list [email protected] https://boum.org/mailman/listinfo/tails-dev
