Develop Reference

Check if user has a third party Chrome extension installed

I am currently trying to detect if a user has a certain Chrome extension installed. The Chrome extension is not my own and I do not have the source code to it. I have tried methods in numerous posts but they all fail. What I've tried and why it failed is detailed below.
This results in 'cannot read property connect of undefined' when executed:
var myPort=chrome.extension.connect('idldbjenlmipmpigmfamdlfifkkeaplc', some_object_to_send_on_connect);
Trying to load a resource of the extension as follows to test if it's there but going to this URL in browser results in 'your file was not found' Chrome error page (note that I found this path by going to C:\Users\\AppData\Local\Google\Chrome\User Data\Default\Extensions\idldbjenlmipmpigmfamdlfifkkeaplc\1.0.0.1_0\ on my Windows local machine):
chrome-extension://idldbjenlmipmpigmfamdlfifkkeaplc/1.0.0.1_0/icon_16.png
Using Chrome management but this results in console error 'cannot read property get of undefined' when executed
chrome.management.get("idldbjenlmipmpigmfamdlfifkkeaplc", function(a){console.log(a);});
And most other answers I've come across seem to involve the extension being written by the same person who is trying to check for it.

Assuming you need it from a website
connect/message method implies that the extension specifically listed your website in the list of origins it expects connection from. This is unlikely unless you wrote this extension yourself, as this cannot be a wildcard domain.
Referring to files within the extension from web context will return 404 simulate a network error unless the extension declared them as web-accessible. This used to work before 2012, but Google closed that as a fingerprinting method - now extensions have to explicitly list resources that can be accessed. The extension you specifically mention doesn't list any files as web-accessible, so this route is closed as well.
chrome.management is an extension API; websites cannot use it at all.
Lastly, if an extension has a content script that somehow modifies the DOM of your webpage, you may detect those changes. But it's not very reliable, as content scripts can change their logic. Again, in your specific case the extension listens to a DOM event, but does not anyhow make clear the event is received - so this route is closed.
Note that, in general, you cannot determine that content script code runs alongside yours, as it runs in an isolated context.
All in all, there is no magic solution to that problem. The extension has to cooperate to be discoverable, and you cannot bypass that.
Assuming you need it from another extension
Origins whitelisted for connect/message method default to all extensions; however, for this to work the target extension needs to listen to onConnectExternal or onMessageExternal event, which is not common.
Web-accessible resources have the same restrictions for access from other extensions, so the situation is not better.
Observing a page for changes with your own content script is possible, but again there may be no observable ones and you cannot rely on those changes being always the same.
Similar to extension-webpage interaction, content scripts from different extensions run in isolated context, so it's not possible to directly "catch"code being run.
chrome.management API from an extension is the only surefire way to detect a 3rd party extension being installed, but note that it requires "management" permission with its scary warnings.

In modern browsers, is there any security limitation for JavaScript bookmarklets?

I read an article about bookmarklets which says that bookmarklets are so powerful they can be dangerous. For example, a malicious bookmarklet can collect your "cookies", "localStorage", the string in the password input box and then send it to a remote server, which is similar to "script injection".
I'm curious about that. Since this article was written in 2007 (8 years ago), is there any limitation for bookmarklets (as well as browser plugins) to improve the security in modern browsers?

Bookmarklets are scripts run by the user. Yes, they can do all of the things you mentioned (limited in the same way that any other code in the page you inject them into is limited), but only when the user triggers them. They are indeed script injection, but script injection by the person in charge of the machine. The user can do at least as much, and really quite a lot more, by opening the browser's developer's tools.
But answering the question you actually asked: No, I don't think any new restrictions have been put on bookmarklets in the last several years.

