Mel's Notes
Wednesday, 19 November 2008
Webwise test page and test Bookmarklets
Check for Webwise-uid if this bookmarklet finds a webwise-uid cookie it will also replace the uid with a new random one.
Create a webwise-uid=OPTED_OUT test cookie
delete webwise-uid test cookie
Monday, 9 June 2008
Firephorm - the anti-phorm Firefox extension
I've been working on my own anti-phorm extension for Firefox.
Phorm's system will redirect webpage requests through webwise.net to access and transfer the identity number they allocate to you from your webwise.net master cookie to a tracking cookie they'll create for each site you visit. Your browser will send this cookie with future web page request to the site, and their system will use the cookie to identify your profile as it analyses your http traffic - including the search parameters you enter into major search engines, and the content of the pages you view.
My extension modifies http request and response headers. If your ISP deploys Phorm, the idea is to add fake phorm opt-out cookies to all requests which will at least avoid your browser having to store hundreds of Phorm's tracking cookies while you are waiting to migrate to another ISP and to avoid phorm's redirections, and also to have the option of "poisoning" phorm's test data by opting-in but with a tracking UID number that is constantly changing.
It can also warn you if a webpage request was redirected via Phorm's webwise.net or if Nebuad's Faireagle.com site is accessed.
Firephorm is available on the mozila addon site
If your ISP deploys Phorm, then I recommend changing ISP as soon as possible; if that's not an option then another way to protect your privacy is to use an encrypted VPN connection to a trustworthy endpoint.
Useful Links
http://www.inphormationdesk.org/welcome.htm
www.lightbluetouchpaper.org
http://www.donottrustwebwise.org/
http://www.badphorm.co.uk
https://nodpi.org/
Don't forget to sign the petiton http://petitions.pm.gov.uk/ispphorm/
Friday, 16 May 2008
Nebuad's opt-out
I thought I'd have a quick look at one of Phorm's rivals, Nebuad.
Apparently much like Phorm, Nebuad uses a cookie based opt-out. Opting out or back-in is achieved by requesting a URL, in response to which Nebuad's server sends your browser its opt-out, or opt-in cookies...
Surprisingly, the opt-in /opt-out pages are indexed by google: http://www.google.co.uk/search?num=100&hl=en&q=site%3Anebuad.com+optin&meta=.
The above search no longer works try http://www.google.co.uk/search?num=100&hl=en&q=site%3Anebuad.com+optout+OR+optin_done&btnG=Search&meta=.
Also cookie "h" is no longer set.
WARNING: if your ISP uses Nebuad and you've already opted-out, then opening the second search result shown in google (www.nebuad.com/privacy/optin_done.php) will almost certainly opt you back in.
WARNING: I've just noticed that Firefox has a page pre-fetch feature which might result in the opt-in page being accessed and the cookie changed just by clicking on the google search above (depends on which link appears first I think)- if you click on the link above, please make sure you opt-out afterwards.
Nebuad's opt-in/opt page can be found here:- www.nebuad.com/company/optout.php
Opting in creates 2 sets of 5 cookies, "o","u","c","h","w", one set in "a.faireagle.com", and the other in the "b.faireagle.com" subdomain. Opting out sets "o"="9" and deletes the other cookies.
o = 0 appears to indicate opted in.
o = 9 indicates opted out.
My guess is "o" might be a set of binary flags eg
bit #0 = 1 - don't track
bit #3 = 1 - don't show targetted adverts.
'c' is the name of an adserver.
'h' and 'u' are set to matching 14 digit numbers.
'w' is another 14 digit number, which appears to count upwards (could be a date and time perhaps?).
Different sets of numbers are generated for the a and b subdomains.
If you look at the bottom of the opt-in page you'll see the actual opt-in urls passed using a couple of <script> tags right at the very bottom after the closing html tag, the browser will request these urls and the server will set the cookies in the response and close the connection (no actual javascript is returned by the response).
<script language="JavaScript" src="http://a.faireagle.com/a?t=o&track=yes&noads=none"></script>
<script language="JavaScript" src="http://b.faireagle.com/a?t=o&track=yes&noads=none"></script>
And for the opt-out page.
<script language="JavaScript" src="http://a.faireagle.com/a?t=o&track=no&noads=all"></script>
<script language="JavaScript" src="http://b.faireagle.com/a?t=o&track=no&noads=all"></script>
There does not appear to be any measures in place to prevent an "evil" website from opting you back-in using the same method - try clicking on Google's cached optin_done link and check for faireagle.com cookies.
Apparently much like Phorm, Nebuad uses a cookie based opt-out. Opting out or back-in is achieved by requesting a URL, in response to which Nebuad's server sends your browser its opt-out, or opt-in cookies...
Surprisingly, the opt-in /opt-out pages are indexed by google: http://www.google.co.uk/search?num=100&hl=en&q=site%3Anebuad.com+optin&meta=.
The above search no longer works try http://www.google.co.uk/search?num=100&hl=en&q=site%3Anebuad.com+optout+OR+optin_done&btnG=Search&meta=.
Also cookie "h" is no longer set.
WARNING: if your ISP uses Nebuad and you've already opted-out, then opening the second search result shown in google (www.nebuad.com/privacy/optin_done.php) will almost certainly opt you back in.
WARNING: I've just noticed that Firefox has a page pre-fetch feature which might result in the opt-in page being accessed and the cookie changed just by clicking on the google search above (depends on which link appears first I think)- if you click on the link above, please make sure you opt-out afterwards.
Nebuad's opt-in/opt page can be found here:- www.nebuad.com/company/optout.php
Opting in creates 2 sets of 5 cookies, "o","u","c","h","w", one set in "a.faireagle.com", and the other in the "b.faireagle.com" subdomain. Opting out sets "o"="9" and deletes the other cookies.
o = 0 appears to indicate opted in.
o = 9 indicates opted out.
My guess is "o" might be a set of binary flags eg
bit #0 = 1 - don't track
bit #3 = 1 - don't show targetted adverts.
'c' is the name of an adserver.
'h' and 'u' are set to matching 14 digit numbers.
'w' is another 14 digit number, which appears to count upwards (could be a date and time perhaps?).
Different sets of numbers are generated for the a and b subdomains.
If you look at the bottom of the opt-in page you'll see the actual opt-in urls passed using a couple of <script> tags right at the very bottom after the closing html tag, the browser will request these urls and the server will set the cookies in the response and close the connection (no actual javascript is returned by the response).
<script language="JavaScript" src="http://a.faireagle.com/a?t=o&track=yes&noads=none"></script>
<script language="JavaScript" src="http://b.faireagle.com/a?t=o&track=yes&noads=none"></script>
And for the opt-out page.
<script language="JavaScript" src="http://a.faireagle.com/a?t=o&track=no&noads=all"></script>
<script language="JavaScript" src="http://b.faireagle.com/a?t=o&track=no&noads=all"></script>
There does not appear to be any measures in place to prevent an "evil" website from opting you back-in using the same method - try clicking on Google's cached optin_done link and check for faireagle.com cookies.
Thursday, 24 April 2008
Phorm Webwise diagram
A diagram showing how Phorm's system creates copies of its tracking cookie in each domain the brower fetches, based on the analysis published by Richard Clayton The Phorm Webwise System
Phorm's system will intercept requests that don't contain their "webwise" tracking cookie and send them through a series of redirects to access and transfer the unique identity number they allocate to you from your webwise.net master cookie to a tracking cookie they'll create for each site you visit.
This cookie will expire after three days, until then your browser will send this cookie with future requests for the site and their system will strip the cookie from each request and use it to identify your profile as it analyses your http traffic - including the search parameters you enter into major search engines, and the content of the pages you view.
Dr Richard Clayton has updated his paper on Phorm webwise, after Phorm managed to recall more of the detail of their system twisty-little-passages-all-alike.
It now seem that an additonal redirect will occur if a webwise.net cookie isn't present to determine if the user is blocking webwise.net cookies, in which case the user's IP address will be blacklisted for 30 minutes to avoid infinite loops.
It seems logical to me that they would use a similar approach to determine if the user is blocking cookies for the actual site he is visiting, either by setting a test cookie with the first redirect if no cookies are present in the initial request, or by using an additional redirect.
A poster on Badphorm has pointed out that because phorm's system redirects the browser to a third party domain (webwise.net), the webwise.net cookie is in fact a third party cookie.
As reported in that thread Opera will correctly (according to rfc2965) block (neither send not accept) all cookies after a redirect to a third party domain occurs if the "accept only cookies from the site I visit" option has been enabled by the user. It will continue to block cookies until a user action occurs where the user can verify the domain requested -such as clicking on a link on the page (even if subsequently redirected back to the original URL).
This will also result in the genuine website not being sent its cookies after a Phorm redirect, which will cause problems for users of Opera that block third party cookies.
Sunday, 20 April 2008
Dg834gt-1skuk
These "tweaks" are currently only compatible with Firefox and Internet Explorer, unless otherwise indicated.
|
DG834GT Stats basic version. (This should also work in Opera and Safari)
Enable telnet Open telnet console to disable type "killall utelnetd" in the console. (Enable telnet should also work in Opera and Safari)
Target Noise Margin
Override Target Noise Margin % of default target margin 86%=6dB, 100%=7dB(default), 114%= 8db, 180%=12.6db... (also works in Opera)
Connection Table (ip_conntrack)
DNS Settings
Reboot the Router, or restart the PPP connection for DNS changes to take effect. If you input invalid DNS servers, you will be unable to access the internet - to restore the original setting click the "use ISP allocated Domain Name Servers (default)" button above. This change can also be cleared by resetting the router to factory settings using the reset button in the back
This page must be downloaded and opened locally for these options to be enabled.
Add entries to router's hosts file
These settings are not particularily useful unless your connection is 100% stable as the Netgear's host file & its dns server will be reset every time the PPP connection is re-established after a drop.
Enter IP address <space> hostname (eg. 192.168.0.10 mel.lan)
(doesn't survive connection drop or reboot)
Reset DNS Server
Router based "speed test"
If you think poor speeds are caused by your PC or wireless link - This will download a file to the router and time the download (if this test fails to work choose a download file with a shorter URL) Results are only a very rough estimate.
Input the URL of a file to download and its filesize (url must be quite short).
Please be patient, the page will only open once the file download has completed.
Download url Filesize=
Alternative test: Downloads and displays the start and end times so that you can calculate the speed more accurately
Download url {44668/(end-start) Kbps}
Subscribe to:
Posts (Atom)