Forums
| BadPhorm - When good ISPs go bad! :: Forums :: Phorm Discussion :: Tech Talk |
|
<< Previous thread | Next thread >> |
| How Webwise Works: intercepts eveything even if opted out? Experts Please Comment | ||
| Go to page >> | |
|
Moderators: Jim Murray, narcosis, felixcatuk, Sammy
|
| Author | Post | ||
| Oblonsky |
| ||
| Guest | Okay, lets examine some facts. Cookies are used as the opt-out mechanism, as stated in the E&Y report. Cookies are domain based (see RFC2965), which means they are tied to a website and it's sub domains so can't be used to control global settings like Webwise off/on. So how does Phorm use cookies to control the opt-out and store the unique random number against which a profile is built? This leaked document, the authenticity of which hasn't yet been challenged, states the browser will "resend" requests, which is interesting. Now lets make an assumption that fits these facts - that every single HTTP GET request is intercepted, and the Phorm servers respond with a redirect header (status code 302 moved temporarily? I'm a bit rusty need to get some experimental proof). And lets assume the redirect will always be a subdomain of a phorm-owned domain, say oix.net. So you ask for www.pcpro.co.uk/phpbb and your browser is told to go to www.pcpro.co.uk.redir.oix.net/phpbb. The browser resends the request but this time the Phorm cookies will be transmitted. The two requests are matched up and Phorm cookies are replaced after the resend with the original site's cookies and the request is finally submitted to the web server (redir.oix.net is stripped from the url, a match against the original request is made and the original HTTP GET request is submitted). The return path is easy to imagine. We know opt-out is via cookie. We know Phorm won't be sent this cookie unless they are first redirected via their server. SO EVEN WHEN A USER HAS OPTED-OUT, ALL THEIR REQUESTS ARE REDIRECTED AND SENT VIA THE PHORM SERVERS. Phorm has been at pains to point out that HTML <FORM> data sent via HTTP POST mechanism won't be intercepted as if this was a privacy feature. But if this assumption is true then of course it CAN'T be intercepted, because security features in browsers do not re-send POST data to be retransmitted in the case of redirects! Tech Team - what is the main reason behind form data not being intercepted? You sound like marketing PR types, is this just spin? From the BBC Q&A wrote ... Q: Does the service modify web-pages you receive via http if they do not contain adverts by participating companies? Does the service ever modify web-pages you receive if you have opted out, even in ways that (shouldn't) be noticeable? A: No, we do not modify web pages or inject ads. We only serve ads to the websites we partner with. In order to participate, websites have to insert a tag into their own page. If you have opted out, will still see ads as you browse - just as you do today - but they won't be from the OIX and they won't be relevant to your browsing. Q: Even if you do opt out your web traffic will still be intercepted and analysed, you just wont see the ads. Is this true? A: No this is not true. If you opt out no data is passed from the ISP to Phorm. ... Q:Would they consider hiring an external agency to audit the provisions for opt-out? A: Yes. We already have an external auditor -- Ernst & Young, and 80/20 Thinking is conducting a Privacy Impact Assessment, but we would welcome suggestions for additional auditing. To be fair to Phorm, it was made clear in The Register Q&A that some parts of the process were under control of the ISP. But who writes the software for this and who tests and audits it before upgrades and patches are deployed? Is it the same audit firm that endorsed a system with a rather flimsy opt-out mechanism that they themselves noted in their own report? I won't bother requoting but from this BBC article Simon Davies of 80/20 talks about being opposed to services which users have to opt-out, but yet he studied the technology before being "impressed" with the safeguards in place to protect privacy. Presumably he also considered the opt-out mechanism? Phorm - has the scope of the Privacy Impact Assessment and the report itself been released in full? In the same article, Kent Ertugrul talks about choice. Add to this the debate about RIPA and DPA and informed consent and consider how that would sit if the assumption holds? Furthermore consider the performance impact at peak times - even if you've disabled Webwise! Would you want to pay your ISP for a service in which every HTTP GET request is repeated and all page requests seemingly go via a proxy which would I imagine get quite busy. And finally - the request matching worries me. Consider multiple users behind a single IP (proxy or masquerading gateway) all visiting the same URL (e.g. gmail) and all signed in with their own session cookies. Is there any chance at all of a mix up? Could you find yourself in an internet cafe spuriously receiving a page containing someone elses email because the session cookies were bound to the wrong re-send? Not if this was implemented properly and port numbers used to bind the orginal and the resent requests, but who has tested the software to this level? Oh, yes, Phorm does not look at web-based email. How is this enforced? If it's a list of websites, then how can you be sure to have every web-based email for every company and private email service in the world? DISCLAIMER - THIS IS ONLY AN ASSUMPTION, but I'm a veteran web developer (created my 1st website in 1994) and I've read the facts: documents released by Phorm, press releases and interviews, plus most forum posts from accross the web. I INVITE FELLOW TECHIES TO PEER REVIEW THIS. DOES THIS HOLD? ARE THERE OTHER POSSIBILITIES TO THE REDIRECT? AND THEN, IF IT HOLDS, HOPEFULLY A JOURNALIST WILL START TO LOOK AT THE ACCURACY AND COMPLETENESS OF ANSWERS FROM PHORM. [ Edited Sun Mar 09 2008, 10:36PM ] | ||
| Back to top | | ||
| davews |
| ||
 Registered Member #142 Joined: Sun Mar 09 2008, 06:47PMPosts: 44 | This theory would seem to be bourne out by what I experienced last summer during the sysip.net trial. I noticed on occasions when I was browsing my own website, hosted in btinternet webspace, that I got requests 'waiting for connection to sysip.net' when I knew damned well that there was no such coding in my site, and checking the downloaded page source proved this (and I certainly know my own coding!). A double request on the lines you suggest would fit this pattern perfectly, and I knew of course that my IP address was masked by the proxy server. At one time I posted a link to whatsmyip (or similar, I forget) and next time I tried that I got blocked as 'too many accesses from that IP'. These sort of issues will surely make the system a nightmare to use regardless of the security issues. Dave | ||
| Back to top | | ||
| Oblonsky |
| ||
| Guest | Very good point Dave. At least 2 journalists I had exchanges with made it clear to me they thought the IT community a bunch of paranoid reactionaries but this arrangement is totally unproven and could have many side effects. Kent and the Phorm PR machine are talking a lot about openness at the moment, maybe BT, Virgin Media and Talk Talk should let us know the exact nature of the trials done to date and talk a bit more about a PROPER opt out where my traffic doesn't touch anything to do with Webwise. [ Edited Sun Mar 09 2008, 07:03PM ] | ||
| Back to top | | ||
| Phormic Acid |
| ||
 Registered Member #22 Joined: Mon Feb 25 2008, 11:11PMPosts: 240 | I’ll now try and expand on what Dephormation Pete, Oblonsky and I have covered previously. The example describes how a request for the BBC homepage might proceed. 1) The browser sends a request for the the page http://www.bbc.co.uk/ 2) This is trapped. A non-persistent cookie is faked for the requested domain and path, containing a unique transaction ID. In this case, the transaction ID is 304709837639687983834. Set-Cookie: phorm304709837639687983834=1 I’m assuming that the transaction ID will be placed in the name rather than the value, to help avoid clashes with genuine cookies. 3) The browser is redirected using code 302 to http://a.webwise.net/services/redirecter?id=304709837639687983834&url=http://www.bbc.co.uk/ 4) This is trapped. The Phorm cookies are retrieved. If no opt-out cookie is detected, the transaction ID is linked to the user’s Phorm ID that is held in the uid cookie. 5) The browser is redirected using code 302 back to http://www.bbc.co.uk/ 6) This is trapped. The request now contains the transaction ID that was set in step 2. The presence of the transaction ID stops further redirection. The transaction ID cookie is stripped out of the request, before finally being passed on to the real www.bbc.co.uk. 7) The response from the real www.bbc.co.uk is relayed back to the browser. The transaction ID cookie is removed by setting it to null in what’s sent back to the browser. | ||
| Back to top | | ||
| RichieISPs |
| ||
 Registered Member #145 Joined: Mon Mar 10 2008, 05:26AMPosts: 91 | Hi phormic - not sure but I think what oblonsky was proposing was even simpler. At step 2 a cookie isnt needed in the bbc.co.uk domain and woulnt I see be any use to phorm to be planting cookies in individual website domains. Phorm claim to know nothing about IP or a connection so lets believe them. Thats becuase in step 3 the domain being redirected to is a subdomain of a phorm domain so phorm cookies belopning to the Phorm system can be readI&set here. Also as oblonsky neatly shows, the url does not have to be rewritten here so extensively as you say. It can be "shifted" onto a subdomain of where the phorm cookies llive by tagging on .oix.net or similar. You do raise an interesting point though - does the client browser then need shifting BACK to the original domain in order to work properly (e.g. cookies from the real web site would't work - the real website wouldnt be allowed to set any cookies if the browser thought it was sat on the redirected domain). Is a second redirect needed? Is this a flaw in the theory or does it mean your ISPs are really medling with your stream even if you opted out? | ||
| Back to top | | ||
| Phormic Acid |
| ||
| Registered Member #22 Joined: Mon Feb 25 2008, 11:11PMPosts: 240 | I think an initial cookie needs to be set because, at that stage, the system doesn’t know the user’s Phorm UID. There needs to be some way of tying up all the requests. A problem with subdomains is that it would mean extra DNS lookups. As you say, if you’re not redirected back, it would break cookies, and how happy would people be if they typed in www.bbc.co.uk and ended up at www.bbc.co.uk.oix.net? The final browser state - address bar, cookies, etc. - must be as if Phorm never intervened. There’s the question of what happens if you block cookies. With the steps I’ve given, you’d be stuck in a never-ending loop. So, if, at step 4, there are no Phorm cookies, different steps need to be taken. 4a) Try and set a cookie. 4b) If the browser refuses the cookie, flag the IP address as non-compliant and redirect the browser from whence it came. All traffic from that IP address will be allowed to pass without intervention for a fix period of time, say one hour. Kent Ertugrul may have been relatively honest when he said that you can just block cookies to opt out. Every so often, a URL will get intercepted by your ISP. I infer from Bill Thompson’s Are the watchers being watched? that the ISPs already record all unencrypted URLs and store them for four days. 4c) If the browser accepts the cookies, redirect the browser to the Webwise consent page. You’d also need to record any important headers, such as Referer, in step 2 to put back in step 6. Even if this isn’t how things are going to work, however it will be implemented will be fairly horrific. | ||
| Back to top | | ||
| TonyH |
| ||
 Registered Member #130 Joined: Sat Mar 08 2008, 09:12AMPosts: 11 | <speculation> I've come across several mentions on various support forums that Safari has, or had, problems dealing with a 302 temporary redirect code and an associated content length of 0. Could this be why (according to BT) Webwise isn't going to to be supported on Safari? </speculation> | ||
| Back to top | | ||
| davews |
| ||
| Registered Member #142 Joined: Sun Mar 09 2008, 06:47PMPosts: 44 | A couple of further comments, having just been reading the patent linked elsewhere in this forum: Assuming this is the correct way it is to be implemented, blocking oix.net and/or webwise.net will not be possible, as this will block access to the redirection on Phorm's servers. ie you will lose all your browsing... Blocking cookies will work as described. I remember some commenting they did lose browsing if they blocked them during the trial. Last summer in the trial I looked specifically for added code in pages as retrieved (especially my own site pages). There was no sign of any added javascript in them, so the suggestion of that as the mechanism to add cookies is incorrect (assuming of course they will do it the same way as in the trial). I also do not recall any cookies from unknown sources arriving on my computer, maybe they weren't sent in the trial. The plot thickens! Dave | ||
| Back to top | | ||
| narcosis |
| ||
  Registered Member #39 Joined: Wed Feb 27 2008, 05:14PMPosts: 324 | Could it be they were just testing the profiler at that stage ? | ||
| Back to top | | ||
| davews |
| ||
| Registered Member #142 Joined: Sun Mar 09 2008, 06:47PMPosts: 44 | Yes you might be right that they were not trialing the cookie process at the time. Another thing has just prompted my memory. During the sysip.net trials I once visited my ebay account. The login did not work the first time, I forget what actually happened but I had to login a second time and all was well. As the theory being put around at the time was hackers getting into the BT network I promptly changed my ebay and paypal passwords (but no nasties happened with those anyway). I wonder if this is one of the 'broken sites' or maybe a reason why they decided to remove looking at Form pages (as presumably ebay login is via a form POST function? Dave | ||
| Back to top | | ||
| Go to page >> | |
Powered by e107 Forum System