Skip navigation

Explaining Chrome’s Linux Sandbox

Note: The documentation for Chrome’s Linux sandbox is lacking. This is my attempt to make sense of it and clarify how it works for users who may not want to sift through multiple docs on the subject. If I have misinterpreted, let me know, some of the docs are out of date and I may not have been informed.

Chrome is well known for its sandbox, which has held up incredibly well over the years – not a single in the wild attack against it. But on the Linux side of things it’s even more impressive, Chrome’s sandbox is immensely more powerful than on Windows. Though the architecture is similar, the mechanism is fairly different.

Chrome’s architecture is made up of multiple parts – on Linux there is a broker, your SetUID Sandbox process, and your tabs, renderer, plugins, and extensions (the Zygote processes).

The Chrome-Sandbox SUID Helper Binary launches when Chrome does, and sets up the sandbox environment. The sandbox environment is meant to be restrictive to the file system and other processes, attempting to isolate various Chrome parts (such as the renderer) from the system.

A sandboxed process is put inside a Chroot, a sort of a virtual file system (chroot = change root, it’s a new root). It basically gets its own file system to work with, an din this case, it’s not given any write access to the system. The limitations imposed on the process prevent it from escaping the chroot.

The sandboxed process is also provided a PID namespace (a way for a process to look like it’s standalone on the machine,  or among a subset of processes), denying it the ability to use ptrace() or kill() other processes. ptrace() in particular is dangerous as it allows processes to read or manipulate data in other processes. Sandboxed processes are unable to ptrace() each other as well (set to undumpable).

A network namespace is used as well in order to prevent sandboxed processes from connecting out – not much documentation on this.

The Broker process, which remains unrestricted by SUID, is what handles decisions about downloading files, writing to the disk, etc. It handles the dangerous stuff, and is unrestricted, but it is separated from the areas of the program that are most open to attack. Using an Apparmor profile will allow restriction even of the broker process. Otherwise it remains confined purely by DAC.

The next layer of restriction is provided by the Seccomp-BPF sandbox. Seccomp filters are something I’ve written about before. Their goal isn’t to protect the system from damage, like the SUID sandbox does, but to protect the system from further exploitation.

Seccomp-BPF works by restricting the system calls that programs can make. The implications of this are covered in this post. A quick summary is that a sandbox, or any form of access control, is only as powerful as the kernel. It is very often the case that, rather than trying to find issues with the sandbox itself, an attacker can simply go after the big buggy kernel running underneath it. An attack on the kernel allows for a full bypass of the sandbox.*

Seccomp works by restricting access to the kernel by filtering the ‘calls’ that can be made to it. The fewer calls a program can make the fewer ways it can exploit the system. Suddenly the kernel isn’t this massive glob of attack surface, it’s a much smaller are, with monitored interaction between it and the program.

Chrome on Windows had its sandbox broken at Pwn2Own by MWRLabs. It was, in fact, a local kernel vulnerable that allowed them to bypass the sandbox once they’d gained access to the renderer. Such an attack would be far more difficult on a Linux system with Seccomp enabled.

Overall the sandbox works by reducing the potential for damage and reducing the potential for local exploitation. Chrome is, as always, pouring work into their security. Their sandbox is very impressive, and I would love to see some research into breaking it.

There was a ‘partial reward’ for PinkiePie exploiting ChromeOS, but it was unreliable. No details have been released yet, quite unfortunately.

*Plug for Grsecurity here. See my guide for setting up a hardened Grsec kernel. Seccomp limits kernel attack surface, Grsecurity makes the entire kernel more difficult to exploit.

Java 8 Delayed – Oracle Getting Serious About Security

Oracle’s Mark Reinhold, chief architect of the Java Platform Group has written a blog post about Java 8′s postponement: 

“Looking ahead, Oracle is committed to continue fixing security issues at an accelerated pace, to enhance the Java security model, and to introduce new security features. This work will require more engineer hours than we can free up by dropping features from Java 8 or otherwise reducing the scope of the release at this stage.”

