"Facebook's new ad service, launched earlier this month, gets around the traditional third-party advertising cookies by doing the tracking on its own. When a person visits a website selling shoes on a work PC, a piece of Facebook code placed on that site—Facebook's own cookie—recognizes that the person has logged into Facebook using that browser before. The shoe seller can then send the person an ad for the shoe on Facebook's mobile app—even if that person never registered with the shoe seller."
This highlights the dangers of the seemingly harmless social widgets. Anyone who doesn't already, I highly recommend using a plugin such as ghostery[1] to block them.
Webmasters can create static sharing "widgets" that are nothing more than an href to a url which encodes the page to be shared. This doesn't use any javascript and can't be used to track anyone (unless they actually share the page, in which case tracking is unavoidable). This can be done programmatically or with a simple web service (e.g. [1]).
This is a great technique, because despite the mood in the echochamber here sometimes (I also have absolutely zero interest in using them), many many users legitimately do want to like things or share things or interact with social widget whatevers at some point on some sites.
Using libraries like this makes that interaction absolutely explicit, with minimal loss of ease of use, which means that nothing is shared until that explicit signal that the user wants to share.
The mere loading of the widget sends a signal to Facebook that you visited the shoes page. You don't have to interact with the widget for the info to be sent.
I describe an alternate widget that uses a single link instead of the typical javascript. Loading such a widget sends nothing at all to Facebook, and is untrackable unless clicked by the user.
I prefer "Request Policy", which blocks everything that comes from external domains, and allows you to selectively enable what's needed on a per domain basis, i.e. you can enable googleapis.com on google domains, but it remains off everywhere else.
It's usually obvious to spot the CDNs and avoid the spies.
It breaks a lot of things initially, but after a while, the sites you use often are properly whitelisted, and it isn't a pain anymore.
Seconded. I use this along with NoScript, SelfDestructingCookies, and Adblock Edge (an ABP fork without any "acceptable ads" feature).
A lot of the time it's a big pain to get it working right (say, to watch a video on a news site), but that's simply the price I have to pay in today's web to retain at least a bit of privacy and security.
If anyone wants to make a neat extension, it seems like all these extensions could be combined into one with a slightly better user interface. If you want to make it really spiffy, the black/white listing for these could be shared in a distributed hash table with some sort of voting/trust mechanism.
Is the only difference between Adblock Edge and Adblock Plus that ABE removes the "acceptable ads" checkbox? The ABE site is unclear because it talks about being a fork.
I've been thinking this for a while too! The best comparison would be something akin to "Would you like to allow cnn.com to access XYZ?" that most mobile phones use these days.
It seems that the more locked-down hardware manufacturers may have accidentally stumbled upon a kind of end-user workflow that may actually work for controlling what they want to share with the web!
On my personal blog I made a button to disable/enable all the social media plugins. I don't know if anybody uses it (my readership is approximately zero, so no point in tracking clicks or A/B testing), but I figured I'd give users the option out of courtesy.
It does use a cookie to track your preference. The default is to enable them (since most users are not tech savvy enough to know they want them off, and those same users wouldn't easily find a button to turn them on).
Instead of tracking by default, consider the approach taken by a few sites, where you have "dumb" images with the various social networking logos, that are replaced by the real button when clicked.
Similarly on my current pet project (https://www.photographer.io) I opted to not use the standard sharing buttons at all due to the cookies involved, and I also added an option for users to remove all social buttons from across the site (even though they just use the pop-up share windows now). I've had a few people say they appreciated it, so it's definitely worth giving users that option if possible.
"Facebook's new ad service, launched earlier this month, gets around the traditional third-party advertising cookies by doing the tracking on its own. When a person visits a website selling shoes on a work PC, a piece of Facebook code placed on that site—Facebook's own cookie—recognizes that the person has logged into Facebook using that browser before."
How does this even work? Is the shoe seller placing some kind of JavaScript snippet on their website in order to allow Facebook to track users? Is this coming from their "Like" button?
Yes, the "Like" button is used by Facebook to track users across third-party sites. Clicking the button is not necessary for information to be transmitted to Facebook.
Ghostery seems like a good thing... but how can you really trust them with your privacy? Isn't installing a browser plugin potentially a lot worse for your privacy than just being tracked with cookies? Hate to spread FUD, but I just don't understand how I'm supposed to trust these guys - I would certainly like to.
Well, you can inspect the entirety of the plugin code yourself. While they could of course update it with something bad, there is nothing inherently hidden from you that I'm aware of.
Really? Where can you find the source code? I never noticed it on their site - seems like they're a typically closed-source company to me. Am I missing something obvious?
Lots of ways! First and easiest would be to simply 'inspect popup' on the icon, and then navigate to the sources tab, though you may not get all of the code this way (perhaps if it was conditionally/dynamically loaded).
Second way, and probably the best, would be to go to its store page, and in the URL will be the extension ID; for Ghostery, it's "mlomiejdfkolichcflejclcbmpeaniij". Now, just find that in your Chrome installation directory, e.g. for Win7 the extension would be located at %LOCALAPPDATA%\Google\Chrome\User Data\Default\Extensions\mlomiejdfkolichcflejclcbmpeaniij\.
The last way would be to intercept or otherwise directly down the .crx file (curl, wget, etc.), which is just a compressed zip archive. You can do the same for FF extensions as well, those .xpi files are just zip files.
Man, I don't know. That's not open source - they don't seem to intend for you to easily be able to see and understand the code. There's less peer review that way.
They're also an ad (analytics?) company. I just don't trust them.
"On Wednesday, Microsoft quietly announced in a blog post that the company will give marketers the ability to track and advertise to people who use apps on its Windows 8 and 8.1 operating system on tablets and PCs. The company will do this by assigning each user a number—a unique identifier—that monitors them across all of their apps. (The system doesn't block cookies in Microsoft's Internet Explorer Web browser.) Industry players think Microsoft-powered smartphones and Xbox game consoles will be a natural extension of the system, but Microsoft kept mum on the question."
Apple's change wasn't a feature expansion, it was a limitation and clarification of how the device identifier should be used. Originally, Apple allowed all apps to access a common unique identifier tied to each device. As a developer, it's incredibly useful to identify devices -- but it also had significant privacy implications, so they deprecated this common identifier.
Instead, Apple provided two alternatives:
* A vendor-specific identifier that is shared among all apps created with the same vendor prefix (essentially, coming from the same company). This provides what most devs need for identifying users within their apps and even across apps.
* An advertising identifier that is shared across all apps. This is intended for tracking, but Apple also provides a couple privacy protections for users: (a) users can set a flag asking apps not to perform tracking with this identifier, and (b) users can reset this identifier whenever they want –- the equivalent to clearing cookies.
In case of Apple, the ID isn't shared between apps though. Every app now gets their own ID and even that can be reset across all apps in the privacy preference pane.
In earlier versions of iOS, people were using the device UUID which allowed tracking across apps, but using the UUID isn't possible any more, so tracking is now only possible within one app.
Just to clarify, in the newer iOS versions there are two classes of identifier that replace the UUID:
identifierForVendor is not shared across vendors, but it is shared across apps from the same vendor.
identiferForAdvertising is shared across all apps, but it is not shared between devices and can be reset at any time by the user. (I think the user can suppress it altogether, but I'm not 100% sure.)
This is one of those articles where you really wish the author had a better grasp of technology. From what I could decipher the really story here isn't ending of Cookie Tracking but supplementing/replacing it with unique identifiers for users. Which, if you're logged into Google's system at the moment, I'm pretty sure is already the case. Google knows who you are throughout all of its systems. What it doesn't allow is advertisers to know who you are. If they're considering allowing advertisers access to unique data about each user, that would be a really big story.
Facebook requires you to be logged in to do anything, so there's nothing new here.
Microsoft assigning unique IDs to its Surface devices doesn't really matter because nobody uses them.
What I understood from the badly-written article is this: the big platform companies will start blocking third-party cookies (where applicable, say Chrome) and replacing it with their own centralized, incompatible, proprietary, wannabe-monopolistic version of third-party cookies.
So instead of having pretty much anyone on the Internet tracking you by default you will have pretty much anyone on the Internet tracking you through Google - except for people Google doesn't like. And in the Apple world Apple will be the gatekeeper and so on.
I don't see how this is an improvement.
And thank god for Firefox for keeping these people in check.
Letting the browser generate the unique ID (such as a guid) may actually have benefits for users. As long as the identifiers are kept secret you would have the benefit of a login without the site needing to store any personal information. This gives much more positive control to users than an opaque cookie. It is also easier to make legislation around as you could mandate that the user supplied unique ID is the only information (along with basic browser details) that can be stored.
And then remove the existence of cookies altogether, I infer. Since only a unique identifier is necessary, with all other session data and preferences being stored on the server.
I notice in a comment further up that Apple has two separate IDs. One for advertising and one for tracking users of a vendor's applications. Should this browser ID system have two separate IDs, one for securely identifying a user and another for advertising? The secure ID would have to be unique per website, otherwise phishing schemes just became ridiculously easy.
I suppose you could implement a browser plugin that maintains separate cookies for separate combinations of sites. So that buzzfeed + facebook would be put in one bucket, and cnn + facebook in another bucket. You could then ask the users permission to use real cookies.
This may be part of the lack of technical background in the article, but how do Facebook widgets on people's sites track whether you are logged in to Facebook if not via cookies? The mechanisms I know, user agent and IP address, don't seem reliable enough to replace a session cookie.
So, this isn't so much about the "end" of using cookies to track users as it is about the "rise" of enhanced methods enabled by the fact we are constantly logged in to services like Facebook, Google, Microsoft, etc.
The thing is, even Google services (Search, Analytics, etc) and Facebook (the Like Button, etc) use cookies to track users. It's still fundamentally the same thing. The difference is that by logging in to the same service (Google, Facebook, etc) on difference devices and browsers, they can "link" the cookie data together for a more complete picture of your online activity.
Adding to this cross-cookie data, these services can include data from their actual services (Google Search, the Facebook Social Graph, etc), and are starting to include data about the Apps you use (in their respective ecosystems). It's a nice bundle of data they can sell to advertisers (indirectly, via ad targeting).
The scarier question is: will the tracking be enabled at the client/device level? Will your Google or Microsoft web browser (or OS) directly collect and track information about your browsing? Or will it still be limited to "web tracking" (with enhanced ability to connect cookie data across multiple devices)?
It's a ridiculous nonsensical law full of gaping holes.
If I visit your website, you'll log details about what I'm doing. That's kinda how it works.
This "pop up a massive cookie warning on every fucking website" is worse than advertising that start up playing sound. Worse than the original 'problem'.
BTW The EU are now planning to ban powerful vacuum cleaners in their ever further reaching quest to limit freedom.
"Cookies let advertisers reach digital audiences, but the trail stops at smartphones and tablets, because cookie technology doesn't work well on them."
Is there something here I'm missing? I spend more time browsing the web on my Android phone than my PC and I've never ran into any issues with "cookie-driven" features.
The story seems to be that these companies want to do ad attribution across devices. Example: I click on an Adword on my phone, and come to your site. I then come back later on my desktop computer and buy something. Google would like you to consider this when you evaluate the ROI of that ad campaign. The author of the story sounds completely clueless.
yea, if google, microsoft, fb id every single web/mobile user and sync with each other, wouldn't that trigger some legal issue? that's the least thing the whole online ad industry wants
Interestingly it sounds like MS is going the opposite way to Apple which has been taking steps to stop apps (and probably ads too) from tracking the device (although you can track across different apps from the same developer).
This highlights the dangers of the seemingly harmless social widgets. Anyone who doesn't already, I highly recommend using a plugin such as ghostery[1] to block them.
[1]https://www.ghostery.com/