FileBot

Hi there,

How do I prevent the Windows version of Filebot from phoning home to check for updates each time I launch it?

Thanks,
Lin

1.
You can't. Always using the latest version is most highly recommended.

2.
FileBot is checking for updates once a week.

Would you please provide the address it connects to so that I can block it with a firewall? I don't want the software to phone home without my express permission.

Thanks,
Lin

Well, I guess if you're paranoid enough you will eventually find a solution somewhere.

Sure, you can dismiss it as paranoid. But the real issue is your wrongful belief that you're entitled to track the usage patterns of people using the software you've provided. Or that folks can't decide for themselves whether or not an upgrade is warranted.

Anyway, thank you for providing the information I require.

Sincerely,
Lin

Lindon22 wrote:But the real issue is your wrongful belief that you're entitled to track the usage patterns of people using the software you've provided.

Does FileBot send identifying information that could be used for tracking? I invite you to send the HTTP logs that proof that.
Do FileBot servers even answer any of those requests? AFAIK, CloudFlare caches and answers most requests. How can FileBot servers track your usage when they never even any of those requests? I invite you to argue your point.

Lindon22 wrote:Or that folks can't decide for themselves whether or not an upgrade is warranted.

No, they can't. You yourself are the best example. FileBot 4.7 includes important security improvements that you would have happily skipped if given a choice.