The Content Security Policy is not intended to affect bookmarklets:
Enforcing a CSP policy should not interfere with the operation of user-supplied scripts such as third-party user-agent add-ons and JavaScript bookmarklets.
but has some unintended consequences:
Bookmarklets. People love them, and CSP breaks them.
Instapaper, for instance, injects a script tag to load instapapering code from Instapaper's origin. I suspect it would end up injecting CSS as well. Though the bookmarklet itself executes as expected, it's actions on the page are subject to the page's policy, so these loads are likely blocked. That's certainly the case on mikewest.org and github.com.
CSP blocks javascript: protocol URIs which load external scripts:
Whenever the user agent would execute script contained in a javascript URI, instead the user agent must not execute the script. (The user agent should execute script contained in "bookmarklets" even when enforcing this restriction.)
Fixing that would make most of my bookmarklets work, but it won't help with bookmarklets associated with services like Pocket and SubToMe. Those bookmarklets load external scripts which will be blocked by GitHub's script-src CSP directive.
script-src can be circumvented by running bookmarklet code through developer tools or userscripts, but that's besides the point
...although you are limited in what URL you can use to inject a script into certain CSP-protected documents, you can insert ANY text DIRECTLY into the document.
A userscript which converts bookmarklets to script tags would be another workaround
References
Content Security Policy Level 2
The Resurrection of Bookmarklets
Chromium Issue 233903: CSP: Bookmarklets should bypass pages' policies
Mozilla Bug #866522- Bookmarklets affected by CSP
Webkit Bug 149000 – Some extensions triggers CSP violation reports
333318 - Remove support for BeforeLoad event - chromium - Monorail

bookmarklet on https page

I'm trying to make a bookmarklet to use on youtube and other video sites in order to easily get information from the video and store it elsewhere.
From today, apparently I can't do that anymore since youtube force itself on a https connection and from what I've read on chrome's console window, the bookmarklet doesn't run on a https page. Is there a workaround?
Here is the edited code:
javascript:(function(){var jsCode=document.createElement('script');jsCode.setAttribute('src','http://[mysite]/b/enter.php?i=userid&r='+Math.random());document.body.appendChild(jsCode);}());

Google Chrome (and possibly other browsers?) blocks HTTP resources from being accessed from an HTTPS document. This is to prevent "mixed content" attacks, in which insecure HTTP scripts could be intercepted by an attacker in transit over the network and altered to perform any kind of malicious activity (e.g., leak cookies or sensitive page information to a third party). Such a violation would undo any protection granted by HTTPS.
Chrome used to provide a prominent warning that an insecure resource was blocked, but now it no longer does so, and all insecure loads silently fail. The only solution available to you at this time is to use HTTPS yourself when you serve the script.

In Firefox, if you want to run a bookmarklet that references http on an https page, the way to get around this is to temporarily disable security.mixed_content.block_active_content. There are two ways to do this.
go to about:config in a new tab, search for security.mixed_content.block_active_content and then toggle the value to false. Run your bookmarklet and then toggle it back to true (since you probably want it turned on most of the time).
use an add-on / extension to toggle the block. A quick search turned up Toggle Mixed Active Content, and a quick test seemed to work well. There may be others.
Have fun and be careful. Here be dragons!

the bookmarklet doesn't run on a https page
Why not?
Try changing to a HTTPS domain yourself. Usually HTTP content is blocked when you're on a HTTPS domain.

I have created a work-around "fix" for this issue using a Greasemonkey userscript. You can now have bookmarklets on all CSP and https:// sites, plus have your bookmarklets in a nice, easily-editable library file instead of being individually squished into a bookmark.

Unsafe JavaScript attempt to access frame in Google Chrome

Our web application (based on HTML5, SVG & JS) runs fine in all the browsers except Google Chrome.
In Google Chrome, the normal javascript events run fine, however, all the javascript events attached to the iFrame are not executed. We get the error in the console:
Unsafe JavaScript attempt to access frame
At the moment, the application is locally hosted and this problem cropped up during inhouse testing.
Googling this brings up lots of posts but none suggests any concrete solution. Any suggestions?

As an additional security measure, Chrome treats every "file" path as its own origin rather than treating the entire "file" scheme as a single origin (which is what other browsers do). This behavior applies only to "file" URLs and you can force Chrome to revert to a single local origin (like other browsers) by passing the --allow-file-access-from-files switch at startup.
You can find more information on the risks associated with local origins described here: http://blog.chromium.org/2008/12/security-in-depth-local-web-pages.html