There you have it, really. Oracle is committed to securing Java. Recently they’ve implemented Click to Play for Java Applets not signed by a legitimate certificate authority. An interesting move, though it’s unclear what effect it will have.

Java 8 is going to bring a number of important features, so it’s a strong move by Oracle to postpone it in order to focus on security. In my opinion, that shows they’re taking it more seriously.

Features like Click To Play are nice, but not new or particularly robust. Browsers have enabled Click To Play for out of date Java for some time now. Yet exploits have continued. Another layer of “click yes” is unlikely to deter attackers all too much.

I think it’s worth looking at Adobe FlashPlayer. In the last few months I can’t remember a single in-the-wild attack against it. Yet just a year or two ago it was one of the biggest holes a system could have, providing attackers the same type of opportunity as Java does now. But Adobe did a complete 180, they implemented multiple important hardening features, they forced their plugin into a sandbox for major browsers, and now it’s rarely attacked.

Attackers moved from Flash to Java, because it’s the last plugin to lack security, while maintaining popularity. If Java implements an integrity based sandbox, or finds other ways to reach the level that Flash has, attackers will be left yet again with the decision of where to go, and this time there won’t be as many low hanging fruits.

If Java does it right, and let’s hope they do, I think we’ll see a massive change in the way attacks work over the next year.

EMET 4.0 Beta Released – What’s New?

EMET 4.0 Beta has been released by Microsoft. There are a fair number of changes here.

Certificate Pinning Support

Certificate pinning is a method in which the operating system matches specific certificates to specific servers. This prevents Man-In-The-Middle attacks that involve using another valid certificate to spoof and intercept the connection. It’s essentially a way to enforce that the site you’re seeing is the site you want to see, and it builds on the CA system. It’s a nice feature, though it is already supported by Chrome and probably Firefox as far as I know.

Improved Anti-ROP

The anti-ROP (return oriented programming) mitigation techniques built into EMET 3.5 are now improved for a broader scope. This will prevent new attacks that rely on Return Oriented Programming to bypass DEP. When these methods were first implemented I pointed out the flaws, and these same flaws were later demonstrated by various researchers. We’ll see how these improvements have changed things, if at all.

[...]instead of hooking and protecting only functions at the kernel32!VirtualAlloc layer of the call stack, EMET 4.0 will additional hook lower level functions such as kernelbase!VirtualAlloc and ntdll!NtAllocateVirtualMemory.

Multiple other improvements have been added to address specific issues/ bypasses.

Note that these new features will now also send back a report via the Windows Error Reporting services, with information about exploit attempts on your system.

Default Settings Changed

A really nice feature is that after installation EMET will configure specific apps that Microsoft has tested for compatibility to be enabled. That means that by default you’re protected against a large number of threats, just by installing EMET and doing nothing else. Hugely beneficial.

For more information on EMET see:

http://www.insanitybit.com/2013/03/03/emet-the-enhanced-mitigation-experience-toolkit/

For a guide to set EMET up see:

http://www.insanitybit.com/2012/07/26/setting-up-emet-3-5-tech-preview-9-2/

 

Note that while the guide for set up is for EMET 3.5 it is still almost entirely the same procedure.

Research Precedes Reality

When you look at security from just the last few years you only get a small picture of how things are. And based on that picture you may believe that your systems are secure – you’ve tested them against malware in the wild, you haven’t been infected yet, you’ve stayed ahead of the pack. But, depending on your particular security policies, this may not be the case – it may in fact be the case that there’s already research about bypassing those policies, and attackers will follow.

It’s not hard to see this in more recent days. ROP was a long time ago (at least for me) but what about the first MD5 hash collision ever used for in-the-wild attacks? That’s s something researched as early as the 90′s, but we’ve now seen it adopted for a real attack. Flamer used that collision to bypass Windows Update authentication (or trick it, whatever you want to call it) and install malware onto regular users systems. Those were regular people infected, and that was a very advanced attack. Will we start seeing commonplace MD5 collisions? Absolutely not, but first came the research, and then came the attack.

