Re: [freenet-dev] Summary of recent opennet discussions
On Friday 02 Aug 2013 19:12:31 Peter Todd wrote: On Thu, Jul 25, 2013 at 12:36:34PM +0100, Matthew Toseland wrote: Basically the security model is now an attacker has to outspend the defenders in terms of Bitcoins sacrificed. Not perfect, but it may be of value, especially in conjunction with other protections. They do have potential anonymity issues, but we're talking about opennet where the attacker knows your IP address anyway. There's also a varient of proof-of-sacrifice where you prove you attempted to create Bitcoins, a proof that has no linkage to any other Bitcoin transaction. AFAICS this is a slightly more complex form of pay to join, with the dubious advantage that nobody gets the money. In theory this might help people to not think we're scammers (although transient mode is more important to that end) ... but by the time you've explained it, you've lost them anyway, so I doubt it's worth the additional complexity. Well any decentralized attempt to limit sybil attacks and other attacks via some kind of limited resource ultimately boils down to pay to join, the question is what are you paying and how likely are honest users to already have what they need to pay? It's likely that for the foreseeable future, any attempt to charge an entry fee will result in losing a lot of nodes... (Not existing nodes, but potential nodes). Social issues are a real concern - we have this same problem in Bitcoin with SPV nodes, like a light-weight smartphone wallet, that aren't contributing back to the network but are consuming resources. How do you distinguish between a botnet pretending to be tens of thousands of smart phones and tens of thousands of real ones? People are allergic to any kind of fee... Another option you might want to consider is proof-of-work. In some ways it's not as effective, because like I said before often the actual cost to attackers is less, but the social dimensions may be more effective. What are your thoughts there? The proof-of-work could easily be something that is gradually phased out and replaced by proof-of-useful-work as the opennet peer responds to more and more requests, doing useful work. Proof of work meaning hashcash? This is always going to be vastly cheaper for a competent attacker than for a user with low end hardware. signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Summary of recent opennet discussions
On Thu, Jul 25, 2013 at 12:36:34PM +0100, Matthew Toseland wrote: Basically the security model is now an attacker has to outspend the defenders in terms of Bitcoins sacrificed. Not perfect, but it may be of value, especially in conjunction with other protections. They do have potential anonymity issues, but we're talking about opennet where the attacker knows your IP address anyway. There's also a varient of proof-of-sacrifice where you prove you attempted to create Bitcoins, a proof that has no linkage to any other Bitcoin transaction. AFAICS this is a slightly more complex form of pay to join, with the dubious advantage that nobody gets the money. In theory this might help people to not think we're scammers (although transient mode is more important to that end) ... but by the time you've explained it, you've lost them anyway, so I doubt it's worth the additional complexity. Well any decentralized attempt to limit sybil attacks and other attacks via some kind of limited resource ultimately boils down to pay to join, the question is what are you paying and how likely are honest users to already have what they need to pay? It's likely that for the foreseeable future, any attempt to charge an entry fee will result in losing a lot of nodes... (Not existing nodes, but potential nodes). Social issues are a real concern - we have this same problem in Bitcoin with SPV nodes, like a light-weight smartphone wallet, that aren't contributing back to the network but are consuming resources. How do you distinguish between a botnet pretending to be tens of thousands of smart phones and tens of thousands of real ones? People are allergic to any kind of fee... Another option you might want to consider is proof-of-work. In some ways it's not as effective, because like I said before often the actual cost to attackers is less, but the social dimensions may be more effective. What are your thoughts there? The proof-of-work could easily be something that is gradually phased out and replaced by proof-of-useful-work as the opennet peer responds to more and more requests, doing useful work. -- 'peter'[:-1]@petertodd.org 00717df9323a96a2c158b1be0249d0762d3b966e861d728a7b67 signature.asc Description: Digital signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Summary of recent opennet discussions
On Mon, Jul 22, 2013 at 03:18:32PM -0500, Robert Hailey wrote: Judging from a business-process perspective, if it were up to me (and it's not!) I would elect to do these two options. Direct paypal for those that want it now (and they likely have a paypal account). I presume this is pretty easy. Vanilla Yubikeys ... for those who don't want to use paypal (but don't mind waiting). Atop of the base amount of work that the other mechanisms need anyway, this is trivial. In such a case, we then only alienate those who are both paranoid *AND* impatient; plus we give them a choice, and don't require that they obtain the yubikey in any particular way (only that it has the stock identity). What's more, implementing both of these options is probably simpler than implementing *only* a BTC workflow. Speaking of Bitcoins... As Matthew Toseland said at the top of this thread: Surveillance: Connect to every node, log all the inserts for a month (freenet content doesn't last long if not requested). Connect it to announced content. Surprisingly cheap, given our relatively low bandwidth usage per peer etc, and it will become cheaper per node as the network grows because bandwidth (and everything else) gets *really* cheap in large volumes. This is a Sybil attack: The only way to beat it is by using some sort of scarcity. Have you guys looked into using Bitcoin fidelity bonds? Basically the idea is you associate your pseudonym with the act of destroying or giving away some Bitcoins - a scarce resource - thus making a normally cheap pseudonym expensive. Since they are denominated in Bitcoins the cost for the attacker is the same as the defender - often not the case, eg. bandwidth or ip addresses which are much cheaper in bulk. Verifying fidelity bonds (specifically the Bitcoin sacrifice proofs within them) is quite cheap to do and requires only block headers - about 5MB of data a year. Basically the security model is now an attacker has to outspend the defenders in terms of Bitcoins sacrificed. Not perfect, but it may be of value, especially in conjunction with other protections. They do have potential anonymity issues, but we're talking about opennet where the attacker knows your IP address anyway. There's also a varient of proof-of-sacrifice where you prove you attempted to create Bitcoins, a proof that has no linkage to any other Bitcoin transaction. Of course they could also be useful for anti-spam on FMS/Front/Sone and so forth, especially as captcha-solving technology gets better. The puzzle system is clever, but probably won't work forever. 1) https://en.bitcoin.it/wiki/Fidelity_bonds -- 'peter'[:-1]@petertodd.org 003ccba88d8a6838d94c6417e5a0b70685125af8f70f6803aaa3 signature.asc Description: Digital signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Summary of recent opennet discussions
On Thursday 25 Jul 2013 07:48:39 Peter Todd wrote: On Mon, Jul 22, 2013 at 03:18:32PM -0500, Robert Hailey wrote: Judging from a business-process perspective, if it were up to me (and it's not!) I would elect to do these two options. Direct paypal for those that want it now (and they likely have a paypal account). I presume this is pretty easy. Vanilla Yubikeys ... for those who don't want to use paypal (but don't mind waiting). Atop of the base amount of work that the other mechanisms need anyway, this is trivial. In such a case, we then only alienate those who are both paranoid *AND* impatient; plus we give them a choice, and don't require that they obtain the yubikey in any particular way (only that it has the stock identity). What's more, implementing both of these options is probably simpler than implementing *only* a BTC workflow. Speaking of Bitcoins... As Matthew Toseland said at the top of this thread: Surveillance: Connect to every node, log all the inserts for a month (freenet content doesn't last long if not requested). Connect it to announced content. Surprisingly cheap, given our relatively low bandwidth usage per peer etc, and it will become cheaper per node as the network grows because bandwidth (and everything else) gets *really* cheap in large volumes. This is a Sybil attack: The only way to beat it is by using some sort of scarcity. Have you guys looked into using Bitcoin fidelity bonds? Basically the idea is you associate your pseudonym with the act of destroying or giving away some Bitcoins - a scarce resource - thus making a normally cheap pseudonym expensive. Since they are denominated in Bitcoins the cost for the attacker is the same as the defender - often not the case, eg. bandwidth or ip addresses which are much cheaper in bulk. Verifying fidelity bonds (specifically the Bitcoin sacrifice proofs within them) is quite cheap to do and requires only block headers - about 5MB of data a year. Basically the security model is now an attacker has to outspend the defenders in terms of Bitcoins sacrificed. Not perfect, but it may be of value, especially in conjunction with other protections. They do have potential anonymity issues, but we're talking about opennet where the attacker knows your IP address anyway. There's also a varient of proof-of-sacrifice where you prove you attempted to create Bitcoins, a proof that has no linkage to any other Bitcoin transaction. AFAICS this is a slightly more complex form of pay to join, with the dubious advantage that nobody gets the money. In theory this might help people to not think we're scammers (although transient mode is more important to that end) ... but by the time you've explained it, you've lost them anyway, so I doubt it's worth the additional complexity. It's likely that for the foreseeable future, any attempt to charge an entry fee will result in losing a lot of nodes... (Not existing nodes, but potential nodes). Of course they could also be useful for anti-spam on FMS/Front/Sone and so forth, especially as captcha-solving technology gets better. The puzzle system is clever, but probably won't work forever. Yes. :( Bitcoin isn't all that anonymous at the moment, and isn't very convenient, and people's access to money varies enormously. There are other possible answers for spam-proof announcement for services inside Freenet, but only on darknet. signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Summary of recent opennet discussions
> One problem with the yubikey thing is it takes time to deliver them. > Hence the need to be able to just buy an invite e.g. with BTC. I agree that yubikey can't be the only way to introduce core nodes. There should be a (near) instant method as well. > On the level of tunnels - what I would consider real security - it's > a major unsolved problem in academia. (Tunnel setup on DHTs) I'm probably speaking out of my ass now (I promise to read more on it), but isn't the whole problem here that on DHTs, nodes don't have access to the complete node pool, so attacker can influence a set of nodes chosen for the tunnel, making compromised nodes progressively more likely to be chosen? If this is correct, can't we just side-step this problem by keeping full node tables in all bootstrap nodes? For a million nodes and 1K structure per node (which is probably an upper estimate), it's just 1G total. I think it can easily be fully distributed (i.e., without any partitioning) over a set of bootstrap nodes; when new core nodes contact bootstrap nodes, bootstrap nodes collectively produce whatever bootstrap information is required (set of node references for tunneling, location, etc), and update node information in their tables (like IP address, last seen time, etc). >>> If you trust your friends less than you trust the jack-boots, >>> then you probably don't have much to fear from the jack-boots. >> >> As I'd mentioned in a previous email, it's not a question of trust >> as is, it's a question of damage my friend can do to me if he >> decides to betray my trust. > > No. If they can prove that a given IP address at a given time > uploaded a given illegal file, game over. Or downloaded it, but > uploaders are worth more. That's the only safe assumption. Then neither darknet nor (current) opennet can work - at all. Basically, I'm trusting my friends to not disclose that I'm running Freenet - but no more than that. >> I still don't get why it happens. Are torrent clients run by >> significantly different slice of users? Again: I can reliably >> demonstrate speeds of *at least* 500 KB/s for any torrent with 10+ >> peers; with 20 peers, 90% of torrents, taken from all over the >> world, will max out my internet connection. This indicates average >> upload speeds of at least 50 KB/s, and probably closer to 100 KB/s >> (and with most connections being asymmetric in one way or another, >> we can safely assume that upload bandwidth is the limiting >> factor). > > Because torrent traffic is more bursty than Freenet? I.e. most of the > time they are idle? It's one possible explanation. I wonder if we can get a distribution of traffic on a node over the applications accessing it? Can I find out somehow how much physical traffic is associated with, i.e., FMS? This would be a very interesting stat, IMO. VD.
Re: [freenet-dev] Summary of recent opennet discussions
On Tuesday 23 Jul 2013 09:32:31 Victor Denisov wrote: One problem with the yubikey thing is it takes time to deliver them. Hence the need to be able to just buy an invite e.g. with BTC. I agree that yubikey can't be the only way to introduce core nodes. There should be a (near) instant method as well. On the level of tunnels - what I would consider real security - it's a major unsolved problem in academia. (Tunnel setup on DHTs) I'm probably speaking out of my ass now (I promise to read more on it), but isn't the whole problem here that on DHTs, nodes don't have access to the complete node pool, so attacker can influence a set of nodes chosen for the tunnel, making compromised nodes progressively more likely to be chosen? If this is correct, can't we just side-step this problem by keeping full node tables in all bootstrap nodes? For a million nodes and 1K structure per node (which is probably an upper estimate), it's just 1G total. I think it can easily be fully distributed (i.e., without any partitioning) over a set of bootstrap nodes; when new core nodes contact bootstrap nodes, bootstrap nodes collectively produce whatever bootstrap information is required (set of node references for tunneling, location, etc), and update node information in their tables (like IP address, last seen time, etc). How does this help with tunnel setup? Also, it's only practical if core nodes have very high uptime; update traffic is the problem for such schemes in practice. If you trust your friends less than you trust the jack-boots, then you probably don't have much to fear from the jack-boots. As I'd mentioned in a previous email, it's not a question of trust as is, it's a question of damage my friend can do to me if he decides to betray my trust. No. If they can prove that a given IP address at a given time uploaded a given illegal file, game over. Or downloaded it, but uploaders are worth more. That's the only safe assumption. Then neither darknet nor (current) opennet can work - at all. Basically, I'm trusting my friends to not disclose that I'm running Freenet - but no more than that. No, anything with proper tunnels can work fine. I still don't get why it happens. Are torrent clients run by significantly different slice of users? Again: I can reliably demonstrate speeds of *at least* 500 KB/s for any torrent with 10+ peers; with 20 peers, 90% of torrents, taken from all over the world, will max out my internet connection. This indicates average upload speeds of at least 50 KB/s, and probably closer to 100 KB/s (and with most connections being asymmetric in one way or another, we can safely assume that upload bandwidth is the limiting factor). Because torrent traffic is more bursty than Freenet? I.e. most of the time they are idle? It's one possible explanation. I wonder if we can get a distribution of traffic on a node over the applications accessing it? Can I find out somehow how much physical traffic is associated with, i.e., FMS? This would be a very interesting stat, IMO. We don't collect that data at present. We could, if we can identify requests associated with FMS. VD. signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Summary of recent opennet discussions
> Exactly my point... why, then, does the common case need freenet. It doesn't. This is bad how? VD.
[freenet-dev] Summary of recent opennet discussions
> But let us not forget what I consider to be more common use case (for > which we are not optimized and has nothing to do with child porn)... > > I have a friend, and would like to communicate with him/her > "securely" in an email or instant-message like way. This is trivial without Freenet - just exchange your PGP keys and send each other encrypted email. And I believe a number of XMPP clients also support PGP encryption, solving the need for secure one-on-one and group communications. Freenet's main attraction is a resilient, censorship-resistant, distributed data store. That works well for one-to-many applications; moderately well for one-to-group applications; and not so well for many-to-many and one-to-one applications, unfortunately. Regards, Victor Denisov.
[freenet-dev] Summary of recent opennet discussions
>> 1. Paying for becoming a "VIP" Freenet node is not out of the >> question (people buy invites to elite torrent trackers for sizable >> amount of money), but the benefits must be *very* obvious. > > There's no point if it's only the handful of elite nodes. It needs to > be the bulk of the network - everyone who routes requests where they > could conceivably spy on other nodes. The benefits could be made > obvious though: If we have a high bandwidth threshold then we'll have > much higher average transfer rates, and people will have less need to > hack their nodes to have 500 peers, as the Japanese are doing on > Frost after Winny and Perfect Dark fell down. "Elite" trackers have tens of thousands of users. Granted, most of those obtained their invites for free; but a fair amount had paid anywhere between $5 and $100 for such invites. > There isn't anything else. Except darknet. And everyone keeps telling > me that darknet is impossible, at least until the network is much > bigger. We (as a community) just hadn't figured out such a way, IMO. Perhaps it doesn't really exist - I'm not qualified enough to tell yet - but I highly doubt it. > On opennet, your peers choose you. Hence MAST and connect-to-everyone > surveillance. On darknet, you choose your peers. Umm, would there be any benefit to security if this was reversed? If Freenet will go down the "tangible verification" route (certificates, yubikeys, whatever), hiding the fact that you run a Freenet node would become pointless anyway. > If you trust your friends less than you trust the jack-boots, then > you probably don't have much to fear from the jack-boots. As I'd mentioned in a previous email, it's not a question of trust as is, it's a question of damage my friend can do to me if he decides to betray my trust. >> 4. I think that performance issues *absolutely* should be handled >> before anything else, even before security. I understand that many >> - even most - will disagree with me, but if I found *one* thing >> from practice, it is that people widely prefer less secure, but >> working, systems to more secure, but non-working, ones. > > Right up until the point when somebody publishes a toolkit for MAST, > and a list of paedophiles they busted with it. That's sort of a catch 22. The network won't be "worthy" of growing until it's secure, but it won't be secure until it grows. I'm not saying security isn't important; that would be stupid. But for an *experimental* network *under heavy development* lightly secure, but well-performing, network will be preferable to very secure (until the next attack vector is found), but poorly-performing, network. >> Right now, Freenet exhibits a level of performance which can only >> be called "abysmal". I can download torrents at 4 MB/s, reliably, >> one after another, from different trackers in different countries; >> considering that in Freenet mine (and everyone's else) traffic >> should pass through several nodes (say, 20 of them, worst case), > > Typically for requests it should be 5-7 or thereabouts. Yes, that's why I'm assuming 20 as worst case. >> I'd say Freenet should provide around 200 KB/s of sustained >> download performance (with the rest of my pipe being donated to >> other nodes, thus hiding my traffic). In reality, in my tests, on a >> lightly-loaded and well-integrated node I'm lucky to see speeds >> above 10 KB/s, with "typical" downloads making 2-3 KB/s on average, >> start to finish. My node with 90 peers only consumes around 200-250 >> KB/s (out of 1 MB/s allocated); my higher bandwidth allocation is >> effectively *wasted* by the inefficient network. > > Most nodes have relatively low bandwidth limits. We could boost > performance by excluding slow nodes (say under 40KB/sec). This is the > first part of the proposal. Of course we'd lose a large number of > nodes - but we'd probably gain more to compensate when performance > improves. I still don't get why it happens. Are torrent clients run by significantly different slice of users? Again: I can reliably demonstrate speeds of *at least* 500 KB/s for any torrent with 10+ peers; with 20 peers, 90% of torrents, taken from all over the world, will max out my internet connection. This indicates average upload speeds of at least 50 KB/s, and probably closer to 100 KB/s (and with most connections being asymmetric in one way or another, we can safely assume that upload bandwidth is the limiting factor). >> If another major rewrite of Freenet is ahead (which, I'd argue, is >> long overdue), I'd be happy to provide more input (i.e., I think >> that filesharing and social communication is *much* more important >> than keyword search and site publishing), but I feel this email is >> already too bloated :-(. > > Filesharing implies keyword search, no? At the very least it requires > working forums. Filesharing implies content indices of one sort or another, that's true. But it doesn't imply, for example, spidering for content, like
[freenet-dev] Summary of recent opennet discussions
> 2) Most people on Freenet have no real enemies and so care far too > much about their friends' feelings and not enough about their actual > enemies, compared to our threat model. I think it's slightly different. Let's imagine I'm a passive pedophile; a stranger sees me watching child porn in the park and calls the police. If I scram immediately, chances of me getting caught would be (relatively) low. If my friend will see me watching child porn (or doing anything similarly offensive), chances are high that I'm doomed, as he'll be able to provide law enforcing agencies with enough information to virtually guarantee my capture. Same with Freenet. When a stranger (no matter if he's an active attacker or a casual observer) detects that my node transfers objectionable material, it's one thing. "They" - at least, with the current judicial system in the (more or less) developed countries - still have to seize my computer and find the evidence there, attempting which will, or will not be, successful. If a friend detects that same transfer, and finds it objectionable enough to alert the authorities - and, let's face it, most *real* free speech contents *will be* objectionable for the majority of people - I'm doomed, as he'll be able to provide enough evidence - possibly even by using my trust to compromise my computer, etc. Regards, Victor Denisov.
[freenet-dev] Summary of recent opennet discussions
A number of somewhat-connected observations from someone who had been following Freenet since early 0.3 days: 1. Paying for becoming a "VIP" Freenet node is not out of the question (people buy invites to elite torrent trackers for sizable amount of money), but the benefits must be *very* obvious. 2. However, any reasonable amount you can ask from users can easily be matched by a dedicated attacker. If I'm correct and an attacker will need to roughly match the network size for a successful attack, then matching a network of 100K nodes, each of which had paid, say, $5 to join, would require $500K - heck, even I, being a (relatively) poor scientist, would probably be able to raise that money in a couple of months (by, i.e., selling off all my property, getting to my eyeballs in debt, etc) if I'd be really motivated (i.e., to find a pervert who raped my daughter and posted video of that on Freenet, or something). Even if nodes would be paying $50 to join (which I don't think is a realistic amount), an attacker would still need to come up with just $5M, which isn't that much for a middle-sized private company, and is chump change for any government agency. 2a. Yes, that means that, in my opinion, we can't look to money for scarcity, it should be obtained from somewhere else. To find it, I think that threat model should be defined better. Fighting a bored millionaire (or a vigilante, or a mad corporate head looking for a whistleblower) is one thing; fighting a government agency is another. For example, it would be difficult for a vigilante with money to come up with 100K valid national ids; it would be completely trivial for a government agency. 3. I also think that Freenet project has been getting it wrong for the past couple of years. "Somewhat" secure opennet must come before *any* attempt at building darknets, however "romantic" those seem to be on paper. The reason is, IMHO, two-fold: a) most people *won't* trust their RL friends for most of the activities that Freenet would *actually* be useful for. I may trust my friends enough to let them know that I download warez (or porn, whatever); but if I'm a government whistleblower (or a pedophile, or marijuana grower) I *definitely* would like my friends to know about that last, not first. b) we can't expect a well-connected darknet to form right from the beginning; most likely, its growth will be organic, starting from small non-connected cells - in this case, a well-working opennet will provide the initial "glue" to connect those together. In any case, I think it's not a good idea to work on darknet before opennet works as well as can be (reasonably) expected - more on that right below. 4. I think that performance issues *absolutely* should be handled before anything else, even before security. I understand that many - even most - will disagree with me, but if I found *one* thing from practice, it is that people widely prefer less secure, but working, systems to more secure, but non-working, ones. Right now, Freenet exhibits a level of performance which can only be called "abysmal". I can download torrents at 4 MB/s, reliably, one after another, from different trackers in different countries; considering that in Freenet mine (and everyone's else) traffic should pass through several nodes (say, 20 of them, worst case), I'd say Freenet should provide around 200 KB/s of sustained download performance (with the rest of my pipe being donated to other nodes, thus hiding my traffic). In reality, in my tests, on a lightly-loaded and well-integrated node I'm lucky to see speeds above 10 KB/s, with "typical" downloads making 2-3 KB/s on average, start to finish. My node with 90 peers only consumes around 200-250 KB/s (out of 1 MB/s allocated); my higher bandwidth allocation is effectively *wasted* by the inefficient network. If another major rewrite of Freenet is ahead (which, I'd argue, is long overdue), I'd be happy to provide more input (i.e., I think that filesharing and social communication is *much* more important than keyword search and site publishing), but I feel this email is already too bloated :-(. With best regards, Victor Denisov.
[freenet-dev] Summary of recent opennet discussions
On 2013/07/22 (Jul), at 2:57 PM, Robert Hailey wrote: > * If we use direct paypal, the paranoid will avoid it like the plague (paypal > records!) > ... > * If we use vanilla yubikeys, the impatient will eschew the whole process by > a wide birth, and the project doesn't get the funding. On 2013/07/22 (Jul), at 10:57 AM, Ian Clarke wrote: > Most of the proposals below are directly contrary > to usability - we need to encourage people to contribute to the Freenet > network, not punish them for it, nor make them jump through unnecessary > hoops. Judging from a business-process perspective, if it were up to me (and it's not!) I would elect to do these two options. Direct paypal for those that want it now (and they likely have a paypal account). I presume this is pretty easy. Vanilla Yubikeys ... for those who don't want to use paypal (but don't mind waiting). Atop of the base amount of work that the other mechanisms need anyway, this is trivial. In such a case, we then only alienate those who are both paranoid *AND* impatient; plus we give them a choice, and don't require that they obtain the yubikey in any particular way (only that it has the stock identity). What's more, implementing both of these options is probably simpler than implementing *only* a BTC workflow. -- Robert Hailey
[freenet-dev] Summary of recent opennet discussions
On 2013/07/22 (Jul), at 2:22 PM, Matthew Toseland wrote: > One problem with the yubikey thing is it takes time to deliver them. Depending upon the expected use case and average psychology (patience), that might be the only critical issue... and yet, it would be an issue with *any* hardware solution. As I noted in the other thread, it might be possible to ameliorate this if one could join the darknet by conveyance, or if the node operated as a leaf (or limited performance / outer-network). In either case, they could get the yubikey later. > Hence the need to be able to just buy an invite e.g. with BTC. That sounds simple, but how much work (both for you once & for the onboarding user) does that require?! AFAICS, this is a rock-paper-scissors situation. * If we use direct paypal, the paranoid will avoid it like the plague (paypal records!) * If we use BTC, the technically challenged will get lost in trying signing up for new accounts, funding them, installing software, setting up the transaction, and sending the coins * If we use vanilla yubikeys, the impatient will eschew the whole process by a wide birth, and the project doesn't get the funding. * If we use custom-programmed yubikeys, we need more infrastructure & processes than might be practical [and we still lose the impatient crowd] ... and if we do nothing, there is no way to call opennet reasonably secure. ... and if we implement more than one of the above, we'll probably make toad go crazy by reduplication of effort. Is there any winning? -- Robert Hailey
[freenet-dev] Summary of recent opennet discussions
On 2013/07/22 (Jul), at 1:21 PM, Victor Denisov wrote: > [Point to point communication] is [relatively easy] without Freenet Exactly my point... why, then, does the common case need freenet. -- Robert Hailey
[freenet-dev] Summary of recent opennet discussions
On 2013/07/22 (Jul), at 12:53 PM, Robert Hailey wrote: > It may be that Freenet cannot "win" in the p2p paranoia market until it makes > that [communication] workflow trivial At the risk of diverting attention away from (or confusing the ideas of) my former discussion of using yubi for opennet refs... and furthermore risking sounding like a yubikey shill I wonder if it is possible to make darknet connections in this manner: [suppose I'm at a friends house, and through conversation find interest in secure communication with him] (1) download/activate freenet on his computer, (2) navigate to the [originally empty] "darknet peers" section, (3) plugging in my "freenet [yubi] key", (4) activating the yubikey somehow forms a darknet link (to my computer) from his side, and (5) he can get a yubikey later I know that it is possible to store a constant string in one of the two yubikey modes (short press & long press), but I'm not sure it can fit a full darknet ref... (and even then, I would need his node ref too). Arghh. -- Robert Hailey
[freenet-dev] Summary of recent opennet discussions
On 2013/07/22 (Jul), at 12:32 PM, Victor Denisov wrote: >> 2) Most people on Freenet have no real enemies and so care far too >> much about their friends' feelings and not enough about their actual >> enemies, compared to our threat model. > > I think it's slightly different. Let's imagine I'm a passive pedophile; As strange as that thought-experiment was, I think it gives a good case "when you have something to hide" and the communication is that for broadcast publishing. But let us not forget what I consider to be more common use case (for which we are not optimized and has nothing to do with child porn)... I have a friend, and would like to communicate with him/her "securely" in an email or instant-message like way. It may be that Freenet cannot "win" in the p2p paranoia market until it makes that workflow trivial (and then gets better content in the p2p storage/publication realm as people later explore this other "free" functionality). As there are other mechanisms that beat freenet hands-down in this area in terms of required setup. -- Robert Hailey
[freenet-dev] Summary of recent opennet discussions
On 2013/07/22 (Jul), at 11:01 AM, Victor Denisov wrote: > If I'm correct and an attacker will > need to roughly match the network size for a successful attack, then > matching a network of 100K nodes, each of which had paid, say, $5 to > join, would require $500K - heck, even I, being a (relatively) poor > scientist, would probably be able to raise that money in a couple of > months (by, i.e., selling off all my property, getting to my eyeballs in > debt, etc) if I'd be really motivated (i.e., to find a pervert who raped > my daughter and posted video of that on Freenet, or something). Even if > nodes would be paying $50 to join (which I don't think is a realistic > amount), an attacker would still need to come up with just $5M, which > isn't that much for a middle-sized private company, and is chump change > for any government agency. > > 2a. Yes, that means that, in my opinion, we can't look to money for > scarcity, it should be obtained from somewhere else. To find it, I think > that threat model should be defined better. I agree. Another way to think of "scarcity" is by defining the "bottleneck" required for a sybil attack. If we can engineer it such that a legitimate user only needs to "find and mash his yubikey once a month", that is near-trivial, but if a sybil network needs someone to mash 100k yubikeys per month... you start to get a bottleneck, no? What other options are then available but to higher dedicated yubikey mashers (now I wonder if that can be done by an auto-loader-type machine), or try and compromise yubico corporate? Beyond more expensive & far-out ideas, that's the best I can come up with ATM. -- Robert Hailey
[freenet-dev] Summary of recent opennet discussions
On 2013/07/22 (Jul), at 9:32 AM, Matthew Toseland wrote: > ...almost everyone argues that darknet is impossible. I wonder if this is really b/c "hermits don't have friends", or if there is something between the theory and practice for which we have not accounted. I have put much thought into a Ronja-like FSO p2p network as of late; and it occurs to me that there may be enough implicit trust with whomever you make a FSO link with to qualify as a darknet peer (and the data is being transmitted out-of-band wrt the internet). It's probably just wishful thinking, but if such devices became popular for any reason (wireless bridge, sharing internet connections, backup internet, etc), you might be able to see an effect where the darknet would "build itself" as local networks begin to have multiple FSO links. -- Robert Hailey
[freenet-dev] Summary of recent opennet discussions
On Mon, Jul 22, 2013 at 9:32 AM, Matthew Toseland wrote: > Since Eleriseth announced he was leaving and we should focus on > speed/usability, then opennet security, and only then darknet, I have been > looking into options for securing opennet, and discussing this with various > people. > I agree that speed/usability should be the top priority (although obviously not the only priority). Most of the proposals below are directly contrary to usability - we need to encourage people to contribute to the Freenet network, not punish them for it, nor make them jump through unnecessary hoops. We need to find solutions that won't make it even more difficult to contribute to the Freenet network. The main attacks here are: > - MAST: Listen for a predictable request/insert, triangulate roughly where > the originator is on the network based on the requests you receive, > announce to that location, repeat until you have the target. Cheap. Really, > really cheap. > To the extent that this is feasible, routing a request randomly on its initial hop, perhaps with a bias towards nodes that are further from your node's location, should make this considerably more difficult. > - Surveillance: Connect to every node, log all the inserts for a month > (freenet content doesn't last long if not requested). Connect it to > announced content. Surprisingly cheap, given our relatively low bandwidth > usage per peer etc, and it will become cheaper per node as the network > grows because bandwidth (and everything else) gets *really* cheap in large > volumes. This is a Sybil attack: The only way to beat it is by using some > sort of scarcity. > We could have nodes detect this kind of behavior since it would be somewhat weird - a bunch of inserts coming from the same node, etc. Essentially a heuristic "bad behavior" detector that cases nodes to be blocked. Ian. -- Ian Clarke Personal blog: http://blog.locut.us/
[freenet-dev] Summary of recent opennet discussions
Since Eleriseth announced he was leaving and we should focus on speed/usability, then opennet security, and only then darknet, I have been looking into options for securing opennet, and discussing this with various people. The main attacks here are: - MAST: Listen for a predictable request/insert, triangulate roughly where the originator is on the network based on the requests you receive, announce to that location, repeat until you have the target. Cheap. Really, really cheap. - Surveillance: Connect to every node, log all the inserts for a month (freenet content doesn't last long if not requested). Connect it to announced content. Surprisingly cheap, given our relatively low bandwidth usage per peer etc, and it will become cheaper per node as the network grows because bandwidth (and everything else) gets *really* cheap in large volumes. This is a Sybil attack: The only way to beat it is by using some sort of scarcity. Unfortunately, tunnels are still vulnerable to Sybil attacks. In particular, tunnel setup is often vulnerable to such attacks. If we can create meaningful scarcity, then we can have tunnels and an interesting level of security. If not, tunnels aren't necessarily a big gain. Bandwidth requirements / scarcity by bandwidth usage -- We could require that core opennet nodes have some minimum level of bandwidth available, possibly requiring a given uptime as well, in order to stay connected as core opennet nodes. Other nodes - transient nodes - would then not route traffic, and would have limited connectivity to core nodes, so would be slower too. This would significantly increase bandwidth usage on the fast nodes, and improve performance for those able to run core nodes. The question is, what effect would this have on users? Would we lose a lot of core nodes, and thus have much less storage capacity, or would we be swamped with filesharers and gain capacity? Scarcity by IP address Currently individual seednodes limit announcements per IP address per 24 hours. We could make this a collective limit, and limit the number of different locations you can announce to (which would make some easy attacks harder). More complex schemes would create the random location on the seeds/bootstrap nodes, and allow us to ensure that one IP only has one (or two) nodes, which only have up to N connections each; this would make a lot of attacks harder. Ensuring that there aren't too many nodes per IP address would require that nodes connect to the seed/bootstrap central nodes when they change IP address, and might require them to do so periodically (meaning a DoS attack would not only take out the ability to announce new nodes but also may affect existing nodes fairly quickly). It is also possible to do this in a more distributed way (which would be more robust) but it would be a lot more work. Unfortunately, scarcity by IP address probably doesn't greatly increase the costs of a Sybl attack: - Resetting your DSL modem: For lots of people on dynamic IPs, this is a free way to get a new IP address. Of course you can't use the old IP address at the same time, so some of the more expensive measures mentioned above may help. Spoofing is also a possibility. - Botnets: Illegal, but relatively cheap. Can happen, and not only if your enemy is openly criminal. - VPNs: Roughly a few dollars per IP per month. This is a definite improvement on the status quo. - IPv6: You can get large IPv6 allocations relatively cheaply, and it is not easy to detect this reliably AFAICS. Scarcity by money We could require a small donation to become a core opennet node. Combined with the above measures this would probably be an effective deterrent to moderately funded Sybil attackers, especially on a large network. And the money would be helpful too, although in the long run this is a deterrent rather than a fundraising exercise, so we could have most of it go to other charities. IMHO there are significant costs to running Freenet, most of which can be expressed in $: - Bandwidth, especially if you end up paying for going over limits, your other access gets throttled because of high usage, or you get a more filesharing-friendly ISP (= a more expensive ISP), or more bandwidth (particularly upstream), as a result of using Freenet. - Hard disk space, and wear on hard disks caused by increased load. - Electricity, especially if you run your computer 24x7 just to run Freenet on it. Arguably most of these don't apply to most Freenet users: Either they are students who don't pay their own utilities, or they have to have a fat pipe anyway for other filesharing, etc etc. And then there's the anonymity thing: Paying for something isn't anonymous. The fact of the matter is that installing Freenet from the website and using it on opennet isn't anonymous: At best, what you
Re: [freenet-dev] Summary of recent opennet discussions
On Monday 22 Jul 2013 16:57:35 Ian Clarke wrote: On Mon, Jul 22, 2013 at 9:32 AM, Matthew Toseland t...@amphibian.dyndns.org wrote: Since Eleriseth announced he was leaving and we should focus on speed/usability, then opennet security, and only then darknet, I have been looking into options for securing opennet, and discussing this with various people. I agree that speed/usability should be the top priority (although obviously not the only priority). There is plenty we can do to improve both. Including on darknet. Most of the proposals below are directly contrary to usability - we need to encourage people to contribute to the Freenet network, not punish them for it, nor make them jump through unnecessary hoops. We need to find solutions that won't make it even more difficult to contribute to the Freenet network. There are none IMHO. Our options for significantly better security are either: 1) Make darknet easy and fast, and hope it doesn't take the rest of the century to reach critical mass, or 2) Make opennet secure (meaning considerably less easy) The main attacks here are: - MAST: Listen for a predictable request/insert, triangulate roughly where the originator is on the network based on the requests you receive, announce to that location, repeat until you have the target. Cheap. Really, really cheap. To the extent that this is feasible, routing a request randomly on its initial hop, perhaps with a bias towards nodes that are further from your node's location, should make this considerably more difficult. We can route randomly for several hops, with only minimal performance impact (especially on inserts). We can bundle a bunch of related inserts together and route them as a block for several random hops. Combined with some means to make it hard to choose locations to announce to, this makes MAST somewhat harder. But it has no effect on the second attack. - Surveillance: Connect to every node, log all the inserts for a month (freenet content doesn't last long if not requested). Connect it to announced content. Surprisingly cheap, given our relatively low bandwidth usage per peer etc, and it will become cheaper per node as the network grows because bandwidth (and everything else) gets *really* cheap in large volumes. This is a Sybil attack: The only way to beat it is by using some sort of scarcity. We could have nodes detect this kind of behavior since it would be somewhat weird - a bunch of inserts coming from the same node, etc. Essentially a heuristic bad behavior detector that cases nodes to be blocked. All the attacker has to do is connect to lots of nodes. The simplest implementation is not detectable at all (short of dubious IP scarcity etc), but it requires a relatively large number of nodes. Some of the hacks that might be used to retain connections to the right set of nodes *might* be detectable. Maybe. signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Summary of recent opennet discussions
On Monday 22 Jul 2013 17:22:40 Robert Hailey wrote: On 2013/07/22 (Jul), at 9:32 AM, Matthew Toseland wrote: ...almost everyone argues that darknet is impossible. I wonder if this is really b/c hermits don't have friends, or if there is something between the theory and practice for which we have not accounted. This is because: 1) People don't understand anonymity, or security. 2) Most people on Freenet have no real enemies and so care far too much about their friends' feelings and not enough about their actual enemies, compared to our threat model. 3) I didn't know you were a paedophile. signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Summary of recent opennet discussions
On Monday 22 Jul 2013 17:22:40 Robert Hailey wrote: On 2013/07/22 (Jul), at 9:32 AM, Matthew Toseland wrote: ...almost everyone argues that darknet is impossible. I wonder if this is really b/c hermits don't have friends, or if there is something between the theory and practice for which we have not accounted. I have put much thought into a Ronja-like FSO p2p network as of late; and it occurs to me that there may be enough implicit trust with whomever you make a FSO link with to qualify as a darknet peer (and the data is being transmitted out-of-band wrt the internet). It's probably just wishful thinking, but if such devices became popular for any reason (wireless bridge, sharing internet connections, backup internet, etc), you might be able to see an effect where the darknet would build itself as local networks begin to have multiple FSO links. The main problem with that sort of thing is you need some long links, and that tends to be hierarchical, expensive, and owned by somebody who is vulnerable to censorship demands. The secondary problem is that putting hardware on the roof is expensive for most people, and you need a whole set of directional links (whether optical or wifi), which will need to change as the network evolves. I agree in principle it's the sort of dream that I'd like to support though. Like Freenet. :) signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Summary of recent opennet discussions
On Monday 22 Jul 2013 17:01:08 Victor Denisov wrote: A number of somewhat-connected observations from someone who had been following Freenet since early 0.3 days: 1. Paying for becoming a VIP Freenet node is not out of the question (people buy invites to elite torrent trackers for sizable amount of money), but the benefits must be *very* obvious. There's no point if it's only the handful of elite nodes. It needs to be the bulk of the network - everyone who routes requests where they could conceivably spy on other nodes. The benefits could be made obvious though: If we have a high bandwidth threshold then we'll have much higher average transfer rates, and people will have less need to hack their nodes to have 500 peers, as the Japanese are doing on Frost after Winny and Perfect Dark fell down. 2. However, any reasonable amount you can ask from users can easily be matched by a dedicated attacker. If I'm correct and an attacker will need to roughly match the network size for a successful attack, then matching a network of 100K nodes, each of which had paid, say, $5 to join, would require $500K - heck, even I, being a (relatively) poor scientist, would probably be able to raise that money in a couple of months (by, i.e., selling off all my property, getting to my eyeballs in debt, etc) if I'd be really motivated (i.e., to find a pervert who raped my daughter and posted video of that on Freenet, or something). Even if nodes would be paying $50 to join (which I don't think is a realistic amount), an attacker would still need to come up with just $5M, which isn't that much for a middle-sized private company, and is chump change for any government agency. True. Unfortunately the attacks that are possible right now are considerably cheaper, and remain so even on a bigger network. 2a. Yes, that means that, in my opinion, we can't look to money for scarcity, it should be obtained from somewhere else. There isn't anything else. Except darknet. And everyone keeps telling me that darknet is impossible, at least until the network is much bigger. To find it, I think that threat model should be defined better. Fighting a bored millionaire (or a vigilante, or a mad corporate head looking for a whistleblower) is one thing; fighting a government agency is another. For example, it would be difficult for a vigilante with money to come up with 100K valid national ids; it would be completely trivial for a government agency. Right now we're at the fighting a bored CS student stage. Connect-to-every-node is a relatively small amount of money - hundreds of nodes, maybe tens of servers, maybe 3KB/sec/node (and there are cheats to reduce that further). As the network gets bigger you optimise it more heavily, and buy bandwidth more cheaply. 3. I also think that Freenet project has been getting it wrong for the past couple of years. Somewhat secure opennet must come before *any* attempt at building darknets, however romantic those seem to be on paper. The reason is, IMHO, two-fold: Using IP scarcity is possible, though it will cause problems for some users. It will be a lot of work, for relatively little benefit: it will only slightly increase the cost of the comprehensive surveillance attack. a) most people *won't* trust their RL friends for most of the activities that Freenet would *actually* be useful for. I may trust my friends enough to let them know that I download warez (or porn, whatever); but if I'm a government whistleblower (or a pedophile, or marijuana grower) I *definitely* would like my friends to know about that last, not first. On opennet, your peers choose you. Hence MAST and connect-to-everyone surveillance. On darknet, you choose your peers. If you trust your friends less than you trust the jack-boots, then you probably don't have much to fear from the jack-boots. The other point here is that we can build a tunneling system that protects you from your direct peers, unless they conspire. But we can't do that unless we can beat Sybil. Which appears to be either impossible or politically unacceptable on opennet. b) we can't expect a well-connected darknet to form right from the beginning; most likely, its growth will be organic, starting from small non-connected cells - in this case, a well-working opennet will provide the initial glue to connect those together. Probably true. In any case, I think it's not a good idea to work on darknet before opennet works as well as can be (reasonably) expected - more on that right below. 4. I think that performance issues *absolutely* should be handled before anything else, even before security. I understand that many - even most - will disagree with me, but if I found *one* thing from practice, it is that people widely prefer less secure, but working, systems to more secure, but non-working, ones. Right up until the point when somebody publishes a toolkit for MAST, and a list of paedophiles
Re: [freenet-dev] Summary of recent opennet discussions
On Monday 22 Jul 2013 18:08:57 Matthew Toseland wrote: On Monday 22 Jul 2013 16:57:35 Ian Clarke wrote: On Mon, Jul 22, 2013 at 9:32 AM, Matthew Toseland t...@amphibian.dyndns.org wrote: Since Eleriseth announced he was leaving and we should focus on speed/usability, then opennet security, and only then darknet, I have been looking into options for securing opennet, and discussing this with various people. I agree that speed/usability should be the top priority (although obviously not the only priority). There is plenty we can do to improve both. Including on darknet. Most of the proposals below are directly contrary to usability - we need to encourage people to contribute to the Freenet network, not punish them for it, nor make them jump through unnecessary hoops. We need to find solutions that won't make it even more difficult to contribute to the Freenet network. There are none IMHO. Our options for significantly better security are either: 1) Make darknet easy and fast, and hope it doesn't take the rest of the century to reach critical mass, or 2) Make opennet secure (meaning considerably less easy) The main attacks here are: - MAST: Listen for a predictable request/insert, triangulate roughly where the originator is on the network based on the requests you receive, announce to that location, repeat until you have the target. Cheap. Really, really cheap. To the extent that this is feasible, routing a request randomly on its initial hop, perhaps with a bias towards nodes that are further from your node's location, should make this considerably more difficult. We can route randomly for several hops, with only minimal performance impact (especially on inserts). We can bundle a bunch of related inserts together and route them as a block for several random hops. Combined with some means to make it hard to choose locations to announce to, this makes MAST somewhat harder. But it has no effect on the second attack. Correction, the bundling thing does help with the second attack, but it likely has performance implications if we use it for large inserts. If we only use it for the top block then it has no benefit against connect-to-everyone. Likewise, full blown tunneling but only for the top keys has no effect against connect-to-everyone - even if the tunnels aren't compromised, which they would be on opennet because the attacker can control the keyspace, dominate any targeted node's connections, do tagging attacks and so on. signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Summary of recent opennet discussions
On Monday 22 Jul 2013 19:11:05 Robert Hailey wrote: On 2013/07/22 (Jul), at 12:53 PM, Robert Hailey wrote: It may be that Freenet cannot win in the p2p paranoia market until it makes that [communication] workflow trivial At the risk of diverting attention away from (or confusing the ideas of) my former discussion of using yubi for opennet refs... and furthermore risking sounding like a yubikey shill I wonder if it is possible to make darknet connections in this manner: [suppose I'm at a friends house, and through conversation find interest in secure communication with him] (1) download/activate freenet on his computer, (2) navigate to the [originally empty] darknet peers section, (3) plugging in my freenet [yubi] key, (4) activating the yubikey somehow forms a darknet link (to my computer) from his side, and (5) he can get a yubikey later I know that it is possible to store a constant string in one of the two yubikey modes (short press long press), but I'm not sure it can fit a full darknet ref... (and even then, I would need his node ref too). Arghh. That's more or less what the smartphone app is for. On Monday 22 Jul 2013 19:21:40 Victor Denisov wrote: But let us not forget what I consider to be more common use case (for which we are not optimized and has nothing to do with child porn)... I have a friend, and would like to communicate with him/her securely in an email or instant-message like way. This is trivial without Freenet - just exchange your PGP keys and send each other encrypted email. And I believe a number of XMPP clients also support PGP encryption, solving the need for secure one-on-one and group communications. It's not trivial in practice. It's surprisingly difficult to securely exchange files or fingerprints. So much so that it's largely limited to geek conferences. Hence the smartphone app. I do think that e.g. a Jabber gateway and other pure f2f stuff would be useful within Freenet. signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Summary of recent opennet discussions
On Monday 22 Jul 2013 19:00:03 Victor Denisov wrote: 1. Paying for becoming a VIP Freenet node is not out of the question (people buy invites to elite torrent trackers for sizable amount of money), but the benefits must be *very* obvious. There's no point if it's only the handful of elite nodes. It needs to be the bulk of the network - everyone who routes requests where they could conceivably spy on other nodes. The benefits could be made obvious though: If we have a high bandwidth threshold then we'll have much higher average transfer rates, and people will have less need to hack their nodes to have 500 peers, as the Japanese are doing on Frost after Winny and Perfect Dark fell down. Elite trackers have tens of thousands of users. Granted, most of those obtained their invites for free; but a fair amount had paid anywhere between $5 and $100 for such invites. Meaning that some people may be willing to pay to get on opennet. The catch is, how many? If it reduces the rate of users joining the network by a factor of 2, for example, the network will shrink, even if we were growing slowly to start with. One problem with the yubikey thing is it takes time to deliver them. Hence the need to be able to just buy an invite e.g. with BTC. There isn't anything else. Except darknet. And everyone keeps telling me that darknet is impossible, at least until the network is much bigger. We (as a community) just hadn't figured out such a way, IMO. Perhaps it doesn't really exist - I'm not qualified enough to tell yet - but I highly doubt it. On the level of tunnels - what I would consider real security - it's a major unsolved problem in academia. (Tunnel setup on DHTs) On opennet, your peers choose you. Hence MAST and connect-to-everyone surveillance. On darknet, you choose your peers. Umm, would there be any benefit to security if this was reversed? If Freenet will go down the tangible verification route (certificates, yubikeys, whatever), hiding the fact that you run a Freenet node would become pointless anyway. I don't follow? If you trust your friends less than you trust the jack-boots, then you probably don't have much to fear from the jack-boots. As I'd mentioned in a previous email, it's not a question of trust as is, it's a question of damage my friend can do to me if he decides to betray my trust. No. If they can prove that a given IP address at a given time uploaded a given illegal file, game over. Or downloaded it, but uploaders are worth more. That's the only safe assumption. 4. I think that performance issues *absolutely* should be handled before anything else, even before security. I understand that many - even most - will disagree with me, but if I found *one* thing from practice, it is that people widely prefer less secure, but working, systems to more secure, but non-working, ones. Right up until the point when somebody publishes a toolkit for MAST, and a list of paedophiles they busted with it. That's sort of a catch 22. The network won't be worthy of growing until it's secure, but it won't be secure until it grows. I'm not saying security isn't important; that would be stupid. But for an *experimental* network *under heavy development* lightly secure, but well-performing, network will be preferable to very secure (until the next attack vector is found), but poorly-performing, network. A one million node network would still be vulnerable to MAST, and connect-to-everyone would be quite affordable for small to medium sized corporate attackers. Right now, Freenet exhibits a level of performance which can only be called abysmal. I can download torrents at 4 MB/s, reliably, one after another, from different trackers in different countries; considering that in Freenet mine (and everyone's else) traffic should pass through several nodes (say, 20 of them, worst case), Typically for requests it should be 5-7 or thereabouts. Yes, that's why I'm assuming 20 as worst case. I'd say Freenet should provide around 200 KB/s of sustained download performance (with the rest of my pipe being donated to other nodes, thus hiding my traffic). In reality, in my tests, on a lightly-loaded and well-integrated node I'm lucky to see speeds above 10 KB/s, with typical downloads making 2-3 KB/s on average, start to finish. My node with 90 peers only consumes around 200-250 KB/s (out of 1 MB/s allocated); my higher bandwidth allocation is effectively *wasted* by the inefficient network. Most nodes have relatively low bandwidth limits. We could boost performance by excluding slow nodes (say under 40KB/sec). This is the first part of the proposal. Of course we'd lose a large number of nodes - but we'd probably gain more to compensate when performance improves. I still don't get why it happens. Are torrent clients run by significantly different slice of users? Again: I can reliably