EDIT: Case and point: Windows XP (this shit keeps flowing in, I don't even have to search for it)


Instead of being paranoid on principle, learn how stuff works, learn about computer security, learn how the internet works.


PS: Last week there was a paranoid person that didn't want to download from SourceForge.net for security reasons, and then went to some random shareware site instead. The same person also didn't know what cryptographic hashes do. Blatant ignorance of basic computer security from people that "care about security" make me want to scream...

Instead of being paranoid on principle, learn how stuff works, learn about computer security, learn how the internet works.

Sure, and instead of making snarky assumptions about who you're talking to, you should take a dose of your own medicine. If you had half the education that your haughty, obnoxious response portends, then you'd be well aware of the Principle of Least Privilege. A program should be given the minimum access absolutely necessary to run. My desire to avoid allowing the program to ping home every time I launch it, or indeed, connect to any site or service unrelated to its advertised purpose is a good security practice. My issue isn't that you're DOING something malicious, it's that you COULD do something malicious. What the hell is wrong with you for labeling me an ignorant, paranoid, annoyance for simply wanting to make my computers (which I depend on for my living) as secure as possible?

Most sincerely,
LDN

PS: You're an asshat. Obstructionist assholes make me want to scream.

... launch applications with as few privileges as possible.

Principle of Least Privilege is meaningless if you trust the application to behave itself. The point of Principle of Least Privilege is that it's imposed by the OS, not voluntary in the application code. Though, given the ImageMagick fiasco I'll concede this point to you.

My desire to avoid allowing the program to ping home every time I launch it, or indeed, connect to any site or service unrelated to its advertised purpose is a good security practice.

Well, let's replace "every time I launch it" with "once per week" because that's what the code says. Of course, that doesn't make a difference from the computer security point of view.

Making sure that you're always running the latest (and most secure) version is part of its purpose (and a much requested feature). Using outdated software is bad security practice.

My issue isn't that you're DOING something malicious, it's that you COULD do something malicious.

No, I can't, and neither can a man-in-the-middle attacker. That's the point. That's why you get update notifications, and not automatic updates of executable code (which is not a trivial problem from a security point of view). [1] [2]

What the hell is wrong with you for labeling me an ignorant, paranoid, annoyance for simply wanting to make my computers (which I depend on for my living) as secure as possible?

Nothing wrong with that, as long as we're talking about real security, and not the illusion and false sense of security.

You worry about FileBot downloading text files (not executable code). You do not worry about downloading FileBot (executable code) via an HTTP connection (vulnerable to man-in-the-middle attacks). Things like verifying SHA-256 hashes or digital certificates to make sure the executable code has not been tampered with in-transit is good security practice.



If you just want to disable the update checks that's fine and I'll leave it at that, as I did previously. But if you argue computer security and privacy then I must tell you that enabling/disabling update checks has absolutely no effect on that.

I'm not sure why you would choose to continue this argument, but since you're becoming more civil I will attempt to do the same.

Principle of Least Privilege is meaningless if you trust the application to behave itself. The point of Principle of Least Privilege is that it's imposed by the OS, not voluntary in the application code.

This makes no sense and is the most backwards possible interpretation. To suggest that applications should be trusted until they misbehave is reprehensible. Better to add all itinerant media files to a "temp media" group and grant the organizer group permissions only, such that even if it goes haywire it is limited in scope. And how can you consider yourself a Java programmer without understanding the significance and history of access modifiers or why it's poor practice to make interfaces public without reason? Having software phone home when I don't wish it to do so is a compromise of security because it leaks information (what software I'm running, when and how often, my IP, etc) that it doesn't need to. That you claim you don't have access to or collect that information doesn't make it any less of a security issue, it just makes you less competent.

I realize that for a large portion of the population, installing software to change your screensaver means accepting that the application will connect to the Internet, access your contacts, run at startup, and update at will, but that's not acceptable. Neither is the snotty response of "because you need to be using the latest version." Your software is essentially an interface for a bunch of other software; can you imagine the nightmare it would create if AccoustID or the JRT components of your distribution were independently updating to incompatible versions? Or how frustrated you'd be if you showed up to ask how you might prevent this and were greeted with the same obnoxious, condescending response you offered me?

Principle of Least Privilege is meaningless IF you trust the application.

Meaning: "do not trust the application"

To suggest that applications should be trusted until they misbehave is reprehensible.

AFAIK. I did no such thing. It says "do not trust the application". We're in agreement here. Move along.

Having software phone home when I don't wish it to

That's a perfectly fine wish. That's why the -Dapplication.update=skip exists. It just doesn't give you any additional security or privacy (you seem to think that it does, so I have to correct you) for reasons explained below.

compromise of security because it leaks information (what software I'm running, when and how often, my IP, etc)

"How often?" => FileBot checks for updates at most once per week regardless of usage (so I can't have "detailed" usage statistics)

"IP" => FileBot connects to CloudFlare servers (which serve 10-20% of the internet, including TheTVDB, TheMovieDB, etc) but that is all that is known to a man-in-the-middle attacker. The HTTP requests (which contain the HOST header) are encrypted in the SSL session. Your provider can log "Connect to CloudFlare" but it can absolutely not log "HOST: app.filebot.net; GET: /update.xml" or "HOST: api.thetvdb.com; GET: /index.json" so your privacy concerns (i.e. "Attacker can know that I use FileBot and TheTVDB") are false.

This is my understanding of how HTTPS works. Feel free to refute my argument.

That you claim you don't have access to or collect that information doesn't make it any less of a security issue

What I claim doesn't matter. To you, I am not (and should not) be trusted. You should assume that I (and CloudFlare and my hosting provider) log every request.

Here's why you don't have an argument here:
* FileBot does not include identifying information (e.g. user cookie) in its requests (don't trust me, wireshark it yourself).
* FileBot will almost certainly connect to filebot.net if you do anything, even if you disable update checks, because it'll need to request series/movie/heuristics data to work well.

IF update checks were the only reason FileBot connects to filebot.net then you would have a point, but that is not the case, plus lack of identifying information... you don't have a good point here. IMHO.

Your software is essentially an interface for a bunch of other software; can you imagine the nightmare it would create if AcoustID or the JRT components of your distribution were independently updating to incompatible versions?

Is this a security argument? Using old versions of software because updating is a hassle? I understand your sentiment, but it's not really a good argument in terms of computer security, is it? [1]

As for specifics:
* "AcoustID" => is a remote web service, so if that changes all versions of FileBot will break, and I will have to publish an update anyway.
* "Java" => has the JCK and binary compatibility with newer JREs has never been an issue. Supporting older versions of Java has been an issue (e.g. back when there was no Java 7 for OS X for a few years) though.



Your security concerns are noted, but not technically valid (as explained above) in this case. Let me know if you find any actual vulnerabilities though.