I think it’s critical to remember that the victims of Flamer were largely your average user. They weren’t the main target, but they were used to propagate the malware. Those people weren’t all government officials and the like, some were just regular people, and they were subjected to a very advanced attack.

Don’t ever think that your computer, or your information, is not highly valuable to an attacker. Maybe you’re just a relay to get to the next person, maybe your credit card info is of value, maybe just compromising the system and hooking it up to a botnot will be enough – the point is that hackers always find a way to make lots of money.

If you think that attacks haven’t evolved in the last few years you’re wrong. One simple example is that attackers aren’t just using the same ROP they always have. As ASLR implementations have improved attackers have had to rely more on information leakage, something that had been talked about for years, but there hadn’t been a need for it as ASLR didn’t even exist on Windows until a few years ago, and it was terribly flawed until Windows 8.

I could list a thousand things, like local kernel exploitation, sandbox escapes, etc, but it would be fruitless. The point is that you can’t look at a system now and judge it by the current threats. Always consider research, because attackers do.

Reminder: I Have A Twitter

Just a reminder, which I like to post once in a while, I do have a Twitter and I use it very often. It’s probably the easiest way to find out about new posts on this site, and I also use it a ton to retweet great research, talk to other people in the field, or ramble (in a brief 140 character limit) about security.

If you’re only following my website you’re only getting half of what I say, really.

Follow me @InsanityBit

Operating Systems Define Security

This seems to be something of an issue for some people to “get” but it’s really not so hard. Your operating system is what defines the security of every part of your system. It enforces a security model, permissions, security technology policies, allows for interfacing in order to garner further security, etc. It is your security, that’s all there is to it.

You can supplement your OS security model by implementing micro-security models within the system. AVs for example have a simple model – allow all execution of files unless they meet a specific criteria. This model is enforced within the operating system, not alongside or above it – it is a policy that can only exist because the OS permits such a thing.

A user model is enforced entirely by the operating system. So far every mainstream operating system maintains a user model in some way or another – enforcing restrictions based on user/group tokens. Linux, Android, Windows all do this.

Enforcing memory corruption policies like DEP, ASLR, SEHOP, are also OS provided technologies – the policies are handled by the operating systems.

It is critical to understand this. It is a fairly basic concept and people seem to get it “from afar” but they don’t seem to get how important it is.

Your micro-security policies that live within your OS do not define the operating system security, in fact, something like an AV can only exist because Windows provides the interfaces for them to work – a significant amount of what an AV does is handled entirely by Windows code.

You must take the above to be true if you’re going to understand the following – users are not some micro-security policy, they exist outside of the operating system, they have a completely separate role. While users can obviously interface with systems through a UI and even change or configure policies, those are still OS policies.

A user can not possibly be expected to hook a function, or perform heuristics on an executable file, because we’ve got a brain and a computer has a CPU and RAM and a HDD and these things don’t just slap together and spit out results.

A user quite obviously has an impact on the system, even on the ‘cleanliness’ of the system – they can make decisions that either infect the system or not. That is entirely different than a user being responsible for the infection, or for the security of the system to rely on the user. If a UAC window asks you “Yes” or “No” that is an OS policy, not a user policy, the user just makes the decision. If they make the wrong decision it is a failing of the policy.

A failing of the operating systems security will lead to infection, not a failing of the user. Perpetuating the notion that users are the ones responsible for infections is backwards and it’ll just continue the constantly too-high rate of infection we see.

Do you blame yourself when you catch a cold? Perhaps. You may have been out in the cold or with a sick person. But do you think that the ability to be infected is a failing on your part? Do you think that somehow illness as a whole is a result of poor decisions? I would hope not – it seems quite obvious that illness is a result of an imperfect immune system fighting off constant waves of rapidly adapting attackers.

