Lack of interest. Please add ideas to help make it popular.

Hi all. It is obvious that Comodo Dragon is not developing hugh amounts of interest just going by the comments on the forum or lack of. I would like to see ideas and suggestions on ways to add excitement and interest to CD. Let us all help improve it and make it a popular leading browser.
What is missing, what does it need, how can we lift this browser, what is holding it back ??
Help! Comodo Dragon, Come on guys/girls Comodo is worth supporting and CD is part of Comodo.
Please help. Maybe a unique GUI upgrade or something. Comodo made this browser for us so lets tell them what we want. Thanks and kind regards.

Offer downloads to be screened by Valkyrie first before hitting the users disk?

Secure DNS verdict indicator green/red regardless of Secure DNS usage?

I know looks aren’t everything but I feel CD needs it’s own style to stand out. Also, extensions (security, privacy, etc) developed by Comodo.

Personally, I feel CD is always playing catchup with Chromium builds so no new features are being added. That said, CD releases seem to be arriving quicker now.


:-TU :-TU :-TU

I do not want to double post, so I will post a link to my comment(s) on another thread :wink: :;msg504705#msg504705

Thanks all for your responses. I am in total agreeance with maybe its own style and make it look like Comodos own and not a copy of another.
To John Jr. Thanks for answers, comments and suggestions, you have some good ideas there.
Apologies for this topics similarities to the the one John Jr mentioned above.
Kind regards.

You are welcome and thank you Captain. :smiley:

If you really want to generate interest and get people to use it, it should keep up with development first and foremost. I am mostly talking about the general public here, not so much Comodo Forum members. (Although I also prefer ver. 10 to ver. 9. There is a big difference.) If the general public gets a choice between Chrome 10 or Dragon 9, which will they choose? Personally, I think it should start there and then it can be tweaked etc.

This is why I think CD should use it’s own numbering scheme as CD will always be compared to Chrome. Chromium builds seem to appear every other week so CD should develop at it’s own pace rather that having to catch up with Chrome/Chromium.


Yep to differ they need to lose the “copy of chrome” image it currently has.

Also have a special promotional site/page whatever about why it’s better/more secure then X,Y,Z
And preferably a web page where you can “test” these features.

Create a bunch of plugins that a user can select on first use to increase overall security and privacy.

  • cookie control
  • http referer filtering/spoofing/control
  • javascript control
  • adblocker
  • etc

Releasing those as a plugin makes it easier to update the browser code without having to re-write the plugins every time in the code so it’s easier to keep track with chromium code.

Very good and valid point. :-TU

Hi Graham, this is a good idea along with its style. Make Comodo Dragon its own, and not a partial clone. Then maybe CD will get compared to other browsers for what it really is, and not compared to other browsers versions. Thanks everyone for your input.

This hits the nail right on the head! When I am in other forums, and look through sections asking about browsers, everyone always insist that the browser they are using is more secure, most of the time it is due to plugins,ect. Comodo Dragon is on right track, but could be improved. These suggestions for plugin’s would make it incredibly secure. It is what the masses are looking for, that and speed and usability…

As far as the GUI, as one member stated “looks are not everything”, but do have a tendency to appeal! :wink:
CD needs to have a style of it’s own, to stand out! ;D

It needs to be its own browser, that is for sure. It feels like Chrome with some extensions right now.

under the hood/basics/etc.
Chrome stuff

go away chrome stuff. :wink:

integration with other comodo products, antivirus etc.
check links/web pages by right clicking and hitting “scan with Comodo AV” before visiting them. ETC.

Dragon is one of the browsers these days that really has the potential to go far. May not be able to advertise your way to 20% market share like Chrome. But a small cult following. :wink:

Just 2 thing is needed

1)People need to know that there’s is adblock plus is available to download for dragon. Offer it on the first start up (It can be gotten from below) Give them a link to click on it

and of course the features from “Noscript” There is no features like this in dragon,

Right now,
“Noscript” is the only reason why I still have firefox(actually it’s palemoon). There is no other reason. If you add noscript features, I’m sure they’ll come :slight_smile:

A nice quote from the site (below)

Usable security

Operating NoScript is really simple.

When you install NoScript, JavaScript, Java, Flash Silverlight and possibly other executable contents are blocked by default. You will be able to allow JavaScript/Java/… execution (scripts from now on) selectively, on the sites you trust. You can allow a site to run scripts temporarily, if you’re just surfing randomly, or permanently, when you visit it often and you really trust it. This means that NoScript learns from your own browser habits and tends to disappear in the background after a while, but it promptly comes back to save your day if you stumble upon a malicious web page.

When you browse a site containing blocked scripts a notification, similar to those issued by popup blocker, is shown.
Look at it or at the statusbar icon to know current NoScript permissions:

* Forbidden Icon - this means that scripts and plugin contents are blocked for the current site and its subframes. Even if some of the 3rd party script sources imported by the page may be in your whitelist, no code could run because the hosting documents are not enabled.
* Partially Allowed Subcontent Icon - this means the top level site is still forbidden but some active subcontent pieces (either frames or plugin objects) are allowed: some code may be running, but the page is likely not to work correctly yet because its main script source is still blocked.
* Partially Allowed Icon - this means scripts are allowed for the top-level (main) document, but some other active content or script sources imported by this page are not allowed yet. This happens when there are multiple frames, or script elements linking code hosted on 3rd party hosts.
  Since they're often unnecessary, the site is likely to work even in this "partially allowed" state. Furthermore, in most cases when a site is compromised with JavaScript malware, the malicious code is hosted on external "shady" sites. Even if you've previously allowed the top-level site, these external sites are still blocked and the attack fails anyway.
* Allowed with Blocked Embedded Content Icon - this means that all the script sources for the page are allowed but some embedded content (frames or plugin objects) is blocked. You can check and allow the blocked content either by looking for yellow visual placeholders in the page or by examining the Allowed with Blocked Embedded Content Icon Blocked Objects sub-menu.
* Partially Allowed / Partially Untrusted Icon - this means that scripts are allowed for some URLs, and all the other ones are marked as untrusted.
* Allowed Icon - this means that script execution is allowed for the current site
* Globally Allowed Icon - this means that scripts are globally allowed (why did you decide to browse with low protection??!)

NoScript: one click to enable/disable JavaScript globally or PER SITE The number of detected tags for current page is shown in a tooltip when you fly over the icon with your mouse. If the “S” inside the icon is white rather than blue (Forbidden Icon - no active script Partially Allowed Icon - no active script Partially Allowed / Partially Untrusted Icon - no active script Allowed Icon - no active script Globally Allowed Icon - no active script), 0 script tags have been detected: this likely means you don’t need to enable JavaScript in that page at all.

If you left click on the icon, you can change script permissions using a simple menu.
You can reach the same menu by right clicking over the document, so you can operate also in windows which don’t provide a status-bar. Of course, if you don’t like contextual menus, you can hide it.
Most menu items are in the form “Allow”, “Temporarily allow”, “Forbid”. The “Temporarily” permissions are in effect until you exit the browser.
Special commands:

* Allow Scripts Globally (dangerous) switches NoScript in the (not recommended) "Default Allow" mode. Only sites and objects explicitly marked as untrusted will be disabled. Other important security features, like Anti-XSS protection, HTTPS enforcement, Clickjacking protection and ABE will still be effective, though.
* Allow all this page and Temporarily allow all this page enable every site shown as allowable by NoScript's menu on the current page, unless already marked as untrusted.
* Make page permissions permanent permanently enables every site shown as temporarily allowed by NoScript's menu on the current page.
* Revoke temporary permissions cancels all the "Temporary allow" commands issued during this session.

A set of toolbar buttons is also provided:

* Main NoScript toolbar button
  By clicking it you will toggle the forbidden/allowed state of the top-most site in the current page, i.e. the one displayed in your address bar. Also, if you click the tiny arrow near the main NoScript toolbar button, the usual NoScript menu will be dropped down.
* Temporarily allow all this page toolbar button
* Revoke temporary permissions toolbar button

To install these buttons, just right click on any Firefox toolbar and select the Customize menu item, the drag the one(s) you want from the buttons palette onto your choosen toolbar.

If you’re not a mouse lover, you will find these two keyboard shortcuts helpful:

  1. CTRL + SHIFT + \ (backslash) toggles allowance status for the current top-level site - temporarily by default, to make it permanent set the about:config noscript.toggle.temp preference to false.
  2. CTRL + SHIFT + S opens the NoScript status bar menu, which lets you perform every NoScript related operation using the cursor keys.

Both these shortcuts can be changed using the about:config noscript.key.* preferences.

