Minggu, April 21, 2019
Text Size


Update Berita

SSL to secure from hacker attacks

Open-source software developer Kai Engert has proposed an overhaul to the Internet's SSL...

Cara Menghemat Bandwidth Internet, mempercepat browsing

Ada situasi ketika menggunakan internet kita harus benar-benar hemat dengan penggunaan bandwidth ...

Istana Merespons Aksi 313 Berhentikan Ahok

Juru Bicara Presiden Joko Widodo, Johan Budi Sapto Pribowo menegaskan, Presiden Jokowi sangat...

Twitter Bakal Sediakan Layanan Berbayar?

KOMPAS.com - Setelah selama ini hanya meyediakan layanan gratis yang didukung iklan, Twitter...

Megawati: Ahok, Sudahlah Jangan Cerewet

.   Kompas.com - Megawati menasihati Ahok agar tidak terlalu banyak bicara. Mengingat kondi...

Butuh kеrjа? Cоbа cеk di Jооblе

Butuh kеrjа? Cоbа cеk di Jооblе.       Pаdа zаmаn yаng sаngаt k...

  • Tips mengatasi bosen dalam pekerjaan

    Kamis, 01 November 2012 07:48
  • Grunt Mars probe stranded in Earth orbit

    Kamis, 10 November 2011 09:40
  • SSL to secure from hacker attacks

    Senin, 27 Februari 2012 21:09
  • Cara Menghemat Bandwidth Internet, mempercepat browsing

    Minggu, 23 September 2012 18:03
  • Istana Merespons Aksi 313 Berhentikan Ahok

    Kamis, 30 Maret 2017 19:45
  • Twitter Bakal Sediakan Layanan Berbayar?

    Kamis, 30 Maret 2017 19:49
  • Megawati: Ahok, Sudahlah Jangan Cerewet

    Kamis, 30 Maret 2017 19:54
  • Butuh kеrjа? Cоbа cеk di Jооblе

    Kamis, 30 Maret 2017 20:09
Internet Friendly Understanding the latest Facebook privacy train wreck
SocialTwist Tell-a-Friend

Understanding the latest Facebook privacy train wreck

Penilaian Pengunjung: / 1

Facebook's latest privacy problem should raise a few eyebrows. Facebook sharing "private" data in unexpected (and occasionally unwelcome) ways is nothing new, but this newest problem is unusual, in that it does something that Facebook's lengthy (and oft-updated) privacy policy explicitly says should not happen: it shares private user information with advertisers.

The research originally describing the problem looked at more than just Facebook. Many social networking sites, including LinkedIn, Digg, and Twitter, suffered the same leakage of personal data. Of the twelve sites looked at by the researchers, the only one that didn't leak data to advertisers was the one already owned by an advertising company—Orkut.

The private information was leaked to advertisers in a couple ways. The most widespread problem was the HTTP Referer (sic). In general, every time a Web browser requests a page from a Web server, it sends the Web server the URL of the current webpage—the "referer"—in addition to the name of the new page.

This information is used for a number of purposes. It's useful to website owners as it allows them to know, for example, which search engines are providing most of their traffic, and which internal links within the site are being followed (and by implication, which aren't). This lets site owners know which parts of their design are useful, the kind of communities that are interested in their content, the search terms that people are using to find their pages, and so on.

Another popular usage scenario is to block certain requests if the referral comes from a different domain, to prevent bandwidth leeching. If a Web server sees a request for an image but the HTTP Referer refers to a different site, indicating that the image has been linked or embedded on someone else's webpage, it can block the request.

Generally, this information is harmless, because usually the referring URL is not personally identifying. That's because most URLs aren't customized for individual users. Everyone performing the same search in Google will get the same URL for the results page; everyone visiting a page here on Ars will visit the same URL, and so on.

The problem this causes with social networking sites is that often, their referring URLs do contain identifying information, such as the ID or username. This makes sense—the entire point of these sites is that they are personalized and contain user-specific data—but it means that referring URLs become a whole lot more valuable.

To respond to this, Facebook uses—and has used for a long time—a redirect system for any link that takes users away from Facebook. Instead of going directly to the page you want (and hence using your profile URL as the referer), you are first directed to Facebook's redirect page, with the URL http://www.facebook.com/l.php?u=address-of-page-you're-going-to. The redirect page them immediately forwards you to the intended page. By doing this, Facebook ensures that the target site only sees the URL of the redirect page, and not the URL of your profile. In this way, private data is stripped out.

Unfortunately, though Facebook does this for external links, the company wasn't doing anything equivalent for ads embedded within Facebook pages. Facebook contains third-party advertising, and each request for these ads included with it the referring URL of the page containing the ad.

The company has since modified the way ads are embedded and linked within Facebook, so they should no longer see a meaningful referer. Facebook's URLs also appear to be constructed differently than was the case in the past; they place most information after a hash (#) symbol. The portion of the URL after the # is meant to indicate an internal reference on the page, and these internal references are not sent as part of an HTTP Referer in any case. This restructuring of URLs should provide a robust defense against data leakage through the HTTP Referer.

Twitter and Digg

The report described a similar problem on Twitter, but this one seems less clear-cut, and is arguably not a problem at all. Twitter uses Google Analytics for tracking usage data, and as part of this, Twitter embeds an image hosted by Google Analytics, hence providing to Google the address of each page used. However, Twitter URLs tend not to be personally identifying anyway.