So instead of blaming your users for just “being so dumb” perhaps you should start implementing policies that work better. And I empathize – Windows especially does not provide much more policies. The user/group system is dumb and broken and only works when you abuse the hell out of it until it mutates into something completely different.

I was going to talk about PatchGuard and how Microsoft absolutely shot themselves in the foot with it, by trying to force their macro-security policy (which is useless) and not allow for any significant micro-security policies. But people seem to have such issues understanding the basics that I’ll just leave things as they are – just take one thing from this; stop blaming users, start blaming the operating system, and if you’re an administrator, maybe take a little blame too (it’s OK, you can blame the OS more.)

Router Security – Linksys Vulns Exposed

Recently a researcher posted an article entitled “Don’t Use Linksys Routers” in which he details a series of vulnerabilities that he found in very little time. The vulnerabilities affect the popular WRT54GL and EA2700, and they’re very significant, allowing for full access to password files, firmware installation, etc.

These vulnerabilities are so dangerous because your router is at the front of your network – the average user has all of their devices behind one, and a compromise of the router will allow for MITM attacks, DOS, or just a silent botnet/backdoor. And these vulnerabilities took a mere 30 minutes to find, indicating that with only a bit more time quite a few more would pop up. As the author puts it:

This vulnerability tells me that this routers software was never given a security pen-test because it is just TOO easy!

The vulnerabilities speak to an issue with the development lifecycle. And that’s key. You are not just “safe” by using a different router, these vulnerabilities indicate that they’re doing something critically incorrect during the development stage of the software – they are not testing their product for security issues.

So your issues are not limited to WRT54GL and EA2700, and, in my opinion, they’re not even limited to Linksys.

Routers simply don’t have strong security. They sit at the edge of your network, fairly exposed, and they take in all incoming data, leaving them in a hostile environment. They’re rarely patched, and even when patches are pushed out, how often do you really update it? Updating isn’t easy, and there’s often big scary warnings saying you’ll brick your device if you do it (what the hell?) so the vast majority of users are likely very very much vulnerable to a series of already patched vulnerabilities.

And routers don’t do anything extraordinary. Even DD-WRT and Tomato don’t. They just run a simple 2.6 Linux Kernel, which has all of the problems of the Linux kernel already, and then they put some services on it that have to connect out to work.

There’s significant attack surface here.

I demonstrated how anybody could design an internet worm that targeted common network devices like routers and turn them into a powerful botnet that is able to monitor traffic across all types of networks.

That vulnerability demonstrated still remains unpatched FYI. This botnet is for the taking, to whoever goes for it first.

So what can you do to protect yourself?

Well, like I said, just running another router firmware isn’t exactly making you “secure”, but they’ll probably patch better, and not suck so completely hard. So that’s a start.

I also suggest disabling Universal Plug And Play if for whatever reason it has been enabled.

In your administrator settings ensure that you have disabled remote configuration entirely (meaning you have to be wired into the router itself just to get access to the webpage.)

Make sure you change your username and password on the router – make it a strong password, make it unique.

Stay patched.

And hope for the best!

Of course, you can build your own router, which would allow you to secure it significantly more. You could simply take some old laptop you don’t use anymore, throw on Linux, patch it with Grsecurity, set up complex uptables rules, get your services patched constantly, etc. But that’s time.

 

Windows XP – Abandon Ship

Windows XP is officially one year from being an unsupported OS. It’s already an insecure operating system even if you are staying patched, but once patches end it’s quite hopeless. If you are an XP user and you have delusions that you’ll somehow be “secure” just because you’ve managed thus far to avoid run-of-the-mill aimed-at-grandpa malware, you are very wrong – upgrade.

What does end of support mean? It doesn’t mean you can call up Microsoft and ask for help with your problems… it means that Microsoft is no longer going to patch your system. So your system that is already insecure will now no longer get the critically necessary holes – when attackers find a hole, they get to know that they can keep on breaking systems with that hole and no patch will stop them.

