Re: [T(A)ILS-dev] Metadata Anonymizing Toolkit for file Publ…

Delete this message

Reply to this message
Author: Antonio Davoli
Date:  
To: intrigeri
CC: Damian Johnson, Tor Assistants, The T\(A\)ILS public development discussion list, tech
Subject: Re: [T(A)ILS-dev] Metadata Anonymizing Toolkit for file Publication - GSoC'11 Proposal
HI intrigeri and all,

On Wed, Apr 6, 2011 at 7:59 AM, intrigeri <intrigeri@???> wrote:

>
> Thanks, see my comments bellow.
>


Thanks for your quick and detailed answer, even if my application will not
be
selected, I have already learnt a lot of useful and interesting things!

>
> "complete" seems pretty strong to me. Remember Tor does not protect
> against every attack against anonymity.
>


I have improperly used that word, it have changed it with "improved" that I
believe more suitable.


> My general feeling about your updated proposal is good. This one is
> really better than the initial one.



Thank you, without your hints it would have still been too poor for a
contest
like GSoC.


> On the other hand, it lacks some
> important bits of the email discussion we've had, in which you
> clarified some points eventually; some of those points are still quite
> vague in your proposal, which I find a bit sad; I'm especially
> thinking of your availability timeline, things you intend to do during
> the Community Bonding Period, and ways you'll offer us to continuously
> test your code is a Real World (read: Tails) environment. While *I* do
> know you already answered most of these questions in a more detailed
> way somewhere else, neither the other Tor/EFF involved people nor
> Google will be able to see it clearly by reading your proposal only.
> See what I mean?
>


I improved these sections and I decided to include for each week of the
timeline
a clear level of availability that I am going to have.


> Your proposal mentions wipe and srm but does not mention shred.
> I doubt this was done on purpose, was it?
>


Obviously it was not done on purpose. I have added it among the candidates.


>
> > RTF, The file in RTF format will be manage through the library
> > librtf (http://sourceforge.net/projects/librtf/).
>
> Seems like this lib:
>
> * has been unmaintained since 2006
> * lacks a Python binding
> * is not part of Debian
>
> => I doubt it is a sound choice.
>


I am thinking to write a little library in Python to manage this file
because
I have not found something interesting. What do you think about?



> > Video Files, The tags contained in video files will be treat through
> > the ffmpeg library (http://packages.debian.org/testing/ffmpeg) and
> > with the Python Wrapper http://code.google.com/p/pyffmpeg/.
>
> Filling a RFP (request for package) Debian bug to ask for the
> inclusion of pyffmpeg would be useful, then. The sooner, the better.
>
> According to the debian/control file [0] found in the preliminary
> packaging on Launchpad, pyffmpeg depends on libavutil50 (>= 4:0.5)
> that is part of Debian testing/sid, but not in Squeeze. Sounds like
> this feature, if implemented this way, will need to be optional and
> won't work in Tails... or have you better plans?
>
> [0]
> http://bazaar.launchpad.net/~rexbron/pyffmpeg/debian.nightly/view/head:/debian/control
>


As you said the Python Wrapper is not useful, even with the RFP.
What do you think about interacting directly with ffmpeg library (without
wrappers) ?


> [...]
> Also, did you think of a more incremental approach that would allow us
> to test / show your results earlier, and allow you to prove your
> design is correct earlier too? I'm e.g. thinking of implementing
> support for only one $FILETYPE in the library to start with, then
> implementing (at least minimally) the command-line (which would only
> support $FILETYPE at this point obviously) and GUI tools, then
> implementing other filetypes? I'd be more comfortable with such a
> process that ensures you don't get lost in the deep mazes of abstract
> design.
>


Great hint, I agree with you and I changed the schedule. You can find
another version of the proposal in this mail.

Thank you again.

Antonio


>
> Bye,
> --
> intrigeri <intrigeri@???>
> | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
> | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
> | We're dreaming of something else.
> | Something more clandestine, something happier.
>




--

Antonio Davoli - Ph.D. Student
Computer Science Department
Sapienza University of Rome
113, Via Salaria 00198 Rome - Italy

Tel. +39 06 4991 8430
Skype: anto.davoli
Web: http://sites.google.com/site/antoniodavoli
E-mail: davoli[at]di[dot]uniroma1[dot]it