I agree. It depends. Using an icon can do wonders for brand recognition whereas a typography based logo could be really strong. But you know, it depends on the branding, vision, message you want to convey, etc. Lots to factor in, like some of the fine examples you stated.
Comodo is a fine example as well. Their custom typeface is what I remember. The icon not so much. Not bad but not really special either. Now the (new) sectigo icon is better. I like it, it's simple, but I take issues with their brand. It's not all bad but for some reason I keep mistaking it for sertigo/certigo. sertigo still available at regfee for some reason. Say certigo, sectigo sertigo and repeat that a couple of times. Do you still recall what the right brandname is? I'd secure it for brand protection, no questions asked.
Back to DNE. I'm not a fan of the name to start with, I don't like the flow of it as it is pronounced with two consecutive /e/ /n/ sounds. It kinds breaks up the name if you get what I'm saying. The DN part is something I don't understand at all. It's not on point with the product. DNE is not
just websites/domains, it's an intermediate CA. Securing HTTP with SSL is at core just a small part of this.
Even if you wouldn't link the DN abbreviation to domains (I reckon non domainers won't that easily), what is the brand here (as shown in the logotype)? Is it an abbreviation (DNE) followed by ncrypt? It would make sense if you used DNE all in caps, and ncrypt would work as alternative spelling for encrypt. But that way the abbreviation wont make sense. Still... It may be nitpicking but this is something you should really tackle right away when you establish a brandname. It's a weaker choice but it is what it is... imo.
As for the proposed logos visually. Most of them are unbalanced, weird kerning and tracking. Basically way too generic. I like A6 somewhat but I dont think the icon is that well done or really holds some meaning, I'm with you on that. And yeah, don't try too hard.
On the brightside... look at what most of the competition is using. They must have let the intern create it or it must have been a monday morning of friday afternoon design job
.
Just my opinion, the project itself is actually pretty cool
Yes, good points.
As for the name, that ship did sail. At the time
we had just named DNProtect.com for an upcoming domain risk-scoring and insurance product. So, the DNEncrypt brand seemed like a logical brand extension. A few weeks later
@Tin Nguyen came on board as Product Manager.
@Ala Dadan and
@Tin Nguyen are chipping away at the site but the real work is in standing up the API provisioning software for issuing SSL at scale with secure key management. We have more than 200,000 SSL-secured domains live now. Lets Encrypt has issued about 850
million certs.
Keep in mind that DNEncrypt started out as a bootstrap project to explore becoming a Root CA. We then completed a multi-year deal with Sectigo and now here we are: a few weeks from releasing (unleashing?) an alternative to LetsEncrypt using commercial DA certs that can be issued at scale.
When it comes to challenging LetsEncrypt, useful read here:
https://medium.com/swlh/why-lets-encrypt-is-a-really-really-really-bad-idea-d69308887801
It is interesting to see people beginning to talk about the
downside of LetsEncrypt. I think the
real downside is that we don't actually know who
owns it or
governs it. That seems to be a black box.
When it comes to things like whether, how, and under what conditions data gets routed,
ownership and
governance matters a lot.
Now think for a moment about all the
pour souls who tried Ashley Madison, and then one day, oopsie, the member rosters were leaked. Some went so far as to call it a
honeypot.
So, one day imagine we wake up to discover that LetsEncrypt's keys were compromised.
Oopsie-daisy. It was all free so any losses that anyone would incur would be without protection.
The ToS of LetsEncrypt are worth a read. Basically if there is an oopsie, well,
sucks to be you. '
See if you can download the full PDF of the
current ToS from their website. It should be easy. It is not but you can piece it together from other documents on their site. You will find segments like this:
To be fair, if you paid nothing, you probably should not expect much in terms of legal protection. On the other hand, consider the
possibility that LE was all just a giant setup for the eventual
oopsie.
As I see it, right now there appear to be a lot of fragile eggs in someone's basket. If that one single encryption key suddenly is compromised, there are a lot of drippy bags.
Does it sound far-fetched that LetsEncrypt would already have encryption backdoors or that the key could one day be compromised? No, not really. See here:
https://www.politico.com/story/2019/06/27/trump-officials-weigh-encryption-crackdown-1385306
Just as "law enforcement" wants a backdoor for WHOIS RDAP to pierce the privacy veil at will, it would be not crazy to assume that similar organizations expect the same for (free) SSL/TLS.
Just as
Epik WHOIS privacy being real for law-abiding entities, I believe the goal with DNEncrypt should also be real encryption for law-abiding entities.
As for the obvious case of a domain that breaks the law, I believe our policy should be simply to block those domains from being able to use the SSL issuance service. We'll see how that goes.
The SSL/TLS area is pretty fascinating. I am glad we initiated exploratory work in this area of the internet delivery value chain. There might be more here than I expected to find.
