3 ms·

I guess we'll have to wait until you post the technical details, but from the Ars article, it sounds like this page is using existing standards (TLS, maybe some

I guess we'll have to wait until you post the technical details, but from the Ars article, it sounds like this page is using existing standards (TLS, maybe some other stuff). That's fine, but what's the incentive for a bank or any secure online service to use this instead of the expected <bank>.com domain name? 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/ 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.

secalex 14y ago
The UX should be the equivalent of the current EV UX, but the point is that if your browser supports DPF then you don't need to look. If you got there after typing bank.secure, you should be good. If the screen is red (and hopefully doesn't have an "accept this risk" button) then you didn't. 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.

secalex 14y ago

The UX should be the equivalent of the current EV UX, but the point is that if your browser supports DPF then you don't need to look. If you got there after typing bank.secure, you should be good. If the screen is red (and hopefully doesn't have an "accept this risk" button) then you didn't. 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.