1. I'm really surprised legit vendors like LastPass don't become verified authors on the Chrome webstore; it's trivial to setup. We were able to do this for Meldium easily.
2. Joe's comments that it's hard to write an extension that steals data does not seem very true. Someone who is dedicated can do a lot with Javascript.
3. The author doesn't mention the model Mozilla follows with its addons: actual humans code review extensions to determine trustworthiness. They reject extensions containing obfuscated code for example.
Agreed. It would be a rather short script to, e.g., send every js-accessible cookie on every site you visit up to a third party. It doesn't take a lot of code to capture a lot of high value data. The supposition that it does is quite strange.
It does seem like an odd oversight that Chrome allows you to block plugins per site but not extensions. If you click the green lock in your address bar now, you can see the option to block all plugins. It stops java and flash, but allows extensions like adblock, etc to keep running on the page.
Why pick on Chrome? How does this differ from extensions offered by Firefox or Internet Explorer? They all allow essentially similar behavior. Eventually it comes down to whether you trust the extension.
If I'm running AdBlock it needs to be able to modify the HTML of any page and occasionally update its lists using the Internet. But AdBlock Extra Evil Edition might also be paid by someone to not block their ads or to leave beacons in place.
A form filling application could potentially push evil information into a form and submit it before I could do anything. Or it may work the way I expect and only fill in data that I want to be filled. How do you allow the good stuff without also allowing the bad stuff?
This is definitely something that affects all browsers. That said, things are a little different with IE since it does not provide an extension marketplace or a fine-grained permissions model, which Chrome (and Firefox) do.
Am I paranoid for not wanting to install any extensions in Chrome? There are some I'd like to use, Feedly is an example, but I can't get past the part of allowing them access to anything on any website. I would prefer something that lets you allow access on a case by case basis.
It is downright scary how incompetent, indifferent and arrogant most IT organizations are. They are usually run by someone who's background is in procurement (i.e. buying things cheap) or compliance (i.e. lawyer). And if you try to explain something like this to them, they just DO NOT CARE.
Security is about business enabling. We're here to help the business work efficiently, not to get in the way. Feature X might work nicer than Feature Y, but Feature X presents an unacceptable risk to the business. Users are going to demand Feature X even still. It's security's job to present these risks and it's up to the business to accept them or not.
Policy is what you're talking about, and solid enforcement. If you don't have a way to ensure people are adhering to the policy, you're in a world of hurt because yes, they will do whatever they can to get the features they want.
There is truth in this, and always some tension between users and IT/corporate security.
But the bottom line is that the machines are there for work, and a single security problem caused by a single careless/uneducated user can cause devastating consequences for the organisation as a whole, so I find myself increasingly taking the IT guys' side on this one.
Put it this way: the employee who wants to install Chrome because it's their favourite browser or to bring their own device because they don't want to carry a second company one probably isn't the employee who's going to get paged at 3am and then spend all weekend reinstalling clean images on compromised machines if there's a security breach, nor the one who is going to have to explain to senior management why the company has lost $6M this week due to downtime because the recovery had to happen during business hours.
So unless the user wanting to break the rules is willing and able to underwrite all potential losses to the employer, which they aren't, it is perfectly reasonable to not only restrict what they can do with the employer's systems but also to penalise them severely if they try to circumvent those rules.
This is an oversimplification and the type of thinking that gets IT labeled as nothing more than a business cost center. IT shouldn't just be limited to preventing downtime and making sure things continue to work. It should also be focused on making employees more productive. You might say allowing Chrome cost the company $6 million due to downtime, but are you factoring in the potential losses from having a more draconian IT policy. For example, how much more productive would employees be if they could automate part of their normal workload with a good browser extension or how does a more employee focused IT policy alter employee moral and in turn employee retention?
Of course I was oversimplifying, and of course any good IT department recognises that that its job is to help other people do theirs. I did start by acknowledging joelthelion's point, and I have no problem with the idea that someone who has a genuine business need to do something outside the normal rules should be able to request a reasonable exception to whatever general policies might apply.
However, you need an awful lot of indirect benefit to make up for one screw-up that breaches corporate security, particularly if you work in a regulated industry like healthcare or finance. Lawyers and industry regulators don't care about any goodwill you got from letting Bob bring his own laptop to work if Bob's laptop was subsequently left on a train opening access to thousands of customers' medical records or credit card details. You could probably have fired Bob and hired an entire team of other people who didn't care about using their own laptop with the money you're instead paying as a fine for that one, though perhaps not so much if the business collapses due to the adverse PR and an executive or two gets thrown in jail for negligence.
I'm in the same position (IT security at a large corp), with the difference that we're a Google customer. Our email and collaboration suite is Gmail/Drive/Talk/Hangouts. This means we are now recommending Chrome as the default browser on all corporate machines. Keeping Chrome locked down has been a challenge for us and not a week goes by where we don't find that someone has or is planning to attempt to bypass our restrictions by installing Chrome extensions or using web apps that integrate with Google Apps by means of giving them your Google username and password.
Google makes it extremely hard for an enterprise security team to set reasonable restrictions. Our support response from Google is usually "we don't support locking that down" or "we don't have a way to let people access feature X without also allowing feature Y". Make no mistake, Google Apps for Enterprise exists in name only.
The policy in these large IT seems do often be : "don't do anything, it could go wrong". The long term damage is worse but the policy stays because, that way, there is no one to blame (or might be MS for security leaks in IE6 in 2013)
I'm not saying that the issue only came from IT. A well prepared plan that went wrong should be considered a necessary evil.
The amazing thing here is: A few of my non-programmer friends told me that they would NEVER install a Chrome extension that can access all their data.
At the same time, all of them have no issue at all to install a regular Windows application from, say, Download.com. They are surprised when I tell them that any Windows application can not only access all their data but could also format their hard drive...
To cut a long story short: Google does a good job of educating users. Microsoft should follow (and innovate with a more fine grained security system).
> Chrome extensions are worse than just "accessing all your data", since they actually inject code into running web apps en masse. At least with Windows, they'd have to patch a particular binary (and it's non-trivial to so).
There's no need to patch binaries -- you can hook just about everything you want. Whether you want to intercept networking, file IO, or just about anything else, it's trivial with tools like Easyhook. A binary running under your account has complete control of everything happening under your account, in essence, and exercising that control is never hard.
Extensions found at https://addons.mozilla.org/ get reviewed by a human. If there are issues with the code (obfuscated, security risks, etc) the add-on is not approved.
Because a reader asked a question specifically about Chrome. The article begins, "I'm a big fan of Google Chrome and I love using extensions. However, I've noticed that a lot of them request permissions to access all of my data on every site. Why is this?".
On Windows, Chrome also deliberately circumvents the normal system security model, installing in the unprotected user directory rather than as a real application in order to allow its background updates.
It also installs (silently, without permission, and for reasons unspecified) a Firefox plug-in, and it reinstalls/reactivates that plug-in even if the user has explicitly chosen to disable it.
It amazes me that Google seem to get such a free ride with Chrome. A lot of the things it does are either indistinguishable from a lot of the things that malware does or leaving itself wide open to compromise if malware gets onto a system by some other mechanism.
> [Chrome] also installs (silently, without permission,
> and for reasons unspecified) a Firefox plug-in, and it
> reinstalls/reactivates that plug-in even if the user has
> explicitly chosen to disable it.
Could you elaborate more on this? Most of my machines have both Chrome and Firefox installed, but I don't see any unexpected or Chrome-related plugins in Firefox. A web search for [chrome installs firefox plugin] also turns up no relevant hits.
Interesting. Right now I'm looking at a Firefox plug-in called Google Update 1.3.21.135 in Firefox, which I recently disabled (again) because it offers no uninstall option. I certainly didn't put it there myself, nor have I ever knowingly approved it. I just checked, and a similar plug-in has been installed on every other machine we've got handy. Is it possible that you've got something installed that somehow blocks this? It's been happening for years for us, causing much gnashing of teeth.
You are right, I just went through my Firefox plugins and I see "Google Update" along with a few "Google Talk" plugins. Given that I installed Firefox after Chrome, could those plugins have been installed and updated with Google Talk or does Chrome have an active app monitoring in the background?
Installing to a user folder doesn't make the system any more vulnerable to attack. Malware could easily put itself in the same place with or without chrome. Malware can also load programs from a secure location and immediately inject themselves.
Installing to a user folder doesn't make the system any more vulnerable to attack.
Of course it does: it means any malware that manages to get onto the machine running as a non-administrator can arbitrarily compromise Chrome.
If Chrome were installed properly as an application under Program Files, the Windows UAC mechanism would intercept attempts to modify it by unprivileged code.
Installing a general executable platform like Chrome under the users directory effectively creates a privilege escalation vulnerability.
>Of course it does: it means any malware that manages to get onto the machine running as a non-administrator can arbitrarily compromise Chrome.
No. The malware would need to be run under an account with write access to Chrome. Because Chrome is in a user directory, the only accounts that should have write access to it are administrator, and that same user. If malware is running as the normal user account, then it can compromise the Chrome executable, and be able to run on that same user account when Chrome gets re-run. However, this at best allows malware to turn a 1 time compromise into a persistent compromise, and even then it is an ability that the malware has anyway. Assuming that Windows has no mechanism for a user to execute arbitrary code at login (which I doubt), the malware can always replace one of the shortcuts on the desktop with a shortcut to a malicious executable, that then loads the original executable, and maintains the same icon. Granted it is harder to detect a compromised executable, but if you do not know to look, how often to you check shortcuts/login programs?
The malware cannot use this for privledge escalation because the only user who should ever run the Chrome executable is the user in whom's directory the executable is installed. And this is also the only non-administrator who could have compromised it in the first place.
Installing to a user directory does however prevent another type of privledge escalation, because you do not ever need the give the executable (or installer) administrative access.
EDIT: I completely re-wrote this while Silhouette wrote a responce.
If an executable is installed where it can not be simply overwritten, then compromising a session is not sufficient to permanently compromise the program. If it is in the user's directory, then compromising one session lets malware insert it self and compromise every session.
Exactly.
There's an old notion in computer security that as long as you can stop someone getting root, you're doing fairly well. In an age where data leakage, privacy invasion and phishing are probably more serious threats than causing "real damage" that can be fixed by simply (relatively speaking) reinstalling and/or restoring from back-ups, I find the emphasis on not being admin by default rather quaint. Of course it's a step in the right direction, but it's nowhere near sufficient.
Any user probably has access to their own e-mail, files, and so on. Often, that data will be far more valuable to an attacker or disclosing it will be far more costly to the victim than merely installing a virus that makes old-school letters drop down the screen or even than turning the machine into part of a botnet.
Ideally, we'd have an OS-level access control model that restricted access by application and data type, not just by user. There are practical challenges to implementing such a model without unacceptably compromising usability, but at least ensuring that only the intended applications are running is a significant step in the right direction. By avoiding that level of explicit check on changing code you're going to run, Chrome is stepping in the opposite and exactly wrong direction.
As I pointed out in my re-write of my original responce, even if Chrome was installed in Program Files, compromising it would still give malware a persistent compromise on the user.
With regards to your OS-level access control, I think we have examples of how to do it without usability problems. For example, in smartphones, when apps get installed they define what permissions they need. If we assume the publisher of an app is not malicous, then their is no need for a typical user to need to know about this, and we can view it as the app saying "these are the things I am going to access, if I try to access anything else, then I have probably been compromised".
The smartphone implementation seems a bit to crude to be very effective in stopping malware, however there is no reason why we should not be able to make a more fine grained system.
For example, in the Linux world, we have apparmor, which does effectively the same, but is much more configurable. Still, this only requires the program to be honest at install time, and to not have write access to the apparmor configuration file; the user does not need to be aware of its existence.
The problem with these systems is that programs need to do things that we do not want malware to be able to do. For example, Chrome has an auto-update feature. If it gets compromised, then the malware can overwrite the executable just as easily (unless the OS enforces code signing). Say that the program wants to be able to create shortcuts on the desktop, and save data to the harddrive. Now, if it gets compromised, the malware can save itself to the harddrive, and create a shortcut on the desktop labeled "Chrome.exe".
They ask for permissions that are very hard to figure out as a user.
When the user is faced with two options:
1. Click Ok and get started with this app that looks cool.
2. Click No, and go back to the previous screen without the app.
The choice becomes pretty obvious.
My wife simply ignores it and clicks ok. I'm sure most users do the same after the first or second app they install and from then on it becomes a reflex response. Install. Ok. Ok.
Woe is the poor user, who is forced to make do with a free app that violates his privacy. Woe is the poor programmer, who is forced to offer his app for free.
I mean, their is obviously no other solution. We should just quit complaining about it.
>their is obviously no other solution
I don't like it in games, but for applications a freemium model (I hate the buzzword too) seems to be best for developers. Charge for extra features, like Instapaper, App.net, etc.
Or go the route of free without ads and hope that the goodwill leads to recognition and donations.
Freemium is best for software firms with accounting departments, not developers, and not users. 99% of people writing software do not work for Valve or Google. If you are writing quality software, charge for it and people will pay for it. If you're porting another butt scratching tip calculator with twitter integration, then perhaps freemium is just the 5th buzzword you need to get that billion dollar eval.
No one would likely be able to cram enough code into a single plugin to manage to get "all" your information and still have a functioning plugin in only JavaScript.
Does not compute. I don't see the logic in this statement.
I think it would be beneficial for Chrome (Android as well) to allow for an app to have a dynamic set of permissions.
Instead of requiring all web access just so an app can perform an action on any page (when you decide for it to) - what if a specific user action could grant temporary/permanent access to a domain? E.g. Clicking an icon if the app is in the toolbar, or selecting a certain action from a menu.
Chrome has a way to prompt for temporary permissions - but this brings up an alert box, and that is never ideal, it would be nice if the user interaction could be taken for permission.
Other features I wish Android's security model has are 'soft permissions', and 'pseudo permissions'.
Soft permissions would be where an app can function without permission, but has feature(s) that require it. For example, if I install a game, I should be able to play it without giving it internet access. However, if they want to have a online high-score system they must require that I give them internet access in order to install the app;
Pseudo permissions would be where the app thinks it has permission to use something, but it is really receiving bogus data. For example, say an app 'requires' access to my phones GPS system (when such access is not critical to the function of the app), it would appear to the app that it has access, but the data it receives would not corralate to the actually data.
I think I recall seeing a project to implement both of these features in Android, but I do not recall what it is called.
Perhaps all data access by extensions should be logged. It wouldn't be of much interest to most programming laymen, but it would be more accessible/understandable than pointing them to Extension Gallery and Web Store Inspector so they can look at the code. I wouldn't recognize well obfuscated code that can grab my CC#, but I can recognize the number itself just fine.
At the least, it would let everyone know that their extension's activities are being watched. And laymen knowing that extension authors know that this activity is watched would be reassuring to the laymen.
Could such logging be done by a separate extension?
Chrome is addressing this with a feature that grants access on a temporary basis to the active tab. This is a great improvement for many types of extensions.
> The activeTab permission gives an extension temporary access to the currently active tab when the user invokes the extension - for example by clicking its browser action. Access to the tab lasts until the tab is navigated or closed.
> The main benefit of the activeTab permission is that it displays no warning message during installation.
For any Extension developers, there are some workarounds to avoid asking for the "tabs" permission.
If you just need to know when a tab is visible for your content scripts to do things, use the Page Visibility API[1].
If you want your Extensions background scripts to notify all content scripts of something, you can rely on `chrome.storage.onChanged` event. The storage API does not warn users about permissions[2]
If anyone's interested in code samples, I could through some snippets in a gist.
52 comments
[ 3.4 ms ] story [ 85.2 ms ] thread1. I'm really surprised legit vendors like LastPass don't become verified authors on the Chrome webstore; it's trivial to setup. We were able to do this for Meldium easily.
2. Joe's comments that it's hard to write an extension that steals data does not seem very true. Someone who is dedicated can do a lot with Javascript.
3. The author doesn't mention the model Mozilla follows with its addons: actual humans code review extensions to determine trustworthiness. They reject extensions containing obfuscated code for example.
If I'm running AdBlock it needs to be able to modify the HTML of any page and occasionally update its lists using the Internet. But AdBlock Extra Evil Edition might also be paid by someone to not block their ads or to leave beacons in place.
A form filling application could potentially push evil information into a form and submit it before I could do anything. Or it may work the way I expect and only fill in data that I want to be filled. How do you allow the good stuff without also allowing the bad stuff?
http://www.chromium.org/administrators/policy-list-3
You can whitelist and blacklist extensions, whitelist sources, force install extensions and block them by type only.
It shouldn't be hard to prevent all extensions from running.
Plus they will make users hate you.
Policy is what you're talking about, and solid enforcement. If you don't have a way to ensure people are adhering to the policy, you're in a world of hurt because yes, they will do whatever they can to get the features they want.
But the bottom line is that the machines are there for work, and a single security problem caused by a single careless/uneducated user can cause devastating consequences for the organisation as a whole, so I find myself increasingly taking the IT guys' side on this one.
Put it this way: the employee who wants to install Chrome because it's their favourite browser or to bring their own device because they don't want to carry a second company one probably isn't the employee who's going to get paged at 3am and then spend all weekend reinstalling clean images on compromised machines if there's a security breach, nor the one who is going to have to explain to senior management why the company has lost $6M this week due to downtime because the recovery had to happen during business hours.
So unless the user wanting to break the rules is willing and able to underwrite all potential losses to the employer, which they aren't, it is perfectly reasonable to not only restrict what they can do with the employer's systems but also to penalise them severely if they try to circumvent those rules.
However, you need an awful lot of indirect benefit to make up for one screw-up that breaches corporate security, particularly if you work in a regulated industry like healthcare or finance. Lawyers and industry regulators don't care about any goodwill you got from letting Bob bring his own laptop to work if Bob's laptop was subsequently left on a train opening access to thousands of customers' medical records or credit card details. You could probably have fired Bob and hired an entire team of other people who didn't care about using their own laptop with the money you're instead paying as a fine for that one, though perhaps not so much if the business collapses due to the adverse PR and an executive or two gets thrown in jail for negligence.
Google makes it extremely hard for an enterprise security team to set reasonable restrictions. Our support response from Google is usually "we don't support locking that down" or "we don't have a way to let people access feature X without also allowing feature Y". Make no mistake, Google Apps for Enterprise exists in name only.
I'm not saying that the issue only came from IT. A well prepared plan that went wrong should be considered a necessary evil.
At the same time, all of them have no issue at all to install a regular Windows application from, say, Download.com. They are surprised when I tell them that any Windows application can not only access all their data but could also format their hard drive...
To cut a long story short: Google does a good job of educating users. Microsoft should follow (and innovate with a more fine grained security system).
There's no need to patch binaries -- you can hook just about everything you want. Whether you want to intercept networking, file IO, or just about anything else, it's trivial with tools like Easyhook. A binary running under your account has complete control of everything happening under your account, in essence, and exercising that control is never hard.
Doesn't the very same problem exist with Firefox extensions / add-ons? After a quick online search, it seems that this problem is far from being a Chrome thing... [1] http://www.computerworld.com/s/article/9152578/Mozilla_confi... [2] http://www.networkworld.com/columnists/2009/020309antonopoul...
It also installs (silently, without permission, and for reasons unspecified) a Firefox plug-in, and it reinstalls/reactivates that plug-in even if the user has explicitly chosen to disable it.
It amazes me that Google seem to get such a free ride with Chrome. A lot of the things it does are either indistinguishable from a lot of the things that malware does or leaving itself wide open to compromise if malware gets onto a system by some other mechanism.
[Edit] Here's a link describing the plug-in: http://superuser.com/questions/156913/what-is-the-google-upd...
Of course it does: it means any malware that manages to get onto the machine running as a non-administrator can arbitrarily compromise Chrome.
If Chrome were installed properly as an application under Program Files, the Windows UAC mechanism would intercept attempts to modify it by unprivileged code.
Installing a general executable platform like Chrome under the users directory effectively creates a privilege escalation vulnerability.
No. The malware would need to be run under an account with write access to Chrome. Because Chrome is in a user directory, the only accounts that should have write access to it are administrator, and that same user. If malware is running as the normal user account, then it can compromise the Chrome executable, and be able to run on that same user account when Chrome gets re-run. However, this at best allows malware to turn a 1 time compromise into a persistent compromise, and even then it is an ability that the malware has anyway. Assuming that Windows has no mechanism for a user to execute arbitrary code at login (which I doubt), the malware can always replace one of the shortcuts on the desktop with a shortcut to a malicious executable, that then loads the original executable, and maintains the same icon. Granted it is harder to detect a compromised executable, but if you do not know to look, how often to you check shortcuts/login programs?
The malware cannot use this for privledge escalation because the only user who should ever run the Chrome executable is the user in whom's directory the executable is installed. And this is also the only non-administrator who could have compromised it in the first place.
Installing to a user directory does however prevent another type of privledge escalation, because you do not ever need the give the executable (or installer) administrative access.
EDIT: I completely re-wrote this while Silhouette wrote a responce.
Exactly.
There's an old notion in computer security that as long as you can stop someone getting root, you're doing fairly well. In an age where data leakage, privacy invasion and phishing are probably more serious threats than causing "real damage" that can be fixed by simply (relatively speaking) reinstalling and/or restoring from back-ups, I find the emphasis on not being admin by default rather quaint. Of course it's a step in the right direction, but it's nowhere near sufficient.
Any user probably has access to their own e-mail, files, and so on. Often, that data will be far more valuable to an attacker or disclosing it will be far more costly to the victim than merely installing a virus that makes old-school letters drop down the screen or even than turning the machine into part of a botnet.
Ideally, we'd have an OS-level access control model that restricted access by application and data type, not just by user. There are practical challenges to implementing such a model without unacceptably compromising usability, but at least ensuring that only the intended applications are running is a significant step in the right direction. By avoiding that level of explicit check on changing code you're going to run, Chrome is stepping in the opposite and exactly wrong direction.
With regards to your OS-level access control, I think we have examples of how to do it without usability problems. For example, in smartphones, when apps get installed they define what permissions they need. If we assume the publisher of an app is not malicous, then their is no need for a typical user to need to know about this, and we can view it as the app saying "these are the things I am going to access, if I try to access anything else, then I have probably been compromised".
The smartphone implementation seems a bit to crude to be very effective in stopping malware, however there is no reason why we should not be able to make a more fine grained system.
For example, in the Linux world, we have apparmor, which does effectively the same, but is much more configurable. Still, this only requires the program to be honest at install time, and to not have write access to the apparmor configuration file; the user does not need to be aware of its existence.
The problem with these systems is that programs need to do things that we do not want malware to be able to do. For example, Chrome has an auto-update feature. If it gets compromised, then the malware can overwrite the executable just as easily (unless the OS enforces code signing). Say that the program wants to be able to create shortcuts on the desktop, and save data to the harddrive. Now, if it gets compromised, the malware can save itself to the harddrive, and create a shortcut on the desktop labeled "Chrome.exe".
They ask for permissions that are very hard to figure out as a user.
When the user is faced with two options:
1. Click Ok and get started with this app that looks cool.
2. Click No, and go back to the previous screen without the app.
The choice becomes pretty obvious.
My wife simply ignores it and clicks ok. I'm sure most users do the same after the first or second app they install and from then on it becomes a reflex response. Install. Ok. Ok.
I mean, their is obviously no other solution. We should just quit complaining about it.
Or go the route of free without ads and hope that the goodwill leads to recognition and donations.
It's not that Firefox is so much better. But Mozilla doesn't have Google's motive or ability to cross-correlate data-streams.
Does not compute. I don't see the logic in this statement.
Instead of requiring all web access just so an app can perform an action on any page (when you decide for it to) - what if a specific user action could grant temporary/permanent access to a domain? E.g. Clicking an icon if the app is in the toolbar, or selecting a certain action from a menu.
Chrome has a way to prompt for temporary permissions - but this brings up an alert box, and that is never ideal, it would be nice if the user interaction could be taken for permission.
edit: apparently its in beta (https://news.ycombinator.com/item?id=5383011)
Soft permissions would be where an app can function without permission, but has feature(s) that require it. For example, if I install a game, I should be able to play it without giving it internet access. However, if they want to have a online high-score system they must require that I give them internet access in order to install the app;
Pseudo permissions would be where the app thinks it has permission to use something, but it is really receiving bogus data. For example, say an app 'requires' access to my phones GPS system (when such access is not critical to the function of the app), it would appear to the app that it has access, but the data it receives would not corralate to the actually data.
I think I recall seeing a project to implement both of these features in Android, but I do not recall what it is called.
At the least, it would let everyone know that their extension's activities are being watched. And laymen knowing that extension authors know that this activity is watched would be reassuring to the laymen.
Could such logging be done by a separate extension?
http://developer.chrome.com/beta/extensions/activeTab.html
> The activeTab permission gives an extension temporary access to the currently active tab when the user invokes the extension - for example by clicking its browser action. Access to the tab lasts until the tab is navigated or closed.
> The main benefit of the activeTab permission is that it displays no warning message during installation.
If you just need to know when a tab is visible for your content scripts to do things, use the Page Visibility API[1].
If you want your Extensions background scripts to notify all content scripts of something, you can rely on `chrome.storage.onChanged` event. The storage API does not warn users about permissions[2]
If anyone's interested in code samples, I could through some snippets in a gist.
[1] http://www.w3.org/TR/2011/WD-page-visibility-20110602/#sec-p... [2] http://developer.chrome.com/extensions/permission_warnings.h...