This was one of my first questions in the project: How can we talk about stuff? I mean stuff like concepts or code that I don't understand, proposals to change or extend concepts or code, org stuff like where I can upload new specs or patches, and so on.
My first concerns were (and still are), that I could step on someone's nerves when discussing things in public mailing lists or IRC channels. Not everyone is interested in my questions, proposals, or even in the project. After being convinced by my mentors Roger and Nick I decided to give it a try. This is why the developers' mailing list is a little overcrowded by my questions at the moment. Sorry! I promise that this will at least decrease in the future.
Further, one needs to be even more careful what to write to a public mailing list, because it will be archived and read by even more people than the mentors who might pardon a silly question or proposal more easily. However, thinking about how to write a question once more is never a bad thing. And you are faced with the same problem when writing a blog entry, though. :)
A third concern to think about is that everyone can directly participate in your thoughts. Sounds egoistic, but in academia---as I know it---it's always an advantage to be some months earlier than others. Write a paper before someone else does. And papers are money. So, when talking about ideas in public you risk to bite the hand that feeds you. On the other hand I would not like to hide 3 years in my room just to come out with a unique idea. After all that takes too much time. I decided to take the plunge.
My conclusion is that I will try to make this project as open as I can. If someone feels that it's too much of a good thing, tell me. But I think that it's better to move a discussion from public to private rather than start a discussion in private that ought to be public.
Sonntag, 15. April 2007
Freitag, 13. April 2007
Welcome to GSoC project blog
Welcome to my Google Summer of Code (GSoC) project blog!
This project is about distributing the Tor directory for hidden service descriptors. Why that? Well, the simple answer is that the current solution does not scale. There may be an arbitrary number of hidden servers in the Tor network. But every hidden server needs to store a service descriptor on every directory servers (at the moment there are 5 in total). And all clients accessing a hidden server need to check one of these directory servers before establishing the connection. This may be okay for the moment, but the Tor network does not stop growing, so that "for the moment" is simply not enough.
The downside of the distribution is loss of authority over the directory (for hidden service descriptors, not router descriptors). Is this a problem? On first sight, no. Descriptors are self-signed and expire automatically after some hours and clients know the descriptor identifiers before accessing the service anyway. So what is the maximum damage that an adversary can cause? That a hidden service is unreachable. That means we have to talk about replication, Sybil attack, and trust. The approach may cause a degradation of the (at least in theory) 100% availability of hidden service descriptors. But we can try to make availability loss as small as possible to make it rather an academic issue than a practical problem.
If you like, you may want to read my full application for GSoC.
The purpose of this blog is to make the project as transparent as possible. I will try to post my thoughts and project progress regularly on this blog. This is both for documentation and as request for comments. If you have a new idea or find something completely stupid, drop me a comment and let's discuss it! Whenever there are final credits or something like that, you will be mentioned!
Just one word to my person: I am a PhD student at University of Bamberg, Germany. You can find more details on my university page (partly in German).
Summer can come!
This project is about distributing the Tor directory for hidden service descriptors. Why that? Well, the simple answer is that the current solution does not scale. There may be an arbitrary number of hidden servers in the Tor network. But every hidden server needs to store a service descriptor on every directory servers (at the moment there are 5 in total). And all clients accessing a hidden server need to check one of these directory servers before establishing the connection. This may be okay for the moment, but the Tor network does not stop growing, so that "for the moment" is simply not enough.
The downside of the distribution is loss of authority over the directory (for hidden service descriptors, not router descriptors). Is this a problem? On first sight, no. Descriptors are self-signed and expire automatically after some hours and clients know the descriptor identifiers before accessing the service anyway. So what is the maximum damage that an adversary can cause? That a hidden service is unreachable. That means we have to talk about replication, Sybil attack, and trust. The approach may cause a degradation of the (at least in theory) 100% availability of hidden service descriptors. But we can try to make availability loss as small as possible to make it rather an academic issue than a practical problem.
If you like, you may want to read my full application for GSoC.
The purpose of this blog is to make the project as transparent as possible. I will try to post my thoughts and project progress regularly on this blog. This is both for documentation and as request for comments. If you have a new idea or find something completely stupid, drop me a comment and let's discuss it! Whenever there are final credits or something like that, you will be mentioned!
Just one word to my person: I am a PhD student at University of Bamberg, Germany. You can find more details on my university page (partly in German).
Summer can come!
Abonnieren
Posts (Atom)