moloch

Say they introduce a bug, that deletes every file on your machine.

No, they don't have access to the Wireguard keys and everything is point-to-point. They'd have to push a backdoored software update to gain access (and this is a threat with any vendor product).

Yeap, I think the Xbox 360 was the first (or one of the first) to implement this protection back in 2005 - https://www.youtube.com/watch?v=uxjpmc8ZIxM

No, unless combined with WebUSB trickery, and such an attack has been possible in the past. However, browsers currently implement blocklists of HIDs and other USB types from working with WebUSB.

Python has had named arguments for a long time (since v1.4), which is arguably more widespread than PHP or Swift.

None of your cited examples are "secure," they're the very definition of "security by obscurity," which is to say insecure.

https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle

If anyone is interested in Electron application security, I wrote a guide that explains the methodology behind some of the choices the author here has taken and even goes a bit further in a variety of areas: https://know.bishopfox.com/research/reasonably-secure-electr...

I've used nsshell to great effect on multiple projects, highly recommend it (but an encrypted option would be great rook). I've also written a more heavy handed asymmetrically encrypted DNS C2 https://github.com/BishopFox/sliver

Always hack with a safety shell!

The conference did _not_ accept the talk, they paid the conference so that they could give the talk.

Using 2Mb with MSVC instead of 1Kb with MASM. Such a wasteful world.

I think their main mistake was requiring a user to change their password to upgrade the hash instead of upgrading the hash on the next user login.

Steam VR/Vive has "AAA" non-exclusive titles.

Is that enabled by default in 4? I use and identical AOT build process with 2.4 and 4 (ng-cli) and there's no problems building with 2.4

Lol, if only the real world were that simple. I have an Angular 2.4 project that when updated to 4.0.0 produces about 300+ build time errors (guess you can't access `private` members from templates anymore, it'll be fuuuuuun updating every component and template to work with "backwards" compatible v4), but basically every other version of Angular breaks your code so you just sorta have to live with it.

This is bad but not horrible, especially in the example given leaking the reset token to Cloudfront. The application is loading JavaScript from the Cloudfront origin, so that origin by definition could already read the tokens by modifying the JavaScript (assuming no SRI). The request is sent over SSL/TLS so the token cannot be viewed by a MITM, and referers aren't sent across HTTP<->HTTPS transitions.

Again this is far from ideal, but also not readily exploitable by attackers that couldn't already access the data.

SVG should only be executing in a null origin if it is not blocked by the CSP.

Well TypeScript is sort of "optionally typed" (variables can have a type of `any`) it's also superset of JavaScript so any valid js is valid ts.

Ubuntu also has LTS releases for this exact reason.

I really want the GPU performance, my mid-2014 MBP can only output to a 4k monitor @30hz

There are a huge number of contextual corner cases, this cheat sheet lists just a few:

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_She...

> Yes, blacklisting is insufficient in general. But it covers many cases, including the one here. Contextual encoding must be done each and every place you emit user input into HTML, and it's easy to screw this up.

Blacklists are only acceptable if you do it in addition to contextual encoding wherever you emit user controlled data, and even then a much stronger protection would be to whitelist acceptable characters. Either way, contextual encoding whenever you emit user data is the only real protection. --And even then it's not a good fallback protection, a strong Content-Security-Policy should be your fallback protection.

> Unless you're intending for your user to post HTML, or math inequalities, or diff patches - there's no reason to allow angle brackets on a form post.

Form posts are not the only vector for XSS, any HTTP request can be potentially exploited to perform XSS (and any part of an HTTP request), doesn't matter if it's a Form, an AJAX request, an HTTP header value, or a GET parameter, they're all potential attack vectors.

This is insufficient to prevent XSS, or DMI -the de facto anti-XSS is contextual (generally HTML) encoding, and it is the only proper mitigation. Blacklisting specific characters such as angle brackets is not safe, and will end in tears.

The actual quote was:

“First of all, VR displays are a little too cumbersome. It has to be much more elegant, being connected by a wire has to be solved. The resolution has to be a lot higher. The physical worlds do not behave according to the laws of physics. The environment you’re in isn’t beautiful enough. We’re going to be solving this problem for the next 20 years.”

"Solving over 20 years" / "20 years from being solved" are very different things.