[tor-dev] Attentive Otter IM: tomorrow Wednesday 2013-10-16 at 1400h Pacific
Sorry about this late notice too. I thought I'd sent these times out already, but apparently I was rather mistaken. We'll be in #tor-dev tomorrow Wednesday 2013-10-16 at 1430 Pacific to talk about the Tor IM project. We may take up to 90 minutes, and plan to meet again next week, probably at the same time unless there are conflicts. Arlo came up with [a cunning plan][1] m'lord. You should totes read it and come tomorrow with questions and suggestions about how best to implement Instantbird as the Tor IM app. See y'all tomorrow. Play nice, now. -Tom [1]: https://gist.github.com/arlolra/6969273 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Cute Otter hidden services & publishing: tomorrow Wednesday 2013-10-16 at 1130 Pacific
Sorry about the late notice, folks. I thought I'd sent these times out already, but apparently I was rather mistaken. We'll be in #tor-dev tomorrow Wednesday 2013-10-16 at 1130 Pacific to talk about hidden services, scaling thereof, and safe publishing therewith. We may take up to 90 minutes, and plan to meet again next week, probably at the same time unless there are conflicts. It'd be super neat if you could familiarize yourself with [Sina's proposal][1] before the meeting. Come with constructive comments and suggestions. See y'all tomorrow. -Tom [1]: https://lists.torproject.org/pipermail/tor-dev/2013-October/005558.html ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Hidden Service Scaling
On Sun, Oct 13, 2013 at 10:22:29PM +0100, Christopher Baines wrote: > On 09/10/13 18:05, Matthew Finkel wrote: > These two changes combined should help with the two goals. Reliability > is improved by having multiple OP's providing the service, and having > all of these accessible from the introduction points. Scalability is > also improved, as you are not limited to one OP (as described above, > currently you can also have +1 but only one will receive most of the > traffic, and fail over is slow). > >>> > >>> Do you see any disadvantages to this design? > >> > >> So, care needs to be taken around the interaction between the hidden > >> service instances, and the introduction points. If each instance just > >> makes one circuit, then this reveals the number of instances. > > > > Does it? > > Given the above, that is, each instance of the hidden serivce connects > once to each introduction point. Then the number of instances of a > hidden service, is equal to the number of connections with that each > introduction point sees with that key. > Ah, I missed something earlier, this makes more sense now. Thanks for reiterating that point. So, this having been said, do you have some thoughts on how to counter this? At this point, introduction points are selected at random, it will be unforunate if they can build a profile of a hidden service's usage over time. > >> There is also uncertainty around the replacement of failing introduction > >> points. New ones have to be chosen, but as the service instances do not > >> directly communicate, there could be some interesting behaviour unless > >> this is done carefully. > > > > Is there a reason they shouldn't communicate with each other? > > I have avoided it so far, as it increases the complexity both the > implementation and setup. However, this is probably a minor issue, as > the major issue is how service providers would want to use this? Complex > hidden services (compared to hidden services with static content) will > probably require either communication between instances, or > communication from all instances to another server (set of servers)? It will surely increase the complexity, however allowing the hidden service peers to coordinate their introduction points (and/or other information) could be a useful feature. This could be especially true if we want to address the "all introduction points know the number of hidden service instances that constitute a hidden service address" problem. As a general rule, we want to minimize the number of nodes that are given a priviledged position within the network. As an example, if we go back to my earlier comment and assume all instances of a hidden service use the same introduction points, then a client will use any one of the introduction points with equal probability. Given this, an introduction point 1) knows the size (number of instances) of the hidden service, 2) can influence which hidden service instances are used by clients, 3) can communicate with a HS without knowing who it is, and 4) can potentially determine the geographical location of the hidden service's users (based on when it is used). These last few points are not unique to your design and the last point is not unique to introduction points, but these leakages are important and we should try to account for them (and plug them, if possible). (This is not an exhaustive list) > I am aware that there are several undefined parts of the above > description, e.g. how does a introduction point choose what circuit to > use? but at the moment I am more interested in the wider picture. It > would be good to get some feedback on this. > > 1: https://blog.torproject.org/blog/hidden-services-need-some-love > 2: > http://tor.stackexchange.com/questions/13/can-a-hidden-service-be-hosted-by-multiple-instances-of-tor/24#24 > >>> > >>> This is a good start! Some important criteria you might also think > >>> about include how much you trust each component/node and which nodes do > >>> you want to be responsible for deciding where connections are routed. > >>> Also seriously think about how something like a botnet that uses hidden > >>> services might impact the reliability of your design (crazy idea, I > >>> know). > >> > >> I assume the characteristics of this are: 1 or more hidden service > >> instances, connected to by very large numbers of clients, sending and > >> reviving small amounts of information? > > > > Perhaps, but just think about the load an intro point can handle and > > sustain. If Introduction Points are where load balacing takes place, > > then does this affect the difficulty of attacking a hidden service? (for > > some undefined definition of 'attack'.) > > At the moment, I am really considering the redundancy and scalibility of > the serivce. Both of these could be helped by allowing for > multi-instance hidden serivces (in a planned and thought through manor). > H
Re: [tor-dev] Comments Requested: General anonymity with Tor video
A couple of things: 1. Number the slides in the bottom, it's mildly useful :-) 2. Mention the licenses of these slides for redistribution (Creative Commons, anyone?) 3. The "Browsing through the Tor network..." bubble seems a bit small and thusly looks like an annotation that is lost in the diagram. Maybe make it bigger or have it encapsulate the 3 nodes with a mild grey background. This is on the slide 6 (titled "Browsing the internet through Tor") 3 and 1/2. Same applied for Slide 5, "This is how you browse the internet..." 4. Maybe a near-final slide jokingly stating that It's "Tor" not "TOR", but maybe that's a bit too tongue in cheek or off-topic. 5. Provide a short link for the "running relay/bridge/node" that goes to a decent intro of what that means. 6. The use of the word "documents" might make users think that means "all downloaded files", maybe update to mention "(doc, pdf)" in brackets in addition to you mentioning it in script (which I see you do). On Tue, Oct 15, 2013 at 4:07 PM, Sherief Alaa wrote: > Hello Everyone, > > I am working on a general anonymity with Tor video [0] and a script [1] > for it. This video will be translated to all of the help desk languages. > > Basically, the video will some slides playing while I talk/explain them, > both the video script and the slides can be found on trac [0][1] > > I would appreciate your comments/suggestions before I start recording the > video. (Deadline 18-Oct-2013.) > > If you find any mistakes, please let me know here or on trac [0][1] > > Thanks! > > [0] https://trac.torproject.org/projects/tor/ticket/5991 > [1] https://trac.torproject.org/projects/tor/ticket/6922 > > -- > Sherief Alaa > pgp 0x8623B882 > > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > -- Best Regards, Justin Bull E09D 38DE 8FB7 5745 2044 A0F4 1A2B DEAA 68FD B34C ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Comments Requested: General anonymity with Tor video
Hello Everyone, I am working on a general anonymity with Tor video [0] and a script [1] for it. This video will be translated to all of the help desk languages. Basically, the video will some slides playing while I talk/explain them, both the video script and the slides can be found on trac [0][1] I would appreciate your comments/suggestions before I start recording the video. (Deadline 18-Oct-2013.) If you find any mistakes, please let me know here or on trac [0][1] Thanks! [0] https://trac.torproject.org/projects/tor/ticket/5991 [1] https://trac.torproject.org/projects/tor/ticket/6922 -- Sherief Alaa pgp 0x8623B882 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] REMINDER: Boisterous Otters helpdesk meeting in 1h
Today at 1100h Pacific (an hour from now), we'll be in #tor-dev to discuss how we're going to start offering webchat support, in line with the [draft][1] produced by Colin (Phoul), with help from Lunar and Erinn (Helix). See y'all soon! -Tom [1]: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter/Boisterous/WebChat ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