Known holes will grow over time, giving attackers everything they need to take out systems. You can sandbox (useless on XP), or use AE (useless anywhere, but especially on XP), or AV (lol), but once an attacker gains any kind of remote code execution your fight is lost. Local security doesn’t exist on XP now, and it certainly won’t in a year.

Now you’re probably looking at your badass XP setup going “Hey, no one’s hacked me yet, I must be doing something right.” You are currently a somewhat slow gazelle in a sea of gazelles with bad knees. In a year you’ll all be running through mud, and the lions will take notice.

Rely on obscurity if you want, but anyone who cares about their security will move to Linux or upgrade their systems to another Windows version.

Let’s cover some programs that you might think will save you if you’re unconvinced.

1) NoScript.

NoScript blocks malicious content within the browser – so if you don’t whitelist attacker-controlled sites, the attacker needs a very specific set of exploits to get into the system. Is it impossible? No. If they get font parsing vulnerabilities, or if they find a NoScript bypass you’re still screwed. And if you whitelist the website you lose significant security. But NoScript is still worthwhile.

 

2) Chrome

Chrome has a powerful sandbox, but on XP it’s much weaker compared to other versions. Without patches all an attacker has to do is get remote code execution and pop the kernel to get full system control and bypass all sandboxes. Again, all sandboxes. Think Sandboxie will save you? Comodo’s virtualization? Avast? They won’t – a kernel exploit is all that’s necessary to bypass all of that. So try to come to terms with that, because I know a lot of people like to believe that their sandbox software is unbreakable.

 

3) AntiExecutable

Only useful in very specific systems on other platforms an AE will be almost entirely useless on XP. Attackers do not need to drop payloads, and even if they did, they could just get privilege escalation before they drop it, unhook the AE software (no, self protection isn’t a thing, stop), and then go ahead and launch their payload. Or like… do any of the other things that make AE less-than-useful. 

 

4) AntiVirus

Well, much like AE, all an attacker has to do is get remote execution and then privilege escalation without touching the disk. Once they do that they can kill the AV, or unhook it, or hijack it, or do whatever they like. And then they continue on their merry way.

 

5) Outbound Firewalls

It should be clear at this point that local security is useless. Especially isolation of applications, because sandboxes are useless, and XP’s attempt at separating users is… not impressive. So an outbound firewall wont’ help either – again, with minor changes to an attack, a full bypass is possible. Local privilege escalation, or simply hop to another user, and get outbound access.

 

6) HIPS

HIPS in this case is referring to ‘pop-up’ HIPS that ask you questions that you will never be able to understand. They’ll ask you about calls to other programs, APIs, the kernel, etc – you can’t understand this. I don’t care who you are. There are undocumented API calls all over Windows, and if you think you can handle that, I don’t know what to tell you – seek help? Any HIPS that’s powerful enough to stop an attacker on XP is also a HIPS that is way too annoying and complex.

 

7) EMET

One of my favorite programs, EMET won’t be of much help here. While it now includes some Anti-ROP mitigation techniques, critical for a system like XP, when the entire OS doesn’t support ASLR it’s entirely useless. And do not think that some other product offering ASLR is going to help – it isn’t, that shit is nonsense that barely randomizes a tiny amount of address space, or, other times, it’s a NOP slide.

 

8) Did I miss anything?

Honestly, just assume that whatever it is, it’s broken. A sandbox on Windows 8 is powerful, and the kernel gets patched, and the system can be secure. On previous versions less so, but at least there are patches. On XP, it was never secure, and patches are bandaids  to provide disincentive to attackers – without them, it’s easy pickings.

And, again, before you go “b-b-but I tested it against real live malware!” – no – in the wild malware is pansy shit aimed at the lowest denominator. If every kid in the class gets a 0 and you get a 5 you’re not a genius, you’re just not a complete idiot. In the wild malware is crafted to target people with only an antivirus installed, with out of date software, etc – it is not hard to stay ahead of it. You can generically attack an XP system and bypass *all* of the security software above (except NoScript potentially) without having to target specific setups.

