|
|
|
|
|
|
|
|
|
|
|
|
 HomeDownloadScreenshotsAnonymity CheckContact / ForumHelp & FAQLegal Notice Support AN.ON!Payment ServiceCrime PreventionAbuseSurvey HelpMix Config ToolVoluntary Commitment DocumentationRecent publicationsPress RoadmapsBugtrackingSource CodesCompiled Binaries
|
|
| |||||||||||||||||||
Privacy-friendly law enforcement |
| Simplified abstract All users logged into the system appear under a group pseudonym (Threshold group signature scheme) that is related to their IP address, but in a way that only all mixes together may uncover it (in order to conceal the IP in the group pseudonym, the first mix issues blind signatures). In order to use the service, they have to do signatures with their pseudonym, that can be verified by the last mix. These signatures may be assigned to a user IP, if a law enforcement agency presents a valid court order to all mixes for the surveillance of one or more URLs and the user visits one of these URLs, but only if all mixes work together. Even in this case, only this single IP is uncovered, which is not even visible by the mix operators, but by the law enforcement agency only (threshold atomic proxy reencryption). This revocation may be done in real-time or via data logged in the past. |
|
Privacy-friendly and multilaterally secure accounting system |
| Simplified abstract In order to use payment cascades, users have to create pseudonymous accounts at a distributed payment instance. These accounts may be charged by using different payment methods (Paysafe card, letters with cash, bank transfers, credit card,...) that can be chosen by the user. For payment methods that do not need any identification, no personal data will be used. For other ones, the data is erased ímmediately after accounting. Even the anonymous connection to the payment instance is possible (e.g. via noch-payment cascades). There will be basically two accounting models, that is temporary and not time-limited volume rates per megabyte (volume flatrates). The volume accounting models are offered by the payment instance's operator who pays off the single mixes according to their demands per data volume and who carries the corporate risk for the calculation of the flatrates. The prices per mix are determined independently by the mix operators (and are only known between operator and payment instance), but must be confirmed by the payment instance operator for granting a mix access to the accounting system. The preceding mixes of a cascade, respectively, send real-time proves for data volume to pay to each other, so that no mix operator may cheat another out of his money. The users, too, have not possibility to harm the accounting instance by sending as much data as possible via "expensive" cascades (that the payment instance provider has to pay according to the data sent), as they cannot "spend" a higher data volume that is loaded on their account. The prices the payment instance determines for the users should therefore be caclulated in a way that even the usage of "expensive" cascades does not cause any net loss for the payment instance. The payment instance (if is is not contacted anonymously) and also the first mixes, respectively, who do the accounting with the users, could link the pseudonymous account with user IP addresses, but do not store this data. Even if they did - the usage of the same pseudonymous account over a longer period would then conform to a service usage with a fixed IP address (within this period), and is therefore not much less anonymous than without payment. In contrast, certain attacks, that rely on introducing a lot of data into the system, will become very expensive now. For the payment system, more and especially faster servers will be set-up, that should be able to supply 2000 or more users without offering unacceptable speed. Moreover, the maximum user number on payment cascades is restricted to provide a constatly high performance. Users that are disconnected from the system may automatically (transparently) be reconnected to other pamyent cascades of their choice. |
|
Measurements of anonymous service usage |
| Simplified abstract In the course of some practical research we realised the correlation between latency in the anonymisation system and the number of users logged into it is linear, at least for the Dresden-Dresden cascade. This insight may help designing technical measures to strengthen anonymity that need a higher latency without diminishing the expected user numbers too strong. A performance measurement of different anonymisation services (Tor, AN.ON) gave some clues that the users might have a common tolerance level regarding latency (about 4 seconds), that adjusts itself if the users are randomly distributed on the servers of a service. This was concluded from the unverifiable latency difference between the very frequented Dresden-Dresden cascade and Tor. An analysis of the URLs requested via AN.ON has shown that 33% of them had erotic content, 26% were web-based services (including e-mail), 8% were corporate sites and the rest had very mixed content. Surprisingly, no URLs of web-shops or health portals have been observed. 60% of the users who requested these contents came from Europe, 27% from Asia and 12% from America, whereas the origin of some was not detectable because of the use of JAP-Forwarding-Servers. This means that AN.ON is still a primary inner-european anonymisation service.Users and requested URLs have not been linked together for these studies. |
|
|
|
 Stable Version 00.20.001 Beta Version 00.20.010  Status of available AN.ON services and information about them. |
|
|
 Restrictions for the Dresden (JAP) anonymisation servers After careful consideration we have decided to restrict the size of downloads over the Dresden (JAP) mixes a little. The reason is to allow a more fair use of scarce resources of our servers especially for users who simply want to surf the Web. more... |
Top
© 2000-2011
JAP Team
