Quote:
Originally Posted by phormwatch
A note from a friend...
Quote:* Phorm plants first-person cookies in the name of various of the sites
that the user visits. *Richard Clayton has noted that it cannot be
guaranteed that these cookies will be invisible to those sites. This
raises the issue that an unexpected cookie arriving at the server, if
the server-side code works by enumerating the cookies, rather than
accessing specific cookies by name (something it is PERFECTLY entitled
to do - it was, up until now, entirely in control of its own
first-person cookies) then it may encounter a cookie containing
unexpected data that fails to parse, and cause server-side errors in
consequence.
|
I've observed such problems while testing my Firefox extension's (Firephorm) option to fake phorm's phorged cookies (intended to avoid redirects) - it caused a few webpages to fail to work with non-helpful error messages.
This would be the same effect a phormed user would observe if they use their laptop to browse on a non-phormed connection (or for 3 days after changing to a non-phormed ISP) Most users probably wouldn't have a clue why they could access such a webpage and probably blame the site or their ISP. ISPs taking on Phormed customers probably should be warning them to delete all cookies after migrating to avoid any phorm caused browsing issues and continued phorm targetting based on the profile compiled while with their previous ISP.
I added the default sub option to my extension to only send a forged cookie after a request has been redirected 3 or more times, in case someone enables forging phorm's tracking cookies on a non-phormed connection as it minimises the chances of it causing a problem.