It's just a videogame. It's just a REMAKE of a videogame. It's not like they're even going to have a different story arc. Or even much of a story. There'd be more actual narrative material in a remake of a bad Saturday morning cartoon, like, oh, the Herculoids.
(If there's going to be a Herculoids movie, I don't wanna know. La la la la, I can't hear you...)
In the alternate universe where companies take basic security seriously, there would be a market for consoles that weren't locked down, because people would have revolted against the restrictions that strong DRM imposed years ago. Or maybe you'd be using a rich scripting language native to the Wii that wasn't piggybacking on PC security holes. Or maybe you'd be working on another product because the particular niche you're selling into wouldn't exist.
Yeh, DRM sucks, and locked platforms suck. We know that. There's a much better solution to the problem of rich homebrew apps on platforms like that, one that doesn't carry with it the implication that huge bleeding maggot-infested security holes are a good idea. I'll let you think about that for a while. I'm sure you'll get it.
So how would a web application work if it requires more low-latency (that is, local) computing power than common JavaScript engines are able to provide, or if it needs a machine feature for which Java and Flash expose an API but web browsers don't?
Not everything that's a web application should be a web application.
This is that old "security vs convenience" dilemma. I'd say this was a perfect example of a slippery slope, except you're so far down the slippery slope you've forgotten that there ever was solid ground to stand on.
When you've pushed the button to expand video to the full screen on YouTube or Hulu, do you really want a bright gray status and address bar ruining the picture's perceived contrast?
I'd go along with that... anything to discourage the four hundred and sixty seven slightly different and flakey flash wrappers around streaming video players.
Yeh, let the user run a dedicated PDF app or Flash app, and maybe idiots would create web pages in HTML instead of 30 different plugins (and all the associated performance and security problems that goes along with that).
Well, to be fair, Microsoft did sell that "friggin arcade machine" to you at a loss with the idea that they would make their money back on inflated game prices.
They didn't eat nearly as much as the arcade machine owner you're paying the quarter to.
Given that YOU paid for the frigging arcade machine already, and YOU paid for the floor space, they should cost *less* to play than Pac Man or Dig Dug. Not more.
So how did they "get used to it" ?The default after downloading a file in IE is, and always has been, "Save".
1. Because Windows is always popping up dialogs with "open" as one of the options, and "open" is usually the option to clock on.
Remember, most people don't use many keyboard shortcuts... I regularly get users going "how do you do that" when I hit tab, return, or space instead of reaching for the mouse. Most people, rather click stuff with the mouse. Especially when they have the mouse in their hand because they'd just clicked on a link they expected to open a new window.
2. More recently, Outlook has been telling them to open attachments in separate applications instead of in Outlook itself, which has been providing even more incentive.
How the limit is imposed, by Java runtime or by virtual machine, capabilities, SELinux or whatnot is irrelevant in principle.
The higher level it is, the more capable it can be without getting in the way. Implemented at the OS level, the way the article writer is talking about, the conflict between security and convenience is stark. Implemented at the language level, where the language itself contains no mechanism to do anything outside the application domain, it can be highly secure and almost invisible.
Now you're talking about an application level sandbox around untrusted code. That's a good way of redusing the surface area, BUT it's also a completely different kind of animal than the article is talking about. He's talking about OS level sandboxes around the whole application itself.
Yes, you can create a sandbox using a FreeBSD jail, and you can union-mount everything in the jail over a read-only file-system, and you can wipe the jail after every run, and that would be pretty secure. Personally, I run dubious software in a VM and roll back to a checkpoint afterwards.
But then people would be a bit upset that their bookmarks didn't get saved and they couldn't download files. Because most of the software that would need to be sandboxed is the stuff that people use regularly. A *useful* sandbox *has to* be leaky.
Making the application itself simple enough that it doesn't contain any mechanism run content outside its *application level* sandbox (like XPI or ActiveX or "Internet Enabled disk images"... it seems like every browser these days has SOME kind of stupidity built in) is a much better place to start. AFTER you get that bit right, worry about sandboxing the application itself... because that kind of sandbox is a secondary line of defense at best.
What's gained by having the user traverse a path of directories before opening the file manually, versus having the user explicitly ask for the file to be opened automatically at some later point?
Well, let me explain something. I've been a system and network admin for 20 years. I can't count the number of times that someone has come to me saying "um, I think I clicked the wrong thing and I think I have a virus". What they've done is some link has downloaded a file, and then IE has popped up a dialog asking "do you want to open or save this", and they automatically clicked "open" because that's what they're used to doing. When Microsoft added more stupid security dialogs, they reflexively approved them, because they get those messages all the time, and 99% of the time approving them is the right thing to do.
I used to say that I'd never had someone come up and say "I downloaded a file, and then opened it, again... and I think I have a virus". Now more recently I had ONE person say that. ONE person, in 20 years.
The difference? Clicking "infect me" on a dialog is something people do by reflex. Opening a folder or a download manager, selecting a file, and opening it... that's a deliberate action. People are so much more likely to realize that they shouldn't do this when they come up after the fact, on THEIR schedule, and look at it, and think about it... than when they're hit with just another "hey, I'm about to do something dumb" dialog that they reflexively approve dozens of times a day.
Your users (family members etc.) think they're safe, and want to be wow'ed. They're going to complain if they can't be.
Yes, I had lots of people complaining when I banned IE and Outlook at our division in 1997. Netscape wasn't "wow" enough. When we were the only part of the company that wasn't whacked by the flood of viruses and worms that hit in 1997 and 1998, most of them quit complaining about it. A few did. One contractor sat there and argued with me that he should be an exception to the no-outlook rule... WHILE I WAS CLEANING UP AN INFECTION HE GOT THROUGH OUTLOOK.
So, yeh, they'll say that. I have no sympathy.
When's the last time you downloaded a file and then immediately decided never to open it?
According to my download folder, 16:48 today. The name was "image_2.gif.exe".
Sandboxing means that once the attacker has used an input exploit to own the process, it has to perform a privilege escalation exploit to get out of the sandbox. The problem is that applications running in sanboxes have to be able to write files, read files, load and install plugins, execute helper applications, and generally do just about anything a regulat application has to. So the sandbox can't be very "strong".
Instead of adding a leaky sandbox, how about reducing the surface area exposed to attack in the first place? Simplify the application. Get rid of things like XPI in Firefox and ActiveX in IE. Get rid of the need for third party plugins like Java and Flash (HTML5 goes a long way here). Get rid of the ability for network apps to masquerade as local apps (there's no reason a web page should be allowed to remove the status and address bar, for example). Don't even *offer* to automatically open a file after downloading. Remove that option from the browser completely. Get rid of Acrobat and other plug-in document viewers.
Yes, this might make it less convenient for websites to "wow" the user. So what? I'd rather be safe than "wow"ed.
I would take the algorithms course first. I'd suggest taking both of them, since it sounds like you're not doing nearly enough math, but graphs and algorithms are central to so much computer science that it will definitely help to take that one first.
Then there were the calculations that physicists used to reassure the public that another accelerator called RHIC was safe. These too turned out to be seriously flawed.
Well first thought is why worry? That's your competition there. [...] Then, when times are lean and projects are scarce the slackers get culled from the herd.
Slashdot Mirror
Oh god, I had no idea, I'm sorry.
Fair enough. That'd be as freaky as Compaq buying DEC.
This is precisely why people were concerned about letting ANY single company own it.
Any company can be bought out.
If a product can't be effectively forked, it's not completely open source.
If a GPL fork of MySQL isn't good enough, then whose fault is that? And what does that mean for other dual-licensed GPL+Proprietary products?
It's just a videogame. It's just a REMAKE of a videogame. It's not like they're even going to have a different story arc. Or even much of a story. There'd be more actual narrative material in a remake of a bad Saturday morning cartoon, like, oh, the Herculoids.
(If there's going to be a Herculoids movie, I don't wanna know. La la la la, I can't hear you...)
You can see through them with beer goggles.
Deny from *.fr
In the alternate universe where companies take basic security seriously, there would be a market for consoles that weren't locked down, because people would have revolted against the restrictions that strong DRM imposed years ago. Or maybe you'd be using a rich scripting language native to the Wii that wasn't piggybacking on PC security holes. Or maybe you'd be working on another product because the particular niche you're selling into wouldn't exist.
Yep, it's a cheaper product to support. Which brings us back to the start of the loop, doesn't it?
Yeh, DRM sucks, and locked platforms suck. We know that. There's a much better solution to the problem of rich homebrew apps on platforms like that, one that doesn't carry with it the implication that huge bleeding maggot-infested security holes are a good idea. I'll let you think about that for a while. I'm sure you'll get it.
So how would a web application work if it requires more low-latency (that is, local) computing power than common JavaScript engines are able to provide, or if it needs a machine feature for which Java and Flash expose an API but web browsers don't?
Not everything that's a web application should be a web application.
This is that old "security vs convenience" dilemma. I'd say this was a perfect example of a slippery slope, except you're so far down the slippery slope you've forgotten that there ever was solid ground to stand on.
When you've pushed the button to expand video to the full screen on YouTube or Hulu, do you really want a bright gray status and address bar ruining the picture's perceived contrast?
I'd go along with that... anything to discourage the four hundred and sixty seven slightly different and flakey flash wrappers around streaming video players.
A browser *is* an HTML viewer.
Yeh, let the user run a dedicated PDF app or Flash app, and maybe idiots would create web pages in HTML instead of 30 different plugins (and all the associated performance and security problems that goes along with that).
Well, to be fair, Microsoft did sell that "friggin arcade machine" to you at a loss with the idea that they would make their money back on inflated game prices.
They didn't eat nearly as much as the arcade machine owner you're paying the quarter to.
+1 Funny, +1 Insightful, +1 Inevitable.
Given that YOU paid for the frigging arcade machine already, and YOU paid for the floor space, they should cost *less* to play than Pac Man or Dig Dug. Not more.
So how did they "get used to it" ?The default after downloading a file in IE is, and always has been, "Save".
1. Because Windows is always popping up dialogs with "open" as one of the options, and "open" is usually the option to clock on.
Remember, most people don't use many keyboard shortcuts... I regularly get users going "how do you do that" when I hit tab, return, or space instead of reaching for the mouse. Most people, rather click stuff with the mouse. Especially when they have the mouse in their hand because they'd just clicked on a link they expected to open a new window.
2. More recently, Outlook has been telling them to open attachments in separate applications instead of in Outlook itself, which has been providing even more incentive.
Not even an HTML file?
After *downloading*? To a local file on your disk?
Given the way Windows security zones work, I'd almost say "especially not an HTML file". :)
How the limit is imposed, by Java runtime or by virtual machine, capabilities, SELinux or whatnot is irrelevant in principle.
The higher level it is, the more capable it can be without getting in the way. Implemented at the OS level, the way the article writer is talking about, the conflict between security and convenience is stark. Implemented at the language level, where the language itself contains no mechanism to do anything outside the application domain, it can be highly secure and almost invisible.
Now you're talking about an application level sandbox around untrusted code. That's a good way of redusing the surface area, BUT it's also a completely different kind of animal than the article is talking about. He's talking about OS level sandboxes around the whole application itself.
Yes, you can create a sandbox using a FreeBSD jail, and you can union-mount everything in the jail over a read-only file-system, and you can wipe the jail after every run, and that would be pretty secure. Personally, I run dubious software in a VM and roll back to a checkpoint afterwards.
But then people would be a bit upset that their bookmarks didn't get saved and they couldn't download files. Because most of the software that would need to be sandboxed is the stuff that people use regularly. A *useful* sandbox *has to* be leaky.
Making the application itself simple enough that it doesn't contain any mechanism run content outside its *application level* sandbox (like XPI or ActiveX or "Internet Enabled disk images" ... it seems like every browser these days has SOME kind of stupidity built in) is a much better place to start. AFTER you get that bit right, worry about sandboxing the application itself... because that kind of sandbox is a secondary line of defense at best.
What's gained by having the user traverse a path of directories before opening the file manually, versus having the user explicitly ask for the file to be opened automatically at some later point?
Well, let me explain something. I've been a system and network admin for 20 years. I can't count the number of times that someone has come to me saying "um, I think I clicked the wrong thing and I think I have a virus". What they've done is some link has downloaded a file, and then IE has popped up a dialog asking "do you want to open or save this", and they automatically clicked "open" because that's what they're used to doing. When Microsoft added more stupid security dialogs, they reflexively approved them, because they get those messages all the time, and 99% of the time approving them is the right thing to do.
I used to say that I'd never had someone come up and say "I downloaded a file, and then opened it, again... and I think I have a virus". Now more recently I had ONE person say that. ONE person, in 20 years.
The difference? Clicking "infect me" on a dialog is something people do by reflex. Opening a folder or a download manager, selecting a file, and opening it... that's a deliberate action. People are so much more likely to realize that they shouldn't do this when they come up after the fact, on THEIR schedule, and look at it, and think about it... than when they're hit with just another "hey, I'm about to do something dumb" dialog that they reflexively approve dozens of times a day.
Your users (family members etc.) think they're safe, and want to be wow'ed. They're going to complain if they can't be.
Yes, I had lots of people complaining when I banned IE and Outlook at our division in 1997. Netscape wasn't "wow" enough. When we were the only part of the company that wasn't whacked by the flood of viruses and worms that hit in 1997 and 1998, most of them quit complaining about it. A few did. One contractor sat there and argued with me that he should be an exception to the no-outlook rule... WHILE I WAS CLEANING UP AN INFECTION HE GOT THROUGH OUTLOOK.
So, yeh, they'll say that. I have no sympathy.
When's the last time you downloaded a file and then immediately decided never to open it?
According to my download folder, 16:48 today. The name was "image_2.gif.exe".
What's the point of this? If you send someone an email, they'll get it? God, I hope so! That used to be the norm before spammers poisoned the well.
Sandboxing means that once the attacker has used an input exploit to own the process, it has to perform a privilege escalation exploit to get out of the sandbox. The problem is that applications running in sanboxes have to be able to write files, read files, load and install plugins, execute helper applications, and generally do just about anything a regulat application has to. So the sandbox can't be very "strong".
Instead of adding a leaky sandbox, how about reducing the surface area exposed to attack in the first place? Simplify the application. Get rid of things like XPI in Firefox and ActiveX in IE. Get rid of the need for third party plugins like Java and Flash (HTML5 goes a long way here). Get rid of the ability for network apps to masquerade as local apps (there's no reason a web page should be allowed to remove the status and address bar, for example). Don't even *offer* to automatically open a file after downloading. Remove that option from the browser completely. Get rid of Acrobat and other plug-in document viewers.
Yes, this might make it less convenient for websites to "wow" the user. So what? I'd rather be safe than "wow"ed.
I would take the algorithms course first. I'd suggest taking both of them, since it sounds like you're not doing nearly enough math, but graphs and algorithms are central to so much computer science that it will definitely help to take that one first.
Then there were the calculations that physicists used to reassure the public that another accelerator called RHIC was safe. These too turned out to be seriously flawed.
Can someone elaborate on this comment?
Well first thought is why worry? That's your competition there. [...] Then, when times are lean and projects are scarce the slackers get culled from the herd.
That's the bottom line.