Please make sure that both the iframe and main page are using the same protocol (i.e. both https or both http, but not mixed) and are on the same domain (i.e. both www.example.com and not example.com and dev.example.com). Also there's the possibility that something tries to use the file:// protocol, which will also cause this message.

Opera: .js file won't load

I have a page that calls a script in the header, like so:
<script type="text/javascript" src="http://www.discoverfire.net/analytics/l/a.js"></script>
(Note you will NOT be able to load this script as it is DNSd locally as a staging domain)
Very Simple.
Firefox, IE, Chrome all have no problem with this basic, square-one feature.
Opera, however, refuses to load the script. Any variables or functions in it are "undefined" and in dragonfly, the script tag is shown in the DOM, but the "Script" tab says "No script files found."
I go to google and find random pages, their external .js files seem to work just fine.
Any idea why Opera hates me? Is there a security/javascript thing I am missing?
A few things that may be relevant, but really should make no difference:
The script is on a different domain than the page.
The script is only available on my local network. The domain is DNS'd locally for staging, from outside the network it points somewhere else. Does Opera have a setting to secretly use an external DNS server?
The script works on every other browser I have.
The problem isn't in the script content. I've reduced it to a single line with an alert and it simply won't work in Opera.
Update:
OK, the problem seems to be how Opera treats the domain.
I have moved the script to several other domains, and it DOES work just fine. I've moved it to several paths on the locally DNS'd domain, and it won't work from anywhere on that domain.
This leads me to believe that the problem is that Opera can't, or won't, load the script from this domain for some reason.
Strangely, there seems to be no problem loading pages and other resources from the domain, the problem lies in .js files only.
The domain is registered, but parked. We DNS'd it locally so we can use it for staging/testing, and that may be messing with Opera somehow with JS security.
I could be wrong though - I really have no idea. If anyone else has one, I'd love to hear it.
Update 2:
Regarding Dragonfly and the error console/developer tools, they don't say anything about the script at all. There are plenty of Undefined Variable errors for variables and functions that should be present from the script, but other than that, no errors. Oddly, the script tag does show up in the DOMM, but if I click on the Scripts tab, it says "No Scripts Found".
Update 3:
There is no blocked content, so we can at least rule out that setting.

You may want to see if its ad blocker is getting in the way. Your URL contains the text "analytics," which may be part of a "block this" pattern. I know some block Google analytics through Opera. An easy test for this may be to try moving your .js to a different path on the host.

Have you checked Opera's error console? Tools > Advanced > Error Console
It should provide information on why it won't load or if there another error of some kind.

Like Jacob suggested, you should check if it isn't blocked. To do this:
Right-click on your page
Select "Block Content..." in the context menu
At the top of the screen, click the "Details..." button
You should see the URL's that are blocked on the current page

You should ask in the Opera Forums. I had some problems with Opera in the past and they answered quickly.

Is the host serving the correct mime type of the JavaScript file. It's not a commonly known fact but the type=text/javascript attribute is actually ignored by browsers as it trusts that the server is specifying the correct type.
Additionally the mime type of text/javascript is actually wrong when it comes to JavaScript, the actual JavaScript mime type is application/ecmascript (if I recall correctly, it may be application/javascript though). If you don't believe me you should have a look here where I had more information and linked off to the Douglas Crockfords videos where he discussed the mime type.

I had something similar recently - opera would just not run a script on an external server... nor if I downloaded it and had it on localhost. It only ran when copy/pasted between script tags into the html page.
It turned out that the script was encoded with UTF-16 and that was somehow confusing the browser. When I converted it to UTF-8, everything ran fine.
So, just in case and if you still have that problem, check out the encoding settings...

I had the exact same issue, tying to load a script from a localhost/development server into a page, hosted on the public server at no avail. The only way I managed the script to load in Opera was to save a copy of the page into a location on the same development server and use the tag to refer to the original domain to get the page's .css and .js linked files. That worked. Looks like Opera doesn't like to mix public and localhost domains, but handles localhost without complaints.

what you're seeing is probably Opera's security precaution against the so-called "phish pharm" attacks: cross-network protection. You can not mix content from a public server and content from a local server.
Have a look at my answer here for a workaround:
Opera won't load some JavaScript files