I don't see exactly how it is a concern for Netflix, but sadly "self-XSS" is real on Facebook. Not among us tech-savvy people obviously, so consider how much you look from inside a bubble.
If people read of a "h4x0r trick to read their bf/gf private messages", they will execute it. And hey, "it has this l33t keyboard shortcut that will make a strange window pop up, it must be what the hackers in the movies use!!". And then "Oh well, thanks to this friend of mine for sharing this cool trick that gives me the stuff to paste there, I would not know how to use it!". And finally "Booooo, Facebook sucks, my account got hacked".
I remember of the internet making fun of a girl that believed to be enrolled in some secret police because she popped up the Dev console. Well, that is just normal people, not uncommon.
I trust that actual developer can find their way around blocks and warnings, that however raise the bar for social engineering.
If Facebook made use of smart OCAP practices, none of that would be possible. Use of object identity as a "security key" would prevent code that doesn't have access to the "key" object from being successful.
Not necessarily, because you can limit how certain values can be accessed due to your scope. For JavaScript, if a key is saved in a variable inside an anonymous function, it's inaccessible for somebody who has a console that sits at the root of the document.
But it requires that the value is hardcoded inside the function. If it was given to an unreachable scope by some async action (like an ajax request) this trick wouldn't work.
One could possibly also wrap the function in an native .bind call to change the output of toString() to [native code]
I wonder if even that's feasibly secure though, when you have stuff like http://esprima.org that can let you fully parse the entirety of the JS on the page.
It's better to assume the console has 100% root (client-side) privileges.
But the enemy here isn't necessarily the console, it's the social attack against the console. Making it harder for the user to screw himself over is a worthwhile endeavor, and not merely "security by obscurity".
right, because patching one of 1000 is the right solution? please give back your engineer card.
- just download this file to see your gf private messages. ok, lets remove download from the browser (actually, ios did this)
- just run this long string in the address bar to see whatever. ok, let prevent javascript: schema in url bar (actually, android stock browser did this)
anyway you go at it, is ineffective. the only solution is to educate. trying to prevent idiots from harming themselves will just lead to annoyance to the non-idiots and more sophisticated attacks until you cant prevent them.
people who implement those dumb thing disgusts me. your comment disgusted me.
Exactly. The more things you do to restrict users so "it's safer for them", the more reckless and stupid they'll become - "because $security_feature will protect me" - and they won't ever learn anything. On the other hand, if we give them the freedom to make mistakes, those that do will learn from them. Instead of trying to block "self-XSS" or telling everyone "don't listen to anyone telling you to paste something into the URL bar", we should be encouraging them with "if you don't know what it does or don't trust the one who told you to do that, then don't do it - or find out what it really does." That last part is particularly important, since it encourages curiosity and that motivates learning.
I understand that many people would just want to use something and not want to learn all that much, but I feel we should also not be encouraging this "lack of thought" mentality either.
Sorry if offended too much. intended for just a little because that behavior is awful and must be treated as such.
Also if you want to learn how to do it right, look at Mozilla. They mostly do the right thing. E.g. telling user and in extreme cases making him wait a very short time before accepting something that may be dangerous.
I'll give back my engineer card (if I find it) if you swear not to apply for a security one :)
There's no way to make a system really secure and as you point out there is no way to "prevent idiots from harming themselves". What you do is stopping common/easy vectors and raising the effort bar/reducing conversions for the attacker.
If we require that a guy to use his computer learns how its threat model works, we failed as a industry.
And to address your points: users know that downloaded files are evil and Chrome warns about that. The javascript schema is mitigated by Chrome - if you copy-paste the initial "javascript:" is cut out. I'd love to know the other 998 to open discussions about them.
Note about the use of the word idiots: more of people who are not tech-savvy; you might be an idiot in this meaning for one or more of: electricians, mechanics, doctors...
If people read of a "h4x0r trick to read their bf/gf private messages", they will execute it. And hey, "it has this l33t keyboard shortcut that will make a strange window pop up, it must be what the hackers in the movies use!!". And then "Oh well, thanks to this friend of mine for sharing this cool trick that gives me the stuff to paste there, I would not know how to use it!". And finally "Booooo, Facebook sucks, my account got hacked".
I remember of the internet making fun of a girl that believed to be enrolled in some secret police because she popped up the Dev console. Well, that is just normal people, not uncommon.
I trust that actual developer can find their way around blocks and warnings, that however raise the bar for social engineering.