Search
2 results.
Where is privacy in the advertising wars?
|
|
2016.03.02. 05:59:12
Gulyás Gábor
I've recently read a very nice summary of the advertising wars by Steve Feldman (Stackoverflow), and if you are not up to date on the topic, here is an extract for you:
At this point, it’s pretty clear that ad blocking is a big deal. A recent study suggesting the advertising industry is set to lose over $22 billion in 2015 alone as a result of ad blockers is setting off alarm bells. That is a LOT of money. Companies are scrambling to ‘fix’ the ad blocking problem, as active users of ad blocking utilities hits nearly 200 million. But it’s not just that tiny stop sign in the toolbar raising alarms. Apple caused a panic when they announced that iOS9 would permit the use of ad blockers, as many see mobile ads are an important piece of revenue for the industry.
First, the ad industry went up in arms over ad blocking, offering suggestions like developing ways to deliver specific ads to users employing ad blockers. Then, they considered going after Apple when they announced iOS 9 would permit ad blockers. Later, they began asking users to turn off their ad blockers as a sign of good faith. That did not go so well for some. Finally, they prevented Ad Block Plus from attending an industry event. [...] But some in the industry do get it. Eyeo (the company behind Adblock Plus) outlined in their ‘Acceptable Ads Manifesto’ some strong ideas for how to improve digital advertising-- not to mention the iAB’s L.E.A.N Ads program. While there is criticism for both of these solutions, the positive takeaway is that powerful organizations are finally moving toward addressing the problem.
This looks like things started to change! People are now taking actions to solve the fundamental problems that are became part of the ad world over the years. For this reason, I think the Accaptable Ads Manifest and the LEAN Ads program are good initiatives, but I sense a fundamental problem: privacy concerning problems should be tackled more in details, especially tracking.
These are my proposals in order to fill the real gap:
- Transparency. Data collection and data processing should be transparent to data subjects. When data collection and use is happening, it should be noticeably and clearly communicated.
- Choice to opt-out from data collection. People should decide if they prefer behavioral or contextual ads (no tracking at all). As people might allow being tracked in some contexts, we need more granularity on this as well.
- Security. Over the last years, we heard about cases where malware was distributed through ads. Advertising companies need to be responsible for what they distribute; they should check the content first.
However, there is one more thing that I personally miss from this, which is granularity of payment. I like to read news from aggregated sources, instead of visiting news sites directly. For this reason, I'd really prefer to pay per news item that I'd like to read, rather then paying a couple of dollars per month to each media where I might read something. I hope there will be such branches, although there already some similar like Google Contributor or Mozilla Subscribe2Web.
This post originally appeared in the professional blog of Gábor Gulyás.
0 comment(s). Update your TOR Browser settings – otherwise it’s less anonymous than you’d think
|
|
2015.11.30. 10:09:06
Gulyás Gábor
In this post we discuss a method that allows tracking users of the TOR Browser Bundle (TBB) with the latest release (5.0.4). We believe that this is an important issue for the TBB users to know, as they would expect anonymity by using TBB, but, as we demonstrate below, this remains a false belief under the default TBB settings.
Although this problem is apparently known by the TOR developers [6], we decided to post our findings due to the following reasons. First, we believe that such a vulnerability should be more clearly communicated to the TOR users. Second, there is a simple workaround that most users can adopt until a patch is delivered by the developers.
Why is TBB anonymity at risk?
TBB is an anonymous browser, thus TBB adopts several measures to make user activities non-trackable, or unlinkable to non-TBB activities. One way for a website to track the activities of a browser is to detect the available fonts on the system. (This is exploited by real-world trackers.) The set of installed fonts is typically highly unique, and it has been shown that it is one of the most unique properties that a browser can have [1]. Even more, fonts can be used to track the OS/device itself [2].
The TOR developer community has already been aware of this problem, and some countermeasures have also been taken: they introduced a limit on the number of fonts a website can load [3]. Due to implementation difficulties, experimental countermeasures have been tested in the alpha release [4], but this seems to be omitted from the current stable version. However, we found that none of these measures work currently, leaving TBB users vulnerable to font-tracking attacks.
Examples: check out if the attack works
It can be easily verified if somebody is vulnerable to the attack or not: we only need to visit a website that obviously loads more than 10 fonts, and if it is successful, we have a problem. For example, you can visit this site [7] and check how many fonts it can load. Alternatively, cross-browser fingerprinting sites [5] can be used to test this attack more systematically.
In the following two screenshots, we compared the detected fonts on Linux and on OSX using TBB (left), and also using a regular browser (right). As you can see, more-or-less the same fonts are detected, which shows that TBB can be tracked across multiple sites, and activities within TOR can potentially be linked with activities outside of TOR.
In the following screenshot we show that the list of installed fonts can also be inferred regardless of the privacy settings in TBB. The highest setting, which provides the strongest privacy protections in TBB, seemingly prevents tracking as it disables JavaScript on all sites. However, this is not perfectly the case: arbitrary fonts can be still loaded by CSS.
The CSS font leakage can be checked in our demonstration here [7].
How should I update TBB settings?
Fortunately there are two things that we can do about this. The better solution is to disable the browser to load any fonts except four of them. This can be done by opening the advanced font settings window (Settings > Content > Advanced) and unselecting the option that “websites could choose fonts on their own”. This will provide sufficient protection with all of the four privacy levels that TBB offers. The other possibility is to use the highest privacy setting offered by TBB, but that will further degrade user-experience, and as discussed above, it is not bullet-proof.
This setting could help with preserving anonymity while waiting for the new stable release to deliver a working solution. (That would desirably also cover the vulnerability against another type of fingerprinting [8].)
Gábor Gulyás, Gergely Ács, Claude Castelluccia
EDITED (2015-12-01): Typekit example removed (our example is enough now).
Footnotes and links
[1] In the Panopticlick experiment fonts alone measured a 13.9 bit entropy over 286,777 users. After plugins, it was the second most unique property of browers. The paper is available here: https://panopticlick.eff.org/browser-uniqueness.pdf
[2] Fonts could be extracted in a way that allows cross-browser fingerprinting. Paper: http://gulyas.info/upload/GulyasG_NORDSEC11.pdf
[3] If you are using TBB, and open about:config, you’ll find two TBB specific settings on this called as browser.display.max_font_count and browser.display.max_font_attempts.
[4] Check here: https://blog.torproject.org/blog/tor-browser-50a4-released
[5] http://fingerprint.pet-portal.eu
[6] A workaround was suggested here: https://trac.torproject.org/projects/tor/ticket/5798#comment:13
[7] CSS-based font tester: http://webpoloska.hu/test_font.php
[8] Further information can be found in the related ticket and article on the subject.
https://trac.torproject.org/projects/tor/ticket/13400
New password 
Register