*A warning to all about BearShare.
 

BearShare is not worth the worry and hassle of possible spyware or adware installed on your machine. Currently, you have the option of not installing OnFlow, SaveNow and New.net, but included in version 2.2.4 is an integrated web browser and who knows what information it is collecting.

The truth of it is, you don't know what information BearShare is "sharing about you" on the GNUtella network or elsewhere while using it. Wake up, people. BearShare is NOT Gnutella. Use another GNUtella client and do NOT support BearShare, regardless of its usability.

BearShare is a user-friendly GNUtella client, but it is NOT privacy friendly. User beware.

Open Source!
 

Open source is the only way to go. With the RIAA and others out there I don't want to take a chance. If it's not open source, don't run it!

Re: A warning to all about BearShare.
 

The integrated web browser isn't collecting any information. It's just loading http://bearshare.vstoremusic.com/ , which is an e-commerce store provided by http://www.v**********/

A lot of programs have integrated web browsers nowadays, including Napster.

"A lot of programs have integrated web browsers nowadays, including Napster."

The only difference is after I run BearShare and load up Ad-Aware 4.6, it always detects cookies from it. I know cookies can be anything, but that's my point.

Yes, but the cookie is set by *.vstoremusic.com so only Vstore has access to it.

Re: A warning to all about BearShare.
 

Vinnie Falco's (the creator of Bearshare) attitude recently is the reason that have uninstalled Bearshare from my box and have
moved to Gnucleus. I have always been disturbed by the spyware bundling, but put up with it because I thought Bearshare was the best servent available. Then I found out about the encrypted message packets that Bearshare sends out and that disturbed me more. I have never heard a pausible explanation for these encrypted messages from Vinnie to this date.

Finally, within the past week, Vinnie has posted several messages on the Bearshare forums which include vitriolic
comments about folks who may have questiond his judgement in using the spyware and has threatened to shut down the Adware forum on Bearshare.net. He has also been censoring posts which are critical of Bearshare. That was enough for me.

I decided to try a couple of servents that I had never tried to find an alternative to Bearshare and I stumbled upon Gnucleus. Let me tell you folks, Gnucleus is as good, if not better than Bearshare. In many ways it IS better than Bearshare. It is more stable, seems to return more search results which are better organized, and the download resume features are a lot more
intuitve. But best of all, there is NO SPYWARE, it sends no encrypted packets, and is OPEN SOURCE. I uninstalled Bearshare and I'm not looking back. Gnucleus is serving all my Gnutella needs without all the hassle and worry associated with Bearshare. I'd urge anyone who has doubts or privacy concerns about Bearshare to check it out.

Hope this helps...

Error of my ways...
 

>"Finally, within the past week, Vinnie has posted several
>messages on the Bearshare forums which include vitriolic
>comments about folks who may have questiond his judgement
>in using the spyware and has threatened to shut down the
>Adware forum on Bearshare.net."

FFF**** you, bodhi


>He has also been censoring posts which are critical of
>Bearshare. That was enough for me.

Come back and post on BearShare.Net, so I can delete your sorry a$$ again.

Re: Error of my ways...
 

Would you want software created by someone with this type of attitude on *YOUR* machine? How could you possibly trust it?

I rest my case.

Good post!
 

Bodhi, I'm completely behind you 100%

BearShare and its creators are not to be trusted on this global network.

Let me further elaborate on the subject.
 

What if Vinnie reads a post he doesn't like or feels that public opinion about his servant is declining and decides to maliciously implement actual spyware that sends personal information about the user back to him, or spreads it throughout the network? What is stopping him from doing this? It might not be happening now, but it could with something as popular as BearShare that is often toted as the next replacement for Napster.

I think there needs to be more peer-to-peer servant policing on this peer-to-peer network. Possibly implement some sort of host blocking according to what servant the client uses. I know it seems harsh, but who should we be protecting? An overbearing Gnutella servant author or a hapless user who doesn't know any better?

Duh
 

Now thats productive. Block other servents.

If I put out a BearShare that blocked non-BearShare servents, the network would be reduced to less than 30% of its current size.

My comments in the forum have absolutely nothing to do with the issue of trust.

BearShare, from day one, has been a clean implementation with no personal information sent out and no funny business going on.

Yes, it has bundled products however these are SEPARATE and not required to operate the program.

Yes, there are proprietary messages being sent out however the nature and purpose has been explained MANY times. You refuse to listen, thats the problem.

