Agreed 100%.

The net cumulative effect of people who _start_ sharing once they don't _have_ to be listable by IP address, could well improve transfer rates a bit.

At the least, for every file that becomes shared to QUERIES (but not to BHs) that otherwise would have been UNSHARED is one more source for that file, which would relieve the burden on a BH-able node who DOES have that file. Therefore, the BH-able host would be able to satisfy the TRANSFER DEMAND placed upon it for that file better, by having some of that demand now offloaded onto the node which begins sharing. This appears to be a net benefit to the people who LIKE to find files by BH-ing people, as those nodes will be under less demand. Everyone wins.

;-)


He told one of our development staff that I was "not constructive" (paraphrased, I have the details at work).

I think he intended it, I just don't know why?!?

As far as Optional browsing - Keep in mind that I am not saying "i want to be completely anonymous", merely that "i don't want my IP address to be the only lookup key required to see my shared content."

If someone wants something from me, I (personally) want them to know WHAT they are looking for, before they can find out whether I am satisfying this desire or not.

As a coder, it isn't a huge issue for me (I can simply disable it locally) - merely the principle. But I know i'm not the only one who wants to be able to turn this off locally. At BS it was an option, and people used it often.

As far as "false security", locally not supporting this feature isn't meant to be a fix-all for security. Nor is it meant to make me anonymous. Therefore, any argument that "it doesn't make you secure" or "it doesn't make you anonymous" is more-or-less a strawman.

As I said in my above posts, why shouldn't I be able to close my (p2p) door without locking it, should I so desire? Just because closing it doesn't lock it (aka completely protect) doesn't mean I shouldn't be able to close it.

The biggest problem I forsee was mentioned inhouse by another developer, and that would be the "confusion factor" whereby non-technical users may think that "not browseable" == "not sharing". However, this is addressable in other ways, which don't invalidate the original desire.

For example, the first thing off my head to address that would be a popup box once the "disable BH" option were enabled which simply informed the user of what, exactly, the option did, and notifying them that they were STILL sharing the file to anyone who looked for it,

If that weren't acceptable, there are any number of other ways to address this sub-issue.

Per Schneier, a leading security expert, security measures are a series of compromises between actual security & usability.

Allowing a user to not have files listed based SOLELY upon knowledge of that user's IP address (even if there are other methods to find the shared files) is a _compromise_ designed to address one single channel for information leakage.

Does anyone have a good reason why I shouldn't be able to disable this feature for MY node, _regardless_ of whether YOU YOURSELF would want it disabled on your node?

My (continued) $0.02.....

-dave-