I’m suspicious.

When I start JBidwatcher, it contacts jbidwatcher.com. Why? If I block that contact it says that I can’t log into ebay.

The obvious concern is that JBidWatcher could be uploading ebay userid’s and passwords to its website for unauthorized purposes. This is a big security flaw.

There should be a way to turn off any contact with JBidwatcher or there should at least be a clear statement somewhere guarenteeing that no personal information is being uploaded.

Greetings,
JBidwatcher’s source code is availabe on GitHub at http://github.com/cyberfox/jbidwatcher and I’ve been developing it for 10 years. I’m not exactly a private person; googling for me gets a TON of hits. If you want to dig into who I am, I recommend my Google Profile as a starting point.

If you use a firewall/proxy which can show you what’s being accessed, as opposed to just the host, you’ll see JBidwatcher is doing a GET for http://www.jbidwatcher.com/jbidwatcher2.xml which is checking for a more recent version. (Actually, on Mac OS X, it may be looking for https://www.jbidwatcher.com/sparkle/updates.xml as I’ve tried to go to Sparkle for Mac OS X consistency. Not sure how that experiment is working out…)

The code in question is in src/com/jbidwatcher/UpdateManager.java and src/com/jbidwatcher/UpdaterEntry.java. On Mac OS X, it uses the Sparkle framework from http://sparkle.andymatuschak.org with a small Java shim, mostly as described by http://www.rkuntz.org/pmwiki.php?n=Code.Sparkle… in order to make it work with an all-Java app.

You can turn off contact with www.jbidwatcher.com by turning off checking for updates. I don’t recommend it, as it’s useful to be notified of important bugs, as they can cost you money, but it’s your call.

It doesn’t send me any information other than what comes through a normal HTTP request; really just your IP address. Heck, right now it doesn’t even send me your real operating system when doing the update. The user-agent is the same as the one used to talk to eBay, so it’s a neutral old version of Firefox.

This is not a security flaw any more than any application which checks for updates for the user contains a security flaw.

I’ll look into why it might have failed to connect to eBay after failing the update check, but it’s entirely possible that by failing that request, it put the Java sockets stack into a bad state. (Along the lines of telling it that networking wasn’t available, or some-such.) This would have caused it to fail to do any future networking. I don’t know if that’s the cause, but there’s no dependencies between the eBay code and the updater code. They do use the same Http networking class, which has a shared http networking object, so if that object gets into a bad state, it won’t work, thus my guess about why it’s broken.

JBidwatcher does not upload your username or password to me; I don’t want it, nor the responsibility for storing it. The only place in JBidwatcher to choose to send me any kind of personal information (still not username/password) is going to be My JBidwatcher-related functionality, which is a general bucket for features I’m adding to JBidwatcher to integrate with a web service, and hopefully make it more valuable to the majority of users. It’s also possible right now to upload your error logs to me, for debugging purposes, but again that’s something you have to choose to do, and I go out of my way to not include password information in those.

I built JBidwatcher so I wouldn’t have to give my username and password to an external web site, and the existing open source sniper application (Bidwatcher, go figure) was not being developed well. I’ve softened my stance on sniping websites somewhat, and will be putting together some features to integrate with the Gixen sniping service because I respect them, and when I do I’ll be emphasizing that you’re sending username and password information in order to set up the snipe with them.

I hope this more-or-less brain dump of information helps you. If not, I’m sorry I couldn’t put your mind at ease. You could probably try Biet-o-Matic; I’ve heard it’s continuing to be developed. I’m not sure what other free snipers there are out there, anymore.

— Morgan Schweers, CyberFOX!

I’m not saying that you’re a bad person Morgan, but I think that the situation is a bit more involved than you have described it.

I have cleared the “Regularly check for new version” and the “Allow live configuration updates” checkboxes in the General tab. I am running 2.1pre8-0-g1a6aac8 on Mac OS X 10.5.8

I am observing that any change to settings causes the program to attempt to connect back to my.jbidwatcher.com. When I disallow the connection(s), the settings dialog box will not close when I press the “save” button. The naive conclusion would be that it is uploading my settings to the jbidwatcher.com web server. I trust that it is not, but it is also clear that the attempt to connect to the jbidwatcher.com server is not just about updates…

I also note that the program leaves stuff on the machine (it is not fully self contained). I load the .dmg and run it from the mounted disk. If I eject the disk, delete the .dmg and replace it with a fresh one, when I start the program it remembers all of my old settings and auctions.

I would kindly request that you provide a complete “uninstaller” for your program. I can probably clean up after it myself, but that will be a miserable job. A quick script included with the application would be plenty. Failing that, a readme.txt file that tells me what I need to delete manually would work.

Overall, it’s a cool little program and I appreciate that you’ve created it.

The reason I assume it still connects to my.jbidwatcher.com is because of this

“The only place in JBidwatcher to choose to send me any kind of personal information (still not username/password) is going to be My JBidwatcher-related functionality, which is a general bucket for features I’m adding to JBidwatcher to integrate with a web service”

As for it not being self contained, that is actually quite true but I found the following in the FAQ

Q. What files does JBidwatcher create, and where? A. There will be a directory in your home directory named .jbidwatcher. On MacOSX, it’s at:
/Users/{Username}/.jbidwatcher
on Windows it’s usually at:
C:\Documents and Settings\{username}\.jbidwatcher
on Linux (and other unices), it’s at:
~/.jbidwatcher
In that directory would be a set of files:
auctions.xml – the XML version of your auctions you are monitoring.
searches.xml – all the searches you’ve defined for it.
JBidWatch.cfg – the configuration file for the program.
display.cfg – Display-related configurations (windowsize, column widths, etc.)
errors.##.log – Error logs of what happened during a given run of the program.
There is also a ‘auctionsave’ directory, which contains a compressed copy of the HTML from the last successful update of all the auctions you are monitoring. This lets you view an auction (through JBidwatcher’s internal web server) long after it’s been removed from eBay’s own site. This directory is only used for cached-views, and the files can be deleted regularly if you don’t use that feature.