hehehe
 

Always good to read the bearshare forums .
It's a great soap !

"Jerry,Jerry,Jerry"

Summer Season is here!
 

That's right, and the summer line up includes a

NEW IMPROVED BEARSHARE.NET!!!

Now with over THIRTY FORUMS!

- More politics!

- More public forums!

- More discussion areas!

- More features!

The saga continues...

Re: Summer Season is here!
 

- More lies!

- More censorship!

- More vulgar profanity!

- More abuse of the user base!

- More spyware!

..........keep it coming !

Re: Re: Summer Season is here!
 

And less bodhi

Re: Let me further elaborate on the subject.
 

Vinnie on the Gnutella Developers Forum:
"If something isn't done, then I will assume its OK to use the same tactics with respect to dropping messages, retry intervals, servant bias, and propaganda that I have seen elsewhere."

Looks like he's already started.

There's nothing stopping him, and with his control/dictator attitude, its 98% that he will do something soon. He has threatened already with his new forum, and now with his new software.

GO OPEN SOURCE! If it's not open source, it doesn't belong on the Gnutella network. Plain and simple. Gnutella is open, so should be the software.

The problem is commercial interests want to make a buck off it. Let them create their own network!

DO NOT SUPPORT ANYTHING THAT ISN'T OPEN SOURCE!

Dill weed
 

Hey, dirtbag, why don't you post the WHOLE thing instead of the part that suits you? I'll do it for you:
----------

> Each time my Bearshare client connects to a new servent, it sends
off
> a query (even if I have an empty temp directory). The TTL of this
> packet will vary, and so will the query payload, but it is always
141
> bytes. What is going on here? And what is the format/meaning of
> this query criteria?

This is a proprietary message that BearShare uses for determining the
version number, newer versions, and measurement of the FreePeers
horizon in the Statistics page.

Due to historical reasons, the TTL on these messages in rather
limited and therefore the FreePeers horizon has never been
particularly accurate (it is always low).

You can identify these types of encoded queries by noting that the
high bit of each character in the string is set to 1. Proper handling
of these messages is to skip the comparison of the query keywords
against local files, and broadcast or expire the message as usuall
(decrementing the TTL by one of course).

You may also see Query Hits descriptors that contain similarly
encoded data. These Query Hits descriptors can be identified by file
names which have the high bit set in all characters of the null
terminated string. For these messages, you should route them just
like a regular query hits message. If your servent supports passive
monitoring of search results, do not perform the usual comparison of
outstanding queries against these query hits, as the data does not
refer to a requestable file.

The information contained in these messages is proprietary and
confidential.

There have been many reactons to this proprietary technique. One is
that it "breaks" the Gnutella protocol, or is not compliant with the
protocol. However, nothing in the protocol specifies that queries
have to be for files, or that search results must contain files.
The "protocol" only defines the format of the messages so that
applications may be interperable. I designed the encoding scheme so
that it is easy to identify and deal with.

Some developers and users have raised objections to these messages,
claiming that they 'fragment the network' or some other junk.
However, we must recognize that in order for Gnutella to grow we must
embrace creative implementations and thinking "outside of the box".

In fact, LimeWire active blocks and drops these proprietary messages
that BearShare sends out, even in the latest version (1.4). This
happens despite the fact that the TTLs are low, and the over-
utilization problem that was present in December has long since been
eradicated. LimeWire drops these queries in all cases, even if the
TTL is low, according to recent tests.

