This has nothing to do with blocking ads. You'd still be affected by this hack whether you were running adblock or not - the service is designed to be extremely difficult for adblockers to catch except maybe on a site-by-site basis. It's more of an argument for blocking all scripts.
This is a service publishers use to show ads when a user has a adblocker enabled. It works on the most popular adblocker, adblock plus (firefox/chrome). Not sure if it works on ublock origin or ghostery/others, but those are still a small proportion of all adblock users.
Noscript would have protected you though, which has a pretty large install base.
Adblock extensions block tracking as well as an extra perk, sometimes by default (ublock origin does). Ultimately their tracking script is a metric they're using to help sell their product/agenda to more users anyway, so its a form of advertising either way, or at the very least in a similar realm.
To be fair, I suspect that content blockers aren't puzzled as to why you would want to block ads. What they're trying to do is make it feel morally/ethically unacceptable to block ads.
This is an example of them failing to live up to their role in the their preferred moral order (i.e. "you don't have to block our ads out of safety concerns because we'll safeguard them for you").
Exactly. Adblocking is almost more important than regular antivirus these days. Arguing against adblocking while serving ads from third party networks with unverified javascript is like arguing that running antivirus software is morally wrong.
I completely agree everyone should be blocking ads for security, but this comparison is not right. Antivirus should already protect you from many known javascript-based malware. The difference is that antivirus will block (some of) the attacks being executed and let ads through. Adblock will block both normal ads and malware.
That's why nobody ever argued that running antivirus is morally wrong.
People have argued against running antivirus: the desktop advertising industry. This is why "antivirus" and "antimalware" are separate products. This is the murky world of the "potentially unwanted program" (PUP).
I'm sure there are people who'd like you not to run AV. But the link you presented does not mention anything about them arguing "that running antivirus is morally wrong."
I don't recall them saying anything about the safety of ads one way or the other. Their arguments seem to center around calling things theft and restating the thesis that if their ad revenue dries up, their content does as well. The safety or lack thereof of advertising isn't mentioned. It isn't part of the narrative they want everyone discussing.
This is more like Banquo's ghost: Something they hoped everyone would forget which comes back to haunt them.
You might be using uBlock, then. For me it's blocking all assets on the pagefair.com site except the contents of the page itself. Temporarily disabling uBlock lets the rest of the page load.
The first iphone jailbreaks went via PNG/JPEG/PDF parser exploits.
Disabling javascript does not protect you against a sufficiently malicious enterprise - and I'd label both the three-letter-agencies and the ex-Soviet mafiya as such. Both have been proven to use such tactics.
If you want to be super-paranoid, only accept BMP or TGA with a specific color depth and no compression and validate the header before parsing. Or even accept only raw RGB data, 3 * width * height, and require the size be passed separately.
Then convert it to png yourself.
You can't prevent exploits from all angles, but you can prevent exploits from some angles.
Is it? I hypothesize that smaller exchange have less resources to develop secure systems. While they maybe smaller targets, I think their architecture maybe less robust. Hence why I trust gmail to run my email rather than rolling my own server.
My advertisers are happy with this approach and instead of taking a CPM or CPC billing monthly like a billboard seems to work just fine meaning I'm not incentivized to game clicks or views.
This is nice because it makes me want to make good decisions for the user experience (no multi-page image galleries) which I believe will help attract the types of visitors my advertisers want to interact with.
Just serve all third-party ad code inside of an IFrame served from a different domain. Even if malicious JS is loaded, it's sandboxed away from any session cookies.
What you've described is precisely what I do, though I also choose to have only static jpg and png graphics. Keeping ads very relevant is also of importance for me: office furniture ads against office design projects and articles.
Selling your own ads takes work for sure, and a different type of work. Instead of technical know how, you need to put in time and energy selling ads and not just sit around waiting for sales to come to you.
You also obviously get to keep 100% of the money from the sale which is nice.
this puts you outside the reach of big ad $, which is moving towards programmatic buying and serving retargeting ads.
You may be able to link up to a big player, but hosting things yourself will require quite a bit of overhead and they pay off may not be worth it, unless you're getting substantial volume (or appealing to a very targeted audience)
btw, traditional display ad CTR is rubbish from an advertisers perspective and we all want to go all in on programmatic + retargeting.
> this puts you outside the reach of big ad $, which is moving towards programmatic buying and serving retargeting ads.
Not if the big ad companies (google's adsense) create a plugin or program that serves the ads up locally instead of making obvious 3rd party calls to their own networks. I suspect they're working on such a plugin as we speak.
I don't think Google's looking to decentralize in any way shape or form. If anything, they want to know more about a viewer and will be actively fighting to prevent decentralization... especially as it'll break a lot of reporting that advertisers expect.
> I don't think Google's looking to decentralize in any way shape or form.
I think google's looking to do what's best for their bottom line. If it becomes more profitable, or even much more profitable to decentralize in that way, they will do it without hesitation.
Perhaps they're looking for a way to decentralize their ads, yet still retain the data & meta-data. Basically, have their cake and eat it too.
I think I saw this. I visited a legit science or business page (don't remember) and a windows said my "Flash player was out of date" and immediately started downloading a Windows ".exe" claiming to be a flash installer. I am on OSX with no Flash installed, so I know it wasn't Adobe's updater.
They're basically selling a content-obfuscating anti-detection system for webpages as a service. Of course it's going to be abused to push malware. They're just lucky the attacker wasn't more sophisticated this time around.
No they aren't. They aren't even an "anti adblocking" tool. They replace ads with "acceptable" (as defined the ad block plus people BTW) ads for ad block users.
That could work but it would be tricky and possibly difficult for them to get right. The hardest part being registering valid content updates.
I've seen integrity validation schemes work well for small enum lists but we'd have to know what the data set size is and the expected rate of change. This of course all before properly adding an SLA to their content providers.
Certainly interesting but I think it may not be the easiest or best way to tackle this problem. I'd love to hypothesize about it if you want to suggest some workflows.
Not really. Since you need to know the correct hash ahead of time, Subresource Integrity works best when you're requesting a well-known piece of static data from a 3rd-party server, e.g. jQuery version x.y from a CDN. For a site like Pagefair (or other sites that serve 3rd-party scripts, like Google Analytics), the benefit of the web platform is being able to serve _dynamic_ data. You get to upgrade your software quickly and easily, without the friction of obtaining the cooperation of your website partners (1st party sites that included Pagefair's scripts) or end users.
If you want to use Subresource Integrity to prevent this kind of a problem, you need to first devise a mechanism to communicate the correct expected hash from the 3rd party site to their 1st party customers in a trusted manner. This is non-trivial. It adds a lot of friction to Pagefair's software development and deployment processes (think about how you would implement A/B testing, for example). It's also not a guarantee - if your servers can be hacked, it's possible your "trusted hash communication mechanism" would be as well, unless you follow stringent security protocols (human confirmation for signing, offline keys, etc.) which would add even more friction.
Of course, you would need cooperation and involvement from your first-party customers for SRI to be effective in the first place, and I don't know how many of them would be thrilled to have to devote engineering resources to fixing potential security problems caused by their partners... sounds like a good reason to consider switching to a competitor.
Sure it could. "It's hard" is not a rebuttal to "it's possible". That ad-networks might need to implement a system to let content-providers review and approve a set of ads that might be served, that have a TTL until they expire, and generates a JS to be included in the local site with SRI hashes to be integrated might be hard, and it also might cede some control to sites as to exactly what ads they are willing to serve, but it's also a responsible way to deal with ad-delivery and would in all likelihood have made this hack if not impossible, at least much harder and likely caught and mitigated with far less exposure. Sure it's harder on both parties (but there are benefits as well), but sometimes things are harder because you are not longer taking unsafe shortcuts, and I have no sympathy for that.
whereas the song content is served from a different host entirely (m.cdn2.rd.io). Presumably this is just because the ads are served from an external ad network, not rdio itself.
You can see the ad request failing in Chrome dev tools, and the console tab shows "net::ERR_BLOCKED_BY_CLIENT".
I will never understand how that company makes money. If you can get users to pay you for your content, then don't try and sell your users time to someone else. Horrible value proposition and if you have to block that much stuff they likely sell your data as well, not to mention many premium clients are shittier than the pirate sites. Hulu value proposition:
* Pay for content.
* Still have to watch commercials.
* Have data about my usage sold to highest bidder.
* Video client that is not as good as putlocker (or whatever the cool kids are using these days)
it is owned by nbc, disney and fox. they still don't get that you can sell content, sell ads, or sell nothing. Very little overlap.
It's like with Lenovo and SuperFish. Even if you have a perfectly good business model and satisfied customer, there's nothing stopping some greedy people to try and extract even more value from their customer.
> they still don't get that you can sell content, sell ads, or sell nothing.
But they can, and do. We pay for our Hulu subscription, and so do literally millions of others.
They are toeing a very fine line, however - too many ads, and I'll ditch them and either use Netflix (which doesn't have the most recent TV shows), or pirate things.
It's also pretty interesting that they're offering a new, more expensive, ad-free service. I wonder how long that one will stay ad-free.
> Since it seems to play an ad after every song (?!) this basically prevents ublock users from using the free version of rdio.
I imagine it tries to play an ad if it hasn't successfully played one in a certain time period. Since you're blocking them, that's between every song. If you weren't blocking them, it would probably be less often.
The big[1] German tabloid BILD.de uses their own anti-adblock solution, and has been in court against the German content network that owns AdBlockPlus for quite some time. (They lost and won some cases each)
So the attacker got the password for a work email (and let's be honest, it was likely a shared account amongst a department not an individual) that was used for the CDN account hosting their serve code, where the attacker appended a malware download link to their script running on however many sites they work with.
And they were able to convince website owners to grant them access to visitor's connection in order to prevent people from blocking ads? And they were also able to convince them to pay money for this service?
> The attackers then immediately performed a password reset to hijack PageFair’s account on a Content Distribution Network (CDN) service that we use to serve our analytics javascript tag. They modified the CDN settings so that instead of serving PageFair’s javascript, it served malicious javascript.
It would have been nice that the article spelled out the exact hostname from that CDN, to find out whether it is blocked by default by blockers.
58 comments
[ 2.7 ms ] story [ 121 ms ] threadNoscript would have protected you though, which has a pretty large install base.
This is an example of them failing to live up to their role in the their preferred moral order (i.e. "you don't have to block our ads out of safety concerns because we'll safeguard them for you").
That's why nobody ever argued that running antivirus is morally wrong.
Normal ads are malware for the brain. It's just that this type of malware is legal and considered by many to be a respectable occupation.
e.g. http://arstechnica.co.uk/information-technology/2015/05/sour...
This is more like Banquo's ghost: Something they hoped everyone would forget which comes back to haunt them.
Out, out, damned spots indeed.
Site owners: Market your ads directly or through smaller exchanges, and host them yourself. This is the only viable long-term option.
Disabling javascript does not protect you against a sufficiently malicious enterprise - and I'd label both the three-letter-agencies and the ex-Soviet mafiya as such. Both have been proven to use such tactics.
Then convert it to png yourself.
You can't prevent exploits from all angles, but you can prevent exploits from some angles.
This is nice because it makes me want to make good decisions for the user experience (no multi-page image galleries) which I believe will help attract the types of visitors my advertisers want to interact with.
Selling your own ads takes work for sure, and a different type of work. Instead of technical know how, you need to put in time and energy selling ads and not just sit around waiting for sales to come to you.
You also obviously get to keep 100% of the money from the sale which is nice.
You may be able to link up to a big player, but hosting things yourself will require quite a bit of overhead and they pay off may not be worth it, unless you're getting substantial volume (or appealing to a very targeted audience)
btw, traditional display ad CTR is rubbish from an advertisers perspective and we all want to go all in on programmatic + retargeting.
Not if the big ad companies (google's adsense) create a plugin or program that serves the ads up locally instead of making obvious 3rd party calls to their own networks. I suspect they're working on such a plugin as we speak.
I think google's looking to do what's best for their bottom line. If it becomes more profitable, or even much more profitable to decentralize in that way, they will do it without hesitation.
Perhaps they're looking for a way to decentralize their ads, yet still retain the data & meta-data. Basically, have their cake and eat it too.
I've seen integrity validation schemes work well for small enum lists but we'd have to know what the data set size is and the expected rate of change. This of course all before properly adding an SLA to their content providers.
Certainly interesting but I think it may not be the easiest or best way to tackle this problem. I'd love to hypothesize about it if you want to suggest some workflows.
If you want to use Subresource Integrity to prevent this kind of a problem, you need to first devise a mechanism to communicate the correct expected hash from the 3rd party site to their 1st party customers in a trusted manner. This is non-trivial. It adds a lot of friction to Pagefair's software development and deployment processes (think about how you would implement A/B testing, for example). It's also not a guarantee - if your servers can be hacked, it's possible your "trusted hash communication mechanism" would be as well, unless you follow stringent security protocols (human confirmation for signing, offline keys, etc.) which would add even more friction.
Of course, you would need cooperation and involvement from your first-party customers for SRI to be effective in the first place, and I don't know how many of them would be thrilled to have to devote engineering resources to fixing potential security problems caused by their partners... sounds like a good reason to consider switching to a competitor.
Since it seems to play an ad after every song (?!) this basically prevents ublock users from using the free version of rdio.
whereas the song content is served from a different host entirely (m.cdn2.rd.io). Presumably this is just because the ads are served from an external ad network, not rdio itself.
You can see the ad request failing in Chrome dev tools, and the console tab shows "net::ERR_BLOCKED_BY_CLIENT".
I just refresh, and it usually works.
I'm not willing to disable Ghostery and uBlock, though; 12 things blocked by Ghostery and 31 by uBlock - I don't need any of it, Hulu, thanks.
* Pay for content. * Still have to watch commercials. * Have data about my usage sold to highest bidder. * Video client that is not as good as putlocker (or whatever the cool kids are using these days)
it is owned by nbc, disney and fox. they still don't get that you can sell content, sell ads, or sell nothing. Very little overlap.
But they can, and do. We pay for our Hulu subscription, and so do literally millions of others.
They are toeing a very fine line, however - too many ads, and I'll ditch them and either use Netflix (which doesn't have the most recent TV shows), or pirate things.
It's also pretty interesting that they're offering a new, more expensive, ad-free service. I wonder how long that one will stay ad-free.
I imagine it tries to play an ad if it hasn't successfully played one in a certain time period. Since you're blocking them, that's between every song. If you weren't blocking them, it would probably be less often.
[1] largest in the western world
And they were able to convince website owners to grant them access to visitor's connection in order to prevent people from blocking ads? And they were also able to convince them to pay money for this service?
It would have been nice that the article spelled out the exact hostname from that CDN, to find out whether it is blocked by default by blockers.