In my previous job, I worked at an advertising company in the "downloadables" department for a number of years. Basically we developed browser toolbars, software installers, mobile apps, and other software all with the sole purpose of gathering information about users in order to make money off them. We never (to my knowledge) developed any actual keyloggers, but we would do other equally insecure things with end users' data. For example, sending browser cookies, registry values, files off the hard drive, etc. in plain text to databases on our servers for later analysis.
Getting this kind of software through spyware screens in antivirus programs is not too difficult. Some of the antivirus companies have automated processes by which you can upload your binaries to them as false-positives and they'll automatically whitelist them for you. Sometimes it requires a quick email or phone call to the appropriate person at the antivirus company. Occasionally you have to make changes (usually just adding more disclaimers to an already ridiculously long EULA) in order to satisfy them and get on the whitelist. On a few occasions we just had to pay some money to get whitelisted.
Some of the more inscrupulous antivirus companies would even take money to bundle our now-whitelisted spyware applications in the installers for their products (as a checked-by-default "also install" option).
My takeaway from my time in that industry is that antivirus and antispyware software and companies are, by and large, just as bad as a lot of the spyware and spyware producing companies that they claim to be protecting you from. It's just a big circle jerk where the ultimate goal is to trick people into generating revenue by installing software or seeing ads that nobody in their right mind would ever actualy opt-in to.
Wow, yeah. I've heard about some of those techniques. I still think it's worth it for the more...upstanding AV companies to blacklist stuff like this. Or at least warn the user of its presence.
And a good example of how a lack of technical knowledge is dangerous. Why would they endorse a product if they weren't sure of it's effectiveness? These are government agencies, and they have access to technical resources that could verify the claims of the salesmen. Imagine firemen handing out smoke detectors (like they often do) without verifying that they actually detect smoke. It would be a catastrophe.
Isn't the example more like: Firemen handing out smoke detectors that will detect fires regardless if there is a fire or not?
Hmm... Give false positive enabling software to law enforcement that will be disseminated to "Concerned Parents", then spend time investigating "Crimes against children."
What is the rate of which this software has been used to investigate crimes?
No. Firemen have incentive to prevent fires. Home fires don't increase their revenue stream and in fact put them at risk of injury or death.
Police are not mandated to prevent crimes, and have no external incentives to do so (I state external because some officers want to reduce crime due to morals/ethical beliefs). In fact, in can be argued by looking at civil forfeiture laws and federal programs paying officers directly for certain arrests, that preventing crime is actually against their best interests both organizationally and individually.
However, handing out a tool that always indicates suspicious activity and allows them to invade privacy.. well, that fits in exactly with the behavior that laws and rules surrounding them have encouraged.
Yes, this is the correct metaphor. It leaves users vulnerable to things the cops are supposed to be trying to protect users from.
What's unclear is, do the cops get access to the keylogged information? Then the metaphor gets silly. It's like... firefighters giving you a smoke detector so they can spy on you in case you're setting fires, which also happens to sometimes cause fires independently.
> What is the rate of which this software has been used to investigate crimes?
Zero. It's not a forensic tool; any "evidence" collected with it would be inadmissable in court. (And, as the EFF notes, its search functions are pretty much useless anyway - most major OSes have considerably better search built in.)
Since this product opens users up to all kinds of identity theft, it's worse than that. It's like a fire alarm with a flashing light that triggers epileptic seizures.
Even worse, it could be a firm alarm that has the ability to start fires on its own. And you don't know if there are any arsonists working for the company that might remotely trigger a fire for their own pleasure.
If you're wired (ethernet): ARP poisoning to get your traffic to route through the attacker, then listening there. Works beautifully on most if not all LANs.
Though even if it didn't, WiFi by itself would be concern enough: most if not all the internet-equipped private homes have (often badly secured) WiFi, and all public spaces (airports, schools & universities, restaurants & bars, etc.) usually use key-less captive portal WiFi APs where listening in is even easier.
So yes: traffic interception is a very legitimate worry IMHO. And as someone said below, beyond those concerns, you could also be sniffed by techs working at your ISP (and its peering partners) / Law Enforcement / etc.
If anti-virus, firewall, and intrusion-detection products are willing to ignore something as hazardous, cheap-ass, and cheesy as this, think what a visit from the FBI or NSA will convince them to do.
Well, I didn't downvote you, but you're essentially asking for free work. If you want contributions, you need to contribute yourself first, usually by writing some code (or paying someone to write if you cannot) and publishing it.
A basic version that doesn't work well yet is OK, an empty repo isn't.
The repo isn't technically empty. :) I put a bit of work into describing the requirements of the proposed software and making suggestions how to proceed.
Basically I was volunteering to tend a garden, not just suggesting that someone plant one.
I've just added `remover.go`
package main
import "fmt"
func main() {
fmt.Println("Limited functionality, WIP.")
//Display introduction message and prompt user if they'd like to continue.
//Determine if current process has permissions to make system changes
//IF yes continue
//IF no initiate appropriate OS call to prompt the user to elevate
// OR advise user how to quit and start over with perms.
//TODO figure out if we're on Mac or Windows
//IF Windows...
// Look for process CCNet.exe
//Criteria: it's insufficient to match the name. Checksum? Publisher name? Install path?
//If found
//var installLocation string = ?? //record the install location.
//terminate process
// Look in these directories for installation
//C:\Program Files\WinSS\Book
//installLocation //defined above
//IF found
//Delete
//IF not found
//Prompt user to offer a suggestion
// Look in this directory for key log files
//C:\Windows\WinCCNet
//IF found
//Prompt for delete
//If not found
//Prompt user to offer a suggestion
// Remove the Add/remove programs entry
// Remove auto-start keys //TODO Where are they?
//IF Mac...
// ???
}
If you want my personal opinion, offering to work isn't enough. You need to have stuff done already. How am I to know that I'm not being suckered into working for you for free? I'd say that to volunteer 10m, I'd need to see 10h of work already done.
Secondly, a small project like this doesn't need a full-time gardener/manager, especially for an objective goal like this (unlike, say, a videogame). If and when a project reaches that need, someone who has contributed important code is preferred. Code talks.
So, in this case, you already know the requirements, right? Does that ease the blow of being told what to do? I mean, also I assure you that I'm not trying to tell you what to do. I presume that more or less the same items would appear on the TODO list if you told me what to do.
I can and will give up on this whole idea if it's truly a bad idea.
But, lets look at some alternative timelines here. Suppose that I'd immediately hunkered down and started writing an uninstaller in isolation. Note: this is not something I'd finish today. Thus: by the time I had a working or semi-working uninstaller, the world would have moved on.
By starting the work in public, I hoped to avoid that eventuality not just for myself but also for anyone else who might otherwise have walked that path. (Experts who could finish the software quickly don't need the suggestion, of course.)
And, by starting the work in public, I hoped to reduce the cost-of-entry for others. I mean, I don't know about you, but I'd rather start with a couple of kb of skeleton than an empty repo.
I likely can make one in a few hours, if I made it I'd put it on my blog. What is your contribution to the project? Why do you even need to be involved?
Think why would anyone be motivated to contribute to your repository, as opposed to creating a new one from scratch under one's own username.
Imagine you got a first pull-request, with a Go app. Then another, with a bunch of working Python scripts. Then yet another, providing a complete Python app packaged on PyPI but somewhat broken. What will you do? It doesn't matter: x-1 of x people have just wasted their time writing code that will end up under your GitHub username anyway.
Yes, it has to do with reputation management, too. You'd have a project under your GitHub name written completely by other people. The way it works currently, people will tend to see it as your project. You'll be free to claim it in your portfolios and resumes. Meanwhile, creating a GitHub repository isn't a hard task, and your README contents is basically what normally happens in one's head as one designs and writes the software.
In addition, and that's what may have actually caused the downvotes IMO, there's something not enjoyable about the idea of stumbling across a bunch of orders issued by a random person in writing to undefined audience, which you unexpectedly find yourself part of, by virtue of reading those orders. Your requirements, without any code, sure looked like such orders though.
It wouldn't be a problem be there a big name or much publicity associated with your project (and the resulting network effect), but without that there's no challenge and no meaningful payoff.
* * *
Things would be different if your repo had a well-thought-out skeleton consisting of some (even if completely no-op) units and a (failing but thorough) test suite, tied up to Travis CI and what not.
That would increase motivation as it would eliminate quite a bit of actual friction associated with starting a new project.
Arguably one of the hardest parts would be already done—us lazy programmers will be able to look at the units, the tests, and figure out how to make it work. No need to even clone, just edit some files via GitHub web interface.
> It wouldn't be a problem be there a big name or much publicity associated with that
My end goal is for my local police department to pass this uninstaller out to citizens, in a similar manner to how they passed out the installer. That will never happen without the support of a big name. I'm hoping the EFF will take an interest (I've already put my name on their volunteer list some time ago).
> humans don't enjoy the idea of being given orders from [random] people. Your requirements sure looked that way, though.
...I'm sorry. :( I'll look back over the README for use of the imperative voice. ...Honestly, I've heard this feedback once or twice before AFK and I wasn't sure how to change then, either.
> When I first imagined this project, I didn't picture it taking all day, from start to finish. An uninstaller doesn't do much.
That's part of the problem: drilling the problem down to atomic subtasks, which is needed to estimate, is the actual hard part. With that part done it would take little effort to complete the project, and contributors for further improvement would be easy to find.
That's better, but “Forked from…” small print doesn't escape anyone's attention, and in any case this issue goes beyond GitHub service. You'd be a ‘founder’ of something without having done much for it (keep in mind I wrote my comment before you added remover.go, and also I might be wrong about this whole point too).
Sorry for calling you a random person, I was just trying to explain what I felt when I opened the repo and took a look at it.
> Things would be different if your repo had a well-thought-out skeleton consisting of some (even if completely no-op) units and a (failing but thorough) test suite, tied up to Travis CI and what not.
Absolutely.
Here's the thing.. I can do that in Java, but not Go. I don't know how to do it in Go. Maybe that's really where I went wrong on this. (And wrong I went indeed! The downvote rate increased when I attempted to defend the idea.)