Fortunately, Gnutella was designed for exactly this type of attack,
and the filtering of BearShare binary messages by the LimeWire
servent has in no way reduced the effectiveness or usefulness of the
messages (partly due to BearShare's market dominance).

Let me remind all of the developers in the group that so far I have
refrained from 'retaliatory' features because I believe it is not in
the best interests of the Gnutella network.

This having been said, there are several issues which have been
bothering me lately, all related to the LimeWire servent:

- Low timeout on download retries in LimeWire servent (currently 20
seconds)

Although at first glance, it seems like a nice cheesy way to improve
the download success rate, it is bad overall for the Gnutella
network. LimeWire blocks BearShare's special messages because they
think they are doing whats best for the network. Should a new
BearShare now block uploads to LimeWire because the low retry timeout
is detrimental to modem users?

Despite me having raised this issue as a problem a long time ago, the
latest version of LimeWire (1.4b) has not corrected this defect. The
GDF has also been completely ineffective in becoming a standards body
for saying with the proper timeout SHOULD be.

Do I need to take matters into my own hands again, or can you
knuckleheads get your collective acts together?

- Dropping of proprietary messages by the LimeWire servent

In order for the network to grow in rich technology and innovation,
this type of behavior is simply unacceptable. Although the bandwidth
issues were resolved rather quickly by me, LimeWire has seen fit to
not only take technical steps to harm the BearShare servent, but also
political steps by labeling them as "Garbage Queries" in the release
notes.

Should the next version of BearShare automatically strip the LimeWire
metadata proposal information from query hits before passing them on?

From http://www.limewire.com/future.htm#openprotocol
>any company or person can use [Gnutella] it to
>send or respond to queries

Apparently, any company except BearShare, based on the behavior of
the LimeWire 1.4b servent.

- "Spyware-free" label in the Feature Comparison about the LimeWire
servent

Do we really want to go there, gentlemen? We all know who is visiting
my forum. Preying on the ignorance of users, spreading
misinformation, and flaunting the negative attention BearShare has
received from my attempts to build a company from ground zero without
outside investors, is in poor taste. I have restrained myself from
reacting as I normally would, out of respect for my peers.

I would be willing to bet I could do a far better job of critizing
other servents in poor taste than anyone else could. Should I
continue to show restraint or should I invest some time in this
direction?
---

> :
> : The information contained in these messages is proprietary and
> : confidential.
>
> It's not very reasonable to expect others to route your proprietary
> and confidential information without some sort of prior agreement.

Sure it is. Since there are commercial interests, it is very
important to remain impartial with respect to traffic. Or else we
would end up with a software war.

See my example about stripping meta-data from search results before
passing it on - would you want that? I never agreed to meta-data so
why should I route it.

> True enough. But any plan depending on others serving your peculiar
> interests without some sort of prior cooperative arrangement is
liable
> to fail on that dependency.

The only dependency is on proper functioning and handling of messages
as per the Gnutella protocol. I think this is the baseline agreement -
everything else like proprietary messages or custom features is fair
game.

However, flooding the network is not a good idea either, which was an
early problem with BearShare. There are two issues, one is
overutilization of bandwidth, and the other is developing proprietary
features.

> : [20 second retry timeout] is bad overall for the Gnutella network.
>
> Can you make this case, please?

Yes. I had been getting reports from many users that claimed LimeWire
servents were making frequent requests for files. I didn't believe
it, so I turned on upload reports and sure enough, the number of
average LimeWire requests over a 24 hour time period more than
quadrupled from its previous values!

So what would be the logical response on my part? I would change my
retry interval to 10 seconds, then BearShare would have a better
chance.

If EVERYONE did this, we would quickly end up with no timeout in a
big game of one-upsmanship. I refrained from playing with the timeout
because it is counter productive. LimeWire got away with it because
their market share is so small, but if I were to reduce my timout
value in BearShare then there would be a significant increase in the
amount of collective traffic. This is known as 'hammering', and if
you are familiar with FTP servers you know that if you hammer you
usually get your IP banned.

> : GDF has also been completely ineffective in becoming a standards
body
> : for saying with the proper timeout SHOULD be.
>
> My opinion: Barring some significant unforseen practical problem
> resulting from underspecification, it is inappropriate for the GDF
to
> act to specify features of the download protocol

The retry interval isn't part of the download protocol, and because
of the "tragedy of the commons" effect where all servent developers
would eventually reduce their retry interval, it is necessary in this
case to have a consensus, and make sure everyone sticks with it, to
prevent a greedy company from lowering their retry interval in an
attempt to make downloads in their servent more successful than
others.

> : Should I continue to show restraint ...?
>
> Please continue to show restraint. I think that your admirable
> energy, if unrestrained, might scorch a lot of productive earth:-)

Maybe you misunderstood me. I've been patiently waiting for these
issues to get resolved and my patience is wearing thin.

If something isn't done, then I will assume its OK to use the same
tactics with respect to dropping messages, retry intervals, servant
bias, and propaganda that I have seen elsewhere.

---

Re: Dill weed
 

Maybe you can start a post without insulting first? Do you think this is appropriate to prove your point of view?
Should I think 'Oh, he calls someone dirtbag, so the rest of the post ist surely worth to read??

No greetings, for this time.

This thread has turned into a flamewar so it's now closed.