With features like this, how could you say no?
> So, let's see. For an inflated price, you publish your app on the App Store which has a vastly more complex application process, which places arbitrary restrictions on what services and configurations you can run under it and which retains the right to suspend your app, possibly permanently, if you don't comply. Oh, and you end up with what is ultimately an app that is only accessible within Apple's walled garden.
I'm not saying this venture will necessarily succeed, but I wouldn't dismiss it so easily.
The difference is that having an application available through the App Store is pretty valuable on its own. It gets you access to Apple's QA, processing, and fulfillment services, as well as a seriously HUGE customer base.
By contrast, a .secure domain doesn't appear to give you much besides the name. All of the actual security is still your responsibility.
Not at this time.
No way, Jose.
for me, HN is the reference section of the library. it is not that it can't have humor, it should be useful for more than just a laugh.
Of course, the first time one of the sites gets hacked, who knows what will happen to the TLD's reputation...
Using .secure just asks users to instead place their trust in a new central authority; why does this even need to be a new TLD? This researcher is wasting money buying into ICANN's bullshit monopoly. The future of strong crypto systems will most certainly be decentralized.
I think we agree about UX. One of the big picture goals of .secure is to invert the current security experience. These days you go to a site and then have to interpret the UI to see if you are safe. In our vision, when you type bank.secure you are telling your browser, OS and the server on the other side that you want to navigate there as safely as possible.
I'm going to post about the tech details more tomorrow and hopefully that clears some things up.
When I browse to a secure page (https) in my browser, I'm told that the connection is secure with a green https prefix in the address bar. But I don't really know it's secure. I'm placing my trust in the CAs. Using .secure to signal a secure connection to user doesn't improve this. It just complicates things further, because now there's two things a savvy user should look for if he/she expects a secure connection (https and .secure).
Because you seem like a fan of XKCD: http://xkcd.com/927/ Creating a new UI standard works best when it kills (totally replaces) it's predecessor. In this case, I think that translates to having every site which currently uses https make the switch to .secure. That seems unlikely to me.
I should point out this is about more than TLS, and more than the web. We have a short window during which we can create an Internet category that is both clear to the user in it's goals and specific in its requirements for hosts. Our hope is to create an extensible protocol with DPF, one that can be extended to give domain registries and registrants the ability to choose higher privacy protections, limit risk to CA compromise, and secure other protocols like SMTP.
This idea actually sounds fantastic. If I only ever buy my certificates from one or two CAs and if I can disallow certificates signed by other CAs, I won't have to worry about some random CA getting hacked and millions of fake certs being trusted by browsers.
Implementing this scheme, on the other hand, will be tricky. If I use a DNS record to specify my trusted CAs, sort of like how we do SPF nowadays, anyone who can hijack DNS queries will also be able to forge that record. Proper DNS security must be provided before this measure can be made effective.
The complicated paperwork will not only drive phishers and scammers away. It also excludes people with little capital but a genuine intent to do business. We already have these barriers:
- Extended Validation SSL
- Merchant Account (including PCI compliance)
- All kinds of trust seals
The cost of these products can be several thousands of dollars every year and they have become pretty much a must-have for anyone who wants to be trusted more easily.
.secure will just impose another barrier, unfortunately.
That said, .secure seems like a poor solution in search of a problem.
Guys. Listen. .com is, has been, and always will be the standard. It's the brand name. It's the default.
There is never not going to be a chase.com. It will either be run by JP Morgan Chase, or it will be run by a scammer, either way the overwhelming majority of internet users will think "chase" and associate "chase.com" with it.
Imagine a non-technical family member getting a phishing email with chase.com in it. Do you honestly think that they're going to think to themselves "bah! the .com tld isn't secure! I should be looking for a .secure website!"
What is even the point of this? Regardless of if people jump on to .secure, the entire .com internet still exists.
Do you honestly think that they're going to think to themselves "bah! the .com tld isn't secure! I should be looking for a .secure website!"
The problem is the classic tld one. With https you know it's the same domain, but who's to say chase.secure is run by the same people as chase.com? Both could own a trademark relating to the word chase, both have verified (and different) addresses, but they're not necessarily the same
I know it ruins the tld extortion model, but I think for this to fly the .secure address should be linked to .com, so only the owner of the .com is eligible to buy the .secure and has been vetted as owning it
Otherwise I'm pretty certain the consumer uncertainty of the tld issue will destroy all trust in the .secure brand. No one argues that https is less secure, but when people have their geek friends put caveats on the .secure domain that they don't quite understand, I think that consumers will eventually avoid it
No, but it might exist only to 301 to chase.secure. Still preferable to type it directly but potentially better than nothing.
If this scheme is going to founder it's because nobody pays attention to the URL despite the best efforts of browsers, not because any of the rest of the scheme is bad.
some folks will read ".secure" as ".pwn-this-i-dare-you" and it will happen eventually unless you air-gap any ".secure" machine from the "real" web. This idea is about as effective as the evil bit RFC imho, just less funny.
Also, I cannot see how they could achieve critical mass without government intervention. I expect if they really do mean business to see some intense political lobbying or sidedoor via some government regulator or commission. It could even be that the intelligence services will love and push for this proposal for the centralisation of so many channels may make their work significantly easier.
No non-trivial corporate will go to the lengths requested without being required to or strong tangible benefits over what they already do and can cost-effectively procure in future. After all, there is nothing in the proposal that corporates cannot already do themselves.
In short, this seems to be at best a security industry playground and the founding companies business model as a play on security concerns subsidised by others, or at worst, security theater.
It would be very interesting to know Bruce Schneier's take on this...
Didn't Verisign try something similar, only to get out of that business as soon as it became obvious the whole system is easily exploited and inherently insecure?
It will be interesting how this company tries to explain how this is different.
"We sell domain names too!"
Just one more thing they can add to their list of "services".
Does it increase security?
Just throw in some buzzwords that clients identify with security. Sold.
No one ever audits the auditor.
Maybe it increases security in the mind of the client or the end-user.
And that's enough to sell the services.
Sometimes, it even makes me wonder if they choose these kinds of names to get penetration testing services for free.
Be consistent - using citibank.com and citibank.secure does not help at all, it will only confuse customers even more.
Inept clowns and scammers.