(Sending again so the list gets it) Your anonymization suggestion sounds a lot like i2p. Gnu social could likely work over it unmodified. http://www.i2p2.de/
Den 15 jul 2010 13.47, "Blaine Cook" <[email protected]> skrev: Thanks [everyone] for the feedback! These are exactly the sorts of details and trade-offs we need to sort out. On 15 July 2010 03:58, Ted Smith <[email protected]> wrote: > On Wed, 2010-07-14 at 02:34 +0100, Bla... > An editing note - you use the phrase "reader" in section 3, but it seems > like after that, you us... Yes - there was a change in terminology, something got mixed up. Thanks for catching that. :-) > The sort of thing in Figure 4 unnerves me - that sort of transparency in > the origin of a reques... The trade-offs here are not easy. If the data is just up on the internet, how do you signal to someone that they should fetch it? You could use Tor and poll your friends for updates, but that means that your latency will be *extremely* high, and that Tor would become a massive heat score (i.e., the incentive for attackers to "own" sufficiently large chunks of the Tor network becomes high enough that they will, and the privacy that you're trying to precipitate disappears, without you knowing it). Keep in mind that in order to discover the social graph (assuming the use of SSL), an attacker would need to gain control of either the Client or the Content Server, and then would only be able to determine links between users on the Client and Content Server. In a P2P scenario, this could be accomplished by installing malware on the target user's computer – something that's not at all difficult to do for the vast majority of cases. Moreover, it's important to not lose sight of the goal; people will only use a social network if it's possible to see the relationships and interconnectedness inherent in the graph. Our real-world social interactions do not happen in "cones of silence", A thought experiment (I don't know if this will address your concerns fully, but it's worth a shot): Given the scenario where sender identity is to be hidden from attackers who have access to either the Client or Content Server, what if we used an HTTPS-based mix network? If we can send messages from HTTP point A to HTTP point B, then we can essentially construct Tor-over-HTTP. This provides both the desired addressability and anonymity properties, and decomposes into something I can build and experiment with using little more than netcat and telnet. > I'm not sure if this is permitted by your specification, however. I'm > not really good at readin... To elaborate a bit, yes, as above it is permitted. Really, the only real constraint (and this is a social constraint that I am trying to support [not enforce] with technology) is that the *publisher* must know who the *user* is, so that the publisher can make a decision to share-or-not-share data with the user based on [[whatever metrics the publisher cares about]]. Ideally the user would be able to trust that they were receiving messages from a verifiable source, too. > Is that included in "Plenty"? :-P Yes :-D
