> Back doors should appear to be standard coding errors > Find some obscure behavior in old and insecure crypto libraries, tie functions to that, use as excuse to not use up to date libraries > Ensure random numbers use a predictable method in some NSA-known number of dimensions > Use some Chinese words to make it look like we're the victims when the backdoor is discovered > Implement hardware protection using chips that are not subject to less than multi million dollar analysis, claim to protect trade secrets > Allow remote updates with 3G, or wireless, or just the wild internet- anything that responds to a private key. Because private keys are never stolen ever. > Don't have any method of verifying the firmware to a particular image or version > Avoid a write protect switch to firmware- firmware should be anything but firm! > Under no circumstances use open source code, or ensure a proprietary part holds the real keys
With standards such as these, Cisco hopes to bring you better quality backdoors in the future!
One of the big problems with writing a browser that does what the user wants is how aggressively ludicrous the javascript devs can be. For instance, many browsers have a setting that disables the ability of right click to be controlled from the HTML, but of course javascript can POLL this flag, and act on the result. The browser shouldn't be leaking user state like that, and it certainly shouldn't allow a savvy user to be asked to pull down their pants and bend over. It's totally possible to create a browser that does all this- but little flags to ignore bad-by-design features are both fiddly and doomed to failure.
Examples:
Everyone hates popups. Popup blockers became a thing, then they just were enabled by default. But then javascript offered popups, and now you can get blockers to disable them. And how many websites do you visit that look reasonable until about 10 seconds in when they suddenly overlay a gray or black box over the whole fucking screen, and force you to interact with them (and keep in mind, the fact that interacting with them removes the overlay is ENTIRELY optional!)? Savvy users will use ublock origin (or Remove it Permanently, or many other things) to eliminate shit like this. Even fucking Wikipedia does this! So there's a workaround, but not a solid generic fix for this shit. The fact is, the browser needs to be fundamentally incapable of taking remote commands like this, while ALSO appearing to take these commands from the server side, to prevent hostile devs from shitting the bed when they detect this.
The "right" answer wouldn't just stop this stuff- it would cut it all off at the source, no matter how clever or evil the javascript writers become- because at least on the evil axis, there seems to be no limit.
> Ah, so ctrl-U is the short cut for "view source"?
It's in the links and is quite googlable, but the post I made discussing viewing source should have been the tipoff:P
> Even if that is completely disabled, you could just save the page and open it in a text editor.
Dude, if they think they can disable Ctrl-U, they ALSO think they can disable Ctrl-S and Ctrl-P. Depending on how gullible your browser is, one of the above links tries to do that too.
> The developer menus are obviously always activated on my browsers
Nice. So Safari already has a mode that steps so far above this stuff that you didn't even realize there were ANY people, ANY where, to whom it might inconvenience, because Safari makes it not even a thing. Excellent. The article doesn't make this point much, but it should- that a lot of modern browsers ignore ALL this stuff anyway.
The website tries to own the right click key too. It tries to vector everything it can, but you'll notice that a lot of it fails to work in many browsers, and all of it is trivially able to be worked around.
That's a lie, and that's bullshit. This destroys the user interface, and should never be allowed or tolerated. If these guys weren't malicious, they'd implement a little drag-down menu that would do all their things, or have a standard way of visibly showing the difference between an in-app menu and user level application menu. Even supporting this shit in the code makes developers confused, and they think they can vector hotkeys and tie them to ground.
Fucking idiots and assholes, enabled by a monumentally shitty language API.
You know you can find them whining that they can't stop the user from CLOSING THE BROWSER? After all, the "webapp" shouldn't close when the user says close, and the fact that it's somehow standing on the browsers head is something that needs to be bypassed in that stupid language. The fact that things like "onclose" stopped being implemented, and the fact that they are currently finding workarounds for "stop this page from creating additional dialogs" is a big problem.
Your issue isn't that you are on a Mac, it's that you are in a version of Safari of 6 or later. In Lion and before, it was Strange Nordic Whilygig + U.
First, you could run firefox or chrome or whatever.
Second, Safari -> Preferences / Advanced Tab, ensure that the develop menu is on, then you can control click and get some options, among them view source.
This is obviously not as nice as having a keyboard shortcut like you used to have. If that's a deal, just grab a third party browser.
..as a note, http://codingcrazy.com/disable... does seem to fuck with a default setting firefox or palemoon. Maybe it won't for you, I dunno. You don't need an addon to fix this behavior or anything, of course.
Sure, it's the onclose event. By javascript spec, any attempt to close the window should run the onclose stuff, which can simply return false, thus preventing the browser from closing.
Sample for an onclose event (this just fires an alert) is here:
You'll notice that it doesn't actually work- not only can you alt-F4, you can also just close the damned window. This is because modern browsers no longer fully support this ludicrously awful command.
But it's still valid javascript. Because javascript is a goddamned nightmare.
With scripts enabled, it actually seems to disable Ctrl-U in Firefox and Palemoon (not Chrome). Obviously there are easy workarounds (addons solve it easily, but also just changing dom.event.contextmenu.enabled to false lets you happily right click). What do you see when you go there in those browsers?
The point is, obviously there are easy work arounds, and obviously most browsers ignore this crap, and obviously no users will really be stopped (the point of the top article). But, that still leaves some real questions. One, why would javascript even HAVE shit like this? This is part of my general rant about javascript being awful at every single level- in this case, the spec implies to the coder that he is in control of someone else's box. That means that the spec is implied as some kind of malicious hack that browsers and users have to work around. These commands shouldn't even exist in the first place! Two, why would anyone expect a browser to listen to this garbage, even a little? Right click is an interaction between the user and the browser, there's never a good reason to intercept that. Three, how are there coders in ANY language who don't understand this shit? Like you're writing vaguely-C-like code and you don't even understand that if you turn off a usability function, it will just make everyone pissed at you?
Right, these assholes made everyone have workarounds. In Chrome, I have "Enable Copy" and "Enable Right Click", and if things get really rough then I go through some kinda monkey or whatever, but that's normally not an issue. I've never seen a browser in recent times that lets a website actually intercept Ctrl-U, but in strange aeons even common sense may die.
You won't be, though. Downtown Denver is full of weed shops. There aren't federal agents trying to randomly fuck with people, and if they were, they'd probably start with the weed shops. These store are recreational marijuana dispensaries, just sitting there with giant glowing green cannabis leaves as their logos and stuff. Also it hasn't happened yet.
Yea, like I said, I'm not aware of any way to do that. If there is one, it won't be effective in general. What they probably did was put a shit lot of linefeeds after a "Viewing source is disabled" comment at the top of the HTML- I'm not even joking, that's a real thing people do lol
But you really can intercept Ctrl-U. The thing is, most browsers simply ignore it, for obvious reasons.
There's plenty of code in there that does it. You'll also find that, in general, working around it is as trivial as not using a shitty browser that listens to bad advice like that. I don't doubt that the guy ranting ran across something that actually did what he said it did, somewhere.
Seriously, can you believe that some browsers in the modern day trust remote code? It's really dumb.
Basically, you can google anything with "javascript disable" and get developers asking how to fuck their users in the pee hole. Often, there's an answer.
It wouldn't actually prevent users from viewing source though- I'm not aware of a way to do that. However, if there is, you can find it at good old google bombing expert sex change:
Also note: the real workaround for this isn't globally disabling javascript, though if everyone did that the web would shape up immediately. The real workaround is the various -monkeys that let you redefine pieces of javascript locally. Many sites go through several hoops to prevent loading on a browser that won't run their shitscript, but redefining parts and/or loading your own CSS can get you around most of it.
Spare the moralizing. "Attacks" aren't bad from the perspective of the attacker, and the attacker could well be doing something like busting up bad guys. That doesn't make the technical discussion less valid, or warrant some new fucking word to avoid offending someone. More importantly, the TOR project isn't there to give back doors to good guys but not to bad guys.
First, I agree with you about Ulbright, DPR. Second, this seems to be about silk road 2. Third, this isn't even about jackasses acting with jackassery- this is about attacks on TOR.
We'll need clever CSS to block the new stupid clever CSS bullshit. I don't know when we'll get that. The existing things are usually served from the same host, making them more static (they usually beg you for an email address or something). You can often get the data with a view source, and the technique I use is to use Remove It Permanently or some other addon to remove element by element. You can also just block the elements with uBlock Origin, which works great for dealing with the mewling on wikipedia.
These types of display bullshit simply need to be rewritten at client side: they show the only real limitations of host files (or even APK's host engine), and they prove for certain that remote sources cannot be trusted to display as intended on the client side- the webpage-as-intended is fundamentally broken, and the client viewer needs to exercise complete control, with no "content provider" ever trustworthy.
> Let's agree that the acceptable level of burnt humans is zero,
Eh, the level of injury we are willing to tolerate from something is roughly in proportion to how cool it is. Cars? Super cool. Guns? Pretty goddamned cool. Mating with a laser mote? TOTALLY AWESOME!
Remember there is risk here too. I don't trust hardware much- and hardware encryption seems almost guaranteed to be broken- but there is some possible recourse to detect at least many of the ways a chip would be compromised- and would a company be able to bounce back from that?
Apple, Ios, and Microsoft had better get on fixing this IMMEDIATELY. If this goes live and stays live for a few months, fixing the bug will be deemed "going dark" and we'll hear about how "terrorists coordinate using securely patched phones".
Slashdot Mirror
What will their auditing standards be?
> Back doors should appear to be standard coding errors
> Find some obscure behavior in old and insecure crypto libraries, tie functions to that, use as excuse to not use up to date libraries
> Ensure random numbers use a predictable method in some NSA-known number of dimensions
> Use some Chinese words to make it look like we're the victims when the backdoor is discovered
> Implement hardware protection using chips that are not subject to less than multi million dollar analysis, claim to protect trade secrets
> Allow remote updates with 3G, or wireless, or just the wild internet- anything that responds to a private key. Because private keys are never stolen ever.
> Don't have any method of verifying the firmware to a particular image or version
> Avoid a write protect switch to firmware- firmware should be anything but firm!
> Under no circumstances use open source code, or ensure a proprietary part holds the real keys
With standards such as these, Cisco hopes to bring you better quality backdoors in the future!
One of the big problems with writing a browser that does what the user wants is how aggressively ludicrous the javascript devs can be. For instance, many browsers have a setting that disables the ability of right click to be controlled from the HTML, but of course javascript can POLL this flag, and act on the result. The browser shouldn't be leaking user state like that, and it certainly shouldn't allow a savvy user to be asked to pull down their pants and bend over. It's totally possible to create a browser that does all this- but little flags to ignore bad-by-design features are both fiddly and doomed to failure.
Examples:
Everyone hates popups. Popup blockers became a thing, then they just were enabled by default. But then javascript offered popups, and now you can get blockers to disable them. And how many websites do you visit that look reasonable until about 10 seconds in when they suddenly overlay a gray or black box over the whole fucking screen, and force you to interact with them (and keep in mind, the fact that interacting with them removes the overlay is ENTIRELY optional!)? Savvy users will use ublock origin (or Remove it Permanently, or many other things) to eliminate shit like this. Even fucking Wikipedia does this! So there's a workaround, but not a solid generic fix for this shit. The fact is, the browser needs to be fundamentally incapable of taking remote commands like this, while ALSO appearing to take these commands from the server side, to prevent hostile devs from shitting the bed when they detect this.
The "right" answer wouldn't just stop this stuff- it would cut it all off at the source, no matter how clever or evil the javascript writers become- because at least on the evil axis, there seems to be no limit.
> Ah, so ctrl-U is the short cut for "view source"?
It's in the links and is quite googlable, but the post I made discussing viewing source should have been the tipoff :P
> Even if that is completely disabled, you could just save the page and open it in a text editor.
Dude, if they think they can disable Ctrl-U, they ALSO think they can disable Ctrl-S and Ctrl-P. Depending on how gullible your browser is, one of the above links tries to do that too.
> The developer menus are obviously always activated on my browsers
Nice. So Safari already has a mode that steps so far above this stuff that you didn't even realize there were ANY people, ANY where, to whom it might inconvenience, because Safari makes it not even a thing. Excellent.
The article doesn't make this point much, but it should- that a lot of modern browsers ignore ALL this stuff anyway.
The website tries to own the right click key too. It tries to vector everything it can, but you'll notice that a lot of it fails to work in many browsers, and all of it is trivially able to be worked around.
Javascript is such a turd lol
That's nice of you, because apparently if he lost his original file, he wouldn't have a backup! You're doing the work of the gods, sir!
That's a lie, and that's bullshit. This destroys the user interface, and should never be allowed or tolerated. If these guys weren't malicious, they'd implement a little drag-down menu that would do all their things, or have a standard way of visibly showing the difference between an in-app menu and user level application menu. Even supporting this shit in the code makes developers confused, and they think they can vector hotkeys and tie them to ground.
Fucking idiots and assholes, enabled by a monumentally shitty language API.
You know you can find them whining that they can't stop the user from CLOSING THE BROWSER? After all, the "webapp" shouldn't close when the user says close, and the fact that it's somehow standing on the browsers head is something that needs to be bypassed in that stupid language. The fact that things like "onclose" stopped being implemented, and the fact that they are currently finding workarounds for "stop this page from creating additional dialogs" is a big problem.
The design is broken from head to toe.
Your issue isn't that you are on a Mac, it's that you are in a version of Safari of 6 or later. In Lion and before, it was Strange Nordic Whilygig + U.
First, you could run firefox or chrome or whatever.
Second, Safari -> Preferences / Advanced Tab, ensure that the develop menu is on, then you can control click and get some options, among them view source.
This is obviously not as nice as having a keyboard shortcut like you used to have. If that's a deal, just grab a third party browser.
satya nadella is that u
I googled "is google a verb" and it says yes:
https://www.google.com/?gws_rd...
Then I bung it:
http://www.bing.com/search?q=i...
So if even bing agrees that google is a verb, I guess that over rules "anonymous coward who can't capitalize for shit"
..as a note, http://codingcrazy.com/disable... does seem to fuck with a default setting firefox or palemoon. Maybe it won't for you, I dunno. You don't need an addon to fix this behavior or anything, of course.
> can you imagine a webpage blocking alt-f4
Sure, it's the onclose event. By javascript spec, any attempt to close the window should run the onclose stuff, which can simply return false, thus preventing the browser from closing.
Sample for an onclose event (this just fires an alert) is here:
http://www.htmlnest.com/javasc...
You'll notice that it doesn't actually work- not only can you alt-F4, you can also just close the damned window. This is because modern browsers no longer fully support this ludicrously awful command.
But it's still valid javascript. Because javascript is a goddamned nightmare.
This website claims to disable Ctrl-U as well:
http://codingcrazy.com/disable...
With scripts enabled, it actually seems to disable Ctrl-U in Firefox and Palemoon (not Chrome). Obviously there are easy workarounds (addons solve it easily, but also just changing dom.event.contextmenu.enabled to false lets you happily right click). What do you see when you go there in those browsers?
The point is, obviously there are easy work arounds, and obviously most browsers ignore this crap, and obviously no users will really be stopped (the point of the top article). But, that still leaves some real questions. One, why would javascript even HAVE shit like this? This is part of my general rant about javascript being awful at every single level- in this case, the spec implies to the coder that he is in control of someone else's box. That means that the spec is implied as some kind of malicious hack that browsers and users have to work around. These commands shouldn't even exist in the first place! Two, why would anyone expect a browser to listen to this garbage, even a little? Right click is an interaction between the user and the browser, there's never a good reason to intercept that. Three, how are there coders in ANY language who don't understand this shit? Like you're writing vaguely-C-like code and you don't even understand that if you turn off a usability function, it will just make everyone pissed at you?
Right, these assholes made everyone have workarounds. In Chrome, I have "Enable Copy" and "Enable Right Click", and if things get really rough then I go through some kinda monkey or whatever, but that's normally not an issue. I've never seen a browser in recent times that lets a website actually intercept Ctrl-U, but in strange aeons even common sense may die.
> stuff like OpenBSD which must have a smaller user base than TAILS does
Can you PROVE how big the TAILS userbase is? If you can, I have some harsh things to say about TAILS...
> you can still be arrested for it at any time
You won't be, though. Downtown Denver is full of weed shops. There aren't federal agents trying to randomly fuck with people, and if they were, they'd probably start with the weed shops. These store are recreational marijuana dispensaries, just sitting there with giant glowing green cannabis leaves as their logos and stuff. Also it hasn't happened yet.
Yea, like I said, I'm not aware of any way to do that. If there is one, it won't be effective in general. What they probably did was put a shit lot of linefeeds after a "Viewing source is disabled" comment at the top of the HTML- I'm not even joking, that's a real thing people do lol
But you really can intercept Ctrl-U. The thing is, most browsers simply ignore it, for obvious reasons.
You probably saw this mewling poopsack:
http://stackoverflow.com/quest...
And this dumb jive turkey:
http://www.makingdifferent.com...
There's plenty of code in there that does it. You'll also find that, in general, working around it is as trivial as not using a shitty browser that listens to bad advice like that. I don't doubt that the guy ranting ran across something that actually did what he said it did, somewhere.
Seriously, can you believe that some browsers in the modern day trust remote code? It's really dumb.
Javascript is a steaming pile of shit, riddled with vulnerabilities and broken from tip to top.
So of course they try to allow some overrides:
http://stackoverflow.com/quest...
Basically, you can google anything with "javascript disable" and get developers asking how to fuck their users in the pee hole. Often, there's an answer.
It wouldn't actually prevent users from viewing source though- I'm not aware of a way to do that. However, if there is, you can find it at good old google bombing expert sex change:
http://www.experts-exchange.co...
Also note: the real workaround for this isn't globally disabling javascript, though if everyone did that the web would shape up immediately. The real workaround is the various -monkeys that let you redefine pieces of javascript locally. Many sites go through several hoops to prevent loading on a browser that won't run their shitscript, but redefining parts and/or loading your own CSS can get you around most of it.
Spare the moralizing. "Attacks" aren't bad from the perspective of the attacker, and the attacker could well be doing something like busting up bad guys. That doesn't make the technical discussion less valid, or warrant some new fucking word to avoid offending someone. More importantly, the TOR project isn't there to give back doors to good guys but not to bad guys.
You seem off topic.
First, I agree with you about Ulbright, DPR.
Second, this seems to be about silk road 2.
Third, this isn't even about jackasses acting with jackassery- this is about attacks on TOR.
It's surprising how only governments seem wiling to make truly airgapped networks the norm, but I'd imagine SOME utilities do- just not all of them?
We'll need clever CSS to block the new stupid clever CSS bullshit. I don't know when we'll get that. The existing things are usually served from the same host, making them more static (they usually beg you for an email address or something). You can often get the data with a view source, and the technique I use is to use Remove It Permanently or some other addon to remove element by element. You can also just block the elements with uBlock Origin, which works great for dealing with the mewling on wikipedia.
These types of display bullshit simply need to be rewritten at client side: they show the only real limitations of host files (or even APK's host engine), and they prove for certain that remote sources cannot be trusted to display as intended on the client side- the webpage-as-intended is fundamentally broken, and the client viewer needs to exercise complete control, with no "content provider" ever trustworthy.
> Let's agree that the acceptable level of burnt humans is zero,
Eh, the level of injury we are willing to tolerate from something is roughly in proportion to how cool it is. Cars? Super cool. Guns? Pretty goddamned cool. Mating with a laser mote? TOTALLY AWESOME!
Remember there is risk here too. I don't trust hardware much- and hardware encryption seems almost guaranteed to be broken- but there is some possible recourse to detect at least many of the ways a chip would be compromised- and would a company be able to bounce back from that?
Apple, Ios, and Microsoft had better get on fixing this IMMEDIATELY. If this goes live and stays live for a few months, fixing the bug will be deemed "going dark" and we'll hear about how "terrorists coordinate using securely patched phones".
> So ... just curious, have you ever put a bowl of candy in front of a kid and they DIDN'T EAT IT?
Well, the researchers did. That's the whole point- the candy viewed increased the candy consumed.
> Perhaps because you don't care to pay for a Windows license, or agree to Microsoft's EULA?
That Windows EULA is some serious 1984 shit too lol