Hacker Newsnew | past | comments | ask | show | jobs | submit | rx4g's commentslogin

Yes, I do, and am almost 50.

I feel fortunate. I get to solve puzzles with a lot of my time.


Yes, I do, and am almost 50.

I feel fortunate. I get to solve puzzles with most of my time.


I have experience with Angular and Backbone. Backbone will definitely give you more control, but you have to make more choices. Angular is definitely generating more buzz, but Backbone has a sizable community too, and is more mature and battle-tested. That's a big deal in the Javascript framework space, where the scenery can change drastically month to month. If you're doing something small, or you have a little extra time, it's worth getting familiar with React, Angular, and Ember too. TodoMVC is a nice way to get a sneak peak at the various idioms of each framework without investing a huge amount of time.


Now I kind of want to cross-reference this with the TIBOE index and make a frankenlanguage with the most popular syntax.


Didn't PL/1 try that? (Or maybe they made the classic error of "worst syntax" instead... not sure. Been a few years since I looked at it =)


Huh, http://www.theverge.com/2014/11/18/7239221/whatsapp-rolls-ou... (found searching Google News for TextSecure) is also 404'ing at the moment.


It also gives you a chance, on subsequent logins, to just login using your FB account. Not that uncommon.


> It also gives you a chance, on subsequent logins, to just login using your FB account. Not that uncommon.

Then why the heck does it ask for a password?

If I use FB login, the primary benefit is not having to track another password.


I think he's saying that clients could decide beforehand whether they want to go into HTTPS-only mode, for example.

But this is something clients can actually do today, without the need for a new protocol or any awareness on the server side. URL isn't HTTPS? Don't load it. I actually did a Firefox plugin that implements this, called http-nowhere.


But this is something clients can actually do today, without the need for a new protocol or any awareness on the server side. URL isn't HTTPS? Don't load it. I actually did a Firefox plugin that implements this, called http-nowhere.

Yes - and my understanding is that the browser developers are going to require all HTTP2 connections to be over TLS anyway.


It's disappointing to hear that the idea of requiring TLS with HTTP/2 has lost traction. For me, TLS-everywhere was the carrot on the stick.

I recognize that getting consensus is hard work, but I don't think creating another encryption-optional protocol and letting vendors duke it over security is going to end well for the users.

  HTTP is a deployed protocol with lots of existing 
  stakeholders, like proxy vendors, network operators, 
  corporate firewalls and so on. Requiring encryption 
  with HTTP/2 means that these stakeholders get
  disenfranchised.
I'd like to hear the arguments of the potentially-disenfranchised stakeholders first hand. Is it mainly because it makes it harder to sell or use products that allow traffic snooping?


One obvious change here is that it would make CA-signed certificates mandatory for all HTTP2 web servers - is that really a situation we want?


That doesn't have to be the case. You could still allow self-signage, with all of the security caveats that presents.

Who knows. Maybe that arrangement could even spur a sorely needed push for a free certificate trust network and get rid of CA's entirely.


Self-signed certs are much harder to get browsers to accept these days. The "I know what I'm doing" button and process are becoming ever more complex, and I wouldn't be surprised if they just start going away in favor of a list of trusted root CAs, which you may or may not be able to control as a user, depending on your browser. Which sucks. But anyway.

StartSSL is one place where you can get a free cert for your website today (and yes, they charge for revocation, but revocation is pretty ineffective anyway). I got a free cert from them, but my mobile browser doesn't trust it, so I decided to shell out $10 for a cert that's more widely auto-trusted by browsers. Not a huge cost, IMO.


I can't speak for anyone else, but I certainly do.

Regardless of the form of PKI employed, there's going to be a cost associated with validating the identity of the parties you're communicating with.

For the average Joe, certs that require domain ownership validation are pretty cheap these days -- certainly on par with domain name registration fees. As with domain names, people need to just start treating it as a necessary cost of running a website.

To be clear, I am far from a fan of X.509, but I'm not holding my breath for something better to come along (and be widely deployed) this decade. So let's use what we've got.


Those who don't have CA-signed certificates can still use HTTP/1.1, I don't think it's that big of a deal.


I'd like to hear why maintaining status quo for stakeholders should ever be a valid argument for a technology standard.


Because for a standard to actually become standard, you have to make it desirable for the people who you're trying to talk into switching to it.


No measure taken in isolation will give you "that much security". As you say, validating the identity of the artifact signer is an extremely important and oft-missed measure, but that should not lead one to conclude that transport layer security (both confidentiality and server authentication) is unimportant or "snake oil".

I will give you that web PKI sucks, but I would rather have a bit more assurance (even if imperfect) that the site I'm pulling artifacts from is indeed the one I intended to retrieve them from, even if I have a good signature + signer verification mechanism in place.


Try the proxy in Burp Suite. The free edition lets you do most of what you can do in Fiddler. More powerful in some ways, rougher around the edges in other ways.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: