I have one question - why WOT (Web of trust extension) not working with COMODO Dragon? I think this is really helpfull extension, give the browser better security. I use it in firefox, but cant do that on COMODO. Why? The WOT icon only showing loading and nothing else.
See Lastpass and WOT - problem in CD SSL certificate validation facilities?
No solution yet, and cannot be overridden. 
Lastpass should be corrected in the next update, whereas WoT has a true DV cert. DV certs have their place on mail servers, but not in a true trusted environment. They should have an OV cert or an EV cert considering the business they are in.
Apparently people are willing to pay GlobalSign’s ridiculous DV cert price. $249 for a DV! Whereas Comodo’s baseline OV is $199!
WOT is still not working with 4.1.1.7 beta.
It won’t work until WOT uses a non DV cert. 
Good point, but wouldn’t it be nice if there was a way to exclude websites from this warning? :-TU
Maybe an “always allow me to proceed option”? I like the browser, but I also like WOT. I’s like to be able to use it again. :-\
I agree. Was surfing twitter yesterday and had to say ‘proceed’ more than 10 times!
Best wishes
Mouse
Perhaps DV certs still have a place for plugins and extensions whereas they are generically supposed to prevent eavesdropping, MiM and what else (whenever these aspect might not be relevant in some scenarios)
Hopefully notification of plugins using DV certs or even about plugins attempting communications to 3rd parties (perhaps providing reputation feedback about the domain) can be possibly added to CD along with options to disable such features for all plugin or selectively for some of them.
Whereas the user is offered the possibility to proceed on sites using DV-certs IMHO it would appear incongruous to deny them such chance/choice for plugins that rely on DV connections whenever an http connection would have posed no issue.
Then tell them to get an EV or OV cert! They won’t see a problem until their users complain.
DV certs need to die a quick and painful death. Their cons out weigh their pros. A lot of scammers/malware providers use them and this is a serious ■■■■ to keeping them around.
Whereas the user is offered the possibility to proceed on sites using DV-certs IMHO it would appear incongruous to deny them such chance/choice for plugins that rely on DV connections whenever an http connection would have posed no issue.
If HTTP would have posed no issue, then why the trouble of using SSL/TLS?
Meanwhile people have to use Dragon!
Ever tried surfing twitter with Dragon :). Asks whether you want to proceed every page when signed in!
Best wishes
Mouse
Twitter is for twits. I personally don’t use Twitter and have no desire to.
A lot of Scammers/malware use also http connection alone but this is apparently no reason for banning the use of http.
If the above quoted consideration would apply to all DV then related choice should be consistently denied in all cases even if this break current standards.
Legitimate sites use DV as well and this is apparently the reason they are not completely denied even in part of CD implementation.
For example mail servers whose maintainers are often disclosed personal informations by subscribers.
Were such informations (necessary to subscribe an account) submitted on a webiste using EV certs?
Should mail clients mandate an approach that block connection to mailservers using DV SSL?
A mail client cannot verify the basis on which the user trust a mailserver nor even if the user configure the mail client manually.
Does the transparent use use of https for plugins make a connection more questionable than an http one without any need to take the destination into account?
If a plugin connection to an un-vetted destination does pose an issue why such issue is limited only to plugins using DV-https?
But they do shut them down at the ISP level. 
Legitimate sites use DV as well and this is apparently the reason they are not completely denied even in part of CD implementation.
While they may be legit, I still see them as being cheap and shady. Pay the extra money. It looks better!
For example mail servers whose maintainers are often disclosed personal informations by subscribers.Were such informations (necessary to subscribe an account) submitted on a webiste using EV certs?
For mail servers, I was speaking truly from a corporate standpoint. Not a public one. If you can’t trust your mail admins, who can you trust?
Should mail clients mandate an approach that block connection to mailservers using DV SSL?
It would be wise, not many use this approach. They usually pay for it. Especially in Exchange environments.
A mail client cannot verify the basis on which the user trust a mailserver nor even if the user configure the mail client manually.
It most certainly can if it is programmed to do so. A mail client has to trust the root in order to make the secure connection, if root isn’t there, connection is not made. Unless the Client has over-ride controls. (Explicit Trust like FileZilla)
[url=https://forums.comodo.com/bug-reports-cd/why-wot-not-working-t56075.0.html;msg396705#msg396705]Does the transparent use use of https for plugins make a connection more questionable than an http one without any need to take the destination into account?[/url] If a plugin connection to an un-vetted destination does pose an issue why such issue is limited only to plugins using DV-https?
It should bring your attention to the situation. Before Dragon, only trained people knew what a DV cert was and why it is bad for business. Anyone can get a DV cert! (THIS IS THE PROBLEM!)
The DV issue isn’t singling out Plugins, it is treating ALL DV certs wherever they may be the same. However, it isn’t “remembering” that you “acknowledged” the warning.
Do you correspond with your bank at a random site or do you make sure you’re connecting to your bank site by viewing their SSL certificate (You should be doing this, not blindly trusting the site)?
Do you connect to Paypal at a random site or do you make sure it is really PayPal?
They don’t shut them down at ISP level based on purely unrelated considerations about http and DV-https though
Indeed if all sites have to look better let’s have them pay the extra money and get rid of (un-vetted) http as well!
Of course I take anybody wouldn’t simply trust the mail client to take such decision for them.
This does verify only one way an user could trust(or not) a mailserver bu means of (mail)client functions
If a mailserver use a DV-SSL and connection will be wisely rejected in all cases this won’t take in account even the users that trusted an organization because their web-server had an EV-SSL (where they also disclosed other personal information to open an account and got instruction to configure the mail client) nor those who relied on other criteria
Part of CD implementation bring DV_SSL to user attention by providing them a way to recognize them and relate this with pertinent information/advice so users can take in account whereas making their choice.
Bringing to the attention can be made also in constructive ways. I take that making easier for users to distinguish DV-SSL from the rest would not require them to be trained. Whereas bringing an issue to their attention would not legitimate anybody from denying their choice in the matter.
“Remembering” and “Acknowledging” are part of bringing something to your attention. Something not achieved by implicitly trusting a tool to silently make such choices for you (without “Remembering” , “Acknowledging” and “Choice”)
Does any un-vetted website raise the same considerations you would have everybody pay attention when there are money transactions involved? ???
And how this relate to the current standing of chromium based browsers whereas they seemingly allow plugin to silently connect to un-vetted sites by http BUT without warning the users?
Would silently blocking plugins’ DV-https connections (but allowing them to silently make http ones) make this any better?
We’re not shutting them down though. We’re just bringing attention to the fact that they’re using a DV certificate. (Implementation may be rough and somewhat buggy, but it does work.) Dragon is a work in progress. It is has ongoing changes. It is still a diamond in the rough, be patient now.
ISPs shut them down because they break the law or their Terms of Service.
Indeed _if_ [i]all sites[/i] _have_ to look better let's have them pay the extra money and get rid of (un-vetted) http as well!
You’re totally taking my words out of context and making random ASSumptions. Please don’t do that.
Of course I take anybody wouldn't simply trust the mail client to take such decision for them.
You would be surprised how many people are so blind. How do you think people get phished? If they paid attention they wouldn’t get phished.
If a mailserver use a DV-SSL and connection will be wisely rejected [u]in all cases[/u] this won't take in account _even_ the users that trusted an organization because their web-server had an EV-SSL (where they also disclosed other personal information to open an account and got instruction to configure the mail client) nor those who relied on other criteria _Part_ of CD implementation bring DV_SSL to user attention by providing them a way to recognize them and relate this with pertinent information/advice so users can take in account whereas making [b]their[/b] choice.
Come again? I don’t understand your circular logic.
Bringing to the attention can be made also in constructive ways. I take that making easier for users to distinguish DV-SSL from the rest would not require them to be trained. Whereas bringing an issue to their attention would not legitimate anybody from denying their choice in the matter. "Remembering" and "Acknowledging" are part of bringing something to your attention. Something not achieved by implicitly trusting a tool to silently make such choices for you (without "Remembering" , "Acknowledging" and "Choice") Does [i]any[/i] [u]un-vetted[/u] website raise the same considerations you would have everybody pay attention when there are [i]money transactions[/i] involved? ???
Yes, secure logins to sites that require login. Such as Gmail, Hotmail, Facebook, Twitter, etc.
[b]Would silently blocking plugins' DV-https connections (but allowing them to silently make http ones) make this any better?[/b]
Well it is only silent, because you don’t see the warning. How can you see the warning if the connections are transparent? Where should Dragon display the warning? In the extensions page? as a drop down notification like it asking to save your password?
What part of silently crippling all plugins that rely on DV-SSL bring something to anybody attention?
I would say the same for your considerations, Sir. The context was speciously narrowed to DV-SSL whereas should not so easily neglect other websites not using OV and EV SSL.
But as long begging the question is a legitimate way to clarify one’s own viewpoint feel free to redefine the context at your convenience.
I did notice you focused only on some part of my earliest post (excluding the following)…
…but provided no word about foreseeable evolution of such rough diamond.
You would be surprised how people cannot be so easily blinded whereas they rely on appropriate information and are encouraged to actively have a choice in the matter.
I don’t see how mentioning “a mail client has to trust the root in order to make the secure connection” was an appropriate reply other than assuming the user consider such the only basis for their trust.
That would be indeed a circular argument as consideration is taken about only one possibility…
It really didn’t appear so whereas your strictly focused on sites that involve money transactions (namely “your bank” and “PayPal”)
Well it was designed to be (only) silent.
Code was altered to achieve such effect.
And yes I didn’t see any warning. Why it was designed in that way?
What was the reason to discard the existing notification possibilities Chromium provide?
How many types of notifications are there and why no alternative was developed if none of those (currently available) was considered fitting?
Are plugins currently allowed to contact 3rd party sites by means of http connections without any notification?
And why while I have repeatedly asked about this aspect I had no pertinent reply whereas the (http) destination cannot so easily assumed to have been vetted by any CA?
In fairness, there is no presumption of security with HTTP, but the general public associate certificates with security with trust.
This is the root problem with DV certs - the public see a lock and think it’s OK.
I would see also fair that DV-certs would not be considered as inherently implying malicious/shady websites.
If they are banned somehow I would like to hear a fair reason and one that applies in the same way to websites and plugins.
the only time a DV is good is when the user enters HTTPS address in the address bar.
In any other scenerio, its false sense of security because there is NO identify information in it.
You go to an HTTP site and click on a HTTPS url secured with DV. You have no means to validate that the site u just went to is the site you thought you were going to. Cos there is no identity information in a DV.
Encryption is an “Exclusion” technology…It excludes everyone but the “intendant” recipient. If the user does not know nor can validate the “recipient” what is the point of the technology? They could be encrypting it for the very fraudster they are trying to exclude!
Encrypting something for someone requires you to know who that someone is!
In DV that sound logic is non existent!
So what is DV good for again?
Melih