Forums
| BadPhorm - When good ISPs go bad! :: Forums :: Phorm Discussion :: Tech Talk |
|
<< Previous thread | Next thread >> |
| The Phorm "Webwise" System (by Richard Clayton) | ||
| Go to page << >> | |
|
Moderators: Jim Murray, narcosis, felixcatuk, Sammy, revrob
|
| Author | Post | ||
| Phormic Acid |
| ||
 Registered Member #22 Joined: Mon Feb 25 2008, 11:11PMPosts: 240 | Phormic Acid wrote ... There’s another standards issue which is concerning me. Phorm’s jiggery-pokery doesn’t work with Safari. Why? An initial answer is at: [ image disabled ]Cambridge expert: use Safari to evade Phorm The Mozilla Foundation should be looking to follow suit, to introduce Safari’s privacy enhancements to Firefox. | ||
| Back to top | | ||
| PhormalWarning |
| ||
 Registered Member #242 Joined: Sun Mar 23 2008, 03:59PMPosts: 31 | Phormic Acid wrote ... The Mozilla Foundation should be looking to follow suit, to introduce Safari’s privacy enhancements to Firefox. I think Safari's default behaviour is to block 3rd party cookies i.e. it only allows cookies to be set by the site you are actually visiting. This prevents cookies being sent to advertisers (e.g. DoubleClick) who embed images served from their own site. Edit: I am assuming that an already set cookie will not be transmitted to a 3rd party by Safari although havn't yet confirmed this. In order to serve targeted adverts, Phorm needs 3rd party cookies enabled otherwise they can't communicate your UID to the advert server. I suspect this is why they don't bother with Safari. Firefox can already do this but you have to delve into the about:config settings. I think they don't enable this by default because it breaks certain web sites e.g. mash-up sites that are amalgamations of various 3rd party sites. I remember reading some Firefox suggestions page somewhere where there was a philosophical discussion going on about this. [ Edited Tue Apr 08 2008, 10:41PM ] | ||
| Back to top | | ||
| lardycake |
| ||
 Registered Member #141 Joined: Sun Mar 09 2008, 06:17PMPosts: 183 | The CookieSafe extension for Firefox is also meant to be able to block 3rd party cookies. I've not used it myself. | ||
| Back to top | | ||
| Mel |
| ||
 Registered Member #137 Joined: Sat Mar 08 2008, 06:00PMPosts: 322 | This http://www.greebo.net/2008/03/25/httponly-update/ might be another reason Safari isn't supported yet. | ||
| Back to top | | ||
| phormwatch |
| ||
 Registered Member #297 Joined: Sun Apr 06 2008, 02:57AMPosts: 212 | >Firefox can already do this but you have to delve into the about:config settings. I think they don't enable this by default because it breaks certain web sites e.g. mash-up sites that are amalgamations of various 3rd party sites. I remember reading some Firefox suggestions page somewhere where there was a philosophical discussion going on about this. In which case, we should try to join their mailing lists and strongly suggest that FF behaves more like Safari in how it handles cookies. Anyone have a link to the developers mailing lists? | ||
