6 ms·

I don't think that's what will happen. Ad firms will come up with a server side API you plug into your website so ads can come through your site. You've just ma

I don't think that's what will happen. Ad firms will come up with a server side API you plug into your website so ads can come through your site. You've just made the security problem worse not better as coming from the same site they are allowed to read everything that site does vs coming from iframes from different domains in which case they are allowed to read nothing.

cm2187 11y ago
No, the tracking becomes specific to the site visited (same origin policy), not cross-websites, and I don't have a problem with that. Now there is also the debate of whether all sites deserve to be able to run javascript. I say no. But some people here think that even rendering a blog article should require a lot of client side scripting.
- JoshTriplett 11y ago
  > No, the tracking becomes specific to the site visited (same origin policy), not cross-websites, and I don't have a problem with that. You're assuming the server-side scripts won't share data with a central server.
  - cm2187 11y ago
    They might but how would they correlate me on abc.com and me on xyz.com if they don't have some form of cookie? Browser fingerprinting is the only way I can think of, and between the phasing out of flash, java and silverlight, and having javascript disabled by default, browser fingerprinting is pretty much toothless.
    - jessaustin 11y ago
      If they're talking to a central ad server they can tell it what cookies they're seeing.
      - cm2187 11y ago
        Yes but how do you correlate the two cookies? I go on site abc.com, which gives me the cookie abc:111 Then I go on xyz.com which gives me the cookie xyz:222 Because of the same origin policy, xyz.com can't access the cookies set by abc.com. Abc and xyz can communicate as much as they want on the server side, they will not be able to tell that abc:111 and xyz:222 are the same user (absent additional information: browser fingerprinting, email address if you have an account on both, etc).
        jessaustin 11y ago
        D'oh! You're right of course.
        tehmaco 11y ago
        Just a thought - if the ad network uses js code (hosted on abc.com and xyz.com servers), which loads images from the same domain (but it loaded in on a server-to-server link, and cached and served from the the domain you're visiting). Can they not just set a tracking cookie for that domain that they control with a unique ID, tied to browser fingerprinting, which is transmitted to the ad network? So you visit abc.com for the first time, get an ad image served from the same domain (but was provided from the ad network), have the cookie set, the ID is noted by the ad network. You then visit xyz.com, a new cookie is generated, which can be tracked by the ad network as the ID is the same. So you now get tailored/tracking adverts without any third party domains being accessed by your browser...
        cm2187 11y ago
        Do you mean: I visit abc.com, abc.com serves me an abc cookie, then I visit xyz.com, and xyz.com makes a call to abc from my browser, so that they can use the abc cookie to track me? Well, that is effectively using abc as a tracking server, and abc.com would quickly be added to the adblockers lists. Effectively this is the current model. The other thing is that I may visit abc.com and xyz.com but this particular combination may be unique to me, i.e. I may visit nytime.com and ford.com which may use the same ad network, but you may not visit nytime.com at all and instead wsj.com. Browser fingerprinting is a different problem. It does defeat the same origin policy. But I suggest you look at the sources of entropy: https://panopticlick.eff.org/ https://panopticlick.eff.org/ With javascript off, there is virtually no entropy, just your user agent and HTTP_ACCEPT header. You can't fingerprint a browser at all. If you enable javascript but not plugins, then the Browser Pluggin details give you some entropy, although looking at the list those a relatively generic and would likely be the same on many machines. If you enable plugins (flash, silverlight, java) then you have a massive amount of entropy but realistically all of these plugins are almost gone from major browsers.
DanBlake 11y ago
The main reason this has not happened is that it requires the ad networks to trust the publisher on things like visits/impressions/clicks. If your server has the ability to say "Hey, Jane doe saw your ad just now" when she didnt, thats a recipe for massive fraud. You might say CPC would work and then just send to unique urls the ad network can track- This too wont work, as it allows the publisher to do things like auto-pop the link, hide it in 1x1 iframes, etc.. Overall its a security and fraud nightmare that involves huge cat-and-mouse games. Not to mention the fact that the ad networks have no incentive to change. As more inventory drys up, the spends go up with them (competition increases) - Supply and demand, mostly.
jessaustin 11y ago
At least in this scenario sites would be able to track how much of their poor performance is caused by ad networks. (hint: a bunch!)

cm2187 11y ago

No, the tracking becomes specific to the site visited (same origin policy), not cross-websites, and I don't have a problem with that. Now there is also the debate of whether all sites deserve to be able to run javascript. I say no. But some people here think that even rendering a blog article should require a lot of client side scripting.

JoshTriplett 11y ago
> No, the tracking becomes specific to the site visited (same origin policy), not cross-websites, and I don't have a problem with that. You're assuming the server-side scripts won't share data with a central server.
- cm2187 11y ago
  They might but how would they correlate me on abc.com and me on xyz.com if they don't have some form of cookie? Browser fingerprinting is the only way I can think of, and between the phasing out of flash, java and silverlight, and having javascript disabled by default, browser fingerprinting is pretty much toothless.
  - jessaustin 11y ago
    If they're talking to a central ad server they can tell it what cookies they're seeing.
    - cm2187 11y ago
      Yes but how do you correlate the two cookies? I go on site abc.com, which gives me the cookie abc:111 Then I go on xyz.com which gives me the cookie xyz:222 Because of the same origin policy, xyz.com can't access the cookies set by abc.com. Abc and xyz can communicate as much as they want on the server side, they will not be able to tell that abc:111 and xyz:222 are the same user (absent additional information: browser fingerprinting, email address if you have an account on both, etc).
      - jessaustin 11y ago
        D'oh! You're right of course.
      - tehmaco 11y ago
        Just a thought - if the ad network uses js code (hosted on abc.com and xyz.com servers), which loads images from the same domain (but it loaded in on a server-to-server link, and cached and served from the the domain you're visiting). Can they not just set a tracking cookie for that domain that they control with a unique ID, tied to browser fingerprinting, which is transmitted to the ad network? So you visit abc.com for the first time, get an ad image served from the same domain (but was provided from the ad network), have the cookie set, the ID is noted by the ad network. You then visit xyz.com, a new cookie is generated, which can be tracked by the ad network as the ID is the same. So you now get tailored/tracking adverts without any third party domains being accessed by your browser...
        cm2187 11y ago
        Do you mean: I visit abc.com, abc.com serves me an abc cookie, then I visit xyz.com, and xyz.com makes a call to abc from my browser, so that they can use the abc cookie to track me? Well, that is effectively using abc as a tracking server, and abc.com would quickly be added to the adblockers lists. Effectively this is the current model. The other thing is that I may visit abc.com and xyz.com but this particular combination may be unique to me, i.e. I may visit nytime.com and ford.com which may use the same ad network, but you may not visit nytime.com at all and instead wsj.com. Browser fingerprinting is a different problem. It does defeat the same origin policy. But I suggest you look at the sources of entropy: https://panopticlick.eff.org/ https://panopticlick.eff.org/ With javascript off, there is virtually no entropy, just your user agent and HTTP_ACCEPT header. You can't fingerprint a browser at all. If you enable javascript but not plugins, then the Browser Pluggin details give you some entropy, although looking at the list those a relatively generic and would likely be the same on many machines. If you enable plugins (flash, silverlight, java) then you have a massive amount of entropy but realistically all of these plugins are almost gone from major browsers.

DanBlake 11y ago

The main reason this has not happened is that it requires the ad networks to trust the publisher on things like visits/impressions/clicks. If your server has the ability to say "Hey, Jane doe saw your ad just now" when she didnt, thats a recipe for massive fraud. You might say CPC would work and then just send to unique urls the ad network can track- This too wont work, as it allows the publisher to do things like auto-pop the link, hide it in 1x1 iframes, etc.. Overall its a security and fraud nightmare that involves huge cat-and-mouse games. Not to mention the fact that the ad networks have no incentive to change. As more inventory drys up, the spends go up with them (competition increases) - Supply and demand, mostly.

jessaustin 11y ago

At least in this scenario sites would be able to track how much of their poor performance is caused by ad networks. (hint: a bunch!)