Matt, do you now whether access to chrome-extensions:// URLs is necessary for content scripts?

Interestingly the enumerator script doesn't list all extensions, only some of them, Arch Linux x64, Chrome 19.0.1068.1 dev

BUT this is necessary while NOT in incongito mode..agree?

if Chrome wont tell them, they can just ask Google?

I believe the addon enumerator just checks against a list of common extension identifiers. There's not actually a way to list all installed extensions, just a way to check if an extension is present or not. It's similar in concept to the :visited CSS hack to check if a given URL is in someone's history. http://hacks.mozilla.org/2010/03/privacy-related-changes-coming-to-css-vistited/

Yes, correct.  It just checks against common extension identifiers.  I probably did not word the original bug description well enough to make that clear.  I think this is a bit worse than the :visited CSS hack though since the space of possible IDs is so much smaller.  I could probably crawl the Google web store and get a list of all possible extension identifiers and put them in a JS file that's less than 1MB in size, so in effect this can reveal every single extension you have installed even if the proof of concept does not.

Note: This is fixed in manifest_version 2:

"A package's resources are no longer available by default to external websites (as the src of an image, or a script tag). If you want a website to be able to load a resource contained in your package, you'll need to explicitly whitelist it via the web_accessible_resources manifest attribute."

https://code.google.com/chrome/extensions/dev/manifestVersion.html

Cool, that's good to know.  I'll be sure to update my extensions.  Thanks Adam.

The incognito portion of this is indeed a bug (probably a regression). I've split off  bug 118721  for that. Thank you very much for reporting it.

As for the other part, as of Chrome 19, extension developers can opt into hiding their resources using the web_accessible_resource manifest attribute even without switching to manifest_version=2:

https://code.google.com/chrome/extensions/dev/manifest.html#web_accessible_resources

manifest_version=2 simply switches the default. Instead of web_accessible_resources defaulting to off, it defaults to on.

benjamin, you should not update your extension to manifest_version=2 until Chrome 18 is deployed to the stable channel. manifest_version 2 is not backward compatible, so your extension will not run on earlier Chrome versions.

You can use the web_accessible_resources feature. In newer Chromes, it will do the right thing. Older Chromes will ignore it.

Yep, got that part.  Thanks again for the quick response.

I have merged  bug 120804  to reduce the number of reports on this issue. It contains an interesting proposal, please read it.

(No comment was entered for this change.)

According to the manifest version 1 support schedule, Chrome will no longer load manifest version 1 extensions in January 2014.

Because this bug is specific to manifest version 1, it should be closed out as WontFix by that time.

Source: http://developer.chrome.com/extensions/manifestVersion.html 

Regardless of when we remove support for manifest v1, we're not going to take further action on this bug. Closing.

Bulk security flag update.