| Back to top | | ||
| phormwatch |
| ||
| Registered Member #297 Joined: Sun Apr 06 2008, 02:57AMPosts: 212 | I found it here: http://developer.mozilla.org/en/docs/Main_Page | ||
| Back to top | | ||
| Phormic Acid |
| ||
| Registered Member #22 Joined: Mon Feb 25 2008, 11:11PMPosts: 240 | I’m having a little trouble understanding this. PhormalWarning wrote ... I think Safari's default behaviour is to block 3rd party cookies i.e. it only allows cookies to be set by the site you are actually visiting. For Windows Safari 3.1, that’s correct. Looking at the Preferences window, I can see that’s the default setting. I also checked the traffic in and out. Edit: I am assuming that an already set cookie will not be transmitted to a 3rd party by Safari although haven't yet confirmed this. However, that relates only to accepting third-party cookies. Once Safari has accepted a first-party cookie, it will happily return it in a third-party request. The 307 redirections should be being treated as first-party as regards cookies, although I need to do more tests to see if there are exceptions. Safari doesn’t mind setting a cookie given in a 307 response, where the redirection is in the same domain. Importantly, Richard Clayton said, [ image disabled ] The reason for that, as far as I can see, is not so much that they can’t snoop on the traffic, but that in practice Safari has some built-in settings, which means that the cookies which they rely on at the end of the process to serve you up targeted ads will not be sent by Safari, because Safari considers that a privacy risk and doesn’t send the cookies. [ image disabled ] The cookie jiggle is right at the start of the process, not at the advert serving stage. Could it be that the Channel Server wants to send updated cookie information along with the advert? I know there’s the idea of a frequency count, to stop the same advert being shown repeatedly. But, I would have thought that that would be stored in the Channel Server along with any channel matches for your UID. One interesting possibility is that the Channel Server doesn’t store your matches in the long term. I was a little surprised to read from Richard’s report that there will be only one instance of the Channel Server function at each of the participating ISPs. Even so, if you place the channel matches in cookies on the user’s browser, you can access the channel match information across ISPs. Not so much use with a desktop PC, but certainly useful with a laptop. At the point where the Channel Server has made the channel match, there’s no way to pass the information back to the user’s computer. It would have to be buffered up. But, as soon as the user’s browser requests an advert from the webwise.net domain, the Channel Server is able to pass it back. The Channel Server can then remove the buffered channel matches, knowing it will get them back the next time an advert is requested. Phorm could them claim they store even less information. If this were the case, surely they’d be telling us about this … often. Firefox can already do this but you have to delve into the about:config settings. Have a look at network.cookie.cookieBehavior. I think they don't enable this by default because it breaks certain web sites e.g. mash-up sites that are amalgamations of various 3rd party sites. I remember reading some Firefox suggestions page somewhere where there was a philosophical discussion going on about this. I think you’re right. Mel wrote ... This http://www.greebo.net/2008/03/25/httponly-update/ might be another reason Safari isn't supported yet. I’m not sure that’s a concern. There seem to be so many other ways the Webwise cookies can leak out, stopping just JavaScript seems rather futile. | ||
| Back to top | | ||
| EtherDreams |
| ||
 Registered Member #185 Joined: Fri Mar 14 2008, 09:27PMPosts: 114 | FWIW, I wanted to quickly verify for myself how IE7 and FF2 work when set to block third party cookies. Here are the results from simple tests.Firefox 2.0:Ignores cookie in RSP for 3rd party iframe: YES Sends cookie in REQ for 3rd party iframe: NOIgnores cookie in RSP for 3rd party img: YESSends cookie in REQ for 3rd party img: NOIgnores cookie in RSP for 3rd party redirect target: NO!!Sends coookie in REQ for 3rd party redirect target: YES!!Ignores cookie in RSP for 3rd party ##SANITISED##> file: NO!!Sends cookie in REQ for 3rd party ##SANITISED##> file: YES!!Ignores cookie in RSP for 3rd party ##SANITISED##> file: NO!!Sends cookie in REQ for 3rd party ##SANITISED##> file: YES!!IE7:Ignores cookie in RSP from 3rd party iframe: YES Sends cookie in REQ for 3rd party iframe: YES!!Ignores cookie in RSP from 3rd party img: YESSends cookie in REQ for 3rd party img: YES!!Ignores cookie in RSP from 3rd party redirect target: NO!!Sends coookie in REQ for 3rd party redirect target: YES!!Ignores cookie in RSP for 3rd party ##SANITISED##> file: YESSends cookie in REQ for 3rd party ##SANITISED##> file: YES!!Ignores cookie in RSP for 3rd party ##SANITISED##> file: YESSends cookie in REQ for 3rd party ##SANITISED##> file: YES!!Phormic Acid wrote...The 307 redirections should be being treated as first-party as regards cookiesIf you are redirected to a third party domain, its cookies are third party cookies. Remember, third party cookie blocking isn't only about privacy, it is also about unexpected changes of state. However, I recognize the potential for confusion were this handled properly. If I were implementing it, I might utilize a sub-option for this and have it disabled by default. | ||
| Back to top | | ||
| EtherDreams |
| ||
| Registered Member #185 Joined: Fri Mar 14 2008, 09:27PMPosts: 114 | While we are on the subject, I would like to encourage people to keep a close eye on what the working groups are putting into specs, what's getting implemented & enabled in the browsers, etc. There are those in the targeted advertising and Web X.0 communities who greatly influence things and who do NOT have our best interests at heart. Take <a ping> and DOM global storage for example. These folks seek expanded cross domain capabilities and privacy isn't a priority of theirs. | ||
| Back to top | | ||
| Phormic Acid |
| ||
| Registered Member #22 Joined: Mon Feb 25 2008, 11:11PMPosts: 240 | EtherDreams wrote ... Phormic Acid wrote... The 307 redirections should be being treated as first-party as regards cookies If you are redirected to a third party domain, its cookies are third party cookies. It’s not where the redirections are going to, but where the redirections have come from. Assume the following page that has the URL http://www.website1.example/.
<html>
Now consider what happens at the stage described by paragraphs 19 and 20. For the page itself, the layer-seven switch will be trying to set a first-party cookie. For the image, however, the layer-seven switch will be trying to set a third-party cookie. Safari, with it’s default settings, will not allow this. The potential infinite loop would have to be detected. Paragraph 27 considers this for the case of first-party cookies. It could be simply that Phorm don’t want Safari users clogging up the blacklist. There are only a limited number of users who choose to alter the default settings of their web browser to increase the number of cookies that are blocked. The number of Safari users is much more significant. As a further point, to ensure the same situation doesn’t happen with the default settings for both Internet Explorer 6 and 7, the layer-seven switch will also have to fake a Platform for Privacy Preferences Project (P3P) header. | ||
| Back to top | | ||
| Go to page << >> | |
Powered by e107 Forum System