Hi,
Antonio Davoli wrote (06 Apr 2011 01:41:38 GMT) :
> I prepared the new version of the proposal. I will be waiting for
> your comments before sending it to the native speaker that will
> proofread it.
Thanks, see my comments bellow.
> I just want to explain a little better this timeline:
[...]
Thanks for clarifying.
> I know that is not a good thing, but here in Italy the summer break
> is in August.
Fair enough.
> A combined use with Tor permits to achieve a complete a complete
> privacy and anonymity.
"complete" seems pretty strong to me. Remember Tor does not protect
against every attack against anonymity.
My general feeling about your updated proposal is good. This one is
really better than the initial one. 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?
> The wipe implementation (http:// packages.debian.org/testing/wipe)
> is included in the Debian Packages and it should be available in
> every GNU/Linux system.
I think you misunderstood one hint I gave you; quoting myself:
shred is another alternative you might want to consider. It's
shipped by the GNU coreutils package and is thus installed by
default in every GNU/Linux system I think.
Your proposal mentions wipe and srm but does not mention shred.
I doubt this was done on purpose, was it?
> 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.
> 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
Other than that, I've got a few remarks about your estimated timeline.
Please read on.
> The support for $FILETYPE will be designed and implemented.
I think you should make it explicit you're talking of supporting
$FILETYPE in the library.
> - June 3 – June 9 (Second week): The support for Images/Archive will
> be designed and implemented.
> - June 10 – June 16 (Third week): The support for Video/Audio will
> be designed and implemented. Start of coding phase for the command
> line utility.
> - June 17 – June 23 (Fourth week): The support for Documents/XMP
> Metadata will be designed and implemented. Start of coding phase
> for the GUI.
> - June 24 – June 30 (Fifth week): Finish of MAT library and command
> line utility code.
I don't like sentences like "Start of ..." that much and would rather
read what subpart of the task you intend to start with and complete
during the week.
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.
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.
