What "lack of backwards compatibility for old apps" are you talking about? WP8 runs WP7 apps just fine. It's a damn good thing it does, too, or there wouldn't have been many launch titles at all (the WP8 SDK was publicly released only at about the same time as the devices themselves).
As a matter of fact, the WP7 "emulator" in the built tools is really just an x86-compiled version of the OS running in a VM. I believe the same of the WP8 "emulator" as well. However, aside from the handful of pieces of assembly and other instruction-set-specific code in the kernels, there's nothing very special about being able to do that. In fact, both CE and NT already had x86 ports, so there's not much special about it at all.
On the other hand, CE and NT are very, very different at higher levels. Although both of them theoretically implement the Win32 API, you'll probably do better porting an app targeting Linux to OpenBSD, or possibly even something more exotic. Yes, they both use POSIX (the same way NT and CE both use Win32) but there's a ton of difference in the details. It may help that NT is close to a superset of CE (porting the reverse direction would be harder) but there's still going to be a fair bit of re-writing involved. CE doesn't really have a concept of user accounts, while they're integral to NT (WP7 had a sort of hacked-together permissions system bolted onto CE, but it bore no resemblance to the NT user account model). WinCE uses a modified FAT filesystem that I'm not even sure there's an NT driver for (it has file modes such as "INROM" which is an indelible read-only attribute, but you can "shadow" the file with a writable one...) while all recent WinNT-based systems use NTFS. CE has a single-rooted filesystem (at least, at the user level) with no drive letters; NTFS has a single-rooted filesystem at the device level, and a DOS-style multi-rooted filesystem at the user level. CE has a bunch of APIs for dealing with things like "CEDB" (CE database) files and mobile functionality, while such things have never been part of NT and would have to either be implemented for it, or the WP7 code that relied on them would have to be re-written. NT drivers and services work differently from CE ones.
I'm sure a lot of code was re-written. Probably nowhere near all of it, but definitely a lot.
While I have no objection to what you stated, I don't understand why you felt the need to state it. It implies that people are trying to prohibit this "whining". Generally, they aren't doing any such thing. They're just calling it out *as* whining. There's absolutely no conflict of free speech there. Individual sites and the WSJ are allowed to publish whatever whining they want, just as others are allowed to point it out as whining. In fact, people are even allowed to call something whining when it isn't! It's not terribly polite of them, but it's permitted.
What is not permitted is actual hate speech, behavior intended to incite violence toward a group, or intentionally cause emotional harm (arguably another form of violence, simply a non-physical one). The "crybaby Republicans" that you and the GP mention are welcome to cry all they like about this policy, and that is their right.
Wow, you got modded up for this?/. groupthink is alive and well, it seems.
A) MS was the *first* to adopt proper CSS. This dates back to the first browser wars, and was a major component of their win over Mozilla. B) IE10, and even IE9, actually support a large portion of the "This site requires Chrome or Safari" pages out there... if you drop the vendor-specific prefixes (webkit-). Most of the time, you don't even have to replace them with Trident-specific ones (ms-) because the standard has already progressed to the point that the browser makers, including MS, have implemented the non-prefixed version. MS *has* adopted "proper CSS and HTML" and are asking developers to stop using *improper* code (using only the webkit- prefixes, and not including either the other vendor-specific prefixes or the unprefixed versions).
IE9 (now a couple years old) passes ACID3... and yet people are still asking whether IE10 passes it, as though the answer to that will prove their argument that IE is standards-noncompliant. They are relics, living in the past and unwilling to face reality. It seems to me a very immature mental posture for supposedly mature minds. Time to grow up.
Source or citation? I see nothing claiming that. There's certainly no technical reason it couldn't be done, though getting the entire browser to run in a low-integrity sandbox apparently has made things difficult for Mozilla. On the other hand, plenty of "third party browsers" for mobile OSes have worked just fine in similar sandboxes; they typically use the platform's built-in rendering engine but as far as I know only iOS mandates that.
In theory, you could publich other browsers to the store. In fact, Mozilla is apparently working on a Windows Store App ("Metro") version of Firefox... but for some reason only for x86. Not sure what's up with that; they know how to do Firefox on ARM but for whatever reason are deciding not too.
Out of curiosity, what do you feel that Desktop on win8 is missing, other than a visible Start button? I've found it to work quite well if I keep using it the way I use Win7, except for the power state controls (which I almost never need). The biggest nuisance to me is the division of the Start search result categories, and that's something I learned to deal with very quickly (an extra keystroke or two).
Re:Innovative companies fail a lot, MSFT included
on
The Empire In Decline?
·
· Score: 1
A laptop, even an "ultrabook" or MBA, is almost always thicker than the Surface and weighs more. Only a few come with touchscreens, which are not *needed* for Win8 but are definitely useful... especially in a device which is designed to be usable as a tablet, not just a laptop. Yeah, the battery life and weight will be inferior to an iPad almost without a doubt, but it *can* be used as a tablet in the iPad sense, as well as in the old convertible laptop sense (stylus support, etc), and also works as a laptop.
At most of 11 inches diagonal, it's definitely not pocketable, but it can be carried under an arm or slipped into any backpack (even one that isn't meant to carry a laptop, or alreayd is carrying one) easily. At least, I'd assume so based on the Surface RT; I obviously haven't had a chance to try carrying arounf a Surface Pro.
Re:Innovative companies fail a lot, MSFT included
on
The Empire In Decline?
·
· Score: 1
Windows Mobile was successful back in the day. MS just rested on their laurels for too long and were caught out by Apple and all.
Bing had (last I checked, which was admittedly about a year ago) a steady year-over-year marketshare growth. Google search is good and is what people are used to, so the transition is slow, but Bing was catching up to it.
I'd put Windows 2000 (NT 5) in before "Windows NT" (which, as an OS name, means v3.1-v4), but as a kernel and OS family, NT has definitely done well. So did DOS though, for far longer than it should have.
By default, both Android and Windows RT are walled (that is, they don't allow "sideloading" where non-app-store apps are installed). In both cases, this default behavior can be changed by the user, easily and officially. Some say it's still a walled garden, others say that the ability to enable sideloading means that it isn't. I don't care much about the terminology; I just want to be able to run my stuff, and in that way both those OSes are fine.
You're mostly right, and Rexdude is mostly wrong. All 32-bit versions of Windows support PAE. Among other things, PAE is required for the NX bit, which is used for Data Execute Prevention (since Windows XP). You can force-disable PAE in the bootloader, but by default it is enabled.
However, the client builds of Windows (as opposed to the server builds) limit the amount of addressable memory to 4GB nonetheless, even though PAE supports more. This restriction is not present in the server builds. The ostensible reason is that Client is much more likely to install older / sketchier drivers, and some drivers expect pointers to be 32 bits and will freak the hell out if they get a 36-bit pointer (where "freak the hell out" typically just means crash, quite possibly with data corruption). Therefore, the client builds' memory manager never exposes more than 4GB. However, since the difference in terms of actual binary kernel code between the client and server OS builds is almost nonexistent, it's a valid argument that the 32-bit limitation is simply by license.
DOSBox is great if it's actually a DOS app, but there were a fairly large number of Win16 apps written, and possibly even more than used Win16 installers but were actually Win32 programs. The first is a pain to use on DOSBox if it's possible at all, and I believe the second is outright impossible.
this add-on is news to me as well. I always thought XP mode meant the compatibility mode. This is more like a XP VM on 7.
That's actually *exactly* what it is. It uses Microsoft's (now discontinued, but still available for Win7) Virtual PC virtualization software to run 32-bit XP in a hidden root window, and then uses the Remote Desktop protocol to forward the windows from XP to Win7 so that you can interact with them and they appear on your Win7 taskbar. Some additional integration takes care of things like adding apps to the Win7 Start Menu when they are installed in the Virtual XP machine.
You can also run the virtual XP machine as a normal VM, with a visible root window and all, if you choose to. This allows you to do things like install OS and software updates (automatic updates are enabled by default, but you may want to mess with that anyhow). Furthermore, you can forward USB ports from the Win7 host to the XP VM. This is great for things like using legacy hardware that doesn't work on Win7.
there is a lot of continuity between NT 3.51 and DOS 2.0
No... no, there really isn't. Unlike the 9x versions of Windows, NT is a complete from-the-ground-up OS that inherits nothing from DOS except for some of its command line syntax. DOS was written largely in assembly, originally entirely 16-bit (starting with Windows 3.11 or so, some stuff was moved to 32-bit; 9x moved the entire kernel to 32-bit but was still a lot of assembly). NT was written almost entirely in C (and heavily portable; the first builds didn't even target x86 explicitly to prevent it from picking up x86-isms during devleopment), 32-bit from the start, and re-uses no part of the DOS codebase in its core. DOS didn't even implement the Win16 API, much less the Win32 one; NT targeted Win32 primarily (with additional support for what amounted to clean-room implementations of POSIX, OS/2, Win16, and DOS). DOS had no scheduler and no real driver model; 16-bit Windows used a cooperative scheduler and simple driver model on top of that but still ran everything in the same address space. NT had a pre-emptive scheduler, process isolation, full driver model, and used separate ring levels for userspace and kernel processes.
You've been fooled by the presence of a compatible ABI in NT (the NTVDM, which ran 16-bit programs in a psuedo-DOS). The two OSes had basically nothing in common; it's debatable whether DOS even qualifies as an OS by modern standards (no scheduler, no real hardware abstraction layer, no process protection, etc.)
Good point on the distinction between server and client side, and the fact that a meaningful cliam is actually being made here (two, really: first that it's possible to get arbitrary code execution on the server, second that it's possible to leverage that into arbitrary code execution on the client).
However, I don't quite buy your argument about updates. The update server is not usually the game server. Compromising a game server doesn't (in theory) let you send an update to the client, much less force them to install it. In practice, it sounds like the game servers have way more control over the connected clients than they should. Especially in the case of games where anybody who wants to can host a game (act as server), connecting to that server absolutely should not expose the client to arbitrary code execution. That's a huge security flaw.
What do you mean, I'm talking about security through obscurity? That makes nothing resembling sense. I certainly didn't suggest that the vuln shouldn't be reported if the researcher doesn't develop an exploit, nor that the developer shouldn't fix it. Some devs won't take a vuln seriously without a PoC, it's true, but that's a failure on their part, not on the researcher's. Some developers don't take security seriously regardless.
I also don't understand why you seem to think that flagging a vuln as probably exploitable is something that requires it be easily exploitable, or where you think I even implied as such. Are you familiar with security testing? You can tell the probable exploitability of a vulnerability by reading a few lines of disassembly, in most cases. Attempt to read a NULL pointer that the attacker cannot control and there's no way for the attacker to have mapped page 0 in this process' memory space? Not exploitable (except for DoS). NX (Data Execute Prevention) violation? Exploitable. Read fail on the instruction pointer at or near 0? Probably exploitable (and can most likely be refined with a bit more research).
My claim was, quite simply, that most people would merely have done the wrok needed to say "yep, looks exploitable, probably arbitrary code execution", flagged the vuln as such, and moved on. The time and effort to develop working exploits, while fun, is rarely cost-effective to a white-hat.
Security would absolutely still be an issue. The scope of an attack might be lower, but the actual threat of compromise would still exit unless they removed the multiplayer funcationity (clients and servers) entirely.
The importance of the remote shell is not that "if you can get arbitrary code execution, you can get a remote shell" (this is pretty much a tautology). The importance is that it demonstrates the possibility of arbitrary code execution at all. A lot of security vulnerabilities are difficult to actually exploit. In most cases, the best that an attacker will ever achieve is denial of service ( a crash, or forced disconnect, or using up all the RAM so the game runs too slowly, or soemthing like that).
Contrary to what the movies would have you believe, actual exploits are (especially in a modern environment full of vulnerability mitigations) very difficult to produce in most cases. Many security researchers don't even bother with that step; it's enough to find the vulnerability and flag it "probably exploitable".
Wow, try switching to a not-complete-shit bank / credit provider. My bank has twice over the last 7 years put a temporary hold on my account after I bout something I don't usually buy in a location I don't usually buy things. One other time it probably would have, but I proactively called ahead and told them that I was going there on vacation, so there was no problem.
Also, they call me, not the other way around, and getting it resolved took about 10 minutes. The list of suspect purchases was short and reasonable, and definitely not things that I had a history of buying.
Your bank is crap. Time to vote with your wallet rather than complaining about it on a tech forum.
Side A wins 51% of the (states/districts/electoral votes) by 1 percent. Side B wins 49% of the same category by a landslide.
Now do you see the problem? This kind of bullshit is why Gerrymandering exists; you district your populations so that the districts you can't possibly win (less than, say, 45% support in the last election) lose all of your supporters, and move those supporters over to other (adjacent) districts that your party actually has a chance at (say, 49% support before). Now, assume everybody votes the same way they did before. The first district still ends up with the same winner-take-all result, but by 80% instead of 55%. The second through nth districts change from one side winning by a little to the other side winning by a little... resuling in a landslide victory (by winner-take-all district) for your party, even though the popular vote is *still* against you.
The only differences at the presidential levels are A) you can't Gerrymander states (not practically), and B) low-population states receive disproportionate votes. A) is dealt with by focusing on appealing to one swing state (very close to an even split) at a time, until you're polling at just over 50% there, and then moving to the next. You don't have to win them all, and you don't have to win them by much at all. B) is the only reason the candidates bother to compaign in the "flyover" states at all, not that which way Colorado or Montana or Idaho were going to break actually impacted anything in this particular election. It sure did in 2000, though. I understand small states have a disproportionate vote, but I still think it's stupid.
Um, HTC bootloaders are officially unlockable on all their Android phones and have been for well over a year now. That's hardly a reason to dislike them now.
Slashdot Mirror
What "lack of backwards compatibility for old apps" are you talking about? WP8 runs WP7 apps just fine. It's a damn good thing it does, too, or there wouldn't have been many launch titles at all (the WP8 SDK was publicly released only at about the same time as the devices themselves).
As a matter of fact, the WP7 "emulator" in the built tools is really just an x86-compiled version of the OS running in a VM. I believe the same of the WP8 "emulator" as well. However, aside from the handful of pieces of assembly and other instruction-set-specific code in the kernels, there's nothing very special about being able to do that. In fact, both CE and NT already had x86 ports, so there's not much special about it at all.
On the other hand, CE and NT are very, very different at higher levels. Although both of them theoretically implement the Win32 API, you'll probably do better porting an app targeting Linux to OpenBSD, or possibly even something more exotic. Yes, they both use POSIX (the same way NT and CE both use Win32) but there's a ton of difference in the details. It may help that NT is close to a superset of CE (porting the reverse direction would be harder) but there's still going to be a fair bit of re-writing involved. CE doesn't really have a concept of user accounts, while they're integral to NT (WP7 had a sort of hacked-together permissions system bolted onto CE, but it bore no resemblance to the NT user account model). WinCE uses a modified FAT filesystem that I'm not even sure there's an NT driver for (it has file modes such as "INROM" which is an indelible read-only attribute, but you can "shadow" the file with a writable one...) while all recent WinNT-based systems use NTFS. CE has a single-rooted filesystem (at least, at the user level) with no drive letters; NTFS has a single-rooted filesystem at the device level, and a DOS-style multi-rooted filesystem at the user level. CE has a bunch of APIs for dealing with things like "CEDB" (CE database) files and mobile functionality, while such things have never been part of NT and would have to either be implemented for it, or the WP7 code that relied on them would have to be re-written. NT drivers and services work differently from CE ones.
I'm sure a lot of code was re-written. Probably nowhere near all of it, but definitely a lot.
While I have no objection to what you stated, I don't understand why you felt the need to state it. It implies that people are trying to prohibit this "whining". Generally, they aren't doing any such thing. They're just calling it out *as* whining. There's absolutely no conflict of free speech there. Individual sites and the WSJ are allowed to publish whatever whining they want, just as others are allowed to point it out as whining. In fact, people are even allowed to call something whining when it isn't! It's not terribly polite of them, but it's permitted.
What is not permitted is actual hate speech, behavior intended to incite violence toward a group, or intentionally cause emotional harm (arguably another form of violence, simply a non-physical one). The "crybaby Republicans" that you and the GP mention are welcome to cry all they like about this policy, and that is their right.
Why are you implying that people think otherwise?
Wow, you got modded up for this? /. groupthink is alive and well, it seems.
A) MS was the *first* to adopt proper CSS. This dates back to the first browser wars, and was a major component of their win over Mozilla.
B) IE10, and even IE9, actually support a large portion of the "This site requires Chrome or Safari" pages out there... if you drop the vendor-specific prefixes (webkit-). Most of the time, you don't even have to replace them with Trident-specific ones (ms-) because the standard has already progressed to the point that the browser makers, including MS, have implemented the non-prefixed version. MS *has* adopted "proper CSS and HTML" and are asking developers to stop using *improper* code (using only the webkit- prefixes, and not including either the other vendor-specific prefixes or the unprefixed versions).
IE9 (now a couple years old) passes ACID3... and yet people are still asking whether IE10 passes it, as though the answer to that will prove their argument that IE is standards-noncompliant. They are relics, living in the past and unwilling to face reality. It seems to me a very immature mental posture for supposedly mature minds. Time to grow up.
Win7 has BitLocker in Enterprise and Ultimate, and Encrypting File System in Pro (same as Vista, if you s/Pro/Business/).
Win8 has BitLocker and EFS in both Pro and Enterprise (there is no Ultimate).
Windows RT has BitLocker but not EFS.
Source or citation? I see nothing claiming that. There's certainly no technical reason it couldn't be done, though getting the entire browser to run in a low-integrity sandbox apparently has made things difficult for Mozilla. On the other hand, plenty of "third party browsers" for mobile OSes have worked just fine in similar sandboxes; they typically use the platform's built-in rendering engine but as far as I know only iOS mandates that.
In theory, you could publich other browsers to the store. In fact, Mozilla is apparently working on a Windows Store App ("Metro") version of Firefox... but for some reason only for x86. Not sure what's up with that; they know how to do Firefox on ARM but for whatever reason are deciding not too.
Out of curiosity, what do you feel that Desktop on win8 is missing, other than a visible Start button? I've found it to work quite well if I keep using it the way I use Win7, except for the power state controls (which I almost never need). The biggest nuisance to me is the division of the Start search result categories, and that's something I learned to deal with very quickly (an extra keystroke or two).
A laptop, even an "ultrabook" or MBA, is almost always thicker than the Surface and weighs more. Only a few come with touchscreens, which are not *needed* for Win8 but are definitely useful... especially in a device which is designed to be usable as a tablet, not just a laptop. Yeah, the battery life and weight will be inferior to an iPad almost without a doubt, but it *can* be used as a tablet in the iPad sense, as well as in the old convertible laptop sense (stylus support, etc), and also works as a laptop.
At most of 11 inches diagonal, it's definitely not pocketable, but it can be carried under an arm or slipped into any backpack (even one that isn't meant to carry a laptop, or alreayd is carrying one) easily. At least, I'd assume so based on the Surface RT; I obviously haven't had a chance to try carrying arounf a Surface Pro.
Windows Mobile was successful back in the day. MS just rested on their laurels for too long and were caught out by Apple and all.
Bing had (last I checked, which was admittedly about a year ago) a steady year-over-year marketshare growth. Google search is good and is what people are used to, so the transition is slow, but Bing was catching up to it.
I'd put Windows 2000 (NT 5) in before "Windows NT" (which, as an OS name, means v3.1-v4), but as a kernel and OS family, NT has definitely done well. So did DOS though, for far longer than it should have.
I have mod points but have lready posted in this thread, so I can't do it myself. That's a very interesting (and quite short) article, though.
TL;DR version: Distribution is modest (only in a few regions), but device is well received.
By default, both Android and Windows RT are walled (that is, they don't allow "sideloading" where non-app-store apps are installed). In both cases, this default behavior can be changed by the user, easily and officially. Some say it's still a walled garden, others say that the ability to enable sideloading means that it isn't. I don't care much about the terminology; I just want to be able to run my stuff, and in that way both those OSes are fine.
You're mostly right, and Rexdude is mostly wrong. All 32-bit versions of Windows support PAE. Among other things, PAE is required for the NX bit, which is used for Data Execute Prevention (since Windows XP). You can force-disable PAE in the bootloader, but by default it is enabled.
However, the client builds of Windows (as opposed to the server builds) limit the amount of addressable memory to 4GB nonetheless, even though PAE supports more. This restriction is not present in the server builds. The ostensible reason is that Client is much more likely to install older / sketchier drivers, and some drivers expect pointers to be 32 bits and will freak the hell out if they get a 36-bit pointer (where "freak the hell out" typically just means crash, quite possibly with data corruption). Therefore, the client builds' memory manager never exposes more than 4GB. However, since the difference in terms of actual binary kernel code between the client and server OS builds is almost nonexistent, it's a valid argument that the 32-bit limitation is simply by license.
DOSBox is great if it's actually a DOS app, but there were a fairly large number of Win16 apps written, and possibly even more than used Win16 installers but were actually Win32 programs. The first is a pain to use on DOSBox if it's possible at all, and I believe the second is outright impossible.
this add-on is news to me as well. I always thought XP mode meant the compatibility mode. This is more like a XP VM on 7.
That's actually *exactly* what it is. It uses Microsoft's (now discontinued, but still available for Win7) Virtual PC virtualization software to run 32-bit XP in a hidden root window, and then uses the Remote Desktop protocol to forward the windows from XP to Win7 so that you can interact with them and they appear on your Win7 taskbar. Some additional integration takes care of things like adding apps to the Win7 Start Menu when they are installed in the Virtual XP machine.
You can also run the virtual XP machine as a normal VM, with a visible root window and all, if you choose to. This allows you to do things like install OS and software updates (automatic updates are enabled by default, but you may want to mess with that anyhow). Furthermore, you can forward USB ports from the Win7 host to the XP VM. This is great for things like using legacy hardware that doesn't work on Win7.
there is a lot of continuity between NT 3.51 and DOS 2.0
No... no, there really isn't. Unlike the 9x versions of Windows, NT is a complete from-the-ground-up OS that inherits nothing from DOS except for some of its command line syntax. DOS was written largely in assembly, originally entirely 16-bit (starting with Windows 3.11 or so, some stuff was moved to 32-bit; 9x moved the entire kernel to 32-bit but was still a lot of assembly). NT was written almost entirely in C (and heavily portable; the first builds didn't even target x86 explicitly to prevent it from picking up x86-isms during devleopment), 32-bit from the start, and re-uses no part of the DOS codebase in its core. DOS didn't even implement the Win16 API, much less the Win32 one; NT targeted Win32 primarily (with additional support for what amounted to clean-room implementations of POSIX, OS/2, Win16, and DOS). DOS had no scheduler and no real driver model; 16-bit Windows used a cooperative scheduler and simple driver model on top of that but still ran everything in the same address space. NT had a pre-emptive scheduler, process isolation, full driver model, and used separate ring levels for userspace and kernel processes.
You've been fooled by the presence of a compatible ABI in NT (the NTVDM, which ran 16-bit programs in a psuedo-DOS). The two OSes had basically nothing in common; it's debatable whether DOS even qualifies as an OS by modern standards (no scheduler, no real hardware abstraction layer, no process protection, etc.)
By $100, you of course mean $40? Pro edition (with Ultimate SKUs discontinued, it's now basically the highest client version) and digital download.
http://windows.microsoft.com/en-us/windows/buy?ocid=GA8_O_MSCOM_Prog_FPP_Null_Null
Good point on the distinction between server and client side, and the fact that a meaningful cliam is actually being made here (two, really: first that it's possible to get arbitrary code execution on the server, second that it's possible to leverage that into arbitrary code execution on the client).
However, I don't quite buy your argument about updates. The update server is not usually the game server. Compromising a game server doesn't (in theory) let you send an update to the client, much less force them to install it. In practice, it sounds like the game servers have way more control over the connected clients than they should. Especially in the case of games where anybody who wants to can host a game (act as server), connecting to that server absolutely should not expose the client to arbitrary code execution. That's a huge security flaw.
What do you mean, I'm talking about security through obscurity? That makes nothing resembling sense. I certainly didn't suggest that the vuln shouldn't be reported if the researcher doesn't develop an exploit, nor that the developer shouldn't fix it. Some devs won't take a vuln seriously without a PoC, it's true, but that's a failure on their part, not on the researcher's. Some developers don't take security seriously regardless.
I also don't understand why you seem to think that flagging a vuln as probably exploitable is something that requires it be easily exploitable, or where you think I even implied as such. Are you familiar with security testing? You can tell the probable exploitability of a vulnerability by reading a few lines of disassembly, in most cases. Attempt to read a NULL pointer that the attacker cannot control and there's no way for the attacker to have mapped page 0 in this process' memory space? Not exploitable (except for DoS). NX (Data Execute Prevention) violation? Exploitable. Read fail on the instruction pointer at or near 0? Probably exploitable (and can most likely be refined with a bit more research).
My claim was, quite simply, that most people would merely have done the wrok needed to say "yep, looks exploitable, probably arbitrary code execution", flagged the vuln as such, and moved on. The time and effort to develop working exploits, while fun, is rarely cost-effective to a white-hat.
Security would absolutely still be an issue. The scope of an attack might be lower, but the actual threat of compromise would still exit unless they removed the multiplayer funcationity (clients and servers) entirely.
The importance of the remote shell is not that "if you can get arbitrary code execution, you can get a remote shell" (this is pretty much a tautology). The importance is that it demonstrates the possibility of arbitrary code execution at all. A lot of security vulnerabilities are difficult to actually exploit. In most cases, the best that an attacker will ever achieve is denial of service ( a crash, or forced disconnect, or using up all the RAM so the game runs too slowly, or soemthing like that).
Contrary to what the movies would have you believe, actual exploits are (especially in a modern environment full of vulnerability mitigations) very difficult to produce in most cases. Many security researchers don't even bother with that step; it's enough to find the vulnerability and flag it "probably exploitable".
Wow, try switching to a not-complete-shit bank / credit provider. My bank has twice over the last 7 years put a temporary hold on my account after I bout something I don't usually buy in a location I don't usually buy things. One other time it probably would have, but I proactively called ahead and told them that I was going there on vacation, so there was no problem.
Also, they call me, not the other way around, and getting it resolved took about 10 minutes. The list of suspect purchases was short and reasonable, and definitely not things that I had a history of buying.
Your bank is crap. Time to vote with your wallet rather than complaining about it on a tech forum.
Side A wins 51% of the (states/districts/electoral votes) by 1 percent.
Side B wins 49% of the same category by a landslide.
Now do you see the problem? This kind of bullshit is why Gerrymandering exists; you district your populations so that the districts you can't possibly win (less than, say, 45% support in the last election) lose all of your supporters, and move those supporters over to other (adjacent) districts that your party actually has a chance at (say, 49% support before). Now, assume everybody votes the same way they did before. The first district still ends up with the same winner-take-all result, but by 80% instead of 55%. The second through nth districts change from one side winning by a little to the other side winning by a little... resuling in a landslide victory (by winner-take-all district) for your party, even though the popular vote is *still* against you.
The only differences at the presidential levels are A) you can't Gerrymander states (not practically), and B) low-population states receive disproportionate votes.
A) is dealt with by focusing on appealing to one swing state (very close to an even split) at a time, until you're polling at just over 50% there, and then moving to the next. You don't have to win them all, and you don't have to win them by much at all.
B) is the only reason the candidates bother to compaign in the "flyover" states at all, not that which way Colorado or Montana or Idaho were going to break actually impacted anything in this particular election. It sure did in 2000, though. I understand small states have a disproportionate vote, but I still think it's stupid.
That is absolutely the "with new two-year contract" price. Amazon actually sells a ton of phones that way.
Um, HTC bootloaders are officially unlockable on all their Android phones and have been for well over a year now. That's hardly a reason to dislike them now.