Normally, the URL Twitter users look at is either just http://twitter.com/. Though Twitter does have profile pages, these are usually visited by other people who are looking at what the profile page's owner has tweeted. In other words, I don't normally look at (or click links on) http://twitter.com/DrPizza. Other people might, but their name doesn't get put into the URL, only mine.

As such, though the report criticized this as a source of data leakage, it's hard to see why. The only slight issue is that any links from private Twitter streams will include the Twitter username in the referral; the privacy leakage in this seems to be negligible. That said, Google Analytics is widely used, and it's possible that other sites do use it in such a way as to cause a problem—but no problematic usage was actually described in the report.

The third problem concerned Digg. Again, this was an area where there was the potential for a problem, but where the example provided in the report failed to actually demonstrate this. The concern here was the way Digg used cookies. Digg's cookies store, among other things, the username of the logged-in user. Any request made to digg.com will include that username cookie. For digg.com, that's just fine: we want the site we're visiting to know who we are, and if we didn't, we wouldn't register or log in at all.

Cookies are tied to a particular domain name. This can be done in two ways; they can be linked to a single, specific domain name (by specifying the full domain name in the cookie), or they can be linked to a domain and any subdomains. Digg uses both types of cookie; some tied to "digg.com" specifically, and some tied to ".digg.com," meaning that any sub-domain can read the cookie.

This was a concern, because Digg uses a digg.com subdomain for certain tracking features. z.digg.com is a third-party tracking server, but because it uses a subdomain of digg.com, it can see any cookies tied to ".digg.com."

However, the cookie containing the username is specific to digg.com. The z.digg.com tracking server hence has no access to it, so there is no information leakage.

The report appeared to be misleading on this point. The example cited does have a URL that includes a Digg username, but it got there through visiting a user page—it's there not because it's leaking private details of the current user, but rather it's reflecting the page they're visiting, and as such mirrors the information found in the HTTP Referer anyway.

Again, there is the potential for a mistake to be made—if the digg.com cookie allowed subdomain access then the identity of the viewer would indeed be leaked—but that's not a mistake that Digg actually makes.

So, the initial claims of the paper seem somewhat overblown. The situation may be muddied somewhat by third-party applications (which could potentially do things "wrong" even if Facebook et al. get them right), but it appears that in general, the social networking sites aren't routinely leaking personally identifying information to advertisers.

A number of sites are reported to be looking into ways to stop the more minor leakage—the data that, for example, the personal page being visited contains a link to a site—but this is a minor issue compared to the ability to track users directly.

One claim does look to have had some merit: Facebook probably was leaking information to advertisers, but doesn't seem to be any more. The Wall Street Journal's writers contacted Facebook, and state that the company acknowledged the potential for leakage and has taken protective measures in response.

What makes this disquieting is that the way the HTTP Referer works—and the data leakage it can cause—is well-known. Facebook has used redirections for off-site links for a long time, so it was certainly aware of the problem; it just failed to apply a solution across the board. Unlike other decisions the company has made, this almost certainly wasn't deliberate, but it definitely shows a kind of recklessness.

Given the amount of data Facebook and other social networking sites contain about us, this kind of reckless behavior is distressing, and will no doubt fuel the small—but growing—trend of deleting your profile to put an end to privacy concerns. Privacy is about more than having a bunch of checkboxes you can tick: it needs to be considered for every piece of development, or else these accidental problems will continue to arise.

Add New Search
Lynn Cachu  - Understanding the latest Facebook privacy train wr   |172.69.55.xxx |2018-12-23 05:40:34
Could anyone advise me regarding the deadline for Trethowans LLP Training
Contract Application? Happy Holidays and many thanks for your friendship and
Wedlake Bell LLP Training Cont  - Understanding the latest Facebook privacy train wr   |108.162.246.xxx |2019-01-02 03:40:32
We are recruiting digital marketing specialist to join our team at M Taher & Co
Solicitors ?? Anyone interested please send us your CV and cover letter via
Northridge Law LLP Training Co  - Understanding the latest Facebook privacy train wr   |108.162.241.xxx |2019-01-04 14:50:41
We have a law vacancy for IT specialist to join our team at Stikeman Elliott
(London) LLP ????? Anyone interested please send us your CV and cover letter via
Write comment
Please input the anti-spam code that you can read in the image.

3.25 Copyright (C) 2007 Alain Georgette / Copyright (C) 2006 Frantisek Hliva. All rights reserved."

Advertisement Site

Ads - World Friend

Ads - World Friend

Berita lain-lainnya

Understanding the latest Facebook privacy train wreck
25/05/2010 | Indra Febria Widy
article thumbnail

Facebook's latest privacy problem should raise a few eyebrows. Facebook sharing "private" data in unexpected (and occasionally unwelcome) ways is nothing new, but this newest problem is unusual, [ ... ]

Pasukan Amerika Serikat Kalah Telak di Afghanistan
12/09/2012 | Indra Febria Widy
article thumbnail

Pasukan Amerika Serikat (AS) menghadapi kekalahan telak di Afghanistan dan warga negara adidaya itu tidak aman di mana pun mereka pergi di dunia, demikian klaim Taliban menjelang peringatan serangan [ ... ]