So let’s simply end any and all ‘debate’ about whether you can stay secure on XP. You can stay lucky, you can even keep the system clean just by being different enough, but you can’t stay secure.

If you don’t get that just slap yourself in the face until it sinks in.

Blink – Chromium And Opera’s New Rendering Engine

Today Google made a very big announcement, they’re leaving WebKit behind and moving to Blink, a new rendering engine based on WebKit. With Blink Google will have more control over the code, and the company will be able to immediately begin stripping out unused or redundant code. Blink is a new project, and Google has only just announced it, but there’s a lot of news coming out all of the time. I don’t know anything that anyone else doesn’t already know, but I’d like to put it in a format that you, my readers, will get, with the sources provided for more in depth study.

I won’t go into any of the ‘browser politics’ or other stuff, this is a security blog, and I’ll write about the security.

1) Smaller code base.

In the Chromium blog post released about Blink it was stated that:

[...]we anticipate that we’ll be able to remove 7 build systems and delete more than 7,000 files—comprising more than 4.5 million lines—right off the bat.

That’s a pretty significant chunk of data they’re removing – 4.5 million lines of code will be removed, ‘right off the bat’. As we know, code is attack surface, and the best way to deal with attack surface is to remove the code. Of course, this code might not have been used in Chromium at all anyways – still, the benefit is now that it’s out of sight and out of mind, vetting code can happen at a much more efficient level without all of that muddled in. A simpler project is a safer project.

2) Google Is Good With Security

Google has been making WebKit more secure by implementing hardening techniques and vetting the code and performing bug bounties etc. It has made a huge difference – but it was limited, they didn’t have the control over the system to make significant changes. Now that this project is under their control (sort of, again, it’s open source, so there’s nothing stopping someone else from forking) they’ll be able to make major changes.

Justin Schuh wrote a Google+ post about this. He notes multiple new security techniques that they’ll be able to implement now:

So, with the Blink project we now have a chance to fix quite a bit of technical security debt that’s accumulated over the years.[...] Some of our immediate changes will include improvements to our basic memory hardening in Blink. We plan on making a number of memory-safety changes, like switching to bounds-checked containers and adding integrity checks at different points in HTML processing and rendering. And one really exciting development will be broad deployment of something we call binding integrity, which ensures that DOM objects are valid at the point they’re bound to JavaScript (nearly eliminating first-order stale pointer and type confusion vulnerabilities in the DOM).

Longer term changes will involve things like refactoring our loading, navigation, and history handling. The nature of bugs in these layers tends to be very subtle and complicated, and is usually due to WebKit’s behavior triggering discontinuities in Chrome’s architecture (e.g. inconsistent navigation state between processes). These issues have led to an array of vulnerabilities including: remote code execution, UXSS, spoofing, and sandbox escapes. With Blink we already have a good sense of how we’ll refactor these layers to directly reflect Chrome’s architecture. As a result, we expect to eliminate certain families of Chrome-specific vulnerabilities entirely.

That’s big news. WebKit has always sort of been Chrome’s ‘weak’ point. It’s not super vulnerable or anything, but based on researchers who break Chrome at competitions, they say the easiest part is always getting RCE. So being able to prevent RCE to begin with is great.

Now that Google’s got the project for itself it’ll be able to implement all of the changes they want.

3) Opera’s On Board Too

Although Opera isn’t known for its security, the company has stated that they will be using Blink in their browser, and committing code to it as well. That’s more eyes on the code, and very qualified ones at that. So it’s not like the Chromium security team has to do it themselves – Blink has already attracted a ton of new developers to look at the code and make changes. This is a great thing. Opera’s browser is way more than just legitimate, it’s constantly quite fast, and has a ton of features. I’m really psyched to see what they commit to Blink.

 

