You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

88 lines
5.3 KiB

<html lang=”en-us”>
<link rel="stylesheet" href="../style.css">
<meta charset="UTF-8">
<title>Spyware Watchdog</title>
<h1>Online Spyware Classification Project — Contribution Guide</h1>
<p><a href="/">Back to Home</a></p>
This guide is to share how these articles are written for readers of this website who want to contribute to it
but don't know how, or would like some resources on how to write these articles. So, it should help ease the burden
of writing new articles for writers who don't know about things that can make the articles easier to write and more
<h2>Common Privacy Policy Pitfalls</h2>
Lots of software today contains a privacy policy — and a great starting point for understanding how a program invades your privacy
is to read the privacy policy so that you know what kinds of things the developers admit that the software does. However, it is a
big mistake to take a privacy policy by its word, as many privacy policies are obfuscated, omit information, or lie. There are
several common pitfalls that most privacy policies are guilty of:
<h3>Organization-Wide Privacy Policies</h3>
This is a common obfuscation tactic that many organizations use when writing privacy policies (if you want to give them the
benefit of the doubt, it could be laziness). Instead of writing a privacy policy that explains what kind of information is
being collected about you for each individual software, a privacy policy is written for all of the software that that company
produces and operates. This obviously makes it very hard to find out what one particular software does, and it means that
understanding the privacy policy and how it applies to the software you are trying to find information about will take longer
and will rely on more speculation because of how uncertain the information is.
<h3>"We aren't spyware so we don't need a privacy policy"</h3>
This category is where it's more difficult: programs that are not spyware do not have privacy policies- they don't need them if they
don't violate your privacy. This is OK but there is a category of programs that do not contain privacy policies but still have privacy
concerns. You can't take a developers word that their program is not spyware: you have to actually run the program and inspect any kind
of packets it sends out and what features it has. A lot of people have a lot of different ideas about what is and isn't spyware- so you
might have a developer who thinks that phoning home, etc, isn't a privacy issue that they need to make their users aware of.
<h3>Outdated/Inaccurate Privacy Policies</h3>
Some privacy policies are very outdated and report privacy violations in the program that don't exist anymore, or fail to report new privacy
violations, just because the developer of the software cannot be bothered to keep his privacy policy up to date. In this case such a
privacy policy should be heavily criticized because it shows that the developer cannot properly communicate to his users the privacy implications
of installing his software. So it's really like rolling the dice... who knows what the program will actually do? It's like not having a
privacy policy at all, except worse, because it can fool people into thinking that the program does things that it doesn't do.
Ultimately the takeaway is that privacy policies are meaningful, but they also can't be the only thing to prove a program's innocence.
You have to verify all of the claims made on a privacy policy, and if you can't, you have to doubt them. When a privacy policy is not
enough to make a final decision, you need to use other methods of finding privacy issues in the program.
<h2>Checking a program with MITMproxy</h2>
Ultimately the only way to prove and discover what a program is actually doing to invade your privacy is to look at what kinds of
network activity it is doing when you run it. A great guide is written about how you can check a program's network activity with
MITMproxy to discover spyware by a writer for this site who has written many of the articles on here. It's linked right here:
<a href="">Lifting the veil — how to test browsers for spyware.</a>
<h2>Citing Sources</h2>
Sources should be cited at the bottom of the article as a list of links, with links to archived versions of these links next to them.
There should be at least two archive links, from two different archiving services, but ideally you should provide alternate links to as many
archives as you can. If you can't find an archived version of the page you want to save on a service that allows you to submit a link for
archiving, you should submit it and use that. That being said, there is a useful online service that lets you find archived links
by searching multiple archive sources for links. <a href=""></a> will usually
automate the process of finding all of these archive links and make citing sources much easier- but it's still important to update
and copies of these links.