I would say yes. Pop-unders should be blocked, and modern browsers work pretty hard to, but it is often viewed as a "low priority" sec issue, and so workarounds are found, ignored, used in the wild, and patched. Here is one implementation, I have seen working versions up to Chrome ~30:
Another serious security issue is when the popunder waits for a while as the parent frame navigates itself to e.g. "java.com", then the child navigates the parent to a malicious drive-by download. This can make it appear to "spoof" a drive-by download. This attack vector has been known and ignored forever (I think Zalewski published about this years back). IE9 and 10 actually do a good job preventing this, but I know it works in most modern browsers.
It depends what you mean by the term "associated browser security." The method they are describing stops CSRF attacks dead in their tracks (e.g. if dev set up a GET endpoint that should have been POST/PUT), prevents plaintext cookies from being stored in a nicely organized sqlite db on disk, and limits the scope of xss (xss on a 404 page would get you nothing).
> Aren't cookies restricted for a reason? Can't anyone who can execute JS on that domain can swipe the JWT token out of storage and then impersonate the user?
HTTP-only cookies prevent attacker from swiping yes, but if you have the ability to execute JS on an arbitrary domain, you can just do your XSS attacks there, the browser will attach the cookie, and attacker has already won.
Of course it is not a perfect solution. Just more depth. XSS into a page that inlines auth details = instant pwn, but that was already true anyways. Inlining cred info into my javascript gives be a bad feeling too.
Congrats, I have been waiting to see someone build something like this for a while. This is truly a glimpse into the future :)
Edit: I should have vetted this a little harder before commenting. I recognized the idea immediately, but the implementation here is rather lacking. Still, props for pushing the envelop.
Not really anything useful in this article. To make fibonacci "non-blocking", you use process.nextTick callbacks to "interweave" the computations, just like real threads!
It's a public wifi network that is broadcast from a device that is (probably) on your LAN. Attacker connects, finds some vulnerability, and has unrestricted access to the LAN. That is just one attack vector.
;tdlr it degrades your security, and is generally annoying.
Sorry. I got bitter there at the end, it was uncalled for. I spent 3+ years as a PHP programmer, there's certainly nothing wrong with being a PHP programmer, but it's hard to argue that in 2013 it is still a good and productive platform to learn. It pains me to see newcomers starting out by learning PHP, they are essentially shooting themselves in the foot for at least a year of their life (if they are going to be a professional web dev). I was pretty productive at PHP, but only because I cut my teeth for years writing shitty cgi-style PHP scripts, learning the abortion they call their stdlib, then using PHP's OOP crap and finally using frameworks like CI. Imagine if I had spent that time writing ruby. By the time you get the whole way through, you realize that your "high-level language" should do work for you, not the other way around. I think what it comes down to is that PHP does not mandate good design patterns because it cannot even decide on one itself. Once I understood this, the language was forever tainted.
I think the only reason PHP is still relevant is because it's so damn accessible (kinda like w3schools), every shared hosting provider under the sun gives you apache+php, and when you're starting learning web programming shared providing is the way to go.
Why do you say php and Javascript suffer from the same ailments? They suffer from a few of the same ailments, like a crappy/confusing stdlib (although you don't see mysql_real_escape_string in javascript's API) and funky invisible type coercions. Lack of true OOP in javascript, though confusing to beginners, is a design feature as far as I'm concerned, prototyping gives you the tools to implement OOP however you like. But javascript has had a known design pattern from the beginning, which is very powerful and useful once you learn it. I strongly doubt a (another?) phplint at this point would change anything.
As for the "anecdotally" slide, I read the last statement as a conclusion of the previous stats, which didn't make any sense to me. Either I am completely misreading it or you are taking the phrase "anecdotally" far too literally.
> Facebook’s PHP Codebase
> x * 105 files
> y*107 LoC
> 10 releases per week
> Anecdotally, good engineers are astonishingly productive in PHP
Erm... are you kidding me? LoC != productivity, not even close. And it goes downhill from there :( I really, really don't want to rail on PHP (people do that enough, it gets old, yada yada), but you're kinda asking for it here. The only useful point made is about state, although that's a double edged sword.
...Fuck it, I'll rail. It's 2013. Do yourself a favor. Use something better than a horribly inconsistent glorified cgi script.
I like coffeescript. Lots of web devs that write ruby all day like coffeescript. tbh I think coffeescript is worth it just to never have to write "function(){..." or "this." again. It's also worth it for its free OOP features. It will have quirks, like what you see here, but I have hit these pain points and still love it.
My first reaction was, oh wow looks just like the NeXT cube, that's kinda a cool tribute to Jobs.
Then my second reaction was, oh man, it will sorta look like I have a trash bin on my desk. I wish they had made the dimensions a little different. I think this will be the "flop" model where they work out hardware kinks and the next one will be prettier/sleeker, so I'll hold out til then.