Which explains exactly *what* of relevance to geekoid's link? I mean, did you even look at it? It's a game, a big-budget currently-supported game, not made by Microsoft or Sony, that you can play on Linux PCs (not consoles)...
There are lots of others, too. For example, I play HoN (a DotA clone from the days before DotA2; I still prefer it over DotA2); they have a native Linux client. A bunch of Humble Bundle games have been released, those have Linux versions.
That's even leaving aside things like Wine, and so on. I've been gaming on Linux since 2006. It's not always as polished an experience as on Windows, but lately it's been getting very good.
Pretty sure Microsoft will only shut down the Nokia handset manufacturing (there's more to Nokia than that, but I don't have a handy name for it like "Motorola Mobility") if they decide to abandon the smartphone OS business entirely. Which they could do, admittedly, but I'd be surprised. They've achieved a pretty solid third place in the market, with an overall marketshare similar to that of OS X among PCs. They've started being taken more seriously by major app developers. They're rolling out updates at a decent rate, and many of the crippling issues of the app model in WP7 are already fixed.
That doesn't mean they won't spin off or re-sell that portion of the business, of course. I'd be surprised if they just killed it though, unless they want to give up on phone OSes entirely. There are at least three other OEMs making WP8 handsets (HTC, Samsung, and Huawei), but the Nokia Lumia line predominates.
Much more than 90 days. Even with top implants and neural mapping, I don't think you can hit all the skill pre-reqs for a titan in under half a year, and probably longer (disclosure: I've been playing much longer than you have, but I stick to sub-capitals). Unlike subcaps, where the progression is pretty simple (spaceship command - frigate - destroyer - cruiser - battlecruiser - battleship), capitals throw a whole bunch of additional requirements in there. You need jump drive training (which means training a handful of the Navigation skills pretty high). You need advanced spaceship command, which is basically great big speed bump between subcaps and caps. I forget if you need the superweapon skills just to pilot a titan or not, but if so, get ready to train a whole bunch of pre-reqs for that too. Etc, etc. And that's just to get in the ship at all. To actually use it, you'll spend months to reach even the point where you can mount its guns, much less use them effectively. You'll need a few months just to get the basic core competency skills maxed out, because there's no way you can afford to give up a 2% edge in something. You'll need to max the gunnery support skills so you have a chance of taking out a heavy interdictor tackling you, the navigation skills so you can actually get to the battle with everybody else, the rigging skills so you can fit the tech-2 rigs you'd be insane not to use on a ship so expensive, the repair skills to be able to keep the thing intact in battle, and so much more.
Being *ready* to fly a titan - that is, having the character skills required to actually be a competitive titan pilot - is probably at least two years of training.
Sad, but true. It has a definite "slowly being boiled" feel to it. What would once have been beyond the pale is now supposed to make us feel happy, because it's better than what we had yesterday...
NVidia drivers? Those are the only things that have caused random-bluescreen-while-gaming for me in the last seven years, from Vista through Win8 (well, my Win8 machines don't use NV drivers, but I've had no problems on AMD or Intel yet, not that I use the tablet for much gaming). The sad thing is, due tot he way WDDM works, the driver has to crash *really* badly to actually cause a bluescreen - usually it just makes the screen go black for a second, then come back as the user-mode portion of the driver gets restarted. I lost count of the number of times that happened - multiple times per day, often, though - back in 2007, but only on my NVidia machine, and a coupel times the driver crashed again while (or immediately after) "recovery" at which point you will get a bluescreen. They eventually released a driver update that reduced it to an every-other-year kind of issue, but still...
There are at least here other active smartphone platforms out there...
Windows Phone: probably not something the poster would consider, and while some of the WP7 models had hardware keyboards I don't think any WP8 ones do, so the hardware and OS would be nearly as obsolescent anyhow. Hackability, on the other hand... Well, a WP7 device with a suitably modified custom ROM might almost work, but it won't be Linux. Most WP8 devices don't have much in the way of hacks at all. If you were to go this route, the phone I would recommend is the HTC 7 Pro / HTC Arrive (same thing really, once just being a CDMA variant) - good hardware keyboard, custom ROM support, outdated but still better specs than the N900.
Blackberry: best bet for a hardware keyboard, and you can get relatively modern hardware for cheap from them, but I don't know how you feel about the company. Hackability is a question, though; I don't know how hard it is to get at their guts, but it's probably not easy. A valid option if you just want a decent hardware-keyboard-equipped smartphone, but otherwise probably not a great option. Not sure what model would suit best.
Jolla Sailfish: still in development and arguably not yet release-ready. The obvious advantage here is the Maemo roots underpinning the Sailfish OS; from a Linux-user/tinkerer point of view, it's probably the closest option for an N900 successor. "Politically" speaking, it's probably the best option as well. Currently you'd need to give up the hardware keyboard, though. That should change, and probably quite soon, but it's too early to say for sure how well Jolla will be able to iterate on their product. It's a cool idea, though!
Yes, I'm aware that all three of those, combined, have *maybe* 10% of the global smartphone marketshare. Oh well. Your claim of "only other choice" is still wrong.
10% isn't strong? WP is edging towards that worldwide, and has beaten it in several markets. It's the #3 spot right now, easily beating Blackberry (former #3).
Well, neither does Microsoft, so I fail to see how that's a difference...
Developer registration for a phone (enables sideloading) is free, and has been for months. Before that, it cost $20 (still the cost to get a developer account that lets you submit apps to the store). Before *that*, it cost $99, but that was some time ago...
With that said, by default, Windows Phone does restrict the number of apps you can sideload at once (given the rampant piracy on Android, their POV is understandable even if annoying). Some phone have hacks to remove this restriction.
Care to give an alternative way that Manning could have "spilled the secrets" only to enfranchised American voters? Because otherwise, your supposed counterpoint is null.
Are you a Russian? I'm not. He gave me plenty of information... If you can list a way he could have released his information to the US as a whole without also letting it be seen by the Russians (who are opponents of ours on multiple political issues, but not our enemies by any stretch of the definition) then I will grant there is *some* point to what you said. Otherwise, it's complete bullshit.
Also, as others have pointed out, he did try going through proper channels. He was told to drop it. How high did you expect him to go, and what good did you expect it to do? The president himself has expressed support for the NSA's programs *and* branded Snowden a criminal *before* he took asylum in Russia, so that part of your argument is bullshit. Enough members of congress have said (or voted in favor of) much the same things that I doubt it would do much good to have gone to them, either. With the heads of the executive and legislative branches complicit in this travesty, Snowden *did* go over their heads: to the people who elect those scum. We, the citizens of these United States of America.
So, I ask you again: how was Snowden supposed to reveal the information to We The People, without also revealing it to our "enemies"? (If you wanted to pick examples of enemies, you could do much better than Russia).
Um, no. You're falling into exactly the kind of stupid traps of "doing this better" that I described above. The whole idea is terrible and should never be attempted.
When the user signs in, generate a cryptographically strong random identifier to use as a session token. 128 bits is pretty much standard here (practically speaking, brute-forcing even 64 bits online is quite impractical, but the birthday paradox means you may hit *somebody* by accident much faster than seems possible). Store, on the server side, the mapping of that identifier to that user. When the user signs out or their session expires, delete that mapping and the identifier. If the user already has an identifier when they make a request, but it's not currently in the mapping dictionary, ignore/delete it. Don't ever re-use the mapping; make it different any time any user logs in.
Yes, this is more expensive for a server cluster than decrypting a cookie, assuming there are lots of concurrent users. However, it's got a critically important advantage: there is literally no possible way for an attacker to forge a session cookie. No information about the web app that they could have, save for the state of the server's/dev/urandom or its cache of logged-in users, could aid them. The best they could possibly hope for is to steal or to stumble upon one while it is in use. Given reasonable protections on the token and a short expiry period, this should be practically impossible barring client-side malware (in which case that particular client is already hosed, since the malware can just steal their credentials as they are typed in, and everything else of value on their computer to boot).
Even then, there's a ton of other vulnerabilities that must be avoided. For example, protecting that token is of course vitally important. The Secure and HttpOnly flags are a good start, although Client Security Policy is even better than HttpOnly (on clients which support it). Make the whole site accessible only over HTTPS, of course, and use HTTP Strict Transport Security to require that (compliant) user-agents never visit the site over HTTP. Permit only the most recent versions of TLS (1.0 may be permitted for legacy browsers; anything older is a bad idea) and only use strong cipher suites (ideally with Perfect Forward Secrecy). Include protections against Cross-Site Request Forgery in the form of an anti-CSRF token that is, at a minimum, unique per-user (and not based on or derivable from any value stored in a cookie or any user information). If you want to be really paranoid, you can do things like include the user's IP address in their token mapping, so that if their IP changes their token gets invalidated immediately and they must log in again (this will occasionally annoy legit users, but a site like this will have a very short session timeout anyhow).
There's a ton more than that (protecting the credentials is an area I haven't even touched on, aside from the crypto). It's a hard space, and even the experts miss things sometimes. Assuming you have the answers (or worse, can figure them out) is a dangerous hole to fall into! This is why companies like mine exist...
How do you know it hasn't been? It's not like some Chinese black hat would issue a press release claiming what had been done in that case. Instead, the information would be sat on for a while to distance its release from the slight bump in traffic when the actual breach occurred. Then it would be farmed out, quietly, to third parties looking to engage in identity theft and such. They in turn would probably take it slow; too big a glut of that kind of activity is not only sure to be noticed, it drives down prices (did you see the article a few days ago about how the Target crackers came away with more CC #s than they could sell?). Then there's the timeline to notice the attacks themselves, which wouldn't be terribly fast; identity theft isn't exactly as noticeable as, say, armed robbery. It might not even be as obvious as unexpected charges on your credit card. Many people go their entire lives without ever directly checking their own credit rating...
In any case, there are other possible reasons. Maybe the attackers are waiting for the intense scrutiny of the site to die down, so they can do it when nobody is looking. Maybe the last time they tried the site was down and they're waiting for it to become more stable. Hell, they might even be a bit concerned about the retaliation of the federal government for going after such a target. You are talking about a crime (and one for which US law permits extremely harsh sentences), after all, and the arm of American "justice" is much longer than its national borders might imply.
Yep. I see this all the time. Sometimes it's a little more subtle, though. Like, say, storing that value in a cookie. Most people never look at their cookies, but a web security expert (on either side) is more likely to see the cookies than they are to see the actual site rendering. Or the value might be something that in the abstract is impossible to guess (like 59340341412091985) but if you happen to know your SSN and your birthdate, you might recognize those values in that 17-digit mess (it's even easier if, for example, there's a | character between the parts) and then you can (relatively easily) start guessing other peoples' pairs.
Sometimes it's even more subtle and requires some actual work to get at it, like storing an ID value concatenated with some other garbage like the date in a cookie encrypted with a static key (this one is actually fairly commonly done as a method of generating a token *identifying* the authenticated session, after all, if you don't have the key you can't generate the authentication token, right?). However, if you can guess which bits of that token are the ID (not hard; they're the ones that are the same whenever a given account signs on, but different for every account) you can twiddle the bits and basically brute-force the search space of valid IDs. There are still many ways to make this at least *somewhat* harder to attack, but a lot of developers won't bother... and there are ways to do it *worse*, too, like using an XOR with a constant mask instead of a merely re-using the key with a real cipher.
Also, they had to know a priori this was going to be a *huge* target (no pun intended). Whether for the treasure trove of neatly collected data or a simple political agenda (doesn't even need to be a partisan one; lots of people who voted for Obama hate the ACA and healthcare.gov), it should have been obvious from the very beginning that the scrutiny of this site for security vulnerabilities would be far greater than most, and the costs (to the site developers) of an attacker exploiting one far more severe. Under those circumstances, business-as-usual things like PCI DSS and such should have looked like nothing. They should have hired an entire internal security team to oversee the development of the site starting from the design phase*, and an external penetration testing team to verify it at least once by now.
* Tacking security onto a design that is inherently insecure is expensive and often futile, just as is true of many other kinds of software bugs. Of course, if they'd designed competently in the first place, maybe the site wouldn't already be a laughingstock...
I'm not personally familiar with the database they're using, but it's worth noting that injection attacks work on some noSQL databases too. It all depends on how the data is added and accessed; any language (for even very loosely defined values of "language") that fails to clearly distinguish instructions from data risks the latter being interpreted as the former.
Sure they would. Not all of them, true, but most. That's not to say they'd be perfect, but they would certainly have done better. Banking websites, despite often having stupid legacy requirements like 8-character passwords or relatively weak SSL ciphers, are routinely designed with vastly better security than is being described here. That's for their own sites; for ones operating under such a high-profile-the-gov-is-paying situation? They'd be idiots not to, and contrary to what it sometimes seems, not many successful companies are actually run by idiots. This whole fiasco has the potential to spell death for this company, and its top people, at least in government circles. They'll be too toxic to touch!
Don't get me wrong, really good web security is hard. There's simple fixes for pretty much every class of problem, but there are a *lot* of possible problems and some of them are pretty un-intuitive. Knowing what security to implement, where, and how to do it is pretty specialized knowledge. In theory, it should be something every web developer knows, of course. In practice, that's not the case at all. Instead, there are a bunch of basic guidelines every code monkey is given, and then there are a handful of experts who oversee the whole thing. Small companies, or those operating on a tight budget of either time or money, may opt to leave that part to some outside experts once the code is already written (I would know; this is what I do) but they still often at least make the attempt.
To go completely without such expertise, on such a high-profile project, though? Pure folly. Even where the implementation of security recommendations is hard (and sometimes it is), the cost of failing to implement them will be much greater, and they really should know that.
There are "standard" controllers from a couple different companies, and "standard" libraries for interacting with them, available for Android (and to a lesser extent, iOS). Two that come to mind are Sony and NVidia, but it's also worth considering that Wii and PlayStation wireless controllers use Bluetooth, which means they can connect to a phone as well as a console or PC (I've written a PC game that used a Wiimote via a standard BT interface and a provided library; it was pretty easy). Part of the problem is, in the classic style of standards, there are too many of them!
Something else many slashdotters may be in a position to do is to vote with their dollars. Even if you can't actually attend or help fund one conference or the other, take note of which companies attend which. Follow the money, and promote those who don't agree with the actions of the NSA and, by extension, with RSA. If attending the RSA conference is a mark against themselves in the eyes of potential customers, fewer companies will attend. If the sponsors and attendees of the new conference get extra business out of it, they'll be better placed to keep doing it, and the next time something similar to RSA's bribe comes to light, their competitors will be more ready to take away their conferences and customers.
Don't forget also that these conferences are networking opportunities. Everybody who doesn't attend the RSA con is missing out on the opportunity to hobnob with all those other attendees. Reward them for standing on principles, and for standing up for their customers. That's how the positive feedback loop which is supposed to encourage companies to behave well works.
Disclosure: I work for one of the companies who will be at TrustyCon instead of RSA.
Considering that any ActiveX control is effectively an "IE extension", and further considering that IE installs ActiveX to a non-user-writable directory by default *and* prompts the user when they update, I think you're full of shit. But sure, work an anti-MS angle into this somehow. I'm sure that'll get you modded up...
Not saying I have anything against ad-blocking; I do it myself. But your argument is either deliberately obtuse or simply stupid. The ads aren't there because the site owner thought "hey, an ad would look good here"; they're there because it costs money to serve the rest of what's on the page, and ads are how they re-coup that cost.
Detection scripts can easily query the DOM to check if the ad is being displayed. In fact, there are already scripts that do this, for different reasons. Besides, one of the core advantages of ad-blocking is the ability to avoid waiting for the damn ad host's servers to send you their trash.
Security: No ASLR. Total pain in the ass to run as a non-Admin. No mandatory integrity controls (everything runs with the permissions of the user that started it, even if it *should* be less trusted). Extremely weak, trivially brute-force-able password hashes. Only one-way firewall with minimal configuration ability. No client certificates for Remote Desktop. Outdated cryptographic provider that doesn't support modern cipher suites or key sizes. No full-volume encryption (BitLocker). No PatchGuard. Code written before the Windows-org-wide security push that so delayed (but improved) Vista.
Stability: Video drivers still run entirely in kernel mode. In fact, relatively little user-mode driver support at all. No support for file system transactions (journaling, yes, but only per-file) so canceled/interrupted operations could leave things in an inconsistent state. Driver installation usually required a reboot. System Restore function was a complete joke, as was backup. Doesn't install recovery tools to hard disk, and the XP recovery software is very primitive and impotent.
Performance: No automatic defragmentation. No pre-caching of commonly used programs or files. No TRIM command for SSDs. No support for more than 4GB of memory (in practice, less, due to drivers reserving some of it). No support for more than two CPUs/cores. Archaic memory management algorithms that aggressively page things out of RAM so that task switching to anything not used for a while is very slow even if there's RAM to spare. No RAM page combining.
Productivity: No instant search. No live previews of running programs when switching between them (very handy when you've got a bunch of different Word documents or something open). No snapping windows to half the screen with a quick gesture. An extremely primitive wireless networking connection interface. No "Previous Versions" (volume shadow copies for restoring deleted or modified files). No per-application volume control. Longer bootup and hibernation times for equivalent hardware.
Interoperability / Other: Tacked-on (and incomplete) IPv6 support. No 64-bit. No USB3 support. No support for roaming profiles unless domain joined (no Microsoft account sign-in). No support for booting from or mounting VHDs. No support for booting from removable storage. No support for mounting ISOs. Poor support for loading drivers from Windows Update.
Do you really need more? I could keep going for a while...
What do you even need privilege escalation for? Damn near everybody runs XP as Admin; it's too painful to do otherwise (I tried for about half a year prior to the public Vista betas; compared to that, Vista's UAC, even during beta, was a godsend). For that matter, a lot of XP installs (at least in the early days) were on FAT32 systems, not NTFS, which meant you could get EoP just by overwriting some system files (no ACLs). Vista and later require NTFS.
Then there's the matter of ease of exploitation. XP has optional DEP, not widely used. That means you can trivially use return-to-libc attacks, or return-oriented programming, making it trivial to weaponize any vulnerability found. Vista and above have DEP enabled by default, plus ASLR (especially since Vista SP1 / Win7, as a number of libraries from before that shipped without ASLR-compatible flags). That means that even a wide-open vulnerability - think something really stupid, like the equivalent of gets() on a network socket - will typically require an additional vulnerability that leaks information about the state of memory before it can be exploited (for anything other than DoS, at least).
Anybody who thinks that "XP + firewall + Firefox = about the same security as Win8.1, really" is talking out their ass. They either don't have a fucking clue or they've got an agenda (probably nothing more than "I don't want to spend money" but they're still intentionally blinding themselves to reality).
Calling 9x "based on DOS" is, at best, an extreme stretch; it's arguably a flat-out lie. DOS was a 16-bit single-tasking OS where every process and driver shared a common address space and ran in ring 0 with absolutely no protections. It had minimal hardware abstraction, enabling and requiring applications to write directly to the drivers (or worse, ship their own drivers) for things like decent audio, graphics, mouse, CD-ROM, network, etc. Its filesystem was laughably primitive (FAT16 with 8.3 file names) and its shell was a joke even compared to cmd.exe.
Even Windows 95 was a substantial improvement in every single one of those areas, and aside from some backward compatibility stuff and a very small amount of pre-boot code (DOS didn't even *have* a bootloader, in the conventional sense, but 9x needed something to bootstrap the 32-bit kernel), there was nothing of DOS in 9x's code.
With that said, NT was definitely a big step up. A lot of the differences were more subtle than they'd been for the DOS-to-9x transition, though. Plenty of "consumers" ran Windows 2000 anyhow, too.
No offense, but that makes you sound pretty incompetent at using Windows, and (to a slightly lesser degree) computers in general. To get to the desktop on Windows 8.x: Click the Desktop tile in Start (I would hope you can find Start, given that there's a dedicated key on the keyboard for it). Hit the Win+D chord that has meant "Show Desktop" since at least XP. Right-click the Start button and select Desktop (this menu, added in Win8, actually has a ton of useful things in it for a desktop user). Launch any program which runs on the desktop (for example, hit Start, then type "cmd" and hit Enter... just like you've been able to do since Vista). Use any keyboard shortcut that appears on the desktop (Win+R for Run, Win+E for Explorer, etc.)... the fact that it took you two hours (excuse me, one hour and fifty-five minutes) to do something so extremely simple and well-documented (did you try consulting Google?) says more about your skill at human-computer interaction in general than about any particular UI.
Slashdot Mirror
Which explains exactly *what* of relevance to geekoid's link? I mean, did you even look at it? It's a game, a big-budget currently-supported game, not made by Microsoft or Sony, that you can play on Linux PCs (not consoles)...
There are lots of others, too. For example, I play HoN (a DotA clone from the days before DotA2; I still prefer it over DotA2); they have a native Linux client. A bunch of Humble Bundle games have been released, those have Linux versions.
That's even leaving aside things like Wine, and so on. I've been gaming on Linux since 2006. It's not always as polished an experience as on Windows, but lately it's been getting very good.
Pretty sure Microsoft will only shut down the Nokia handset manufacturing (there's more to Nokia than that, but I don't have a handy name for it like "Motorola Mobility") if they decide to abandon the smartphone OS business entirely. Which they could do, admittedly, but I'd be surprised. They've achieved a pretty solid third place in the market, with an overall marketshare similar to that of OS X among PCs. They've started being taken more seriously by major app developers. They're rolling out updates at a decent rate, and many of the crippling issues of the app model in WP7 are already fixed.
That doesn't mean they won't spin off or re-sell that portion of the business, of course. I'd be surprised if they just killed it though, unless they want to give up on phone OSes entirely. There are at least three other OEMs making WP8 handsets (HTC, Samsung, and Huawei), but the Nokia Lumia line predominates.
Much more than 90 days. Even with top implants and neural mapping, I don't think you can hit all the skill pre-reqs for a titan in under half a year, and probably longer (disclosure: I've been playing much longer than you have, but I stick to sub-capitals). Unlike subcaps, where the progression is pretty simple (spaceship command - frigate - destroyer - cruiser - battlecruiser - battleship), capitals throw a whole bunch of additional requirements in there. You need jump drive training (which means training a handful of the Navigation skills pretty high). You need advanced spaceship command, which is basically great big speed bump between subcaps and caps. I forget if you need the superweapon skills just to pilot a titan or not, but if so, get ready to train a whole bunch of pre-reqs for that too. Etc, etc. And that's just to get in the ship at all. To actually use it, you'll spend months to reach even the point where you can mount its guns, much less use them effectively. You'll need a few months just to get the basic core competency skills maxed out, because there's no way you can afford to give up a 2% edge in something. You'll need to max the gunnery support skills so you have a chance of taking out a heavy interdictor tackling you, the navigation skills so you can actually get to the battle with everybody else, the rigging skills so you can fit the tech-2 rigs you'd be insane not to use on a ship so expensive, the repair skills to be able to keep the thing intact in battle, and so much more.
Being *ready* to fly a titan - that is, having the character skills required to actually be a competitive titan pilot - is probably at least two years of training.
Sad, but true. It has a definite "slowly being boiled" feel to it. What would once have been beyond the pale is now supposed to make us feel happy, because it's better than what we had yesterday...
NVidia drivers? Those are the only things that have caused random-bluescreen-while-gaming for me in the last seven years, from Vista through Win8 (well, my Win8 machines don't use NV drivers, but I've had no problems on AMD or Intel yet, not that I use the tablet for much gaming). The sad thing is, due tot he way WDDM works, the driver has to crash *really* badly to actually cause a bluescreen - usually it just makes the screen go black for a second, then come back as the user-mode portion of the driver gets restarted. I lost count of the number of times that happened - multiple times per day, often, though - back in 2007, but only on my NVidia machine, and a coupel times the driver crashed again while (or immediately after) "recovery" at which point you will get a bluescreen. They eventually released a driver update that reduced it to an every-other-year kind of issue, but still...
There are at least here other active smartphone platforms out there...
Windows Phone: probably not something the poster would consider, and while some of the WP7 models had hardware keyboards I don't think any WP8 ones do, so the hardware and OS would be nearly as obsolescent anyhow. Hackability, on the other hand... Well, a WP7 device with a suitably modified custom ROM might almost work, but it won't be Linux. Most WP8 devices don't have much in the way of hacks at all. If you were to go this route, the phone I would recommend is the HTC 7 Pro / HTC Arrive (same thing really, once just being a CDMA variant) - good hardware keyboard, custom ROM support, outdated but still better specs than the N900.
Blackberry: best bet for a hardware keyboard, and you can get relatively modern hardware for cheap from them, but I don't know how you feel about the company. Hackability is a question, though; I don't know how hard it is to get at their guts, but it's probably not easy. A valid option if you just want a decent hardware-keyboard-equipped smartphone, but otherwise probably not a great option. Not sure what model would suit best.
Jolla Sailfish: still in development and arguably not yet release-ready. The obvious advantage here is the Maemo roots underpinning the Sailfish OS; from a Linux-user/tinkerer point of view, it's probably the closest option for an N900 successor. "Politically" speaking, it's probably the best option as well. Currently you'd need to give up the hardware keyboard, though. That should change, and probably quite soon, but it's too early to say for sure how well Jolla will be able to iterate on their product. It's a cool idea, though!
Yes, I'm aware that all three of those, combined, have *maybe* 10% of the global smartphone marketshare. Oh well. Your claim of "only other choice" is still wrong.
10% isn't strong? WP is edging towards that worldwide, and has beaten it in several markets. It's the #3 spot right now, easily beating Blackberry (former #3).
Well, neither does Microsoft, so I fail to see how that's a difference...
Developer registration for a phone (enables sideloading) is free, and has been for months. Before that, it cost $20 (still the cost to get a developer account that lets you submit apps to the store). Before *that*, it cost $99, but that was some time ago...
With that said, by default, Windows Phone does restrict the number of apps you can sideload at once (given the rampant piracy on Android, their POV is understandable even if annoying). Some phone have hacks to remove this restriction.
Care to give an alternative way that Manning could have "spilled the secrets" only to enfranchised American voters? Because otherwise, your supposed counterpoint is null.
Are you a Russian? I'm not. He gave me plenty of information... If you can list a way he could have released his information to the US as a whole without also letting it be seen by the Russians (who are opponents of ours on multiple political issues, but not our enemies by any stretch of the definition) then I will grant there is *some* point to what you said. Otherwise, it's complete bullshit.
Also, as others have pointed out, he did try going through proper channels. He was told to drop it. How high did you expect him to go, and what good did you expect it to do? The president himself has expressed support for the NSA's programs *and* branded Snowden a criminal *before* he took asylum in Russia, so that part of your argument is bullshit. Enough members of congress have said (or voted in favor of) much the same things that I doubt it would do much good to have gone to them, either. With the heads of the executive and legislative branches complicit in this travesty, Snowden *did* go over their heads: to the people who elect those scum. We, the citizens of these United States of America.
So, I ask you again: how was Snowden supposed to reveal the information to We The People, without also revealing it to our "enemies"? (If you wanted to pick examples of enemies, you could do much better than Russia).
Um, no. You're falling into exactly the kind of stupid traps of "doing this better" that I described above. The whole idea is terrible and should never be attempted.
When the user signs in, generate a cryptographically strong random identifier to use as a session token. 128 bits is pretty much standard here (practically speaking, brute-forcing even 64 bits online is quite impractical, but the birthday paradox means you may hit *somebody* by accident much faster than seems possible). Store, on the server side, the mapping of that identifier to that user. When the user signs out or their session expires, delete that mapping and the identifier. If the user already has an identifier when they make a request, but it's not currently in the mapping dictionary, ignore/delete it. Don't ever re-use the mapping; make it different any time any user logs in.
Yes, this is more expensive for a server cluster than decrypting a cookie, assuming there are lots of concurrent users. However, it's got a critically important advantage: there is literally no possible way for an attacker to forge a session cookie. No information about the web app that they could have, save for the state of the server's /dev/urandom or its cache of logged-in users, could aid them. The best they could possibly hope for is to steal or to stumble upon one while it is in use. Given reasonable protections on the token and a short expiry period, this should be practically impossible barring client-side malware (in which case that particular client is already hosed, since the malware can just steal their credentials as they are typed in, and everything else of value on their computer to boot).
Even then, there's a ton of other vulnerabilities that must be avoided. For example, protecting that token is of course vitally important. The Secure and HttpOnly flags are a good start, although Client Security Policy is even better than HttpOnly (on clients which support it). Make the whole site accessible only over HTTPS, of course, and use HTTP Strict Transport Security to require that (compliant) user-agents never visit the site over HTTP. Permit only the most recent versions of TLS (1.0 may be permitted for legacy browsers; anything older is a bad idea) and only use strong cipher suites (ideally with Perfect Forward Secrecy). Include protections against Cross-Site Request Forgery in the form of an anti-CSRF token that is, at a minimum, unique per-user (and not based on or derivable from any value stored in a cookie or any user information). If you want to be really paranoid, you can do things like include the user's IP address in their token mapping, so that if their IP changes their token gets invalidated immediately and they must log in again (this will occasionally annoy legit users, but a site like this will have a very short session timeout anyhow).
There's a ton more than that (protecting the credentials is an area I haven't even touched on, aside from the crypto). It's a hard space, and even the experts miss things sometimes. Assuming you have the answers (or worse, can figure them out) is a dangerous hole to fall into! This is why companies like mine exist...
How do you know it hasn't been? It's not like some Chinese black hat would issue a press release claiming what had been done in that case. Instead, the information would be sat on for a while to distance its release from the slight bump in traffic when the actual breach occurred. Then it would be farmed out, quietly, to third parties looking to engage in identity theft and such. They in turn would probably take it slow; too big a glut of that kind of activity is not only sure to be noticed, it drives down prices (did you see the article a few days ago about how the Target crackers came away with more CC #s than they could sell?). Then there's the timeline to notice the attacks themselves, which wouldn't be terribly fast; identity theft isn't exactly as noticeable as, say, armed robbery. It might not even be as obvious as unexpected charges on your credit card. Many people go their entire lives without ever directly checking their own credit rating...
In any case, there are other possible reasons. Maybe the attackers are waiting for the intense scrutiny of the site to die down, so they can do it when nobody is looking. Maybe the last time they tried the site was down and they're waiting for it to become more stable. Hell, they might even be a bit concerned about the retaliation of the federal government for going after such a target. You are talking about a crime (and one for which US law permits extremely harsh sentences), after all, and the arm of American "justice" is much longer than its national borders might imply.
Yep. I see this all the time. Sometimes it's a little more subtle, though. Like, say, storing that value in a cookie. Most people never look at their cookies, but a web security expert (on either side) is more likely to see the cookies than they are to see the actual site rendering. Or the value might be something that in the abstract is impossible to guess (like 59340341412091985) but if you happen to know your SSN and your birthdate, you might recognize those values in that 17-digit mess (it's even easier if, for example, there's a | character between the parts) and then you can (relatively easily) start guessing other peoples' pairs.
Sometimes it's even more subtle and requires some actual work to get at it, like storing an ID value concatenated with some other garbage like the date in a cookie encrypted with a static key (this one is actually fairly commonly done as a method of generating a token *identifying* the authenticated session, after all, if you don't have the key you can't generate the authentication token, right?). However, if you can guess which bits of that token are the ID (not hard; they're the ones that are the same whenever a given account signs on, but different for every account) you can twiddle the bits and basically brute-force the search space of valid IDs. There are still many ways to make this at least *somewhat* harder to attack, but a lot of developers won't bother... and there are ways to do it *worse*, too, like using an XOR with a constant mask instead of a merely re-using the key with a real cipher.
Also, they had to know a priori this was going to be a *huge* target (no pun intended). Whether for the treasure trove of neatly collected data or a simple political agenda (doesn't even need to be a partisan one; lots of people who voted for Obama hate the ACA and healthcare.gov), it should have been obvious from the very beginning that the scrutiny of this site for security vulnerabilities would be far greater than most, and the costs (to the site developers) of an attacker exploiting one far more severe. Under those circumstances, business-as-usual things like PCI DSS and such should have looked like nothing. They should have hired an entire internal security team to oversee the development of the site starting from the design phase*, and an external penetration testing team to verify it at least once by now.
* Tacking security onto a design that is inherently insecure is expensive and often futile, just as is true of many other kinds of software bugs. Of course, if they'd designed competently in the first place, maybe the site wouldn't already be a laughingstock...
I'm not personally familiar with the database they're using, but it's worth noting that injection attacks work on some noSQL databases too. It all depends on how the data is added and accessed; any language (for even very loosely defined values of "language") that fails to clearly distinguish instructions from data risks the latter being interpreted as the former.
Just in case you were being serious. :-)
Sure they would. Not all of them, true, but most. That's not to say they'd be perfect, but they would certainly have done better. Banking websites, despite often having stupid legacy requirements like 8-character passwords or relatively weak SSL ciphers, are routinely designed with vastly better security than is being described here. That's for their own sites; for ones operating under such a high-profile-the-gov-is-paying situation? They'd be idiots not to, and contrary to what it sometimes seems, not many successful companies are actually run by idiots. This whole fiasco has the potential to spell death for this company, and its top people, at least in government circles. They'll be too toxic to touch!
Don't get me wrong, really good web security is hard. There's simple fixes for pretty much every class of problem, but there are a *lot* of possible problems and some of them are pretty un-intuitive. Knowing what security to implement, where, and how to do it is pretty specialized knowledge. In theory, it should be something every web developer knows, of course. In practice, that's not the case at all. Instead, there are a bunch of basic guidelines every code monkey is given, and then there are a handful of experts who oversee the whole thing. Small companies, or those operating on a tight budget of either time or money, may opt to leave that part to some outside experts once the code is already written (I would know; this is what I do) but they still often at least make the attempt.
To go completely without such expertise, on such a high-profile project, though? Pure folly. Even where the implementation of security recommendations is hard (and sometimes it is), the cost of failing to implement them will be much greater, and they really should know that.
There are "standard" controllers from a couple different companies, and "standard" libraries for interacting with them, available for Android (and to a lesser extent, iOS). Two that come to mind are Sony and NVidia, but it's also worth considering that Wii and PlayStation wireless controllers use Bluetooth, which means they can connect to a phone as well as a console or PC (I've written a PC game that used a Wiimote via a standard BT interface and a provided library; it was pretty easy). Part of the problem is, in the classic style of standards, there are too many of them!
Something else many slashdotters may be in a position to do is to vote with their dollars. Even if you can't actually attend or help fund one conference or the other, take note of which companies attend which. Follow the money, and promote those who don't agree with the actions of the NSA and, by extension, with RSA. If attending the RSA conference is a mark against themselves in the eyes of potential customers, fewer companies will attend. If the sponsors and attendees of the new conference get extra business out of it, they'll be better placed to keep doing it, and the next time something similar to RSA's bribe comes to light, their competitors will be more ready to take away their conferences and customers.
Don't forget also that these conferences are networking opportunities. Everybody who doesn't attend the RSA con is missing out on the opportunity to hobnob with all those other attendees. Reward them for standing on principles, and for standing up for their customers. That's how the positive feedback loop which is supposed to encourage companies to behave well works.
Disclosure: I work for one of the companies who will be at TrustyCon instead of RSA.
Considering that any ActiveX control is effectively an "IE extension", and further considering that IE installs ActiveX to a non-user-writable directory by default *and* prompts the user when they update, I think you're full of shit. But sure, work an anti-MS angle into this somehow. I'm sure that'll get you modded up...
Your "cut" is the content on the site...
Not saying I have anything against ad-blocking; I do it myself. But your argument is either deliberately obtuse or simply stupid. The ads aren't there because the site owner thought "hey, an ad would look good here"; they're there because it costs money to serve the rest of what's on the page, and ads are how they re-coup that cost.
Detection scripts can easily query the DOM to check if the ad is being displayed. In fact, there are already scripts that do this, for different reasons. Besides, one of the core advantages of ad-blocking is the ability to avoid waiting for the damn ad host's servers to send you their trash.
Security:
No ASLR. Total pain in the ass to run as a non-Admin. No mandatory integrity controls (everything runs with the permissions of the user that started it, even if it *should* be less trusted). Extremely weak, trivially brute-force-able password hashes. Only one-way firewall with minimal configuration ability. No client certificates for Remote Desktop. Outdated cryptographic provider that doesn't support modern cipher suites or key sizes. No full-volume encryption (BitLocker). No PatchGuard. Code written before the Windows-org-wide security push that so delayed (but improved) Vista.
Stability:
Video drivers still run entirely in kernel mode. In fact, relatively little user-mode driver support at all. No support for file system transactions (journaling, yes, but only per-file) so canceled/interrupted operations could leave things in an inconsistent state. Driver installation usually required a reboot. System Restore function was a complete joke, as was backup. Doesn't install recovery tools to hard disk, and the XP recovery software is very primitive and impotent.
Performance:
No automatic defragmentation. No pre-caching of commonly used programs or files. No TRIM command for SSDs. No support for more than 4GB of memory (in practice, less, due to drivers reserving some of it). No support for more than two CPUs/cores. Archaic memory management algorithms that aggressively page things out of RAM so that task switching to anything not used for a while is very slow even if there's RAM to spare. No RAM page combining.
Productivity:
No instant search. No live previews of running programs when switching between them (very handy when you've got a bunch of different Word documents or something open). No snapping windows to half the screen with a quick gesture. An extremely primitive wireless networking connection interface. No "Previous Versions" (volume shadow copies for restoring deleted or modified files). No per-application volume control. Longer bootup and hibernation times for equivalent hardware.
Interoperability / Other:
Tacked-on (and incomplete) IPv6 support. No 64-bit. No USB3 support. No support for roaming profiles unless domain joined (no Microsoft account sign-in). No support for booting from or mounting VHDs. No support for booting from removable storage. No support for mounting ISOs. Poor support for loading drivers from Windows Update.
Do you really need more? I could keep going for a while...
What do you even need privilege escalation for? Damn near everybody runs XP as Admin; it's too painful to do otherwise (I tried for about half a year prior to the public Vista betas; compared to that, Vista's UAC, even during beta, was a godsend). For that matter, a lot of XP installs (at least in the early days) were on FAT32 systems, not NTFS, which meant you could get EoP just by overwriting some system files (no ACLs). Vista and later require NTFS.
Then there's the matter of ease of exploitation. XP has optional DEP, not widely used. That means you can trivially use return-to-libc attacks, or return-oriented programming, making it trivial to weaponize any vulnerability found. Vista and above have DEP enabled by default, plus ASLR (especially since Vista SP1 / Win7, as a number of libraries from before that shipped without ASLR-compatible flags). That means that even a wide-open vulnerability - think something really stupid, like the equivalent of gets() on a network socket - will typically require an additional vulnerability that leaks information about the state of memory before it can be exploited (for anything other than DoS, at least).
Anybody who thinks that "XP + firewall + Firefox = about the same security as Win8.1, really" is talking out their ass. They either don't have a fucking clue or they've got an agenda (probably nothing more than "I don't want to spend money" but they're still intentionally blinding themselves to reality).
Calling 9x "based on DOS" is, at best, an extreme stretch; it's arguably a flat-out lie. DOS was a 16-bit single-tasking OS where every process and driver shared a common address space and ran in ring 0 with absolutely no protections. It had minimal hardware abstraction, enabling and requiring applications to write directly to the drivers (or worse, ship their own drivers) for things like decent audio, graphics, mouse, CD-ROM, network, etc. Its filesystem was laughably primitive (FAT16 with 8.3 file names) and its shell was a joke even compared to cmd.exe.
Even Windows 95 was a substantial improvement in every single one of those areas, and aside from some backward compatibility stuff and a very small amount of pre-boot code (DOS didn't even *have* a bootloader, in the conventional sense, but 9x needed something to bootstrap the 32-bit kernel), there was nothing of DOS in 9x's code.
With that said, NT was definitely a big step up. A lot of the differences were more subtle than they'd been for the DOS-to-9x transition, though. Plenty of "consumers" ran Windows 2000 anyhow, too.
No offense, but that makes you sound pretty incompetent at using Windows, and (to a slightly lesser degree) computers in general. To get to the desktop on Windows 8.x: ... the fact that it took you two hours (excuse me, one hour and fifty-five minutes) to do something so extremely simple and well-documented (did you try consulting Google?) says more about your skill at human-computer interaction in general than about any particular UI.
Click the Desktop tile in Start (I would hope you can find Start, given that there's a dedicated key on the keyboard for it).
Hit the Win+D chord that has meant "Show Desktop" since at least XP.
Right-click the Start button and select Desktop (this menu, added in Win8, actually has a ton of useful things in it for a desktop user).
Launch any program which runs on the desktop (for example, hit Start, then type "cmd" and hit Enter... just like you've been able to do since Vista).
Use any keyboard shortcut that appears on the desktop (Win+R for Run, Win+E for Explorer, etc.)