- tor-commits - lists.torproject.org

r24748: {} Add final submission PDF. (projects/articles/browser-privacy)
by Mike Perry 13 May '11

13 May '11

Author: mikeperry Date: 2011-05-13 20:50:21 +0000 (Fri, 13 May 2011) New Revision: 24748 Added: projects/articles/browser-privacy/W3CIdentity-Tor-final.pdf Log: Add final submission PDF. Added: projects/articles/browser-privacy/W3CIdentity-Tor-final.pdf =================================================================== (Binary files differ) Property changes on: projects/articles/browser-privacy/W3CIdentity-Tor-final.pdf ___________________________________________________________________ Added: svn:mime-type + application/octet-stream

1 0

r24747: {projects} Add a sentence to the conclusion, tighten some other languag (projects/articles/browser-privacy)
by Mike Perry 13 May '11

13 May '11

Author: mikeperry Date: 2011-05-13 20:47:03 +0000 (Fri, 13 May 2011) New Revision: 24747 Modified: projects/articles/browser-privacy/W3CIdentity.tex Log: Add a sentence to the conclusion, tighten some other language for space. Modified: projects/articles/browser-privacy/W3CIdentity.tex =================================================================== --- projects/articles/browser-privacy/W3CIdentity.tex 2011-05-13 16:10:10 UTC (rev 24746) +++ projects/articles/browser-privacy/W3CIdentity.tex 2011-05-13 20:47:03 UTC (rev 24747) @@ -83,7 +83,7 @@ Both of these directions must be pursued to provide users with the ability to properly use the web in a privacy-preserving way. -\footnotetext{We only consider implementations that involve privacy-by-design. +\footnotetext{We only consider privacy-by-design approaches. Privacy-by-policy approaches such as Do Not Track will not be discussed.} \section{User Privacy on the Web} @@ -122,13 +122,12 @@ pages. The default experience is such that all of this data exchange is concealed from the user. -So then what comprises a user's web identity for tracking purposes? In terms -of authentication, it would at first appear to be limited to cookies, HTTP -Auth tokens, and client TLS certificates. However, this identifier-based -approach breaks down quickly on the modern web. High-security websites are -already using fingerprinting as an auxiliary second factor of -authentication~\cite{security-fingerprinting}, and online data aggregators -utilize everything they can to build complete portraits of users' +So then what comprises a user's web identity for tracking purposes? At first +glance, it appears to be limited to cookies, HTTP Auth tokens, and client TLS +certificates. However, this identifier-based approach breaks down quickly on +the modern web. High-security websites are already using fingerprinting as a +second factor of authentication~\cite{security-fingerprinting}, and data +aggregators utilize everything they can to build complete portraits of users' identities~\cite{tracking-identity}. Despite what the user may believe, her actual web identity then is a superset @@ -150,7 +149,7 @@ When privacy is expanded to cover all items that enable or substantially contribute to linkability, a lot more components of the browser are now in -scope. We will briefly enumerate these four categories of components. +scope. We will briefly enumerate these categories of components. First, the obvious properties are found in the state of the browser: cookies, DOM storage, cache, cryptographic tokens and cryptographic state, and @@ -182,23 +181,21 @@ distribution of each of several key attributes to determine how many bits of identifying information each attribute provided. -While not perfect\footnotemark, this metric allows us to prioritize our efforts -on the -components that have the most potential for linkability. +While not perfect\footnotemark, this metric allows us to prioritize our +efforts on the components that have the most potential for linkability. % -\footnotetext{In particular, the test does not take in all aspects of +\footnotetext{In particular, Panopticlick did not measure all aspects of resolution information. It did not calculate the size of widgets, window decoration, or toolbar size. We believe these resolution-related properties -may add high amounts of entropy to the resolution component. They also did not +may add high amounts of entropy to the resolution component. It also did not measure clock offset and other time-based fingerprints. Furthermore, as new -browser features are added, the experiment should be repeated to include +browser features are added, the experiment should be repeated to measure them.} % -It also shows the benefits of standardizing on -implementations of fingerprinting resistance where possible. More -implementations using the same defenses means more users with similar -fingerprints, which means less entropy in the metric. Similarly, uniform -feature deployment leads to less entropy. +It also shows the benefits of standardizing on implementations of +fingerprinting resistance where possible. More implementations using the same +defenses means more users with similar fingerprints, which means less entropy +in the metric. Similarly, uniform feature deployment leads to less entropy. \section{Matching User Perception with Reality} @@ -222,15 +219,14 @@ indicate that their current set of accumulated linkable state comprise a single, trackable web identity that can be changed or cleared. -We believe that the user interface of the browser should convey a sense of -persistent identity prominently to the user in the form of a visual cue. This -cue can either be an abstract image, graphic or theme (such as the user's -choice of Firefox Persona~\cite{firefox-personas}), or it can be a text area -with the user's current pseudonym. This idea of identity should then be -integrated with the browsing experience. Users should be able to click a -button to get a clean slate for a new identity, and should be able to log into -and out of password-protected stored identities, which would contain the -entire state of the browser. +We believe that the browser UI should convey a sense of persistent identity +prominently to the user in the form of a visual cue. This cue can either be an +image, graphic or theme (such as the user's choice of Firefox +Persona~\cite{firefox-personas}), or it can be a text area with the user's +pseudonym. This idea of identity should then be integrated with the browsing +experience. Users should be able to click a button to get a clean slate for a +new identity, and should be able to log into and out of password-protected +stored identities, which would contain the entire state of the browser. To this user, the Private Browsing Mode would be no more than a special case of this identity UI---a special identity that they can trust not to store @@ -351,9 +347,9 @@ window could have a user-intuitive way of representing the user's relationship with different top-level origins, perhaps by using only the `favicon' of that top-level origin to represent all of the browser state accumulated by that -origin. The user could delete the entire set of browser state (cookies, cache, -storage, cryptographic tokens) associated with a site simply by removing its -favicon from her privacy info panel. +origin. The user could delete the entire set of top-level origin state +(cookies, cache, storage, cryptographic tokens) simply by removing the favicon +from her privacy info panel. Linkability based on fingerprintable browser properties is also amenable to improvement under this model. In particular, one can imagine per-origin plugin @@ -364,9 +360,8 @@ of the web closer to what the user assumes is happening, they must be deployed uniformly, with a consistent top-level origin restriction model. Uniform deployment will take significant coordination and standardization efforts. -Furthermore, even a vastly improved origin model cannot prevent -instances of explicit tracking partnerships between sites and third-party -content providers. Therefore, both origin improvements and +Furthermore, even an improved origin model cannot protect against large +multi-service top-level origins. Therefore, both origin improvements and identity-isolation approaches are necessary. \section{Conclusions} @@ -378,20 +373,21 @@ is so extreme that it raises moral issues about the level of consent actually involved in web use and associated tracking. -In fact, standardization efforts seemed to realize this problem early on but -failed to create feasible recommendations for improving the situation. -RFC~2965 governing HTTP State Management mandated in Section~3.3.6 that -third-party origins must not cause the browser to transmit cookies unless the -interaction is ``verifiable'' and readily apparent to the user~\cite{rfc2965}. -In Section~6, it also strongly suggested that informed consent and user -control should govern the interaction of users to tracking identifiers. +In fact, standardization efforts realized this problem early on but failed to +create feasible recommendations for improving the situation. RFC~2965 +governing HTTP State Management mandated in Section~3.3.6 that third-party +origins must not cause the browser to transmit cookies unless the interaction +is ``verifiable'' and readily apparent to the user~\cite{rfc2965}. In +Section~6, it also strongly suggested that informed consent and user control +should govern the interaction of users to tracking identifiers. Without changes to both browser behavior and browser interface, informed consent is simply not possible on today's web. The lack of informed consent makes it impossible to expect privacy-by-design approaches to function properly. We cannot expect users who do not even understand the basic -properties of these tracking mechanisms to effectively -use privacy mechanisms to avoid, opt out of, or decline such tracking. +properties of these tracking mechanisms to effectively use privacy mechanisms +to avoid, opt out of, or decline such tracking. Therefore, browser inteface +and behavior must be brought in line with user expectations. \bibliographystyle{plain} \bibliography{W3CIdentity}

1 0

[arm/master] fix: Control message lagging being state
by atagar＠torproject.org 13 May '11

13 May '11

commit 6a22d0c090846fe2ffb3dbb5a971cd6831d79bfb Author: Damian Johnson <atagar(a)torproject.org> Date: Fri May 13 07:35:13 2011 -0700 fix: Control message lagging being state The control panel is the last of the old-style panels and doesn't yet support non-forced redraws. --- src/cli/controller.py | 6 +++++- src/util/procName.py | 22 ++++++++++++---------- 2 files changed, 17 insertions(+), 11 deletions(-) diff --git a/src/cli/controller.py b/src/cli/controller.py index 51b64c7..5927e17 100644 --- a/src/cli/controller.py +++ b/src/cli/controller.py @@ -586,7 +586,11 @@ def drawTorMonitor(stdscr, startTime, loggedEvents, isBlindMode): newSize = stdscr.getmaxyx() isResize = lastSize != newSize lastSize = newSize - panels[panelKey].redraw(isResize) + + if panelKey != "control": + panels[panelKey].redraw(isResize) + else: + panels[panelKey].redraw(True) stdscr.refresh() diff --git a/src/util/procName.py b/src/util/procName.py index 97dc707..fab0b1e 100644 --- a/src/util/procName.py +++ b/src/util/procName.py @@ -1,13 +1,15 @@ -# Module to allow for arbitrary renaming of our python process. This is mostly -# based on: -# http://www.rhinocerus.net/forum/lang-python/569677-setting-program-name-lik… -# and an adaptation by Jake: https://github.com/ioerror/chameleon -# -# A cleaner implementation is available at: -# https://github.com/cream/libs/blob/b38970e2a6f6d2620724c828808235be0445b799… -# but I'm not quite clear on their implementation, and it only does targeted -# argument replacement (ie, replace argv[0], argv[1], etc but with a string -# the same size). +""" +Module to allow for arbitrary renaming of our python process. This is mostly +based on: +http://www.rhinocerus.net/forum/lang-python/569677-setting-program-name-like-0-perl.html#post2272369 +and an adaptation by Jake: https://github.com/ioerror/chameleon + +A cleaner implementation is available at: +https://github.com/cream/libs/blob/b38970e2a6f6d2620724c828808235be0445b799/cream/util/procname.py +but I'm not quite clear on their implementation, and it only does targeted +argument replacement (ie, replace argv[0], argv[1], etc but with a string +the same size). +""" import sys import ctypes

1 0

[arm/master] fix: Log panel busy wait during curses lock
by atagar＠torproject.org 13 May '11

13 May '11

commit 6f46b55a97e67922d5d6aa1b1ec8340e5085a406 Author: Damian Johnson <atagar(a)torproject.org> Date: Fri May 13 08:17:13 2011 -0700 fix: Log panel busy wait during curses lock If we registered events while the curses lock was held (for instance with a popup or prompt for user input) then arm would peg the cpu. The reason for this was that the log panel was attempting to redraw itself, but not registering any of the attempts since they all failed so it became a busy wait. --- src/cli/logPanel.py | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/src/cli/logPanel.py b/src/cli/logPanel.py index 34bf759..6d54ab4 100644 --- a/src/cli/logPanel.py +++ b/src/cli/logPanel.py @@ -1079,6 +1079,10 @@ class LogPanel(panel.Panel, threading.Thread): else: lastDay = currentDay self.redraw(True) + + # makes sure that we register this as an update, otherwise lacking the + # curses lock can cause a busy wait here + self._lastUpdate = time.time() def stop(self): """

1 0

r24746: {website} Asking org preference on the GSoC app template to help with (website/trunk/about/en)
by Damian Johnson 13 May '11

13 May '11

Author: atagar Date: 2011-05-13 16:10:10 +0000 (Fri, 13 May 2011) New Revision: 24746 Modified: website/trunk/about/en/gsoc.wml Log: Asking org preference on the GSoC app template to help with deduplication next year Modified: website/trunk/about/en/gsoc.wml =================================================================== --- website/trunk/about/en/gsoc.wml 2011-05-13 15:51:39 UTC (rev 24745) +++ website/trunk/about/en/gsoc.wml 2011-05-13 16:10:10 UTC (rev 24746) @@ -166,6 +166,11 @@ Interacting with us on IRC will help us get to know you, and help you get to know our community.</li> + <li>Are you applying to other projects for GSoC and, if so, what would be + your preference if you're accepted to both? Having a stated preference + helps with the deduplication process and will not impact if we accept your + application or not.</li> + <li>Is there anything else we should know that will make us like your project more?</li>

1 0

r24745: {website} Adding gsoc proposals for this year's students (in website/trunk/about: en gsocProposal)
by Damian Johnson 13 May '11

13 May '11

Author: atagar Date: 2011-05-13 15:51:39 +0000 (Fri, 13 May 2011) New Revision: 24745 Added: website/trunk/about/gsocProposal/gsoc11-proposal-metadataToolkit.txt Modified: website/trunk/about/en/gsoc.wml Log: Adding gsoc proposals for this year's students Modified: website/trunk/about/en/gsoc.wml =================================================================== --- website/trunk/about/en/gsoc.wml 2011-05-12 14:09:44 UTC (rev 24744) +++ website/trunk/about/en/gsoc.wml 2011-05-13 15:51:39 UTC (rev 24745) @@ -212,6 +212,10 @@ <li><h4><a href="http://tor.spanning-tree.org/proposal.html">DNSEL Rewrite</a> by Harry Bock</h4></li> <li><h4><a href="http://kjb.homeunix.com/wp-content/uploads/2010/05/KevinBerry-GSoC2010-TorP…">Extending Tor Network Metrics</a> by Kevin Berry</h4></li> <li><h4><a href="../about/gsocProposal/gsoc10-proposal-soat.txt">SOAT Expansion</a> by John Schanck</h4></li> + <li><h4><a href="http://inspirated.com/uploads/tor-gsoc-11.pdf">GTK+ Frontend and Client Mode Improvements for arm</a> by Kamran Khan</h4></li> + <li><h4><a href="http://www.gsathya.in/gsoc11.html">Orbot + ORLib</a> by Sathya Gunasekaran</h4></li> + <li><h4><a href="http://blanu.net/TorSummerOfCodeProposal.pdf">Blocking-resistant Transport Evaluation Framework</a> by Brandon Wiley</h4></li> + <li><h4><a href="../about/gsocProposal/gsoc11-proposal-metadataToolkit.txt">Metadata Anonymisation Toolkit</a> by Julien Voisin</h4></li> <li><h4><a href="http://www.atagar.com/misc/gsocBlog09/">Website Pootle Translation</a> by Damian Johnson</h4></li> </ul> Added: website/trunk/about/gsocProposal/gsoc11-proposal-metadataToolkit.txt =================================================================== --- website/trunk/about/gsocProposal/gsoc11-proposal-metadataToolkit.txt (rev 0) +++ website/trunk/about/gsocProposal/gsoc11-proposal-metadataToolkit.txt 2011-05-13 15:51:39 UTC (rev 24745) @@ -0,0 +1,231 @@ +Hello, +I am Julien Voisin, undergraduate computer science student from France. + +I am interested to work on the “Meta-data anonymizing toolkit for file publication” project. +I know there is already a student interested in by this project, but I really want to do it : +I needed it for my own and have already thought about a potential design some time ago. + +I would like to work for the EFF, because I am very concerned about privacy issues on the Internet. +I think privacy is an essential right, and not just an option. +Especially, I would really enjoy to work for the Tor project (or Tails, since it's heavily based on him). +I am using it for quite some time and would like to get more involved and contribute back! + +I use F/OSS on a daily basis (Ubuntu, Debian, Archlinux and Gentoo). +So far my major contributions were the writing of documentations for archLinux, openmw, xda-forum and Ubuntu. +Recently I have released a little matrix manipulation library written in C, +originally for an academic project (http://dustri.org/lib/) +I am interested to do the debian package, but heard that it can be quite tricky, so a little +help would be much appreciated + +I do not have any major plan for this summer (but my holidays only begins the june 4th), so I can fully focus on the project and reasonably think that I could commit 5-6 hours per day on it. + +Requirement/Deliverables: + + * A command line and a GUI tool having both the following capabilities (in order of importance): + o Listing the metadatas embedded in a given file + o A batch mode to handle a whole directory (or set of directories) + o The ability to scan files packed in the most common archive formats + o A nice binding for srm (Secure ReMoval) or shred (GNU utils) to properly remove the original file containing the evil metas + o Let the user delete/modify a specific meta + + * Should run on the most common OS/architectures (And especially on Debian Squeeze, since Tails is based on it.) + * The whole thing should be easily extensible (especially it should be easy to add support for new file formats) + * The proper functioning of the software should be easily testable + +I'd like to do this project in Python, because I already have done some personal projects whith it (for which I also used subversion) : an IRC bot tailored for logging (dustri.org/tor/depluie.tar.bz2 still under heavy WIP), a battery monitor, a simple search engine indexing FTP servers, ... + +Why is Python a good choice for implementing this project ? + + 1. I am experienced with the language + 2. There are plenty of libraries to read/write metadatas, among them is Hachoir (https://bitbucket.org/haypo/hachoir/)that looks very promising since it supports quite a few file formats + 3. It is easy to wrap other libraries for our needs (even if they are not written in Python !) + 4. Runs on almost every OS/architecture, what is a great benefit for portability + 5. It is easy to make unit tests (thanks to the built-in Unittest module) + +Proposed design: + +The proposed design has three main components : one lib, a command line tool and a GUI tool. + +The aim of the library (described with more details in the next part) is to make the development of tools easy. A special attention will be made on the API that it exposes. The ultimate goal being to be able to add the support of new file format in the library without changing the whole code of the tools. + +Meta reading/writing library : + +A library to read and write metas for various file formats. The main goal is to provide an abstraction interface (for the file format and for the underlying libraries used). +At first it would only wrap Hachoir. +Why hachoir : + + * Autofix: Hachoir is able to open invalid / truncated files + * Lazy: Open a file is very fast since no information is read from file, data are read and/or computed when the user ask for it + + * Types: Hachoir has many predefined field types (integer, bit, string, etc.) and supports string with charset (ISO-8859-1, UTF-8, UTF-16, ...) + * Addresses and sizes are stored in bit, so flags are stored as classic fields + * Editor: Using Hachoir representation of data, you can edit, insert, remove data and then save in a new file. + * Meta : Support a very large scale of file format + +But we could also wrap other libraries to support a particular file format. Or write ourself the support for a format, although this should be avoided if possible (it looks simple at first, but supporting different versions of the format and maintaining the thing over time is extremely time consuming) +The must would be to make the children libraries optional dependencies. + +One typical use case of the lib is to ask for metadatas for a file, if the format is supported a list (or maybe a tree) of metas is returned. + +Both the GUI and the cmdline tool will use this lib. + +The cmdline/GUI tool features: + + * List all the meta + * Removing all the meta + * Anonymising all the meta + * Let the user chose wich meta he wants to modify + * Support archives anonymisation + * Secure removal + * Cleaning wholes folder recursively + +GUI: +Essentially the GUI tool would do the same features as for the cmd line too. +I do not have a significant GUI development experience, but I'm planing to fix that point during community bonding period. + +Proposed development methods: +One way to develop this would be to do it layer by layer : first implementing the meta reading/writing lib for ale the formats in one shot, then making the command line application, … + +However for this project, developing feature by feature seems more appropriate : +Starting by a skeleton implementing a thin slice of functionality that traverses most of the layers. +For example, I could start by focussing only on EXIF metas : make sure that the meta reading/writing library supports EXIF, then make the command line tool using the previous library. +And only then, when the skeleton is actually working, add supports for other features/formats. + +This allows a more incremental development flow and after only a few weeks I would be able to deliver a working system. The list of features supported in the first iterations would be ridiculously short but at least that would enable me to get feedbacks and notice quickly if I am on the wrong tracks. +Also, since I would add one feature at a time, the structure of the system will tend to easily accommodate that. Thanks to this, adding the support of a new file format will be made easy, even after the end of the GSOC. + + +Testing +For such a tool, since the smallest crack could compromise the user, testing is critically important. I plan to implement two main kind of testings : + +Unit tests + +To test the proper working of the meta accessing library. Maintaining a collection of files with metas for every format we should support. Using Python's unittest I can setup expectations to make sure that the library will finds the good fields. + +End-to-End testing: + +A script (or set of script) to test the proper working of the command line tool. One way is to run the tool in batch mode on the input test files set. If in the output we are still able to find metas, the system is not doing his job right. + +It is possible to write this script in Python, possibly using again the unittest lib (even if here the goal is to execute an external executable and see how it's behaving) to get output of the results that is consistent with the unit tests. + +The goal is to be able to automatically test the whole system in a few commands (one for the unit tests one for the end-to-end tests). It will be easy to add a new document in the test set, so if someone from the community provides a file that was not cleaned properly, we can easily reproduce the problem and then decide on the proper action to take. The ability to tests everything easily might help a user to make sure that everything works fine on his OS/architecture. Also, if for one reason after some months it is decided to change from Hachoir to another underlying library (yes a pretty radical decision, just given as example) we still have the tests, so valuable to check than everything is still working with the new library. + +Timeline: + + * Community Bonding Period (in order of importance) + o Playing around with pygobject + o Playing with Hachoir + o Learning git + + * First two weeks : + o create the structure in the repository (directories, README, ..) + o Create a skeleton + + o Objectives : to have a deployable working system as soon as possible(even if the list of features is ridiculous). So that I can show you my work in an incremental way thereafter and get feedbacks early. + o The lib will handle reading/writing EXIF fields (using Hachoir) + o A set of tests files (and automated unit tests) to demonstrate that the lib does the job + o The beginning of the command line tool, at this point must list and delete EXIF meta + o An automated end-to-end test to show that the command line tool does properly remove the EXIF + +After this first step (making the skeleton) I should be able to deliver a working system right after adding each of the following features. I Hope to get feedbacks so can fix problems quickly + + * 3 weeks + o adding support for (in order of importance) pdf, zip/tar/bzip (just the meta, not the content yet), jpeg/png/bmp, ogg/mpeg1-2-3, exe... + o For every type of meta, that involves : + + Creating some input test files with meta data + + Implementing the feature in the library + + Asserting that the lib does the job with unit tests + + Modifying the cmd line tool to support the feature (if necessary) + + Checking that the cmd line tool can properly delete this type of meta with automated end-to-end test + + * about one day + o Enable the command line tool to set a specific meta to a chosen value + + * about 1 day + o Implementation of the “batch mode” in the cmdline tool, to clean a whole folder + o Implementation of secure removal + + * about 2 days : + o Add support for deep archive cleanup + + Clean the content of the archives + + Make a list of non supported format, for which we warn the user that only the container can be cleaned from meta, not the content (at first that will include rar, 7zip, ..) + + The supported formats will be those supported natively by Python ( bzip2, gzip, tar ) + + Create some test archives for each supported format containing various files with metas + + Implement the deep cleanup for the format + + Assert that the command line passes the end-to-end tests (that is, it can correctly clean the content of the test archives) + + * about 2 days + o Add support for complete deletion of the original files + o Make a binding nice for shred (should not be to hard using Python) + o Implement the feature in the command line tool + + * 3 weeks + o Implementation of the GUI tool + o At this stage, I can use the experience from implementing the cmdline tool to implement the GUI tool, having the same features. + + * 1 week + o Add support for more format (might be based on requests from the community) + + * Remaining weeks + o I want to keep those remaining week in case of problems, and for + + Remaining/polishing cleanup + + Bugfixing + + Integration work + + Missing features + + Packaging + + Final documentation + * Every Week-end : + o Documentation time : both end-user, and design. I do not like to document my code while I'm coding it : it slows a lot the development process, but it's not a good thing to delay it too much : week-ends seems fine for this. + o A blog-post, and a mail on the mailing list about what I have done in the week. + +About the anonymisation process : + +Since I'll relay on Hachoir in a first time, I don't know how much it's +effective on every case. +I am planing to do some tests during the Community Bonding Period. + +The plan is to first rely on the capabilities of Hachoir. I don't know yet +how effective it is for each case. I am planing to do some tests during the +Community Bonding Period. Following the test strategy described before, it +will be easy to add a new document in the test set. If I could make a test +file with metas not supported by Hachoir (or someone from the community +provide such a file), we could then decide on the proper action : propose a +patch to Hachoir or use another library for this specific format. + +Doing R&D about supporting exotics fields, or improve existing support will +depend of my progress. Speaking of the fingerprints, the subject of the +project is “metadata anonymisation”, and not “fingerprint detection” : they +are too many softwares, too many subtle ways to alter/mark a file (and I +don't even speak of steganography). + +So, nop, I'm not planing to implement fingerprinting detection. Not that it +is not interesting, it's just that it's not realistic to support it +correctly (actually it's not realistic to support it at all, given that I +must first support the metas, in such a short time frame). Would you agree +that it is better to first focus on making a working tool that does the job +for the known metadatas ? + +That done, if the design is good we could easily add support for more exotic +fields (or some kind of fingerprinting). I think we should never loose track +of the sad truth : no matter how big the effort we spend on this, making a +comprehensive tool able of detecting every kind of meta and every pattern of +fingerprinting is just not feasible. + +About archives anonymisation + +Task order for anonymisation of an archive : + + 1. Extract the archive + 2. Anonymise his content + 3. Recompress the archive + 4. Securely deleting the extracted content + 5. Anonymise the new created archive + +And I'm planing to support the extraction only of archive formats supported by python (without this limitation, the tool will not be portable). If the user try to anonymize a .rar for example, the tool will popup “WARNING - only the container will be anonymize, and not the content - WARNING” + +As for what I expect from my mentor, I think he should try to be available (not immediately but in the 48 hours) when I need him specifically (e.g. technical questions no one else on IRC can answer) but he doesn't need to check on me all the time. I'm fine with mails to (since intrigeri is not always “online”, it will be I think, the best solution to communicate with him). I'd like to do a weekly reunion, on irc or jabber, to discuss things more smoothly. + +I'm using irc quite a lot, and I'm hanging on #tor, and #tor-dev (nick : jvoisin). +I'm planing to do a blogpost every week-end, about the advancement of the project. +You can mail me at : julien.voisin(a)dustri.org for more information. +

1 0

[tor/master] Teach retry_listener about "auto" ports.
by nickm＠torproject.org 13 May '11

13 May '11

commit 61c06cbc66ecfaece20501417ef81b3f6f202391 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon May 2 15:26:39 2011 -0400 Teach retry_listener about "auto" ports. Otherwise, it will just immediately close any port declared with "auto" on the grounds that it wasn't configured. Now, it will allow "auto" to match any port. This means FWIW if you configure a socks port with SocksPort 9999 and then transition to SocksPort auto, the original socksport will not get closed and reopened. I'm considering this a feature. --- src/or/connection.c | 19 ++++++++++++++++--- 1 files changed, 16 insertions(+), 3 deletions(-) diff --git a/src/or/connection.c b/src/or/connection.c index 47e5423..bc18dab 100644 --- a/src/or/connection.c +++ b/src/or/connection.c @@ -1772,10 +1772,23 @@ retry_listeners(int type, config_line_t *cfg, if (!parse_addr_port(LOG_WARN, wanted->value, &address, NULL, &port)) { int addr_matches = !strcasecmp(address, conn->address); + int port_matches; tor_free(address); - if (! port) - port = port_option; - if (port == conn->port && addr_matches) { + if (port) { + /* The Listener line has a port */ + port_matches = (port == conn->port); + } else if (port_option == CFG_AUTO_PORT) { + /* The Listener line has no port, and the Port line is "auto". + * "auto" matches anything; transitions from any port to + * "auto" succeed. */ + port_matches = 1; + } else { + /* The Listener line has no port, and the Port line is "auto". + * "auto" matches anything; transitions from any port to + * "auto" succeed. */ + port_matches = (port_option == conn->port); + } + if (port_matches && addr_matches) { line = wanted; break; }

1 0

[tor/master] Correct the signature for is_listening_on_low_port for "auto" ports
by nickm＠torproject.org 13 May '11

13 May '11

commit 6f5998fd73849b98c9c1a017845c0669c32fda5d Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon May 2 15:31:49 2011 -0400 Correct the signature for is_listening_on_low_port for "auto" ports --- src/or/config.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/or/config.c b/src/or/config.c index 055a4b8..914c4cb 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -2623,7 +2623,7 @@ options_init(or_options_t *options) * it is, or 0 if it isn't or the concept of a low port isn't applicable for * the platform we're on. */ static int -is_listening_on_low_port(uint16_t port_option, +is_listening_on_low_port(int port_option, const config_line_t *listen_options) { #ifdef MS_WINDOWS

1 0

[tor/master] Add a new "tor_sockaddr_to_str()" function
by nickm＠torproject.org 13 May '11

13 May '11

commit 28cc7b01800e3e2a46a995b2ca18b0d2d5cdc804 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon May 2 16:43:11 2011 -0400 Add a new "tor_sockaddr_to_str()" function It does what it says on the tin. It turns out I'll want this in a couple of places. --- src/common/address.c | 30 ++++++++++++++++++++++++++++++ src/common/address.h | 1 + 2 files changed, 31 insertions(+), 0 deletions(-) diff --git a/src/common/address.c b/src/common/address.c index 34e109f..1c72539 100644 --- a/src/common/address.c +++ b/src/common/address.c @@ -43,6 +43,9 @@ #ifdef HAVE_SYS_PARAM_H #include <sys/param.h> /* FreeBSD needs this to know what version it is */ #endif +#ifdef HAVE_SYS_UN_H +#include <sys/un.h> +#endif #include <stdarg.h> #include <stdio.h> #include <stdlib.h> @@ -120,6 +123,33 @@ tor_addr_from_sockaddr(tor_addr_t *a, const struct sockaddr *sa, return 0; } +/** Return a newly allocated string holding the address described in + * <b>sa</b>. AF_UNIX, AF_UNSPEC, AF_INET, and AF_INET6 are supported. */ +char * +tor_sockaddr_to_str(const struct sockaddr *sa) +{ + char address[TOR_ADDR_BUF_LEN]; + char *result; + tor_addr_t addr; + uint16_t port; +#ifdef HAVE_SYS_UN_H + if (sa->sa_family == AF_UNIX) { + struct sockaddr_un *s_un = (struct sockaddr_un *)sa; + tor_asprintf(&result, "unix:%s", s_un->sun_path); + return result; + } +#endif + if (sa->sa_family == AF_UNSPEC) + return tor_strdup("unspec"); + + if (tor_addr_from_sockaddr(&addr, sa, &port) < 0) + return NULL; + if (! tor_addr_to_str(address, &addr, sizeof(address), 1)) + return NULL; + tor_asprintf(&result, "%s:%d", address, (int)port); + return result; +} + /** Set address <b>a</b> to the unspecified address. This address belongs to * no family. */ void diff --git a/src/common/address.h b/src/common/address.h index d05a3de..9a7656f 100644 --- a/src/common/address.h +++ b/src/common/address.h @@ -44,6 +44,7 @@ socklen_t tor_addr_to_sockaddr(const tor_addr_t *a, uint16_t port, int tor_addr_from_sockaddr(tor_addr_t *a, const struct sockaddr *sa, uint16_t *port_out); void tor_addr_make_unspec(tor_addr_t *a); +char *tor_sockaddr_to_str(const struct sockaddr *sa); /** Return an in6_addr* equivalent to <b>a</b>, or NULL if <b>a</b> is not * an IPv6 address. */

1 0

[tor/master] Advertise correct DirPort/ORPort when configured with "auto"
by nickm＠torproject.org 13 May '11

13 May '11

commit 3da661b2422dbf5a098eb3b8ad9dd2033599016f Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon May 2 15:51:30 2011 -0400 Advertise correct DirPort/ORPort when configured with "auto" We'll eventually want to do more work here to make sure that the ports are stable over multiple invocations. Otherwise, turning your node on and off will get you a new DirPort/ORPort needlessly. --- src/or/config.c | 2 +- src/or/dirserv.c | 6 +++--- src/or/router.c | 38 ++++++++++++++++++++++++++++++++++---- src/or/router.h | 3 +++ 4 files changed, 41 insertions(+), 8 deletions(-) diff --git a/src/or/config.c b/src/or/config.c index 914c4cb..b06c8c9 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -563,7 +563,7 @@ static int or_state_validate(or_state_t *old_options, or_state_t *options, static int or_state_load(void); static int options_init_logs(or_options_t *options, int validate_only); -static int is_listening_on_low_port(uint16_t port_option, +static int is_listening_on_low_port(int port_option, const config_line_t *listen_options); static uint64_t config_parse_memunit(const char *s, int *ok); diff --git a/src/or/dirserv.c b/src/or/dirserv.c index eadc2d7..79b68cd 100644 --- a/src/or/dirserv.c +++ b/src/or/dirserv.c @@ -2699,8 +2699,8 @@ dirserv_generate_networkstatus_vote_obj(crypto_pk_env_t *private_key, voter->sigs = smartlist_create(); voter->address = hostname; voter->addr = addr; - voter->dir_port = options->DirPort; - voter->or_port = options->ORPort; + voter->dir_port = router_get_advertised_dir_port(options); + voter->or_port = router_get_advertised_or_port(options); voter->contact = tor_strdup(contact); if (options->V3AuthUseLegacyKey) { authority_cert_t *c = get_my_v3_legacy_cert(); @@ -2806,7 +2806,7 @@ generate_v2_networkstatus_opinion(void) "dir-options%s%s%s%s\n" "%s" /* client version line, server version line. */ "dir-signing-key\n%s", - hostname, ipaddr, (int)options->DirPort, + hostname, ipaddr, (int)router_get_advertised_dir_port(options), fingerprint, contact, published, diff --git a/src/or/router.c b/src/or/router.c index a7148ea..616a290 100644 --- a/src/or/router.c +++ b/src/or/router.c @@ -704,8 +704,8 @@ init_keys(void) ds = router_get_trusteddirserver_by_digest(digest); if (!ds) { ds = add_trusted_dir_server(options->Nickname, NULL, - (uint16_t)options->DirPort, - (uint16_t)options->ORPort, + router_get_advertised_dir_port(options), + router_get_advertised_or_port(options), digest, v3_digest, type); @@ -1165,6 +1165,36 @@ consider_publishable_server(int force) } } +/** Return the port that we should advertise as our ORPort; this is either + * the one configured in the ORPort option, or the one we actually bound to + * if ORPort is "auto". */ +uint16_t +router_get_advertised_or_port(or_options_t *options) +{ + if (options->ORPort == CFG_AUTO_PORT) { + connection_t *c = connection_get_by_type(CONN_TYPE_OR_LISTENER); + if (c) + return c->port; + return 0; + } + return options->ORPort; +} + +/** Return the port that we should advertise as our DirPort; this is either + * the one configured in the DirPort option, or the one we actually bound to + * if DirPort is "auto". */ +uint16_t +router_get_advertised_dir_port(or_options_t *options) +{ + if (options->DirPort == CFG_AUTO_PORT) { + connection_t *c = connection_get_by_type(CONN_TYPE_DIR_LISTENER); + if (c) + return c->port; + return 0; + } + return options->DirPort; +} + /* * OR descriptor generation. */ @@ -1398,8 +1428,8 @@ router_rebuild_descriptor(int force) ri->address = tor_dup_ip(addr); ri->nickname = tor_strdup(options->Nickname); ri->addr = addr; - ri->or_port = options->ORPort; - ri->dir_port = options->DirPort; + ri->or_port = router_get_advertised_or_port(options); + ri->dir_port = router_get_advertised_dir_port(options); ri->cache_info.published_on = time(NULL); ri->onion_pkey = crypto_pk_dup_key(get_onion_key()); /* must invoke from * main thread */ diff --git a/src/or/router.h b/src/or/router.h index 5e021f6..1bf1a51 100644 --- a/src/or/router.h +++ b/src/or/router.h @@ -50,6 +50,9 @@ int authdir_mode_publishes_statuses(or_options_t *options); int authdir_mode_tests_reachability(or_options_t *options); int authdir_mode_bridge(or_options_t *options); +uint16_t router_get_advertised_or_port(or_options_t *options); +uint16_t router_get_advertised_dir_port(or_options_t *options); + int server_mode(or_options_t *options); int public_server_mode(or_options_t *options); int advertised_server_mode(void);

1 0