*** empty log message ***
authorMatthew Mondor <mmondor@pulsar-zone.net>
Tue, 7 Aug 2012 12:06:46 +0000 (12:06 +0000)
committerMatthew Mondor <mmondor@pulsar-zone.net>
Tue, 7 Aug 2012 12:06:46 +0000 (12:06 +0000)
site/ng/documentation.html
site/ng/optout_features.html [new file with mode: 0644]

index 74bebd9..ff3387e 100644 (file)
    <li><a href="ajax_position.html">ajax_position.html</a>
   </ul>
 
+  <h3>The "scam" of "opt-out" features</h3>
+  <ul>
+   <li><a href="optout_features.html">optout_features.html</a>
+  </ul>
+
  </div>
 
  <div id="footer">
   Copyright © 2012, Matthew Mondor, ALL RIGHTS RESERVED.<br>
-  <code>$Id: documentation.html,v 1.2 2012/06/18 02:22:11 mmondor Exp $</code>
+  <code>$Id: documentation.html,v 1.3 2012/08/07 12:06:46 mmondor Exp $</code>
  </div>
 </div>
 
diff --git a/site/ng/optout_features.html b/site/ng/optout_features.html
new file mode 100644 (file)
index 0000000..e71db36
--- /dev/null
@@ -0,0 +1,156 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
+       "http://www.w3.org/TR/html4/loose.dtd">
+<html><head>
+<meta http-equiv="content-type" content="text/html;
+charset=utf-8">
+<title>MMSoftware - Documentation</title>
+<link rel="stylesheet" href="/css/mmsoftware.css">
+<link rel="shortcut icon" href="/images/mmsoftware.ico">
+</head>
+<body>
+
+<p><a href="../">Back</a></p>
+<h1>The "scam" of "opt-out" features</h1>
+
+<h2>The multiple issues of advertizing servers</h2>
+<p>
+Advertizing servers may be criticized for a number of reasons:
+</p>
+<ul>
+<li>Increasing page loading time (i.e. unresponsive third-party servers)
+<li>Consuming more bandwidth (especially images and Flash)
+<li>Tracking (web bugs used for targetted advertizing "infecting" a high
+ number of web sites)
+<li>Security (may be used to distribute malware, to exploit cross-site
+ scripting vulnerabilities, to violate user privacy, etc.)
+<li>Lowering content quality (disruptive advertizing, or showing that a
+ "free" service is being used)
+<li>Limiting innovating small businesses which may benefit from
+ offering reasonably priced services as opposed to
+ advertizement-bloated "free" services offered by the huge
+ monopolistic corporations (sometimes even violating anti-trust laws).
+<li>Often relying on cookies for tracking information and preferences
+ (but cookies are a volatile resource)
+</ul>
+
+<h2>The multiple issues of "opt-out" features</h2>
+<p>
+We could conclude that "opt-out" features are considered harmful, or
+even that they are borderline "scams", because of the following
+reasons:
+</p>
+<ul>
+<li>Offered by the same advertizing corporations (conflict of
+ interest, may "forget" user settings anytime, are not legally
+ bound)
+<li>Requires the user to "opt-out" at every advertizing corporation
+<li>Also relies on volatile resources such as cookies to save the
+ "opt-out" preference, thus, a user cleaning the cookies, or using
+ security-conscious settings will have to "opt-out" constantly
+<li>Servers are still contacted, as it consists only of a
+ user-preference setting.  They may respect it and not send
+ advertizing back (but they may), and the user tracking is still
+ done.  Whenever one connects to an affiliated site a connection is
+ still made to the advertizing servers.  This may also still slow
+ down page loading, when the advertizing servers are unresponsive.
+ Unless a DNS caching proxy server is being used, additional DNS
+ queries will also be necessary most of the time, which may be
+ slow on a loaded or slow network (and DNS servers may also be
+ unresponsive).
+<li>Ultimately, the users maintain, and even increase their
+ dependence on those monopolistic corporations.
+</ul>
+
+<h2>Actual solutions to the advertizing (or "spam") problem</h2>
+<p>
+Protecting yourself and your network from advertizing servers and
+web bugs is unfortunately made as hard as possible by browser
+vendors and advertizing corporations.  However, here are some
+known solutions, as well as their drawbacks:
+</p>
+<table>
+ <th>Solutions</th>
+ <th>Drawbacks</th>
+ <tr>
+  <td>
+Disabling javascript, Flash and access to all third party images
+and iframes at the browser-level.
+  </td><td>
+Although this seems ideal on a security standpoint, many contemporary sites
+will not function properly.  Although disabling javascript and
+Flash is easy in most browsers, disabling access to third party
+images and iframes is often harder, sometimes requireing
+third-party modules or patches.  This will also only protect this
+browser, not other web/HTTP clients or machines, unless they have
+the same configuration.
+  </td>
+ </tr><tr>
+  <td>
+Using a custom "hosts" file.
+  </td><td>
+Requires a large up to date database of host names to redirect to
+localhost.  Requires one entry per domain variant, when web bugs
+and advertizing sites may even autogenerate permutations.  Only
+protects the local machine.  May inadvertently affect other services
+than HTTP.  Requires trust in the database provider if using a
+"hosts" file from a third party.  The "hosts" file is also not
+designed for this task, and the DNS libraries normally only expect
+this file to hold a few entries for small networks.  A DNS server
+is normally used for larger networks with more entries.  Using the
+"hosts" file for this is thus inefficient on several levels.
+  </td>
+ </tr><tr>
+  <td>
+Using a custom DNS server.
+  </td><td>
+Has all the disadvantages of using a "hosts" file above, except
+for more efficiency looking up entries in the database, and the
+fact that the DNS server can also be used by other machines of
+the network.  Requires a more competent systems administrator to
+install, configure and secure the server, as well as to configure
+the clients to use the custom DNS server (either via DHCP or
+statically).
+  </td>
+ </tr>
+ <tr>
+  <td>
+Using browser-level specialized third-party modules such as
+"adblock" and "noscript" for Firefox.
+  </td><td>
+Requires regular administration or update of the advertizing
+servers database.  Requires trust in third-party databases if
+using them.  Can only protect the local browser, not other
+web/HTTP clients or other machines, unless they share the same
+configuration.  Sharing the configuration among several browsers
+and systems may not be trivial.
+  </td>
+ </tr>
+ <tr>
+  <td>
+Using a custom HTTP proxy server which specializes in filtering
+requests based on regular expressions matching to protect the whole
+network, such as Privoxy.  Filters are less problematic to update
+than DNS filters because of regular expressions matching, and
+transparent firewall rules could cause all HTTP/web clients to
+connect though it.  Will not affect non-web protocols.  May also
+be taken advantage of to forge HTTP-Referer to point to the
+destination site, or the User-Agent to a more secure string that
+avoids disclosure of specific software and version, etc.
+Can also redirect requests transparently to another HTTP proxy
+server specialized on caching, such as Squid, and may also be used
+in conjunction with a custom caching DNS server for enhanced
+network performance.  We recommend this solution if possible.
+  </td><td>
+Requires regular administration or update of the advertizing
+servers filters database.  Requires trust in third-party databases
+if using them.  Requires a competent enough systems administrator to
+install, configure and secure the server, as well as to configure the
+clients to use the custom HTTP proxy server, in browsers or through
+transparent proxying firewall rules (we recommend the latter).
+  </td>
+ </tr>
+</table>
+
+<!-- : vim:tw=66:ai:
+-->
+</body></html>