Oh, don't be a fool. They didn't use Hotmail to send that barrage of spam; that's stupid and trivially blockable. All they needed was the contact list and the email address that those contacts would expect to receive mail from, plus an SMTP server somewhere. In fact, using Microsoft's server would be idiotic, since it would make it easy for them to flag the abuse and (if they cared) track it back to the originating client.
Non-root access makes it more difficult to hide the infection, or cause it to resist deletion (rootkit). However, it's entirely possible for malware to obtain root access with your unknowing cooperation.
1. In a writable, executable location (the user folder works, on most Linux installs), install a program (a script would probably work) called "sudo". 2. Modify the user's profile so that, at login, either their PATH now includes the location fo that sudo, or "sudo" becomes an alias for the malware version. 3. Wait until the user tries to do something as root. 4. Steal the credentials they type into "sudo" and store them. 5. Pass along the credentials to the real sudo program, so the user doesn't know anything went wrong. 6. Install rootkit with your new access to root permissions!
While you're at it, do the same with su and kdesu and whatever the graphical privilege-elevation-credential-prompt programs are for other desktop environments.
Yep. Comparing kernels to kernels, you'd look at NT vs. Linux. Comparing OS distribution to OS distribution, you'd look at Win7 vs. Ubuntu-10.10 (or Server 2008 R2 vs. RHEL $VERSION, or whatever). I'm not going to claim that all of Microsoft's code is so portable, but the kernel (including graphics system), core libraries, and shell of the Windows OS certainly are.
Psh, wow, idiotic MS-bashing ahoy! They've screwed up plenty of things, but portability of the OS is not one of them.
It's been policy, thoughout the entire NT project, to maintain a non-x86 port specificlaly to avoid letting non-portable code in. In the early days it was Alpha, then also things like MIPS and PPC, then Itanium (which, say what you will about it, is extremely far from x86 despite coming from the same company). With MS dropping Itanium support, they moved to ARM as the alternate platform. Then of course there's AMD64, which doesn't even really count (being basically an extension of x86) but does still mean that they can't even make 32-bit assumptions.
Also, I hate to tell you, but you're completely off-base about "Linux was written from the ground up... with portability in mind." Portability has certainly become a major feature of the Linux kernel in the last few decades, but when it was started it was exclusively focused on the 386. http://en.wikipedia.org/wiki/Linux_kernel Read the text of the comp.os.minix post, and the section under Portability. By comparison, the initial development of the NT kernel explicitly did *not* target x86. http://en.wikipedia.org/wiki/Windows_NT#32-bit_platforms
Actually, you're completely wrong. Not because the real-time scan would have caught the exploit applet at first (although any decent antivirus has now had the definition for all known variants for a few weeks) but because this malware explicitly targets people who don't give a damn about their computer's security.
The drive-by download's payload is an installer. Before it installs the botnet kit, the installer checks the filesystem for a list of security programs, including antivirus software. If it find any, it aborts the install and erases itself.
Security-conscious people are more likely to detect the malware earlier and raise a fuss. The longer you go undetected, the more money you earn (and botnets - in fact, almost all widespread malware - is about making money).
Your last line confuses me, badly. I mean, WC2 was fun (for its time), but SC was a much better game (getting off the tile-based movement system, getting away from two damn-near-identical races, adding more sequence to the campaign, a deeper tech tree with more upgrade levels to allow you to prioritize resource spending more broadly, and so on) and also supported much better online play (though they eventually added Battle.Net support to WC2). WC3 was a different *kind* of RTS, but it was still an excellent one in its own right, sold exceptionally well, and its heavily customizable maps and surprisingly versatile game engine led to some incredible "mods"... such as DotA, which has spawned an entire new genre.
That said, I'm no fan of SC2. Its gameplay is good, if nothin particularly exciting, but the mandatory use of Battle.Net is inexcusable to me. That's the third RTS that Blizzard release post-WC2 though, so I'd be curious what you thought was wrong with the other two...
I'm not sure why HoN (Heroes of Newerth, by S2 Games) was left off this list... it started out as actual DotA clone, and has diverged slightly but is still played by the same mechanics. Unlike LoL, which has never been more than like DotA than, say, WarCraft 2 was like StarCraft, a DotA player will immediately be able to play HoN even if using one of the new heroes (with no more difficulty than they would have playing a new hero on DotA).
I get that LoL is popular (though I truly can't understand why; the concept of flat-out bonuses to some players just because they've played more in a competitive multiplayer environment is abhorrent) but HoN is doing quite well for itself and certainly is bigger than DotA 2 (still in beta of course, but listing DotA 2 and not HoN seems weird).
It's changed dramatically. The idea used to be that new items had differen tradeoffs, and that if you didn't have them then you were more or less even on power with those who did. You lacked versatility and flexibility, perhaps (to use a medic example, there are times when crits are more important than invulnerability) but in theory the items were balanced against eachother. Additionally, the items didn't tremendously change the classes - each was still more-or-less played the same way (medic heals, soldier shoots rockets, demo shoots gravity-sensitive explosives, engineer builds turrets, etc.).
Now, that's all been thrown out. There are now weapons, or sets of gear (including hat), that are flat-out upgrades without drawbacks. There are new classes (effectively; kits of gear that alter pretty much everything about a given class) that, although perhaps not strictly better than the other ones, offer completely new gameplay options.
While I'm not opposed to a game evolving over time, I find TF2's changes to be unacceptable, and an excellent example of how to fuck up a game (regardless of F2P or not). Of course, I can't return it (yes, I paid for it, back when it cost money) or resell it, so I've taken a different approach: Valve doesn't get any of my money anymore. I've played DotA 2 (a friend gave me a key) but even if it ever replaces HoN in my preferred list of DotA-like games, I won't spend a cent on it. The last game I bought on Steam was... Mass Effect 2, maybe? I don't even redeem the Steam keys for Humble Bundle games; why would I want DRM added to my currently DRM-free games?
We're actually looking into HaRET for WP7. It's hard, both due to the sandboxing of apps (it took us a while to figure out how to use homebrew native code at all, and even then it had very limited permissions initially) and due to the changes in the WP7 kernel from WinMo (part of which is the aforementioned permissions system, but WP7 also removed some APIs that the HaRET launcher uses).
The idea with ChevronWP7 Labs was exactly what you and the post above you suggested: a way for developers to try running their apps on the phone, before buying the Marketplace account. Apparently, this didn't work; while the interest in WP7 homebrew was immense, apparently very few people converted to Marketplace developers over the time of the "experiment".
There are a rew things you should know about WP7 development. First of all, the dev tools are free (OK, they require a copy of Windows). It will integrate with a full Visual Studio if you have it, but the SDK download includes Visual Studio Express and a limited version of Expression Blend (a tool for designing Silverlight GUIs). Second, the dev tools include an "emulator" (actually a VM running an x86 version of WP7 with some virtualized phone hardware features). You can install and test your apps (including with attached debugger) on this emulator without even owning a WP7 device, much less dev-unlocking it.
I understand that Microsoft wants to focus on Marketplace development. That's where the direct money for them is, and it's also an important statistic to wave in the faces of those who claim there are no apps for Windows Phone (totally untrue; there are fewer apps than on iOS or Android, but there are still a large number of them covering nearly every use case that the APIs permit). However, they need to stop trying to shut down homebrew in their quest to get more Marketplace development... especially in light of how much more you can do with homebrew than with only the official APIs.
It depends on your definition of "still running" but yes, the WP7 kernel is a variant of CE. It's a huge change from previous versions, though - they've added a permissions and accounts system, removed a number of old APIs like SetKMode, re-written the memory manager (it now uses something much more akin to a desktop OS, removing the per-app RAM limits and such), changed the application model (blocking third-party EXEs, changing the way apps launch, and more), and generally yanked it into the 21st century rather abruptly. If you target Compact Embedded 7 APIs, you can generally do pretty good WP7 native code development (yes, it's possible to do native development on WP7; even sometimes to get it approved on the Marketplace).
Win7 is NT based. WP7 is CE based (for loose values of CE; it's a radical overhaul of that kernel). Win8 is NT based. WP8 is rumored to also be NT based, but there's nothing official yet.
The branding on Windows Phone is retarded, but that's no excuse to confuse [PC] Windows (NT-based) and WP7 (currently CE-based). They're completely unrelated. There may be *some* convergence in Win8, but even on ARM (tablets and such), Win8 will still be very different from Windows Phone (which is also on ARM, but uses a different UI, different app model, different APIs, has different hardware specs.... you get the idea).
While I agree with part of what you say (the WinMo back-compat being killed, the abandonment of some enterprise features even though they included some anyhow), you're just pretty much wrong about the app developers thing. BTW, I'm one of the first Recognized Developers on the WP7 section of XDA-Devs.
ChevronWP7 (Labs or otherwise) wasn't useful for Marketplace developers (who would have already had developer-unlock through their developer accounts), it was used by people who wanted to install non-Marketplace apps. Microsoft, for reasons completely unclear to me, appears to be very anti-homebrew in WP7, and the people who care about that but don't care about developing official apps are the people hurt by the ChevronWP7 Labs fiasco. Everybody else, both those who don't care about unsigned apps at all (the vast majority of users) and those who develop (or even think they might at some point develop) apps for the Marketplace, are unaffected.
That's not to say Microsoft isn't being stupid here, because they really are. ChevronWP7 Labs was late, was too limited, and is now being discontinued... all for cheaper access to a built-in-but-paywalled feature of the OS (although iOS seems to do just fine without any equivalent feature at all...). Homebrew development was one of the things that kept WinMo alive as long as it was. The interop-lock in Mango blocked access to a bunch of apps that implemented unofficial but badly needed features, ranging from the superficial but highly in-demand (custom themes) to the critical (the ability to migrate app data and message history between phones).
I will also say that the article you linked contains a fair bit of senseless foaming at the mouth. Things like questioning how you'll be reimbursed for the free year of AppHub (it's a credit on the credit card you used to sign up, just like every other time Microsoft reimburses a cost) and claiming that WinMo was "immensely popular" (in any timespan even vaguely relevant to WP7, that's just not true) suggest an author whose frustration is overriding rational thought.
As of 2010, Adobe Reader was kicking Preview's ass on security. No, that's not a joke. Nor is it fanboyism; I don't use either one. It's just a plain and simple fact. The probable reason? Adobe, like Microsoft, has had many years of being a high-profile target, and has put a lot of effort into finding and fixing security bugs. Apple, quite frankly, has not.
For the lazy, here's the basic facts: Preview had from the same set of 1400 PDFs downloaded from the web, run through a mutational fuzzer to produce 2.8 million test files. Preview had 7 times as many unique crashes as Adobe Reader, and at least 3 times (more realistically, probably 10 times; at worst, 20 times) as many exploitable bugs.
When a guy like Charlie Miller (very well-respected security researcher) can find 7 security bugs in Apple's code for each one he finds in Adobe's (using the exact same test cases), Apple has a serious security problem.
Absolutely! Unless you pre-purchased a support plan that extends beyond the "about 9 years" you mention, your manufacturer is probably under no obligation in any way to fix your car. In fact, they're not even under any obligation to accept money from you to fix your car (nor is Microsoft, although they will in fact continue supporting outdated OSs if you pay them enough). As for the recall, that's not required either, no. It might be economically wise (as it, "end up costing less than the lawsuits and loss of business") but I'm not aware of any law that would compel them to do so.
Personal anecdote: I couldn't find anybody who was willing to fix some damage to my 1990 Subaru Legacy. It's not that it wasn't fixable, it's just that they literally couldn't find the required part. Even ignoring that the cost would have been greater than the insurance value of the car, I literally couldn't find any shop in the area that would take my money to do it, because the car has been out of production for so long that the wrecking yards had even sold off all their working copies of that part.
Also, a car analogy here is stupid, despite Slashdot tradition. A car is quite reasonably expected to run for at least a decade and usually much longer if treated well. The manufacture and maintenance of them is a practice well over a century in age. The rate of improvements in them, despite your "all better than mine, probably safer and with more features" comment, is really quite minor year-over-year. None of those things are true of desktop operating systems. Additionally, my 22-year-old car still ran on pretty much the same "hardware" (internal combustion of gasoline, asphault-paved roads, etc.) today as it was designed to do over two decades ago. These days, sub-$500 new computers come with too much RAM for XP to even address all of it!
Because Computer Science requires math, and "math is hard" or so young girls are taught (and pressured implicitly to believe by many of their peers).
Programming is a field that developed in the aftermath of World War 2. During the war, so many men were off toting rifles and such that women were, by necessity, introduced into the workforce in large numbers. This includes both the "human computers" who performed (without electronic assistance) the calculations that are today done electronically, and the "programmers" (to use the modern term) who were responsible for much of the operation of early electronic computers.
That was in the 40s, though. Feminism in general gained steam throughout the next few decades, driven in part by the wartime revelation that women were perfectly capable of both keeping the economy productive. Women asserted that they could run things, make money, wield power, and so forth - and they were, and are, right.
Here's the catch, though: while many women will self-identify as "feminists" (at least if asked; the term has unfortunately picked up some negative connotations of "female > male" sexism), they still don't want to give and receive the same treatment as guys. For example, you're still not going to meet many women who will buy a guy in a bar a drink, uninvited, just because she thinks he's attractive (girls are taught by their friends how to *get* free drinks). You're also not going to find many who are willing to put up with the social consequences of caring more about finishing an AP Computer Science assignment than going shopping for another pair of shoes with their friends.
At least, that's how it is in the US. Yes, women are taught that they can do whatever they want, and be whatever they want... but they're also taught that what they *should* want is popularity, and that it's more popular to be bad at STEM than good at it! India and China seem to have much less of a problem with this, but I'm only viewing that from a distance so I may be mistaken.
Wait, how the hell did this get modded up? At no point did the GP state or even imply that he (or she, but relevant gender-neutral pronouns are awkward to nonexistent in English) wanted to say "nigger", nor did he state that there's any situation which calls for it. You came closest with "does it just bother you that it's taboo" except you're still wrong, because your statement is factually incorrect.
It's taboo for a certain segment of the population, and not for another.
That's called, quite simply, a double standard. It's a common concept in racism (of all kinds; if you think being racist is a white thing exclusively, you need to see a lot more of the world, especially places where whites are the minority). It's wrong; it is a large part of the problem of racism in general. It is a societally-accepted method of creating significance to what should be an insignificant distinction.
Somehow, you managed to completely miss that point. I'm not entirely sure how...
OK, all that said, you do actually raise some good points. I am personally against the *concept* of a taboo word, even one that is applied equally. If black people calling eachother "nigger" is a way to ease the term into common usage, that's fine by me. I have no intention of ever using it except in a discussion about the word itself, but I take objection to the idea that I should be univerally prohibited from uttering it for *any* reason. It is perfectly acceptable to state that its use as an insult or derogatory epithet is prohibited, provided that the prohibition is against the concept of insulting people, not the concept of speking a specific sequence of phonemes.
Here's the catch, though: if black people were generally OK with being called "nigger" then the work would honestly be losing its negative connotations, as you suggest it should. However, when a black person is only OK with being called "nigger" by another black person regardless of the context or intent of usage, that becomes racism itself, by definition. That is what you should be calling for, if you want to solve the problem: black people being OK with being called "nigger" by anybody, not black people using "nigger" to refer to other black people.
For a parallel, consider the word "gay" which is still (and in my opinion, just as inexcusably) used derogatively. The distinction is that gay people (not some nebulous "I have lots of gay friends" but people like my roommate last year, some of his boyfriends, my 7th-grade teacher, a local politician who I met with in person, and so on) don't have a problem with being described as, or even directly called, "gay". They object if it's used as an insult, of course. They do not, however, give a damn about the orientation of the speaker. This has, I believe, directly helped keep "gay" from ever becoming nearly so loaded a word as "nigger"; we discuss "gay marriage" whereas discussion of blacks and white marrying used terms like "mixed marriage" instead, for example.
Wow, you're wrong (or at least misleading) on a number of points. Let's break them down...
Default Windows installs (for all modern values of "Windows") block those ports at the firewall. There is software listening on them behind the firewall, yes, but the same is true of things like the X11 server on most Linux installs.
There's nothing magical about the security of repositories, they're simply a source you trust for your software. Similar sources exist on Windows too. Access to one of them is even built into the OS (ever wondered why it was called "Add/Remove Programs"?), though nobody short of major coporations seems to use it.
Many Linux distros still do not include strong ASLR, although it has been available on Linux since before it was available on Windows.
The.EXE file extension (or any file extension) is neither sufficient nor required on Windows to make a file executable. Windows includes Execute as a file permission, just like *nix. File extensions are simply used to determine the default action taken when the user requests to "open" a file. That said... you pretty much still win this one, because Windows defaults to setting execute permissions on all files. The only other roadblock is the "mark of the web" which downloaded files get, and cause that "This file could damage your computer!" warning when you try an execute a downloaded file. Linux has no equivalent, but I'm not going to pretend that this feature provides more security than making files non-executable by default.
Windows certainly allows setting file and folder permissions. The group policy you speak of is not how you actually secure a system, it's how you restrict a user experience. Some graphical file managers on Linux hve similar features (hiding the system folders by default and showing you your user folder as the "root" of the filesystem, for example) believe it or not.
Actually, there are significant vulnerabilities in the wild for Android. Yes, they're local EOP, but with the way that the Android Market ("Google Play", LOL) is run, any little "super-uber flashlite!" app could also be containing exploit code.
Don't beleive me? Go look around the XDA-Developers forum. Go read about "gaining root" on various Android devices. Android apps don't run as root normally, and it's not supposed to be possible to run third-party code as root. However, if you want to remove the crap that comes pre-installed on many phones, or you want to install a custom OS, you typically need to get root first.
True story: when my roommate wanted to put CyanogenMod (custom ROM) on his Droid, he downloaded a tool to root it (required step). Microsoft Security Essentials initially blocked the download, claiming it contained a known EoP exploit (for Linux).
Just because Linux gets patches quickly doesn't mean it doesn't mean that security vulnerabilities in it don't get found and published. If the phone had been running an up-to-date version of Linux, the exploit wouldn't have worked. On the other hand, if the phone had been receiving updates on the stock ROM, one of the major reasons for rooting it wouldn't have existed...
FYI, WP7 was not "rooted" immediately after release. All that happened (I assume you're referring to the ChevronWP7 Unlocker hack, here) was a way was found to enble a built-in feature of the OS (sideloading unsigned applications, instead of installing them from the Marketplace) without paying Microsoft for the privilege of being able to do this. Developer-unlocking was neither unavailable in the OS, nor gave anywhere close to full permissions. It just cost money.
Now, there are some ways that a sideloaded app can gain permissions which Microsoft tries to prevent. For example, many OEMs shipped drivers with their phones that allow calling a few APIs (such as file access or registry writing) with high permissions. Although sideloaded apps run with the same low permissions as Marketplace apps, a sideloaded app that specifies a certain capability in its manifest can call into those drivers and use them for limited high-privilege access. In response, Microsoft restricted the use of that capability on sideloaded apps (Mango's "interop-lock", named after the relevant ID_CAP_INTEROPSERVICES capability).
Speaking as somebody with some experience in the underlying security model of WP7, there are a few misconceptions that should be cleared up.
First of all, legacy versions of CE don't have any kind of "multi-user" security. Starting with WP7 (and also in CE7, where the WP7 kernel is somewhere between CE6 and CE7), that's not really true anymore. Apps now have security identifiers (SIDs) that correspond to "accounts" on the phone. I use quotes because these aren't user accounts - it's still a single-user OS - but are better described as "sandbox accounts" or, to use Microsoft's terminology, "chambers". Securable resources on the phone - filesystem, registry, drivers, APIs, and so on - are permitted only to certain chambers.
The major difference betwen the chamber model and the user model is that there's no inheritence of permissions. On a multi-user OS (NT, OS X, Linux, etc.) a high-privilege ("root" for simplicity, though it's actually SYSTEM on NT, for example) process presents a login UI, the user enters their credentials, and the root process then spawns a new process (typically a shell) running with that user's account SID. The shell then spawns additional processes, each of which (by default) inherit the shell's SID. WP7 does things differently. When a user-mode process is created, it is automatically routed to a chamber (SID) determined by the full path of the binary. If the full path isn't found in the policy database (which controls routing, among other things), the CreateProcess call (analogous to fork, very similar to the Win32 CreateProcess call, yes it's a C API, and yes you can call those in WP7 apps if you know how) will fail with an error indicating that the policy for that program can't be found.
When WP7 apps are installed, a new very-low-permission account is created. This account is created in the "Least Privileged Chamber" (LPC) group, which provides some default permissions: Read-only access to the Windows folder (for system resources). Read-only access to parts of the registry (for things like the current theme color, file associations, and so on). Access to a few basic devices, like the display. The new account then also receives additional permissions that are determined by the app's manifest: Read-only access to the app's unique install folder (path includes a GUID used to ID the app). Read-write access to the app's IsolatedStorage folder (also includes the GUID). Access to additional devices, locations, and APIs depending on the "capabilities" specified in the manifest: ID_CAP_NETWORKING - socket APIs. ID_CAP_FILEVIEWER - read/write the temp folder where downloaded files go. ID_CAP_IDENTITY_USER - get a unique ID that corresponds to the user's Windows Live account (one-way mapping). ID_CAP_SENSORS - access the accelerometer and gyro and such. and so on.
Of course, none of this really answers the OP's question, which is "how secure is WP7?" To that, I can't give a good answer. There are a number of known but minor security holes in the design - for example, the LPC registry read permissions are fairly permissive - but it requires explicit permission from Microsoft to use native APIs at all (in a Marketplace app; homebrew apps use them all the time), and there are no managed APIs for things like registry access. There are also certainly true security vulnerabilities in the phone - one of Samsung's drivers had a buffer overflow that could be used for EoP by any app that could access the driver (ID_CAP_INTEROPSERVICES, which was subsequently restricted from use by homebrew apps), for example - but if there's one thing Microsoft has learned from all its years of being the security community's puching bag, it's that secure APIs, security code review, and pen-testing are all very important. Their record has been much better the last few years.
Finestra is my preferred option - it has most of the features you mention (not sure about #3), plus a few:
* Sticky windows
* The ability to automatically put spawned windows onto a specific desktop
* A "switcher" view that shows all virtual desktops by shrinking them to fit on one desktop, and allows you to reorganize windows there
* Numerous ways to represent (and switch) virtual desktops from he taskbar
Additionally, it's free/open source (not sure how many of the others are too; I haven't used VirtuaWin for example): http://vdm.codeplex.com/
Especially when you consider that aircraft have limited access to Antarctica. The weather down there frequently prevents landings / takeoffs, sometimes for quite extended periods. Satellite telephone (Iridium) can be used, but it's very low-bandwidth. Beyond that, though, they're cut off when aircraft can't get through.
Gah... upper right. My bad, sorry. The gear icon is labeled "Preferences" on mouseover. Mind you, this advice only works for the real MSDN documentation / reference stuff, not the new "Dev Center" BS.
It's still there. Switch to Classic reading mode - it's in the upper left, and may be obscured behind a gear-shaped icon, but it's there. The new modes are simpler and render better on mobile browsers, but the classis MSDN is still available for those who find it familiar and useful.
Slashdot Mirror
Oh, don't be a fool. They didn't use Hotmail to send that barrage of spam; that's stupid and trivially blockable. All they needed was the contact list and the email address that those contacts would expect to receive mail from, plus an SMTP server somewhere. In fact, using Microsoft's server would be idiotic, since it would make it easy for them to flag the abuse and (if they cared) track it back to the originating client.
Non-root access makes it more difficult to hide the infection, or cause it to resist deletion (rootkit). However, it's entirely possible for malware to obtain root access with your unknowing cooperation.
1. In a writable, executable location (the user folder works, on most Linux installs), install a program (a script would probably work) called "sudo".
2. Modify the user's profile so that, at login, either their PATH now includes the location fo that sudo, or "sudo" becomes an alias for the malware version.
3. Wait until the user tries to do something as root.
4. Steal the credentials they type into "sudo" and store them.
5. Pass along the credentials to the real sudo program, so the user doesn't know anything went wrong.
6. Install rootkit with your new access to root permissions!
While you're at it, do the same with su and kdesu and whatever the graphical privilege-elevation-credential-prompt programs are for other desktop environments.
Yep. Comparing kernels to kernels, you'd look at NT vs. Linux. Comparing OS distribution to OS distribution, you'd look at Win7 vs. Ubuntu-10.10 (or Server 2008 R2 vs. RHEL $VERSION, or whatever). I'm not going to claim that all of Microsoft's code is so portable, but the kernel (including graphics system), core libraries, and shell of the Windows OS certainly are.
Psh, wow, idiotic MS-bashing ahoy! They've screwed up plenty of things, but portability of the OS is not one of them.
It's been policy, thoughout the entire NT project, to maintain a non-x86 port specificlaly to avoid letting non-portable code in. In the early days it was Alpha, then also things like MIPS and PPC, then Itanium (which, say what you will about it, is extremely far from x86 despite coming from the same company). With MS dropping Itanium support, they moved to ARM as the alternate platform. Then of course there's AMD64, which doesn't even really count (being basically an extension of x86) but does still mean that they can't even make 32-bit assumptions.
Also, I hate to tell you, but you're completely off-base about "Linux was written from the ground up ... with portability in mind." Portability has certainly become a major feature of the Linux kernel in the last few decades, but when it was started it was exclusively focused on the 386. http://en.wikipedia.org/wiki/Linux_kernel Read the text of the comp.os.minix post, and the section under Portability. By comparison, the initial development of the NT kernel explicitly did *not* target x86. http://en.wikipedia.org/wiki/Windows_NT#32-bit_platforms
Actually, you're completely wrong. Not because the real-time scan would have caught the exploit applet at first (although any decent antivirus has now had the definition for all known variants for a few weeks) but because this malware explicitly targets people who don't give a damn about their computer's security.
The drive-by download's payload is an installer. Before it installs the botnet kit, the installer checks the filesystem for a list of security programs, including antivirus software. If it find any, it aborts the install and erases itself.
Security-conscious people are more likely to detect the malware earlier and raise a fuss. The longer you go undetected, the more money you earn (and botnets - in fact, almost all widespread malware - is about making money).
Your last line confuses me, badly. I mean, WC2 was fun (for its time), but SC was a much better game (getting off the tile-based movement system, getting away from two damn-near-identical races, adding more sequence to the campaign, a deeper tech tree with more upgrade levels to allow you to prioritize resource spending more broadly, and so on) and also supported much better online play (though they eventually added Battle.Net support to WC2). WC3 was a different *kind* of RTS, but it was still an excellent one in its own right, sold exceptionally well, and its heavily customizable maps and surprisingly versatile game engine led to some incredible "mods"... such as DotA, which has spawned an entire new genre.
That said, I'm no fan of SC2. Its gameplay is good, if nothin particularly exciting, but the mandatory use of Battle.Net is inexcusable to me. That's the third RTS that Blizzard release post-WC2 though, so I'd be curious what you thought was wrong with the other two...
I'm not sure why HoN (Heroes of Newerth, by S2 Games) was left off this list... it started out as actual DotA clone, and has diverged slightly but is still played by the same mechanics. Unlike LoL, which has never been more than like DotA than, say, WarCraft 2 was like StarCraft, a DotA player will immediately be able to play HoN even if using one of the new heroes (with no more difficulty than they would have playing a new hero on DotA).
I get that LoL is popular (though I truly can't understand why; the concept of flat-out bonuses to some players just because they've played more in a competitive multiplayer environment is abhorrent) but HoN is doing quite well for itself and certainly is bigger than DotA 2 (still in beta of course, but listing DotA 2 and not HoN seems weird).
It's changed dramatically. The idea used to be that new items had differen tradeoffs, and that if you didn't have them then you were more or less even on power with those who did. You lacked versatility and flexibility, perhaps (to use a medic example, there are times when crits are more important than invulnerability) but in theory the items were balanced against eachother. Additionally, the items didn't tremendously change the classes - each was still more-or-less played the same way (medic heals, soldier shoots rockets, demo shoots gravity-sensitive explosives, engineer builds turrets, etc.).
Now, that's all been thrown out. There are now weapons, or sets of gear (including hat), that are flat-out upgrades without drawbacks. There are new classes (effectively; kits of gear that alter pretty much everything about a given class) that, although perhaps not strictly better than the other ones, offer completely new gameplay options.
While I'm not opposed to a game evolving over time, I find TF2's changes to be unacceptable, and an excellent example of how to fuck up a game (regardless of F2P or not). Of course, I can't return it (yes, I paid for it, back when it cost money) or resell it, so I've taken a different approach: Valve doesn't get any of my money anymore. I've played DotA 2 (a friend gave me a key) but even if it ever replaces HoN in my preferred list of DotA-like games, I won't spend a cent on it. The last game I bought on Steam was... Mass Effect 2, maybe? I don't even redeem the Steam keys for Humble Bundle games; why would I want DRM added to my currently DRM-free games?
We're actually looking into HaRET for WP7. It's hard, both due to the sandboxing of apps (it took us a while to figure out how to use homebrew native code at all, and even then it had very limited permissions initially) and due to the changes in the WP7 kernel from WinMo (part of which is the aforementioned permissions system, but WP7 also removed some APIs that the HaRET launcher uses).
The idea with ChevronWP7 Labs was exactly what you and the post above you suggested: a way for developers to try running their apps on the phone, before buying the Marketplace account. Apparently, this didn't work; while the interest in WP7 homebrew was immense, apparently very few people converted to Marketplace developers over the time of the "experiment".
There are a rew things you should know about WP7 development. First of all, the dev tools are free (OK, they require a copy of Windows). It will integrate with a full Visual Studio if you have it, but the SDK download includes Visual Studio Express and a limited version of Expression Blend (a tool for designing Silverlight GUIs). Second, the dev tools include an "emulator" (actually a VM running an x86 version of WP7 with some virtualized phone hardware features). You can install and test your apps (including with attached debugger) on this emulator without even owning a WP7 device, much less dev-unlocking it.
I understand that Microsoft wants to focus on Marketplace development. That's where the direct money for them is, and it's also an important statistic to wave in the faces of those who claim there are no apps for Windows Phone (totally untrue; there are fewer apps than on iOS or Android, but there are still a large number of them covering nearly every use case that the APIs permit). However, they need to stop trying to shut down homebrew in their quest to get more Marketplace development... especially in light of how much more you can do with homebrew than with only the official APIs.
It depends on your definition of "still running" but yes, the WP7 kernel is a variant of CE. It's a huge change from previous versions, though - they've added a permissions and accounts system, removed a number of old APIs like SetKMode, re-written the memory manager (it now uses something much more akin to a desktop OS, removing the per-app RAM limits and such), changed the application model (blocking third-party EXEs, changing the way apps launch, and more), and generally yanked it into the 21st century rather abruptly. If you target Compact Embedded 7 APIs, you can generally do pretty good WP7 native code development (yes, it's possible to do native development on WP7; even sometimes to get it approved on the Marketplace).
Win7 is NT based.
WP7 is CE based (for loose values of CE; it's a radical overhaul of that kernel).
Win8 is NT based.
WP8 is rumored to also be NT based, but there's nothing official yet.
The branding on Windows Phone is retarded, but that's no excuse to confuse [PC] Windows (NT-based) and WP7 (currently CE-based). They're completely unrelated. There may be *some* convergence in Win8, but even on ARM (tablets and such), Win8 will still be very different from Windows Phone (which is also on ARM, but uses a different UI, different app model, different APIs, has different hardware specs.... you get the idea).
While I agree with part of what you say (the WinMo back-compat being killed, the abandonment of some enterprise features even though they included some anyhow), you're just pretty much wrong about the app developers thing. BTW, I'm one of the first Recognized Developers on the WP7 section of XDA-Devs.
ChevronWP7 (Labs or otherwise) wasn't useful for Marketplace developers (who would have already had developer-unlock through their developer accounts), it was used by people who wanted to install non-Marketplace apps. Microsoft, for reasons completely unclear to me, appears to be very anti-homebrew in WP7, and the people who care about that but don't care about developing official apps are the people hurt by the ChevronWP7 Labs fiasco. Everybody else, both those who don't care about unsigned apps at all (the vast majority of users) and those who develop (or even think they might at some point develop) apps for the Marketplace, are unaffected.
That's not to say Microsoft isn't being stupid here, because they really are. ChevronWP7 Labs was late, was too limited, and is now being discontinued... all for cheaper access to a built-in-but-paywalled feature of the OS (although iOS seems to do just fine without any equivalent feature at all...). Homebrew development was one of the things that kept WinMo alive as long as it was. The interop-lock in Mango blocked access to a bunch of apps that implemented unofficial but badly needed features, ranging from the superficial but highly in-demand (custom themes) to the critical (the ability to migrate app data and message history between phones).
I will also say that the article you linked contains a fair bit of senseless foaming at the mouth. Things like questioning how you'll be reimbursed for the free year of AppHub (it's a credit on the credit card you used to sign up, just like every other time Microsoft reimburses a cost) and claiming that WinMo was "immensely popular" (in any timespan even vaguely relevant to WP7, that's just not true) suggest an author whose frustration is overriding rational thought.
As of 2010, Adobe Reader was kicking Preview's ass on security. No, that's not a joke. Nor is it fanboyism; I don't use either one. It's just a plain and simple fact. The probable reason? Adobe, like Microsoft, has had many years of being a high-profile target, and has put a lot of effort into finding and fixing security bugs. Apple, quite frankly, has not.
http://net-security.org/secworld.php?id=9725
Watch the second video, and jump ahead to 8:57 (almost the end) if you want a simple comparison.
For the lazy, here's the basic facts: Preview had from the same set of 1400 PDFs downloaded from the web, run through a mutational fuzzer to produce 2.8 million test files. Preview had 7 times as many unique crashes as Adobe Reader, and at least 3 times (more realistically, probably 10 times; at worst, 20 times) as many exploitable bugs.
When a guy like Charlie Miller (very well-respected security researcher) can find 7 security bugs in Apple's code for each one he finds in Adobe's (using the exact same test cases), Apple has a serious security problem.
Absolutely! Unless you pre-purchased a support plan that extends beyond the "about 9 years" you mention, your manufacturer is probably under no obligation in any way to fix your car. In fact, they're not even under any obligation to accept money from you to fix your car (nor is Microsoft, although they will in fact continue supporting outdated OSs if you pay them enough). As for the recall, that's not required either, no. It might be economically wise (as it, "end up costing less than the lawsuits and loss of business") but I'm not aware of any law that would compel them to do so.
Personal anecdote: I couldn't find anybody who was willing to fix some damage to my 1990 Subaru Legacy. It's not that it wasn't fixable, it's just that they literally couldn't find the required part. Even ignoring that the cost would have been greater than the insurance value of the car, I literally couldn't find any shop in the area that would take my money to do it, because the car has been out of production for so long that the wrecking yards had even sold off all their working copies of that part.
Also, a car analogy here is stupid, despite Slashdot tradition. A car is quite reasonably expected to run for at least a decade and usually much longer if treated well. The manufacture and maintenance of them is a practice well over a century in age. The rate of improvements in them, despite your "all better than mine, probably safer and with more features" comment, is really quite minor year-over-year. None of those things are true of desktop operating systems. Additionally, my 22-year-old car still ran on pretty much the same "hardware" (internal combustion of gasoline, asphault-paved roads, etc.) today as it was designed to do over two decades ago. These days, sub-$500 new computers come with too much RAM for XP to even address all of it!
Because Computer Science requires math, and "math is hard" or so young girls are taught (and pressured implicitly to believe by many of their peers).
Programming is a field that developed in the aftermath of World War 2. During the war, so many men were off toting rifles and such that women were, by necessity, introduced into the workforce in large numbers. This includes both the "human computers" who performed (without electronic assistance) the calculations that are today done electronically, and the "programmers" (to use the modern term) who were responsible for much of the operation of early electronic computers.
That was in the 40s, though. Feminism in general gained steam throughout the next few decades, driven in part by the wartime revelation that women were perfectly capable of both keeping the economy productive. Women asserted that they could run things, make money, wield power, and so forth - and they were, and are, right.
Here's the catch, though: while many women will self-identify as "feminists" (at least if asked; the term has unfortunately picked up some negative connotations of "female > male" sexism), they still don't want to give and receive the same treatment as guys. For example, you're still not going to meet many women who will buy a guy in a bar a drink, uninvited, just because she thinks he's attractive (girls are taught by their friends how to *get* free drinks). You're also not going to find many who are willing to put up with the social consequences of caring more about finishing an AP Computer Science assignment than going shopping for another pair of shoes with their friends.
At least, that's how it is in the US. Yes, women are taught that they can do whatever they want, and be whatever they want... but they're also taught that what they *should* want is popularity, and that it's more popular to be bad at STEM than good at it! India and China seem to have much less of a problem with this, but I'm only viewing that from a distance so I may be mistaken.
Wait, how the hell did this get modded up? At no point did the GP state or even imply that he (or she, but relevant gender-neutral pronouns are awkward to nonexistent in English) wanted to say "nigger", nor did he state that there's any situation which calls for it. You came closest with "does it just bother you that it's taboo" except you're still wrong, because your statement is factually incorrect.
It's taboo for a certain segment of the population, and not for another.
That's called, quite simply, a double standard. It's a common concept in racism (of all kinds; if you think being racist is a white thing exclusively, you need to see a lot more of the world, especially places where whites are the minority). It's wrong; it is a large part of the problem of racism in general. It is a societally-accepted method of creating significance to what should be an insignificant distinction.
Somehow, you managed to completely miss that point. I'm not entirely sure how...
OK, all that said, you do actually raise some good points. I am personally against the *concept* of a taboo word, even one that is applied equally. If black people calling eachother "nigger" is a way to ease the term into common usage, that's fine by me. I have no intention of ever using it except in a discussion about the word itself, but I take objection to the idea that I should be univerally prohibited from uttering it for *any* reason. It is perfectly acceptable to state that its use as an insult or derogatory epithet is prohibited, provided that the prohibition is against the concept of insulting people, not the concept of speking a specific sequence of phonemes.
Here's the catch, though: if black people were generally OK with being called "nigger" then the work would honestly be losing its negative connotations, as you suggest it should. However, when a black person is only OK with being called "nigger" by another black person regardless of the context or intent of usage, that becomes racism itself, by definition. That is what you should be calling for, if you want to solve the problem: black people being OK with being called "nigger" by anybody, not black people using "nigger" to refer to other black people.
For a parallel, consider the word "gay" which is still (and in my opinion, just as inexcusably) used derogatively. The distinction is that gay people (not some nebulous "I have lots of gay friends" but people like my roommate last year, some of his boyfriends, my 7th-grade teacher, a local politician who I met with in person, and so on) don't have a problem with being described as, or even directly called, "gay". They object if it's used as an insult, of course. They do not, however, give a damn about the orientation of the speaker. This has, I believe, directly helped keep "gay" from ever becoming nearly so loaded a word as "nigger"; we discuss "gay marriage" whereas discussion of blacks and white marrying used terms like "mixed marriage" instead, for example.
Wow, you're wrong (or at least misleading) on a number of points. Let's break them down...
Default Windows installs (for all modern values of "Windows") block those ports at the firewall. There is software listening on them behind the firewall, yes, but the same is true of things like the X11 server on most Linux installs.
There's nothing magical about the security of repositories, they're simply a source you trust for your software. Similar sources exist on Windows too. Access to one of them is even built into the OS (ever wondered why it was called "Add/Remove Programs"?), though nobody short of major coporations seems to use it.
Many Linux distros still do not include strong ASLR, although it has been available on Linux since before it was available on Windows.
The .EXE file extension (or any file extension) is neither sufficient nor required on Windows to make a file executable. Windows includes Execute as a file permission, just like *nix. File extensions are simply used to determine the default action taken when the user requests to "open" a file. That said... you pretty much still win this one, because Windows defaults to setting execute permissions on all files. The only other roadblock is the "mark of the web" which downloaded files get, and cause that "This file could damage your computer!" warning when you try an execute a downloaded file. Linux has no equivalent, but I'm not going to pretend that this feature provides more security than making files non-executable by default.
Windows certainly allows setting file and folder permissions. The group policy you speak of is not how you actually secure a system, it's how you restrict a user experience. Some graphical file managers on Linux hve similar features (hiding the system folders by default and showing you your user folder as the "root" of the filesystem, for example) believe it or not.
Actually, there are significant vulnerabilities in the wild for Android. Yes, they're local EOP, but with the way that the Android Market ("Google Play", LOL) is run, any little "super-uber flashlite!" app could also be containing exploit code.
Don't beleive me? Go look around the XDA-Developers forum. Go read about "gaining root" on various Android devices. Android apps don't run as root normally, and it's not supposed to be possible to run third-party code as root. However, if you want to remove the crap that comes pre-installed on many phones, or you want to install a custom OS, you typically need to get root first.
True story: when my roommate wanted to put CyanogenMod (custom ROM) on his Droid, he downloaded a tool to root it (required step). Microsoft Security Essentials initially blocked the download, claiming it contained a known EoP exploit (for Linux).
Just because Linux gets patches quickly doesn't mean it doesn't mean that security vulnerabilities in it don't get found and published. If the phone had been running an up-to-date version of Linux, the exploit wouldn't have worked. On the other hand, if the phone had been receiving updates on the stock ROM, one of the major reasons for rooting it wouldn't have existed...
FYI, WP7 was not "rooted" immediately after release. All that happened (I assume you're referring to the ChevronWP7 Unlocker hack, here) was a way was found to enble a built-in feature of the OS (sideloading unsigned applications, instead of installing them from the Marketplace) without paying Microsoft for the privilege of being able to do this. Developer-unlocking was neither unavailable in the OS, nor gave anywhere close to full permissions. It just cost money.
Now, there are some ways that a sideloaded app can gain permissions which Microsoft tries to prevent. For example, many OEMs shipped drivers with their phones that allow calling a few APIs (such as file access or registry writing) with high permissions. Although sideloaded apps run with the same low permissions as Marketplace apps, a sideloaded app that specifies a certain capability in its manifest can call into those drivers and use them for limited high-privilege access. In response, Microsoft restricted the use of that capability on sideloaded apps (Mango's "interop-lock", named after the relevant ID_CAP_INTEROPSERVICES capability).
Speaking as somebody with some experience in the underlying security model of WP7, there are a few misconceptions that should be cleared up.
First of all, legacy versions of CE don't have any kind of "multi-user" security. Starting with WP7 (and also in CE7, where the WP7 kernel is somewhere between CE6 and CE7), that's not really true anymore. Apps now have security identifiers (SIDs) that correspond to "accounts" on the phone. I use quotes because these aren't user accounts - it's still a single-user OS - but are better described as "sandbox accounts" or, to use Microsoft's terminology, "chambers". Securable resources on the phone - filesystem, registry, drivers, APIs, and so on - are permitted only to certain chambers.
The major difference betwen the chamber model and the user model is that there's no inheritence of permissions. On a multi-user OS (NT, OS X, Linux, etc.) a high-privilege ("root" for simplicity, though it's actually SYSTEM on NT, for example) process presents a login UI, the user enters their credentials, and the root process then spawns a new process (typically a shell) running with that user's account SID. The shell then spawns additional processes, each of which (by default) inherit the shell's SID. WP7 does things differently. When a user-mode process is created, it is automatically routed to a chamber (SID) determined by the full path of the binary. If the full path isn't found in the policy database (which controls routing, among other things), the CreateProcess call (analogous to fork, very similar to the Win32 CreateProcess call, yes it's a C API, and yes you can call those in WP7 apps if you know how) will fail with an error indicating that the policy for that program can't be found.
When WP7 apps are installed, a new very-low-permission account is created. This account is created in the "Least Privileged Chamber" (LPC) group, which provides some default permissions:
Read-only access to the Windows folder (for system resources).
Read-only access to parts of the registry (for things like the current theme color, file associations, and so on).
Access to a few basic devices, like the display.
The new account then also receives additional permissions that are determined by the app's manifest:
Read-only access to the app's unique install folder (path includes a GUID used to ID the app).
Read-write access to the app's IsolatedStorage folder (also includes the GUID).
Access to additional devices, locations, and APIs depending on the "capabilities" specified in the manifest:
ID_CAP_NETWORKING - socket APIs.
ID_CAP_FILEVIEWER - read/write the temp folder where downloaded files go.
ID_CAP_IDENTITY_USER - get a unique ID that corresponds to the user's Windows Live account (one-way mapping).
ID_CAP_SENSORS - access the accelerometer and gyro and such.
and so on.
Of course, none of this really answers the OP's question, which is "how secure is WP7?" To that, I can't give a good answer. There are a number of known but minor security holes in the design - for example, the LPC registry read permissions are fairly permissive - but it requires explicit permission from Microsoft to use native APIs at all (in a Marketplace app; homebrew apps use them all the time), and there are no managed APIs for things like registry access. There are also certainly true security vulnerabilities in the phone - one of Samsung's drivers had a buffer overflow that could be used for EoP by any app that could access the driver (ID_CAP_INTEROPSERVICES, which was subsequently restricted from use by homebrew apps), for example - but if there's one thing Microsoft has learned from all its years of being the security community's puching bag, it's that secure APIs, security code review, and pen-testing are all very important. Their record has been much better the last few years.
Finestra is my preferred option - it has most of the features you mention (not sure about #3), plus a few:
* Sticky windows
* The ability to automatically put spawned windows onto a specific desktop
* A "switcher" view that shows all virtual desktops by shrinking them to fit on one desktop, and allows you to reorganize windows there
* Numerous ways to represent (and switch) virtual desktops from he taskbar
Additionally, it's free/open source (not sure how many of the others are too; I haven't used VirtuaWin for example): http://vdm.codeplex.com/
Especially when you consider that aircraft have limited access to Antarctica. The weather down there frequently prevents landings / takeoffs, sometimes for quite extended periods. Satellite telephone (Iridium) can be used, but it's very low-bandwidth. Beyond that, though, they're cut off when aircraft can't get through.
Gah... upper right. My bad, sorry. The gear icon is labeled "Preferences" on mouseover. Mind you, this advice only works for the real MSDN documentation / reference stuff, not the new "Dev Center" BS.
It's still there. Switch to Classic reading mode - it's in the upper left, and may be obscured behind a gear-shaped icon, but it's there. The new modes are simpler and render better on mobile browsers, but the classis MSDN is still available for those who find it familiar and useful.
Just FYI, you can easily install both Android and WP7 (and also Maemo/Meego and Ubuntu) on an HD2. Most versatile smartphone I know of.
http://forum.xda-developers.com/index.php