Seems the "lets enhance the mechanisms explicitly built-into browsers/web-platforms for collecting information about how user's interact with webpages, apps, etc" folks have been busy. I figured a thread was in order, to mention some recent developments and exchange info. Hyperlink-Auditing aka <a ping> has been around for awhile. It is a pure phone home mechanism meant to inform one or more [cross-domain] servers of which links you click on (and when). Chrome/Chromium Already built into releases Enabled by default: ? Browser settings to control it: ? To disable: ? Firefox Already built into releases Disabled by default in 30.0, etc but people are (once again) pushing to have it enabled by default. Furthermore, some are trying to remove the preferences which control it. Browser settings to control it, which hopefully will remain: browser.send_pings (bool) browser.send_pings.max_per_link (number) browser.send_pings.require_same_host (bool) To disable: set browser.send_pings = false via about:config, user.js, or autoconfig. Some extensions should also block it. Beacon aka navigator.sendBeacon() is newer, and has recently been checked into at least Chrome/Chromium and Firefox. It is a pure phone home mechanism meant to send <whatever> data to (potentially cross-domain) servers, particularly when leaving a page. Chrome/Chromium Already Implemented Which builds, enabled status, etc I don't follow so: ? Browser settings to control it: ? To disable: ? Firefox Already Implemented In FF 30.0 (disabled by default), plans are to enable it soon Browser settings to control it: beacon.enabled (bool) To disable: set beacon.enabled = false via about:config, user.js, or autoconfig. Some extensions should also block it. Note: I spent a modest amount of time trying to understand the Firefox situation. At present, it appears that a Beacon hits shouldLoad() as an entirely new aContentType (TYPE_BEACON). Furthermore, it seems the Mozilla guys are only preflighting *some* cross-domain beacons. So conceivably, there might be some filtering extensions that won't block beacons properly. I tried Firefox Portable 31.0a2 with the latest ABP development build, and that seemed to work OK. Which I think is due to ABP treating non-recognized types as OTHER and applying its rules to OTHER. Long story short, I think this newer "feature" may call for some attention/testing to make sure extensions block it when expected. I can't afford the time to look into the Chrome/Chromium situation, to answer those ?s up above, and try to determine if its implementation might pose any problems for filtering extensions. Perhaps someone else will have the time to do so. I don't know of any public tests pages for these "features", but for those who have a [local] server and would know how to go about things, attached are two test pages I used to do some testing on Firefox.
Thanks for the info . NoScript has two "<a ping...>"-related Advanced options. I don't have "beacon.enabled" in FF 30.0.
In FF 30.0 the preference, itself, is not created by default. Which renders sendBeacon() unavailable for use. Someone wanting to test sendBeacon on FF 30.0 would have to create the preference and set it to true. You should see beacon.enabled=true in FF 31.
For hyperlink auditing in Chrome/Chromium chrome://flags/#disable-hyperlink-auditing AFAIK, nothing can be done about beacons without extensions...or blocking all images.
Thanks for the Chrome/Chromium tip. There is a potential point of confusion here. Some people use the term "web bugs", while others use the term "web beacons", to refer to tracking images and the like. The beacons... Beacons... discussed here are something fundamentally different: Blocking images should not help unless the blocking mechanism is more general and applies to other types of requests. FWIW, I did some FF30.0 + NoScript 2.6.8.28 testing. I spotted TYPE_BEACON in the source so Giorgio Maone is aware of it. NoScript can break sendBeacon() by disabling JavaScript, but I was interested to know if it would detect cross-domain beacon requests "on their way out" and block them in cases where the *receiving site* hasn't been allowed. That is what NoScript does in the case of cross-domain XHR, so I was/am hoping for the same with Beacon. At present though, it appears to me that NoScript *doesn't* detect/block the cross-domain Beacon or Beacon preflight requests. Even when the destination site is explicitly forbidden. Unless you create an ABE rule to do so. ABE does appear to work. FF30.0 + noscript-2.6.8.29rc1.xpi = same result. If anyone else is testing things, I'd be interested to know what you are seeing.
Because I Have a Microsoft account I got a email yesterday about all this lovely stuff that Microsoft is going to do for my privacy and benefit.
Ah, I should read more carefully next time. Maybe HTTP Switchboard would be helpful on the Chrome end. https://chrome.google.com/webstore/detail/http-switchboard/mghdpehejfekicfjcdbfofhcmnjhgaag
Wow I had no clue about this. What an horrible idea. And to see Firefox going along with this nonsense when they are so busy marketing themselves as caring first and foremost for users' best interests is nauseating. DRM, now this... We are now so far from the Firefox which took on IE a decade ago. Are there test pages somewhere using these pings so I can see if it is caught by HTTPSB? (I don't have a server which I fully control, I just have a no-fancy shared hosting). EDIT1: Found this js-fiddle: http://jsfiddle.net/Ronny/5ntzw/ So these hyperlink-auditing pings are sent as request of type "other", so this means HTTPSB can block them through the `other` column in the matrix. EDIT2: More accurately, they are reported in the `other` column in the behind-the-scene matrix, not on the page on which they occur. Most extensions dismiss behind-the-scene requests (as I have observed so far). I am tempted to say they really went out of their way to make sure these pings are not going to be blocked by the user. I advise privacy-conscious users of HTTPSB to blacklist the `other` column in the behind-the-scene matrix. I need to come up with a prominent wiki page to document this.
Generally speaking, you can just point the appropriate url to a specific page on your server and watch for the requests leaving the browser and/or hitting the server. To get past CORS checks, the server will need to send headers. Many shared hosting plans will do. For some instructions: http://enable-cors.org/server.html. For testing purposes, you could be selective about sending access control headers or just send them all (if that would be safe for your context).
FF30.0 + ghostery-5.3.1-fx+an.xpi => Seems that Ghostery for Firefox is designed such that it can/will block both the Beacons and Pings. I'm not familiar with its ruleset and how that may vary for specific types of trackers. I just enabled blocking of all trackers and tried sending beacons and pings to doubleclick.net (mapped to my server).
I integrated my Hyperlink-Auditing, Beacon, and XHR tests into one page, and made it easier to do both same-origin and cross-origin testing. Attached, in case anyone is interested. Edit: 1.1 = Changed ping test hrefs, improved messages, added test mutual exclusion, added version & changelog, cosmetic changes
Looks like Google is now using hyperlink auditing in its search result pages, though I see it only when javascript is enabled.