Every NoScript menu includes a command to open the Options dialog: you use it to allow or forbid many sites at once, to customize user interface and to decide if you want to automatically reload current site when you change permissions. Other useful options are also available there.
Site matching

For each site you can decide to allow the exact address, or the exact domain, or a parent domain. If you enable a domain (e.g., you’re implicitly enabling all its subdomains (e.g., and so on) with every possible protocol (e.g. http and https). If you enable an address (protocol://host, e.g., you’re enabling its subdirectories (e.g. Firefox - Protect your life online with privacy-first products — Mozilla and, but not its domain ancestors nor its siblings, i.e. and will not be automatically enabled.
By default only the 2nd level (base) domain is shown (e.g. is shown in the menus, but you can configure appearance to show full domains and full addresses as well.

NoScript recognizes two kinds of “shorthand” patterns, to be manually entered in the NoScript Options|Whitelist panel:

  1. Jolly port matching - an address with a 0 (zero) port specification will match every site with the same protocol, domain and any non-standard port: if one is met during navigation, it gets temporarily enabled. For instance, matches and, but not (different protocol) nor (standard 80 port, omitted). Since protocol specification is mandatory, regular subdomain matching with rightmost components comparison couldn’t work for multiple subdomain. You can specify subdomain matching patterns using an asterisk in place of the leftmost domain component: for instance, you need to match all the subdomains of for all ports with the HTTPS protocol, you can whitelist https://* This is the ONLY situation where asterisk is considered a wildcard.
  2. Subnet matching - an address with a partial numeric IPv4 IP will match all the subnet. You must specify at least the 2 leftmost bytes, e.g. 192.168 or 10.0.0. Again, matching sites will be temporarily allowed on demand.

Important notice: the asterisk character (*) have NO special meaning to NoScript, other than subdomain matching in Jolly port matching patterns (see above). Asterisk is NOT a general wildcard, so if you’re typing it while manually adding a site to your whitelist, double check you know what you’re doing. By the way, most of the time you prefer not to fiddle with your whitelist manually: just use the NoScript “Allow” and “Forbid” menu items, it’s much simpler and error free!
Beyond JavaScript: blocking Java, Silverlight, Flash and other embedded content

While its primary aim is preventing malicious JavaScript from running, NoScript effectively blocks Java™, Silverlight™, Flash®, and other plugins and embeddings (such HTML video/audio elements and downloadable fonts) on sites you didn’t explicitly whitelisted. Java Applets, Flash movies/applications, Quicktime clips, PDF documents and other content won’t be even downloaded from sites where you consider them annoyances or dangers, saving your bandwidth and increasing your navigation speed. While in early NoScript versions only JavaScript and Java were blocked by default, this restriction has been extended to Flash and the other embeddable content, in order to prevent Flash-based XSS and other plugin-based attacks. Anyway you can configure the kinds of content you want to forbid using the NoScript Options|Embeddings panel. The status bar tooltip and the message bar display the total count of detected embeddings () next to the count. Keep in mind that some sites use Java applets, Silverlight embedded objects or Flash movies to deliver rich content and applications, hence if you meet some web page you need to use but you find some functionality is missing, consider the possibility that you’re blocking some essential applet or movie.

On a non-whitelisted site you can still temporarily allow an individual embedded object with just one left click on its placeholder (screenshot). The movie/applet/clip will stay enabled until the end of the session or until you Revoke Temporary Permissions.
Middle clicking on an object placeholder opens it in a window of its own.
Right clicking on an object placeholder opens the context menu for links, allowing you to save the content with Save Link As…
Holding down the Shift key and clicking on an object placeholder temporarily hides it.

You can also use the Blocked Objects menu to find out which content instances you’re blocking even if their placeholder is not easily visible, and/or enable them individually, per site or per type.

It’s worth noticing that while early NoScript versions used to block plugin content objects checking exclusively their origin, i.e. the site where they were downloaded from, most recent NoScript versions check also the parent site which is embedding the content: a non-whitelisted site won’t be able to run a plugin content piece, even if coming from a trusted site, unless you explictly unblock it through its placeholder or the Blocked Objects menu.
This behavior is meant to provide effective protection against Flash-based XSS. Reverting to the old behavior is possible, even if not recommended: just switch the noscript.forbidActiveContentParentTrustCheck about:config preference to false.

The same blocking treatment can be reserved to IFRAMEs as well, especially to defeat clickjacking. Please read this FAQ for more details.

Finally, toggling NoScript Options/Embeddings/Apply these restrictions to whitelisted sites too extends the embedded content restrictions set for untrusted sites also to “trusted” pages which are in your whitelist, turning NoScript in a general content blocker for Java, Silverlight, Flash and other embeddings, functionally similar to FlashBlock.

You can configure some exception to the Forbid Other Plugins option by setting the noscript.allowedMimeRegExp about:config preference to a pattern matching the content types you want to allow. For instance, setting it to “application/pdf” will let PDF document load automatically on every site. That said, are you sure you need to? Adobe Acrobat Reader plugin got its share of vulnerabilites so far, and after all, you can still allow individual PDF documents from untrusted sites just clicking on their placeholders.
Untrusted blacklist

Some sites, especially those serving ads, can appear in your “Allow …” menu more often than you like, making it too much long and noisy.

If you know you don’t want to allow a certain site now and in the foreseeable future, you can permanently mark it as untrusted: just click the NoScript icon, open the Untrusted menu and select the Mark as Untrusted menu item.

NoScript won’t even propose you to allow it again and your NoScript will be even more clean and usable.

If you later change your mind, don’t worry: just open the Untrusted menu again (on the same page), and you’ll find the Allow command there.

This feature is especially useful if you decided to use the (not recommended) Temporarily allow top level sites by default or Allow Scripts Globally modes, because sites marked as untrusted won’t be allowed anyway.

Advanced users: even though the untrusted sites blacklist has no listing UI of its own, you can mass-edit it either modifying the noscript.untrusted about:config preference or using the Import/Export functionality of the NoScript Options|Whitelist panel, knowing that the untrusted entries are exported under an [UNTRUSTED] header.
Anti-XSS protection

Cross-Site Scripting (XSS) vulnerabilities are usually programming errors made by web developers, which allow an attacker to inject his own malicious code from a certain site into a different site. They can be used, for instance, to steal your authentication credentials and, more in general, to impersonate you on the victim site (e.g. your online banking or your web mail).

This kind of vulnerability, often overlooked, is very widespread and becoming highly popular among hackers: someone even bothered to write a JavaScript-based bot, called Jikto, turning your browser into a zombie which relentlessly sends automated XSS attacks all around. Of course this tool has been built “for research purpose”, but its code unfortunately appears to be leaked in the wild, so anybody can take advantage of it, now…

NoScript XSS notification and its menu NoScript features unique Anti-XSS counter-measures against XSS Type 0 (DOM based) and XSS Type 1 (Reflective, absolutely the most common) attacks targeted to whitelisted sites.

Whenever a certain site tries to inject JavaScript code inside a different trusted (whitelisted and JavaScript enabled) site, NoScript filters the malicious request neutralizing its dangerous load.

Then a yellow notification bar displays a message like
“NoScript filtered a potential cross-site scripting (XSS) attempt from []. Technical details have been logged to the Console.”
On the left side of this bar there’s also an “Options…” button: if you click it, you can choose among the following actions:

* Show Console, displaying the Error Console where further technical details about the actions taken by NoScript are logged.
  Please notice that the Error Console is a standard Firefox component reporting every JavaScript-related message from any source: the explanatory messages specifically coming from NoScript and related to XSS are only the ones marked with a [NoScript XSS] label.
* Unsafe Reload, which will "replay" the request bypassing XSS filters. Use this command only if you're absolutely sure that NoScript detected a false positive.
* Suppress the XSS-related notifications (you will still be able to operate through the standard NoScript menu).
* Open the XSS Options panel.
* Navigate to the XSS FAQ web page.

The specific Anti-XSS counter-measures are controlled by the NoScript Options|Advanced|XSS options.
Both these options are enabled by default for your maximum protection.

By default, Anti-XSS protection automatically filters the requests from untrusted origins to trusted destinations, considering trusted either "Allow"ed or "Temporary allow"ed sites. If you prefer "Temporarily allow"ed sites to be still considered as untrusted origins from the XSS point of view, you just need to set about:config noscript.xss.trustTemp preference to false.

Furthermore, NoScript’s sophisticated InjectionChecker engine checks also all the requests started from whitelisted origins for suspicious patterns landing on different trusted sites: if a potential XSS attack is detected, even if coming from a trusted source, Anti-XSS filters are promptly triggered.

This feature can be tweaked by changing the value of the noscript.injectionCheck about:config preference as follows:

0 - never check
1 - check cross-site requests from temporary allowed sites
2 - check every cross-site request (default)
3 - check every request

NoScript’s Anti-XSS filters have been deeply tested and proved their ability to defeat every known reflective XSS technique, but their power is a double-edged sword: sometime they may detect a weird looking but legitimate request as a “potential XSS attempt”. This should almost never be a show stopper, since the filter most of the time doesn’t prevent you from navigating the filtered page, but the aforementioned Unsafe reload command and the XSS Advanced Options have been made easily accessible so you can work-around if you hit a false positive with side effects. Just please notify me when it happens, possibly reporting the messages NoScript logged (the lines starting with “[NoScript XSS]” in the Error Console), so I can keep tweaking NoScript’s “XSS sensibility” as needed.

NoScript also protects against most XSS Type 2 (Persistent) attacks: in facts, the exploited vulnerabilities usually impose space constraints, therefore the attacker is often forced to rely on the inclusion of external scripts or IFrames from origins which are already blocked by default.

While Cross-Site Scripting (XSS) vulnerabilities need to be fixed by the web developers, users can finally do something to protect themselves: NoScript is the only effective defense available to “web-consumers”, waiting for “web-providers” to clean up their mess.

See also the NoScript XSS FAQ, or read the excellent Cross Site Scripting Attacks: Xss Exploits and Defense book.

Most NoScript options are quite simple and self explanatory.

Default values are almost always OK, however you may find useful knowing about these:

      o Temporarily allow top-level sites by default, not recommended and disabled by default, grants permissions "on the fly" to the address of the main page (the one usually displayed in the location bar), excluding subframes, embedded objects and sites marked as untrusted.
      o Allow sites opened through bookmarks, grants permissions "on the fly" to sites you open clicking on a bookmark of yours.
      o Left clicking on NoScript toolbar button toggles permissions for current top level site, action reachable also using the CTRL+SHIFT+S keyboard shortcut.
  An interface to manually manage the list of your trusted sites, adding or removing web addresses. This panel contains also "Import" and an "Export" buttons to backup/restore your whitelist as a plain text file.
  A list of content blocking and anti-clickjacking options.
  Contains preferences to hide/show UI elements.
  Contains preferences to enable/disable various notifications (message bars and sound alerts).
        Contains additional restrictions and policies for untrusted (unknown) sites:
            + Attempt to fix JavaScript links ( enabled by default): this means that NoScript will try to turn javascript: links into normal ones on untrusted sites as you click them, improving usability of the most unfriendly pages.
            + Hide <noscript> elements prevents the replacement content from being displayed on JavaScript disabled sites.
            + Forbid "Web Bugs" blocks Web Bugs (tracking images) found inside <noscript> tags, used as a (less effective) fall-back to spy on user's behavior when scripts are not available.
            + Forbid META redirections inside <noscript> elements, which are often used to send the unwilling user to a dumb "Please enable JavaScript" page. Notice that this option may interfere with the RefreshBlocker extension.
            + Forbid bookmarklets, disabled by default, prevents JavaScript bookmarks (also known as bookmarklets) from working on untrusted sites.
            + Forbid <a ping...> (enabled by default), controls the controversial "ping" feature on untrusted sites.
        Contains additional permissions and bonuses for trusted sites:
            + Show the <noscript> element which follows a blocked <script> forces the nearest replacement content to be shown for blocked 3rd party script tags even if the main page has JavaScript enabled.
            + Allow <a ping...> (disabled by default), controls the controversial "ping" feature on trusted sites.
            + Allow rich text copy and paste from external clipboard is an additional permission you can grant to trusted sites, e.g. on Web Mail or CMS user interfaces where you may want to copy inside an editor box styled text content from outside the browser.
            + Allow local links (disabled by default) allows linking local resources from web pages, as required by some gaming on line sites.
        Preferences for the Anti-XSS protection system:
            + Sanitize cross-site suspicious requests* - potentially dangerous characters, why may be used to inject malicious JavaScript code, are stripped out from both the URL and the REFERER header.
            + Turn cross-site POST requests into data-less GET requests - the request is sent but no malicious data is uploaded.
            + Anti-XSS Protection Exceptions, a list of regular expressions (one on each line) used to identify web addresses which you deem do not need to be protected against XSS.
        * "Cross-site suspicious requests" are requests from untrusted origins to trusted destinations, considering trusted either "Allow"ed or "Temporary allow"ed sites, unless the cross-site request is found to contain HTML or JavaScript injections. If you prefer "Temporarily allow"ed sites to be still considered as untrusted origins from the XSS point of view, even for requests which does not seem to contain injections, you just need to set about:config noscript.xss.trustTemp preference to false.
        Notice: NoScript 2.0.9 and above removed this feature because the same protection is now available by means of other more transparent countermeasures, both from Firefox >= 3.0 and from NoScript itself
        Preferences for JAR document blocking:
            + Block JAR remote resources being loaded as documents - jar: URLs which are loading from remote in a context which will lead to document building are blocked. This prevents XSS attacks like the one described in this article.
            + JAR document blocking Exceptions, a list of regular expressions (one on each line) matching JAR urls which you want to bypass blocking.
        Preferences for enhancing HTTPS behavior and cookies:
            + Forbid active web content unless it comes from a secure (HTTPS) connection:
                 1. Never - every site matching your whitelist gets allowed to run active content.
                 2. When using a proxy (recommended with Tor) - only whitelisted sites which are being served through HTTPS are allowed when coming through a proxy. This way, even if an evil node in your proxy chain manages to spoof a site in your whitelist, it won't be allowed to run active content anyway.
                 3. Always - no page loaded by a plain HTTP or FTP connection is allowed.
            + Force the following sites to use secure (HTTPS) connections - a space-separated list of site patterns
            + Never force secure (HTTPS) connections for the following sites - a space-separated list of site patterns (taking precedence over the above)
            + Enable Secure Cookie Management - countermeasures against HTTPS cookie hijacking, see this FAQ for more details.
        Preferences to control the Application Boundaries Enforcer (ABE) module. Check also this FAQ.

Some about:config preference you may want to know are:

* noscript.jsredirectIgnore - defaults to false, if true disables searching and displaying JavaScript links in non-whitelisted pages which do not contain any regular link, like
* noscript.jsredirectFollow - when true (default) and only one single JavaScript link is found in a top-level page, that link is automatically followed becaus we assume it's a JavaScript redirection (e.g.
* noscript.autoReload.allTabs - switch it to false if you want only the current page to be reloaded when permissions change (it will prevent a slowdown when you've got many tabs open on the same site).
* - decides if allowing scripts globally causes an autoreload or not.</blockquote>

Just turn off Javascript… :wink:

But seriously, the problem with NoScript is that Javascript isn’t as evil as the developer would like you to think it is. There are a lot of websites out there that use Javascript for navigation. NoScript breaks these pages by default.

The majority of malicious Javascript aren’t navigation type scripts, but externally hosted scripts. Unless you regularly visit dubious websites, you aren’t going to encounter any malicious Javascript contained in the locally hosted navigation type scripts.

A better approach to NoScript is to use a simple filter in AdBlock Plus.


This filter ensures that only locally hosted scripts are allowed to run, yet the site navigation is unaffected. This includes all scripts, not just Javascript, so external Flash content is also blocked.

If you encounter a site such as YouTube that uses content distribution servers, it’s easy enough to add an excluded domain to the filter.


Multiple domains can be added with a pipe.


I agree about NoScript not being particularly desirable in CD. I started using Sandboxie with Firefox so I didn’t have to restrict JavaScript functions. I now mostly use Google Chrome. I’m still deciding if Sandboxie is needed in view of sandboxing already being in place within Chrome and CD (a different kind of sandboxing I know).

I also agree about the update numbers and the frequency they appear at. I think a lot of people gauge other available versions of Chromium against the version number of Google Chrome. If an alternative doesn’t equal or go beyond Google Chrome’s number, there can be a feeling that it might not be up to date. This could result in some potential CD users staying with Google.

I stated elsewhere why I’m staying with Google Chrome at present. It’s the WOT problem. I like my search results individually rated. If CD can overcome that, or offer something similar, I’ll try again.

I run Dragon inside Sandboxie. It wasn’t very long ago that an exploit used Flash Player to jump out of Chrome’s sandbox. If I’m running Dragon in Sandboxie, malware will need to jump out of Chrome’s access restrictions, then out of Sandboxie’s virtualization in order to attempt anything on my system. :wink:

Do you think that could have occurred within Google Chrome where Flash Player is integrated into the browser and therefore sandboxed by it too?

It did occur in Google Chrome…

And as far as I’m aware, the sandbox applies to all plugins in Chrome.