Overall I’m very happy with this move. I think it will have a very big effect on security, and I think we’re likely to see immediate changes. I am very excited to see future bug bounties and where they focus, and where Blink security begins.

To read about Blink: http://www.chromium.org/blink

http://infrequently.org/2013/04/probably-wrong/

http://aerotwist.com/blog/hello-blink/

Will Increased DVR Use Cut Into Advertiser Revenue?

This post is actually an application to the attsavings.com/scholarship, so it’s a break from my usual computer security content. The scholarship asks an interesting question:

In a presentation to advertisers, Ted Harbert, the chairman of NBC, expressed his distaste over using DVRs to skip commercials by saying, “This is an insult to our joint investment in programming, and I’m against it.”

Harbert is expressing an industry-wide phobia among broadcast networks, but what do you think?

The question of DVR and its effect on advertisers ability to make money is interesting, and really applies to quite a lot. Technology is fast paced, but adopting new business models tends to be slow. In the following post I’ll be discussing this specific relationship between DVR as a technology and advertising as a business model.

Will increased DVR use cut into TV advertising revenue?

DVR stands for Digital Video Recorder and, as the name suggests, it’s a technology used to record your favorite TV shows and then watch them later. You’re probably familiar with DVR devices, such as TiVo, which have made their ways into a very significant number of homes. The technology allows you to record your TV shows when you’re not around, and then watch at your convenience, with the ability to fast forward, rewind, or pause at any given time.

The issues that advertisers have with this is pretty clear – when you watch TV you get a commercial break, and those commercials are paid for by various companies. They make a lot of money using these commercials and DVR allows users to circumvent them easily.

But is the issue really DVR? Is that the one technology that advertisers should be worried about? With so many networks now hosting their content online through Hulu or their own services, it seems clear to me that users are always going to be able to control the content better than the advertisers can. Installing Adblock Plus is enough to remove the commercials in the vast majority of online broadcasting.

And what about Piracy? With pirated content the commercials are stripped right out of the videos. No fast forwarding necessary. Pirated content is usually available minutes after the TV show has aired, before the networks even have it on their sites, and it’s accessible by just about anyone.

And, most obviously, what about the remote? I don’t know anyone who doesn’t at the very least just mute their TV during commercials and then ignore it until the show is back, or they’ll just flip to another channel for a few minutes. How can that be controlled? It really can’t be.

All of these new ways of viewing content or avoiding commercials are not going to stop. Things are only going ot get worse for advertisers who rely on commercials. But, again, we still need  the money, so what to do?

Lately it seems like all that’s gotten done is a few innocent people have gotten in trouble for pirating. And while DVR is entirely legal, advertisers’ clearly aren’t happy about it.

But advertisers still need to make money, because all of this content has to get paid for somehow. What they need to do is evolve. The business model of commercials is broken once the users have any control over the content – you can try DRM, but anyone who’s read this blog should know that it’s just not going to do the trick. The content exists on a device that you own and you control, and it’s only ever a matter of work and time before you find a way to control any content that your device accesses.

Instead of trying to fight this technology they should be trying to work with it. Technology isn’t going to wait, they need to catch up. The answer, or at least one of the answers, is to move the advertisements into the shows. Instead of a coca-cola commercial for 30 seconds, have your main character stand near a vending machine, or order a coke at a diner. Get your products into the show, but don’t annoy anyone about it.

If you have a coca-cola commercial for 30 seconds, everyone’s just going to mute it. Or fast forward. Or change the channel. It doesn’t matter how they avoid it, but they will. You put a can of coke in the main characters hand when he’s delivering a speech or dodging bullets, or anything, and people are going to notice it, but they’re not going to try to avoid it at all.

And maybe that’s not solution, maybe the solution is to reformat the entire business model of entertainment, it’s difficult to say. What I can say, with absolute certainty, is that if you try to fight the progress of any technology that’s already out there, you will lose. This goes double for technologies that involve a user getting what they want in a convenient format.