[Geoff Down] [Polipo-users] Polipo crash (Vidalia Bundle) on OSX10.3.9
---BeginMessage--- Hello, the Polipo in https://www.torproject.org/dist/vidalia-bundles/vidalia-bundle-0.2.2.22-alpha-0.2.10-ppc.dmg crashes on startup as follows: dyld: /Applications/Vidalia.app.new/Contents/MacOS/polipo Undefined symbols: /Applications/Vidalia.app.new/Contents/MacOS/polipo undefined reference to ___stderrp expected to be defined in /usr/lib/libSystem.B.dylib /Applications/Vidalia.app.new/Contents/MacOS/polipo undefined reference to ___stdoutp expected to be defined in /usr/lib/libSystem.B.dylib Trace/BPT trap (This is a similar error message to that with which the Vidalia in that bundle crashes, even when Polipo is already running (an older version) and so Vidalia doesn't need to start it...) Regards, Geoff Down PS I haven't joined the list, so please cc me in any reply. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ ---End Message---
Re: Is gatereloaded a Bad Exit?
Been a fencesitter on this since posting the note about recording traffic that helped send this thread over the top. For once, I'm in agreement with Scott :) (and others) Badexiting based on exit policy seems rather silly as it will prevent nothing. And because of that, doing so is security theatre. Which sends both the project into questionable practice and the user into misplaced trust. If anything, the user should be educated instead. Nothing keeps an operator from dropping a gig split between 80 and 443. And if you defend against their rate limiting of 443 down to a meg, at best you've doubled their cost per eligible volume. No big deal. And due to typical protocol distribution on the open internet, if you force all operators to a fixed selection of 'ideal' policies, the cost per volume doesn't really change beyond that. It also seems the distribution of traffic around the nodes, operators, and globe won't change either... a broadbase level up is more likely, so there's no win there. Further, take the top fifth of exits by bandwidth, even take them all. No one can provably say whether or not any of them are recording traffic. And only a fool would trust an operator's (or shill's) statements to the contrary. The only way one can be sure is to stand watch over the node itself, in person. And lastly, some hat (or entity) packet groping their exit, or handfull of same, is the least of your worries. They're just a nuisance. It's the PA's and GPA's that one should be worried about. Seems everyone forgot that. They will always follow bandwidth, oppurtunity, interesting things and anomalies. Per the distribution notes above, and the architecture of Tor, exit policy doesn't seem likely to be interesting to a GPA. Badexit should be reserved only for those exits that are physically broken... modification of expected cleartext, corrupted ciphertext, certificate games, packet mischief, dns issues, upstream path issues, etc. The right thing to do with unprovable consipiracy theories such as exit sniffing, is to push it out to userland and provide tools for the user to manage it as desired. Some have suggested various node ranking metrics... Country, 'suspicious' strings in the nickname, 'suspicious' CIDR blocks, PTR's, ISP's etc, the preselected metrics and exit set of the 'badtornodes' guy, Scott and others, node keysigning parties, importable wiki [.onion] node config lists, and so on. Exit policy is currently at the operator's pleasure, need and design. If exit policy mandates will help solve some Tor scalability or attack vector issues, in a substantive way, from an engineering standpoint, fine. But please, don't claim it makes users any more 'safe' from sniffing. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Feedback and Suspicions about Tor...
Simply because every good thing needs checks, balances and feedback. Thus spoke Msr. Bennett: The tor project until very lately has always promoted end user understanding and responsibility. Now the project *appears* to be undergoing a major philosophical change toward nannying the tor user community, a direction I find very unappealing, to say the least. Horrifying might be a more appropriate word. Anonymity systems are potentially disruptive, facilitative of change, etc. People should not be surprised if *any* such system exhibits *any* such odd behaviors or deviations from norms. It would of course be nice if they were spoken. Tor seems to be doing a good job indicating the usefulness and application of anonymity to a wide variety of potential users. Moreso than before. But it does hesitate from suggesting that it can be used as a check and balance within the user's own particular state. Which is certainly an equally valid and worthy use case. Why does Tor not use a fully distributed model? Seems it's allowing itself to be shutdown by shutting down the Directory Authorities. And allowing censorship of any given .onion through the cooperation or coercion of same. Perhaps these are not true, or have been addressed technically elsewhere, for which a link would be welcome. Then again, if they're valid weaknesses, and only a technical change, why not put it on roadmap and do it? Perhaps others have other concerns or thoughts to voice. Nothing untowards, nor trolling, is meant by this thread. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Feedback and Suspicions about Tor...
On Thu, Feb 10, 2011 at 05:34:51PM -0500, grarpamp wrote: Tor seems to be doing a good job indicating the usefulness and application of anonymity to a wide variety of potential users. Moreso than before. But it does hesitate from suggesting that it can be used as a check and balance within the user's own particular state. Which is certainly an equally valid and worthy use case. Why does Tor not use a fully distributed model? Seems it's allowing itself to be shutdown by shutting down the Directory Authorities. Perhaps these are not true, or have been addressed technically elsewhere, for which a link would be welcome. Then again, if they're valid weaknesses, and only a technical change, why not put it on roadmap and do it? You may like: https://svn.torproject.org/svn/projects/design-paper/blocking.html (available via https://www.torproject.org/docs/documentation#DesignDoc) https://www.torproject.org/press/presskit/2008-12-19-roadmap-full.pdf (available via https://www.torproject.org/press/press) https://www.torproject.org/press/presskit/2010-09-16-circumvention-features.pdf (available via https://www.torproject.org/press/press) https://www.torproject.org/bridges https://blog.torproject.org/blog/tor-and-censorship-lessons-learned http://freehaven.net/anonbib/#danezis-pet2008 http://freehaven.net/anonbib/#ccs09-torsk http://freehaven.net/anonbib/#ccs09-nisan http://freehaven.net/anonbib/#ccs09-shadowwalker http://freehaven.net/anonbib/#wpes09-dht-attack http://freehaven.net/anonbib/#ccs10-lookup as for and do it, it's proving to be a bit more complex than that. And allowing censorship of any given .onion through the cooperation or coercion of same. Yeah, that hasn't been true for years. https://git.torproject.org/tor/doc/spec/rend-spec.txt but Karsten sure has been procrastinating about merging in proposal 114 to the rend-spec.txt file. Hope that helps, --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
advice on using accounting...
Hi onion peeps, I run a no-exit relay that can sustain about a hundred KB/s but I need to limit to about 4 GB/day to stay under bandwidth caps. I have accounting set up but what happens now is that it blows through that in 12 hours and then hibernates until the next day. However, because server descriptors aren't accepted into the consensus if they're not much different from the last one, at some point during hibernation my node appears to go down (presumably until it starts relaying again and publishes a significantly different descriptor). Is that the trade-off nodes that do bandwidth accounting have to make? That is, appear down due to the consensus refresh parameter of 12 hours? Are nodes that hibernate daily by definition not stable? (and in torstatus and torweather appear down for a large chunk of the day?) best, Joe -- Joseph Lorenzo Hall ACCURATE Postdoctoral Research Associate UC Berkeley School of Information Princeton Center for Information Technology Policy http://josephhall.org/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: advice on using accounting...
On Thu, Feb 10, 2011 at 06:19:27PM -0500, Joseph Lorenzo Hall wrote: I run a no-exit relay that can sustain about a hundred KB/s but I need to limit to about 4 GB/day to stay under bandwidth caps. I have accounting set up but what happens now is that it blows through that in 12 hours and then hibernates until the next day. Sounds reasonable. However, because server descriptors aren't accepted into the consensus if they're not much different from the last one, at some point during hibernation my node appears to go down (presumably until it starts relaying again and publishes a significantly different descriptor). Your node *is* down. That's what hibernation does. As soon as it goes into 'soft' hibernation, it closes its external ports. Next time the directory authorities test it for reachability, they will find that it is gone. That said, the authorities should be accepting your new descriptor, because it _is_ much different from the previous one. The hibernating 1 line makes it different. It also means that they won't wait until they've tried several reachability tests to mark you as not running, since you published an explicit I'm hibernating descriptor. Is that the trade-off nodes that do bandwidth accounting have to make? That is, appear down due to the consensus refresh parameter of 12 hours? Yes. Are nodes that hibernate daily by definition not stable? (and in torstatus and torweather appear down for a large chunk of the day?) Tor weather's behavior here may need some improvement. I haven't had time to look at how they determine whether you're hibernating vs down. It's quite possible they made some wrong assumptions when building that part. As for whether they're not stable by definition, the definition is that you have to be in the top half of nodes by mean-time-between-failure. So if many nodes have this behavior, some of them will end up with the stable flag. If few nodes do, probably none of them will get the stable flag. --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: advice on using accounting...
Thanks, Roger! I appreciate the clarification... if there is an effort to write a relay operator's manual I'd contribute to that. I've had a series of questions like this that could be answered by something less intense than having to look at the C/specs but more detailed than the current manual. Sorry to bug. best, Joe -- Joseph Lorenzo Hall ACCURATE Postdoctoral Research Associate UC Berkeley School of Information Princeton Center for Information Technology Policy http://josephhall.org/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Current state of affairs regarding Torservers.net
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Hi Joseph, On 09.02.2011 01:03, Joseph Lorenzo Hall wrote: At what point can torservers be confident it can support $800/month? It's a very tough decision to make. Our current funds ($2400) mean we would survive 3 months. Three months of beating the drum, incorporation, proper announcement and press release, finally translating the website, plus some nice ticking clocks and bars on the website and Kickstarter fundraising. State of affairs: 100tb doesn't respond 2host doesn't respond evoboxes isn't quite sure yet; cannot SWIP yet Most don't like us Other are too expensive: Professional offers start at ~500 Euro per 200 Mbps at the cheapest (with 100 of that already donated) FDC has a new datacenter in CZ, $300 for unmetered Gbit; not sure they would accept us, waiting on a reply. Mike Perry left and told me to better stay away, but he was at a US datacenter. http://www.webhostingtalk.com/showthread.php?t=1017226 And we don't even know if we can push the server to Gbit anyway. There seem to be some bottlenecks still hidden inside the code. Amunet is at not more than 800 Mbps most of the time. We can: * go with Swiftway in a strategic moment and hope for the best (in terms of bandwidth and publicity) * run the first Icelandic exit for 12€/Mbps * go with a reliable 200 mbps in Germany for ~500 Euro/mnth * try FDC * look/wait for better offers I think we should make a decision before, or, at the latest, at the foundation meeting. I haven't heard back from the tax authorities yet, I expect it to take no longer than one more week. I'm leaving Dresden for two weeks on 22nd, so Feb 19th would be the last possible ad hoc founding date or we'll have to postpone until mid March. If you want to discuss any of this, join us at irc.oftc.net #torservers, or contact me personally on XMPP mor...@torservers.net. - -- Moritz Bartl http://www.torservers.net/ -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJNVJJVAAoJEOGPxWJITcUAcvkIALa0NvvPqU9C5hA5OcemYTAk EjREQsuE6L8TpVTN0sp4pTCxk3QJ3RQ0Ygxlz2GKLXWuopOKu8D8mE6yb0IE4WHs 15aPZF1dttyiWEK3FEQb1BAZP2EFdeOin1xHtWmsNJrVUB3C6vim2XjtKLfjhZ75 XBFcfWoCgJ61ck2jWMHpr7LgLZQN7gWvf46HMY7Rxn/wlwJTXTedJ+DcPR4BIJkB 25W7TKm9qvTEl1C0eiYDwboNdzbES77Kzmrgyljk80vZvu/rV5jdQW3K8hasnh3f RIEoD3EJtHrPSi6KZ9H0vj1ysa8UJKg1v6W7FYtc7qel0JT5zojImTsOBk0Gobo= =feyN -END PGP SIGNATURE- *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: advice on using accounting...
On 2/10/2011 6:34 PM, Roger Dingledine wrote: On Thu, Feb 10, 2011 at 06:19:27PM -0500, Joseph Lorenzo Hall wrote: I run a no-exit relay that can sustain about a hundred KB/s but I need to limit to about 4 GB/day to stay under bandwidth caps. I have accounting set up but what happens now is that it blows through that in 12 hours and then hibernates until the next day. Sounds reasonable. [snip] I've been meaning to ask about this for awhile. Is it more helpful to the network to have (using this example) a node running at 100KB/s for 12 h/d, or limit it to 50KB/s and have it run 24/7? At what point does speed outweigh uptime (or vice versa)? ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
Thus spake grarpamp (grarp...@gmail.com): Exit policy is currently at the operator's pleasure, need and design. If exit policy mandates will help solve some Tor scalability or attack vector issues, in a substantive way, from an engineering standpoint, fine. But please, don't claim it makes users any more 'safe' from sniffing. I've already addressed the rest of your points. For the record, you're just strawmanning here. I never made the claim this was safer. I cited several engineering reasosn why this type of exit policy is a pain for us. I've also made the claim that there is no rational reason to operate an exit in this fashion, other than to log/monitor/censor traffic or because of undesirable network conditions, and no one has disputed that claim. Morphium gave us a reason, even if it was rather petty and irrational, so he won't be getting the badexit flag. But for my vote in the process, any other relay that does not give a reason for this policy, or that can not give us one because of no contact info, will be getting the flag. The same goes for exits that we detect RSTing 443, or censoring 443, or throttling 443, or doing anything else to TLS connections. But I only have one vote out of three. Roger and Peter are free to change their minds. Perhaps we should bring more people on board in this process, too. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpG9O9HmMzFj.pgp Description: PGP signature
Re: advice on using accounting...
On Thursday 10 February 2011 21:02:15 Aplin, Justin M wrote: I've been meaning to ask about this for awhile. Is it more helpful to the network to have (using this example) a node running at 100KB/s for 12 h/d, or limit it to 50KB/s and have it run 24/7? At what point does speed outweigh uptime (or vice versa)? Based on my experience running a node, first at 20 kB/s and now at 64 kB/s, I'd say it's better to keep it at 50 kB/s on all the time. But if your bandwidth cap is less than 50 kB/s, it may be better to hibernate. I get full 64 kB/s throughput some of the time, and not much the rest. I don't know if that means someone's downloading a big file and happened to pick me, or if there's a daily rhythm to the network usage. cmeclax *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Thu, 10 Feb 2011, Mike Perry wrote: Exit policy is currently at the operator's pleasure, need and design. If exit policy mandates will help solve some Tor scalability or attack vector issues, in a substantive way, from an engineering standpoint, fine. But please, don't claim it makes users any more 'safe' from sniffing. I've already addressed the rest of your points. For the record, you're just strawmanning here. I never made the claim this was safer. I cited several engineering reasosn why this type of exit policy is a pain for us. I think these reasons should be worked around or ignored. I think you, and others on that side of this argument have a very, very myopic view of the constraints and non-technical decisions that go into running a particular node - exit or not. Rich white people in the north can just trade some dollars for co-location, exercise their free speech, and argue back at the police, as their equals, when they come calling. That's not the case for everyone - and even in those rich, white countries, there are political and economic ramifications for running a Tor node, exit or otherwise, that seem to have not occurred to you. I've also made the claim that there is no rational reason to operate an exit in this fashion, other than to log/monitor/censor traffic or because of undesirable network conditions, and no one has disputed that claim. No, there is no _technical_ reason to operate an exit in this fashion. There is no reason, from a myopic, borderline autistic view of the externalities involved, to run an exit in this fashion. However, I can think of many, many reasons to: - run a node with no contact information - run a node with an odd set of exits - run a node with plain (unencrypted) exits - run a node with odd (non standard port) exits You have absolutely NO FUCKING IDEA what a node has been deployed for, who is using it, and how many layers of subterfuge are being employed between the external function and the true function underneath. Further, the power of a platform such as ToR is in the arbitrary extension of the base set of capabilities, and many, many different models of subterfuge, trust, anonymity, etc., can then be built - at arbitrary levels of complexity - and you are chopping those off at the knees. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Fri, Feb 11, 2011 at 6:58 AM, John Case c...@sdf.lonestar.org wrote: No, there is no _technical_ reason to operate an exit in this fashion. There is no reason, from a myopic, borderline autistic view of the externalities involved, to run an exit in this fashion. However, I can think of many, many reasons to: - run a node with no contact information - run a node with an odd set of exits - run a node with plain (unencrypted) exits - run a node with odd (non standard port) exits Can you please list some of the reasons for doing all of this at the same time? Since you reply here I assume you have read the posts in this very long thread, and Mike have already countered the given reasons, from a non-technical perspective. It would be nice if you could give an example that have not already been brought up, since you seem to know some. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On Fri, Feb 11, 2011 at 12:58 AM, John Case c...@sdf.lonestar.org wrote: I think these reasons should be worked around or ignored. I think you, and others on that side of this argument have a very, very myopic view of the constraints and non-technical decisions that go into running a particular node - exit or not. Rich white people in the north can just trade some dollars for co-location, exercise their free speech, and argue back at the police, as their equals, when they come calling. That's not the case for everyone - and even in those rich, white countries, there are political and economic ramifications for running a Tor node, exit or otherwise, that seem to have not occurred to you. As far as I can tell this is a completely spurious strawman argument. Where is this person with a legitimate reason why they can allow :80 and not :443? What is their reason? If anyone was showing up expressing this as a serious constraint with a legitimate cause, then it might be reasonable to reconsider. Certainly if there were many of them. If you want myopia, you need to look no further than this obsession with some speculative hypothetical universe where someone is going to be gravely injured by the tor network not choosing to use their :80 but not :443 exit. There are a great many ways to contribute to the tor network, so it isn't even as though their contributions are being turned away completely. Tor already has a great many tweaks and heuristics. Why are you not complaining about the exit load-balancing heuristic that denies the exit flag to nodes which don't exit to at least a /8 of several important ports? It impacts a great many more nodes. Or why not complain about the countermeasures against one hop usage that make nodes seizure targets and takes an unfair share of the bandwidth? Why are you not outraged about the hundreds and hundreds of bridge operators who are getting no use _at all_ because their identities are being held in reserve in order to build up decent pools of bridges for use with differentiated distribution? Will this contingent next be advocating not blacklisting exits known to insert malware or advertisements in the traffic because without this activity the exit operator can not afford to keep their exit going? If running an exit is somehow so imposing on someone that they feel the need to impose bizarre (even inexplicable) restrictions on its behaviour then they really should be helping the tor network in some other way — by running a bridge or a regular middle node. Or finding something else to do with their scarce resources. Tor needs people's help, sure, but it doesn't demand their blood. Why not let the rich white people in the north that you seem to have so much disdain for take a larger part of the exit burden? No, there is no _technical_ reason to operate an exit in this fashion. There is no reason, from a myopic, borderline autistic view of the externalities involved, to run an exit in this fashion. However, I can think of many, many reasons to: - run a node with no contact information - run a node with an odd set of exits - run a node with plain (unencrypted) exits - run a node with odd (non standard port) exits I personally run a node with an oddball exit policy (well, it's down at the moment due to a hardware failure). I wouldn't have any issue explaining the exit policy to someone who asked. (basically I have a node that exists to a collection of hand selected 'read only' websites, plus tcp dns to some dns servers, and a number of other assorted things that I know should will be free of complaint generating outcomes) But I don't care that it barely gets used as an exit (due to various technical details), nor would I care if tor changed in a way that would prevent it from it ever being used as an exit. Do you really think that someone who doesn't provide contact information is more likely to care about this sort of thing than me? You have absolutely NO FUCKING IDEA what a node has been deployed for, who is using it, and how many layers of subterfuge are being employed between the external function and the true function underneath. You could employ that same argument against _every_ _single_ technical or policy decision in the design and operation of the tor software and network. It's an information free argument. Ultimately the tor network is _not_ anyone's personal spy-business playground. It provides a real anonymity service to a great many people, and real censorship avoidance to a great many people. If it's also useful for things outside of this, then great, but you don't get to argue in favour of these non-primary uses when you can't even disclose what they are. There are too many real constraints on Tor already for people to worry about imaginary much less unimaginable ones! at arbitrary levels of complexity - and you are chopping those off at the knees. I am greatly disappointed by Tor's failure to steganographically
