1: There is a low barrier for entry. One gets Eclipse, some Java tools, the Android SK, and they can write APK files. $25 later, and one can upload into Google's store. Apple is $99/year, and it requires going into ID theft territory to create another account if Apple drops the axe on an app developer. Android development can happen on Windows, Macs, and Linux. XCode only can happen on one platform, be it a true Mac, or a hackintosh.
2: Android is used on inexpensive smartphones. This makes it a very popular platform in China, India, and other nations developing an ecosystem, as well as countries that separate the phone from the provider. So, there are a lot of the devices out there. iOS devices are very popular, but not as common and wide ranging as Android models.
3: Android's permission model is strong, and rooting does not affect security in the slightest. An installed app won't get anything that it does not have access to, unless it manages to pull off some successful root exploit (which is difficult as the app has to escape the Dalvik VM first.)
Where the problem happens, is that permissions are not fine grained enough. Combine this with the user training to mindlessly click on any button labeled "send/accept/OK/submit/pay/download", and an app can be tossed on a device that shouldn't have anywhere near the permissions it requested. For example, a game does not need access to a contact list.
What would be nice is if Google went back to the modal dialogs with the permission contents in them, forcing a user to look at it, as opposed to displaying them below the button that allows for a quick double-tap purchase.
3: The current Google app repository is more of a marketplace than a store. The good thing is that a developer can have an extremely tight and fast feedback cycle, churning out updates hourly in some cases without having to wait for a bean counter to approve them. The bad thing is that apps that are not vetted can be an avenue for malware.
4: In some countries, pirated apps are the norm, so finding a bunch of Angry Birds APK files that have the LVL code yanked is the norm rather than the exception.
All and all, this isn't really Google's fault -- Android went from being on the sidelines to a mainstream OS in remarkable time, especially with the fact that iOS was well entrenched with an App Store. Android matured from doing the basics to an OS that is not just consumer-friendly, but can support the needs of businesses with Exchange support.
This is anecotal, but in the US, I'm sure the chance of a malicious app is low, even an inexperienced user just clicks on download, then accepts without looking. A clued user can look at reviews, discount the vague ones that are shills, and look for the scathing reviews. For example, a game that popped up also brought along with it some adware, and it was obvious with the 1-2 stars it was rated that something was afoot. A couple reviews of "one star, spams contact list" will sink an app before Google comes by with the ban-hammer.
I stated this in another post, but I still think that the current Google Marketplace structure is well done. However, a significant improvement would be a tier of service of Google actively vetting apps, where an app developer who pays for the higher level of assurance (since black box reviewing of apps does take time and money) can release an app as normal. Then, Google can sign that version when they get done reviewing, and this can be on their own schedule. A subsequent update would be allowed on the store, but it would be unsigned until Google reviewed and approved it.
This way, phones can ship by default only allowing Google-vetted apps. If a user wants to get other apps, they can answer a warning dialog about doing so at their own risk [1].
IMHO (and I've stated this before): If Android devices shipped with a store/marketplace/repository that hand-approved apps (with facilities for allowing full
With iOS, there is not much one can do about malware, if it gets past Apple's gatekeepers. JB-ing the device and slapping on Firewall iP is probably the best thing one can do. However, the barrier for entry for malware writers is very high. It is pretty difficult (and more expensive) for a blackhat organization create a new account with Apple , paying them a C-note a year), and cook up some personal info (like bank accounts and such to register under) to even be able to see iTunes Connect, much less have the app approved. This has done a good job in keeping iPhone users safe, although in theory, if an app decided to have some type of module that would allow code execution, users would never know about an app that would be slurping contact info, E-mails, and other items then shipping that off to a blackhat server, especially if the app was smart enough to do it only on Wi-Fi, or a small trickle over 3G.
Because of this, the only permission iOS asks for is for using the GPS. Since the App Store does all the work essentially, there isn't that much of a need to have anything more than that.
Even with Firewall IP, there is no protection against apps deciding to spam with SMS, other than Apple's gatekeepers.
So, Apple's security model may have some (in theory) bad flaws, but it has proven to be decently tight, with exploits being used for jailbreaking as opposed to turning the device into a mobile money machine for criminal organizations.
Android's model is more robust in some ways. If Android phones were shipped with a marketplace that vetted/approved apps [1][2], this would virtually eliminate compromised phones [3].
The nice thing about Android is that even with full root and a custom ROM, app security is just as tight as it is on a vendor ROM. Unlike jailbreaking on iOS which completely creams the security model, apps on Android still function exactly the same on a rooted phone, other than being able to prompt the user for su access.
Since Android isn't reliant on a store's gatekeepers, its permission model has to be robust. It has been OK so far, provided users read and disallow apps like a game demanding full access, but it would be nice to have a better model -- something along the lines of minimum permissions needed to run the app, optimal permissions, and maximum permissions (a notepad app that just stores notes in its directory generally does not need full access or access to root unless it has some special features.)
What can help Android immensely would be an app that runs as root and can allow/disallow access to SD cards, contacts, SMS, phone, and networking. There is an app called LBE Privacy Guard which runs as root and offers features that should really be part of Android (perhaps some features behind an Advanced menu.) CyanogenMod also has similar features for restricting access.
Another app that is a must have for rooted devices is DroidWall, which is essentially a shell for performing iptables commands. This is an immense help because it can not just block network access for apps, but limit the bandwidth hogs to Wi-Fi (or security sensitive apps to 3G).
Pretty much for the tl;dr in all of us, Android would be best off with two tiers of stores, and having the user go through a dialog of "these apps are untested, but the reviews will be a good guide. Use at your own risk" before a user gets access to the free-for-all market. Couple that with the functionality of DroidWall and LBE Privacy Guard which can be set to prompt/allow/deny access to critical things (contacts, network, phone, SMS) integrated into the OS, and Android would be a lot more secure.
[1]: Amazon is good at vetting apps, and it would be nice for Google to offer two tiers of their Marketplace, where one tier would be the current free-for-all, while having another tier (which would cost app developers more because of the time taken) just for apps that would have a "blessed" flag attached.
[2]: It goes without saying to have a way to add more stores, or if Google w
I'd disagree. Yes, there are other video sites, but a lot of them use dodgy ad rotators that serve up exploits, require Web based add-ons or codecs (which likely are exploited), or just won't display on most machines.
Youtube is nice because it won't just give you the middle finger if you decide to browse it on your iPad; most other vid sites, the only thing you will be viewing is a link to Adobe to download Flash, Shockwave, or RealPlayer.
Here in TX, there are vans which actually aim a laser at exhaust to try to detect those types of things, and pull people over immediately and impound their ride.
What is affected is tuning the engine, such as giving a couple better horsepower, changing response of the transmission, changing shift points, advancing timing to get a better burn with higher octane gas, etc. In fact, sometimes you can tune some engines where the MPG gain from using premium unleaded is more than the difference in cost.
Tunes is what car/engine makers are trying their best to stamp out. Some car makers have explicitly told their dealers to look for traces of tunes and mark warranties void if found. Other vehicles will just deactivate until completely re-flashed at the dealer.
Why are car makers wanting to do this? Some day that it keeps them from adding 2-5 horsepower per year to their vehicles as a selling point. Others just are protective of their engines and view consumers modding their stuff as scumbags.
Believe it or not, on some makes of cars, the ECM/TCM will check if it is tampered with, and when taken to a service depot, the entire warranty will be voided.
It took about a year for people to "jailbreak" the latest EcoBoost engines so one can run a custom tune on them.
Expanding on that idea, I would like to see a kiosk that has a book printing/book binding press, a small 3D printer, and a stack of blank media that can be programmed and automatically embossed with the game title. HP LightScribe media comes to mind for this.
This way, a publisher can not just have a cool game and printed media, but have it come with a manual, and perhaps some tokens made with the 3D printer as well. This might bring around a revitalization of the game industry. To boot, game manuals can stop being a four page flyer, but actual books with background and other stuff with the game, so they in themselves would be keepsakes.
As for DRM, the best I have seen is what Bioware did in NWN1 -- you need a CD key to use their multiplayer system (which is only fair because pirating a game is one thing, leeching time and CPU power is another.) The pirates won't be stopped, the used market is still unaffected, and well-written DLC will help make up the difference.
It might just give impetus for more indies to hit the PC game market where the barrier for entry is basically paying for an Authenticode signing key, or a yearly membership for use of iTunes Connect. Instead of paying $60, one can pay $20 for a game like Torchlight that may not have the latest and greatest eye-popping graphics, but is very playable.
Consoles may be hitting the skids, but with the fact that stores/repos/markets are becoming commonplace, it isn't hard for an indie to get in the ball game and be a link away from having a good game. Possibly another ID with an awesome game demo might even appear.
Isn't forcing a business to take expenses such as having to buy an EMC VNX SAN a tax?
This is pretty much taxation without representation, unless the HI government is willing to spend the money to hand each ISP the proper disk space to do this.
The more governments and ISPs press this, the more people will go to VPS services. Offshore VPS services in countries that have real privacy laws (Sweden/Switzerland), or in nations hostile to the US.
Then, the serious computer crime cases will be impossible to investigate because everything from the endpoint on up would be encrypted.
Of course, the next step is doing like Pakistan and banning VPNs, but that will start a cat and mouse game. Yes, it can be won by using a Great Firewall-like system, but even that isn't a total victory.
I can see why in the US there is such resistance to autonomous vehicles: Small towns and counties depend on driver error, be it speeding, red light cameras, or stuff like that for revenue. An autonomous system means that everyone will be going the speed limit, so no tickets (and no chance at finding marijuana and thus earning a civil forfeiture prize) will be given.
This is sad because the US is the perfect place for autonomous vehicles -- most cities are too sprawled out for even buses to be reliable, much less light rail. So, vehicles that drive themselves would be ideal because it would allow long distances to be covered with vehicles packed in as much as their computer and mechanical systems would allow, compared to current driving conditions which depend on the driver's ability/reactions (or lack of when compared to a computer.) Even for people who don't own a car, it wouldn't be hard to have a Car2Go/Zipcar like service.
Even more ironic, with computer controlled cars, it would lesson the need for more and more highway improvements. Cars can be sped up or slowed down to allow vehicles in and out, they can be moved into lanes depending on their destination, and if there is a vehicle problem, it can be moved to the side of the road and traffic routed around it without putting the highway out of commission for hours on end. This would save a municipal area far more money than they ever would earn by speeding tickets.
In reality, the defense lawyer will argue that, while the prosecuter will then rebut with "realistically, would someone actually do this?"
A jury of/.-ers would acquit, or nullify. However, even though we wish that we would get a jury of our peers in cluefulness, most likely the jurors picked will have almost zero clue what a MAC address is, so a good prosecutor setting up a case can say something like it is impossible to forge with almost no real life cases. With this in mind, plus a "ignore the defense's mumbo-jumbo", and a jury with glazed eyes and a brain full of buzzwords they don't know or understand will likely convict... just so they can go back to Mike's Watering Hole and swill some Duff before traffic gets bad.
I should have been clearer: The write blocker is used to dd the hard disk to another drive (or virtual drive) for forensic research. This way, the contents of the original drive are guaranteed to be untouched.
This has been talked about on the TrueCrypt forums ad nauseum: A suggestion that the utility has a password that would erase volumes.
First, it is part of forensic practice to whip out a hardware write blocker. No hardware write blocker, and the evidence can be thrown out of court.
So, if someone hands a decent forensic analyzer a key, and it zaps the contents of the image, they just roll back the logs, add a destruction of evidence charge.
Realistically, it probably wouldn't affect a single sale. The reason is that companies buy SEP not because of its virus stomping capability. They buy it because it has good audit logging, works with Cisco's NAC, and checks that all-important little box off about "do these machines have antivirus on them?".
If SEP wasn't able to report that machines were up to date, didn't lock out "hack tools", and didn't work with the healthcheck features, then Symantec would be in a world of hurt.
As for security, even with source code out, it might hurt some things, but zero day exploits are still zero days, and few AV products actually protect against the primary source of infection these days, which would be infections through compromised ad servers that serve up attacks against Web browsers or browser add-ons. The only thing that comes close is Malwarebytes IP address blocking.
Compression comes into handy for dealing with directories full of log files.
File level encryption is useful for volumes where BitLocker can't be used.
Sparse files are extremely useful.
As for quotas, unless they have another layer for warning/enforcement, how will places keep users from filling up their home directories?
I'm hoping ReFS is up to ZFS with needed features, such as deduplication, encryption, an analog of RAID-Z, the filesystem working with the LVM layer (or even replacing it), and so on. Otherwise, people will just shrug and keep NTFS as their default fs of choice because it has been around for so long.
It isn't that 4E is bad per se, but there is a marked difference between a 3/3.5/4E campaign versus 1E, or even D&D (before the "A" was tacked on.) The big difference is that you have to be a better DM with 1E to deal with some gaps in the rules.
In general, a 1E campaign, magic items were relatively rare. Crafting one took a high level (perfect item + enchant + permanency + a possible wish spell if one wanted more than a "+x" bonus). 3+E, they can be crafted once people get up to a skill level fairly easily.
1E also had class imbalances, which the DM needed to be good enough to fudge around. Especially when characters got around level 10 and they had to bump off NPCs in order to advance in rank.
I'd probably go for DM-ing a 5E campaign. Mainly because it would be interesting converting a campaign that has been around for a long time to the latest rules and how it would work. Especially with magic being relatively rare at the outset, versus the player skill of being able to craft items.
30 minutes is good in the lab, but in reality, we need WORM technologies to be readable for a lot longer than the stated 10^5 seconds. We need readability in decades or centuries for the underlying medium, and that is before we slap the ECC layer on top to deal with bad sectors/blocks and such.
What might complement this technology would be developing a way to cause the DNA to polymerize (similar to how organic tissue is preserved in "Bodies: The Exhibition"), so once it is written, it stays in that form for a far longer period of time.
That is my complaint as well, that and the fact that classes really don't mean as much.
Call me old, but one of the things about First Edition is that you had to be a REALLY good player, or else you would die, die fast, and die permanently. +1 swords were not dug out of trash barrels, they were usually something obtained at the end of a module, and only if the hidden treasure trove was found.
There is something about old-school DM-ing. With the advent of MUDs and MMOs, people have become attached to their characters, so perma-death is something that isn't wanted these days. as a good DM, it took a balance between "oops, Flark is dead, thank you drive through" versus a Monty Haul campaign where the PCs could not be killed off.
What I do to get around 1E's fast character death (and trust me... in a 1E world, there isn't a Temple of Cant around the corner to pay a couple gold pieces at and res a comrade... once dead, finding a high level priest/priestess was a quest in itself,) was to have three types of characters that players could play (and other players did not know this info), "Meat/Red Shirt" characters which were meant to die immediately, to keep the "life is cheap" aspect going, "normal" characters, and "main" characters. If a player played a "meat" character, their "main" character got a boon to keep from dying. A "normal " character was halfway to a death prevention mechanic. This way, players could play one shot characters to add to the flavor of the game, or their "mains" which might get bounced around a lot, but it would take some significantly poor roleplay to get them killed.
It resulted in some interesting campaign questlines. The "meat" character with the ring of three wishes using it with the "gee, I wish something really exciting would happen to all of us" for example.
That reminds me of the old TRS-80s with MS-DOS in ROM. The version on the HDD not booting? Boot from ROM and even though it may be a "1.0" version with no updates, it will at least get you somewhere.
With flash so cheap, why can't this be on motherboards that are licensed for Windows? It would make needing recovery media a non-issue.
What I'd do is similar to what the parent suggested. The Windows 8 install media in ROM. No write access allowed, no way, no how. Another boot partition with Windows 8 that can be upgraded via signed updates (with the BIOS checking signatures, and with the option to load custom images so one can load another OS if they so chose.) Ideally, the updated OS install would not just be service packs, but monthly fixes, so if an install is required, it won't take numerous updates to get it to the latest security patch level.
This functionality could be mainly hidden, where on a reboot, the user could do the "press F11 to go into restore mode" and go from there. Since the "Press F11" bit would be done by the host OS, the only thing malware could do is try to do its own "Press F11" in hopes of catching the user after it is too late for a normal boot.
Heck, this could even be done in BIOS, where one can go into that to edit/delete/restore snapshots.
You are 100% right -- the guest OS shouldn't even know about the hypervisor, much less have access to it.
Of course, there would be an additional advantage of this hypervisor setup -- the ability to do completely hot image based backups to another drive. This way, a restore would just be pointing the hypervisor to the virtual disk and copying that back to the main drive.
Already going on. I've de-loused boxes where not just the original OS partition were infected, but files were copied over to the recovery area as well so that would cause a re-infection if the box was recovered from it.
To mitigate that, on one hand, it would be nice for BIOSes to have a way to recognize signed copies of install images, check the signature and report if something was tampered with. On the other hand, it would be yet another mechanism to lock out Linux and anything but Windows.
Maybe the solution would be a built in flash drive with a read-only (as in hardware enforced) copy of Windows + recovery tools. The BIOS could turn this on when asked, and when the box is completely installed, disable this drive (so as not to use up valuable drive letters.) It might suck having to install that, then go through the service pack process, but at least there is a known good install ready to go.
I wonder if MS might be better off using Hyper-V and having Windows 8 run under that, where the hypervisor can save off snapshots on a filesystem that is deduplicated. This way, it can save snapshots often of the machine while the user can go their merry way. If the user decides to do a "reset", it can be done immediately, but a snapshot of the current volume is taken just in case the user forgot to save off some critical documents, and needs to undo the reset.
Having Windows 8 run under Hyper-V and snapshot functionality might allow the user to completely roll back to a pristine OS copy, while leaving everything in \Users\username\Documents completely alone.
I'd consider keeping more than that:/usr/local should be kept, or at least renamed./etc should be moved aside due to config files./var usually has a bunch of data on it that might be useful, so if it gets tarred, compressed, and set aside, it can't hurt./boot might be good to keep too, just in case a custom kernel is in use.
Of course, there is/opt, which can be independent of the OS, but might not be (as in the case of Solaris).
Maybe the best route would be those directories getting tarred and compressed (bzip2), and set some place, perhaps on their own logical volume that can be deleted and/or resized at any time.
Slashdot Mirror
Android has a perfect storm for this to occur:
1: There is a low barrier for entry. One gets Eclipse, some Java tools, the Android SK, and they can write APK files. $25 later, and one can upload into Google's store. Apple is $99/year, and it requires going into ID theft territory to create another account if Apple drops the axe on an app developer. Android development can happen on Windows, Macs, and Linux. XCode only can happen on one platform, be it a true Mac, or a hackintosh.
2: Android is used on inexpensive smartphones. This makes it a very popular platform in China, India, and other nations developing an ecosystem, as well as countries that separate the phone from the provider. So, there are a lot of the devices out there. iOS devices are very popular, but not as common and wide ranging as Android models.
3: Android's permission model is strong, and rooting does not affect security in the slightest. An installed app won't get anything that it does not have access to, unless it manages to pull off some successful root exploit (which is difficult as the app has to escape the Dalvik VM first.)
Where the problem happens, is that permissions are not fine grained enough. Combine this with the user training to mindlessly click on any button labeled "send/accept/OK/submit/pay/download", and an app can be tossed on a device that shouldn't have anywhere near the permissions it requested. For example, a game does not need access to a contact list.
What would be nice is if Google went back to the modal dialogs with the permission contents in them, forcing a user to look at it, as opposed to displaying them below the button that allows for a quick double-tap purchase.
3: The current Google app repository is more of a marketplace than a store. The good thing is that a developer can have an extremely tight and fast feedback cycle, churning out updates hourly in some cases without having to wait for a bean counter to approve them. The bad thing is that apps that are not vetted can be an avenue for malware.
4: In some countries, pirated apps are the norm, so finding a bunch of Angry Birds APK files that have the LVL code yanked is the norm rather than the exception.
All and all, this isn't really Google's fault -- Android went from being on the sidelines to a mainstream OS in remarkable time, especially with the fact that iOS was well entrenched with an App Store. Android matured from doing the basics to an OS that is not just consumer-friendly, but can support the needs of businesses with Exchange support.
This is anecotal, but in the US, I'm sure the chance of a malicious app is low, even an inexperienced user just clicks on download, then accepts without looking. A clued user can look at reviews, discount the vague ones that are shills, and look for the scathing reviews. For example, a game that popped up also brought along with it some adware, and it was obvious with the 1-2 stars it was rated that something was afoot. A couple reviews of "one star, spams contact list" will sink an app before Google comes by with the ban-hammer.
I stated this in another post, but I still think that the current Google Marketplace structure is well done. However, a significant improvement would be a tier of service of Google actively vetting apps, where an app developer who pays for the higher level of assurance (since black box reviewing of apps does take time and money) can release an app as normal. Then, Google can sign that version when they get done reviewing, and this can be on their own schedule. A subsequent update would be allowed on the store, but it would be unsigned until Google reviewed and approved it.
This way, phones can ship by default only allowing Google-vetted apps. If a user wants to get other apps, they can answer a warning dialog about doing so at their own risk [1].
IMHO (and I've stated this before): If Android devices shipped with a store/marketplace/repository that hand-approved apps (with facilities for allowing full
With iOS, there is not much one can do about malware, if it gets past Apple's gatekeepers. JB-ing the device and slapping on Firewall iP is probably the best thing one can do. However, the barrier for entry for malware writers is very high. It is pretty difficult (and more expensive) for a blackhat organization create a new account with Apple , paying them a C-note a year), and cook up some personal info (like bank accounts and such to register under) to even be able to see iTunes Connect, much less have the app approved. This has done a good job in keeping iPhone users safe, although in theory, if an app decided to have some type of module that would allow code execution, users would never know about an app that would be slurping contact info, E-mails, and other items then shipping that off to a blackhat server, especially if the app was smart enough to do it only on Wi-Fi, or a small trickle over 3G.
Because of this, the only permission iOS asks for is for using the GPS. Since the App Store does all the work essentially, there isn't that much of a need to have anything more than that.
Even with Firewall IP, there is no protection against apps deciding to spam with SMS, other than Apple's gatekeepers.
So, Apple's security model may have some (in theory) bad flaws, but it has proven to be decently tight, with exploits being used for jailbreaking as opposed to turning the device into a mobile money machine for criminal organizations.
Android's model is more robust in some ways. If Android phones were shipped with a marketplace that vetted/approved apps [1][2], this would virtually eliminate compromised phones [3].
The nice thing about Android is that even with full root and a custom ROM, app security is just as tight as it is on a vendor ROM. Unlike jailbreaking on iOS which completely creams the security model, apps on Android still function exactly the same on a rooted phone, other than being able to prompt the user for su access.
Since Android isn't reliant on a store's gatekeepers, its permission model has to be robust. It has been OK so far, provided users read and disallow apps like a game demanding full access, but it would be nice to have a better model -- something along the lines of minimum permissions needed to run the app, optimal permissions, and maximum permissions (a notepad app that just stores notes in its directory generally does not need full access or access to root unless it has some special features.)
What can help Android immensely would be an app that runs as root and can allow/disallow access to SD cards, contacts, SMS, phone, and networking. There is an app called LBE Privacy Guard which runs as root and offers features that should really be part of Android (perhaps some features behind an Advanced menu.) CyanogenMod also has similar features for restricting access.
Another app that is a must have for rooted devices is DroidWall, which is essentially a shell for performing iptables commands. This is an immense help because it can not just block network access for apps, but limit the bandwidth hogs to Wi-Fi (or security sensitive apps to 3G).
Pretty much for the tl;dr in all of us, Android would be best off with two tiers of stores, and having the user go through a dialog of "these apps are untested, but the reviews will be a good guide. Use at your own risk" before a user gets access to the free-for-all market. Couple that with the functionality of DroidWall and LBE Privacy Guard which can be set to prompt/allow/deny access to critical things (contacts, network, phone, SMS) integrated into the OS, and Android would be a lot more secure.
[1]: Amazon is good at vetting apps, and it would be nice for Google to offer two tiers of their Marketplace, where one tier would be the current free-for-all, while having another tier (which would cost app developers more because of the time taken) just for apps that would have a "blessed" flag attached.
[2]: It goes without saying to have a way to add more stores, or if Google w
I'd disagree. Yes, there are other video sites, but a lot of them use dodgy ad rotators that serve up exploits, require Web based add-ons or codecs (which likely are exploited), or just won't display on most machines.
Youtube is nice because it won't just give you the middle finger if you decide to browse it on your iPad; most other vid sites, the only thing you will be viewing is a link to Adobe to download Flash, Shockwave, or RealPlayer.
Who knows... a blackhat might have been using the USB flash drive for storing their cache of stuff when it was plugged in to a compromised computer.
Here in TX, there are vans which actually aim a laser at exhaust to try to detect those types of things, and pull people over immediately and impound their ride.
What is affected is tuning the engine, such as giving a couple better horsepower, changing response of the transmission, changing shift points, advancing timing to get a better burn with higher octane gas, etc. In fact, sometimes you can tune some engines where the MPG gain from using premium unleaded is more than the difference in cost.
Tunes is what car/engine makers are trying their best to stamp out. Some car makers have explicitly told their dealers to look for traces of tunes and mark warranties void if found. Other vehicles will just deactivate until completely re-flashed at the dealer.
Why are car makers wanting to do this? Some day that it keeps them from adding 2-5 horsepower per year to their vehicles as a selling point. Others just are protective of their engines and view consumers modding their stuff as scumbags.
On one hand, it would be nice to have sunset provisions, but in reality, I can see what would end up sunsetted if this happened:
The Clean Air/Water Acts.
Acts making national parks/preserves/national forests.
Labor laws.
Minimum wage.
Bank regulations.
Believe it or not, on some makes of cars, the ECM/TCM will check if it is tampered with, and when taken to a service depot, the entire warranty will be voided.
It took about a year for people to "jailbreak" the latest EcoBoost engines so one can run a custom tune on them.
Expanding on that idea, I would like to see a kiosk that has a book printing/book binding press, a small 3D printer, and a stack of blank media that can be programmed and automatically embossed with the game title. HP LightScribe media comes to mind for this.
This way, a publisher can not just have a cool game and printed media, but have it come with a manual, and perhaps some tokens made with the 3D printer as well. This might bring around a revitalization of the game industry. To boot, game manuals can stop being a four page flyer, but actual books with background and other stuff with the game, so they in themselves would be keepsakes.
As for DRM, the best I have seen is what Bioware did in NWN1 -- you need a CD key to use their multiplayer system (which is only fair because pirating a game is one thing, leeching time and CPU power is another.) The pirates won't be stopped, the used market is still unaffected, and well-written DLC will help make up the difference.
It might just give impetus for more indies to hit the PC game market where the barrier for entry is basically paying for an Authenticode signing key, or a yearly membership for use of iTunes Connect. Instead of paying $60, one can pay $20 for a game like Torchlight that may not have the latest and greatest eye-popping graphics, but is very playable.
Consoles may be hitting the skids, but with the fact that stores/repos/markets are becoming commonplace, it isn't hard for an indie to get in the ball game and be a link away from having a good game. Possibly another ID with an awesome game demo might even appear.
Isn't forcing a business to take expenses such as having to buy an EMC VNX SAN a tax?
This is pretty much taxation without representation, unless the HI government is willing to spend the money to hand each ISP the proper disk space to do this.
The more governments and ISPs press this, the more people will go to VPS services. Offshore VPS services in countries that have real privacy laws (Sweden/Switzerland), or in nations hostile to the US.
Then, the serious computer crime cases will be impossible to investigate because everything from the endpoint on up would be encrypted.
Of course, the next step is doing like Pakistan and banning VPNs, but that will start a cat and mouse game. Yes, it can be won by using a Great Firewall-like system, but even that isn't a total victory.
I can see why in the US there is such resistance to autonomous vehicles: Small towns and counties depend on driver error, be it speeding, red light cameras, or stuff like that for revenue. An autonomous system means that everyone will be going the speed limit, so no tickets (and no chance at finding marijuana and thus earning a civil forfeiture prize) will be given.
This is sad because the US is the perfect place for autonomous vehicles -- most cities are too sprawled out for even buses to be reliable, much less light rail. So, vehicles that drive themselves would be ideal because it would allow long distances to be covered with vehicles packed in as much as their computer and mechanical systems would allow, compared to current driving conditions which depend on the driver's ability/reactions (or lack of when compared to a computer.) Even for people who don't own a car, it wouldn't be hard to have a Car2Go/Zipcar like service.
Even more ironic, with computer controlled cars, it would lesson the need for more and more highway improvements. Cars can be sped up or slowed down to allow vehicles in and out, they can be moved into lanes depending on their destination, and if there is a vehicle problem, it can be moved to the side of the road and traffic routed around it without putting the highway out of commission for hours on end. This would save a municipal area far more money than they ever would earn by speeding tickets.
In reality, the defense lawyer will argue that, while the prosecuter will then rebut with "realistically, would someone actually do this?"
A jury of /.-ers would acquit, or nullify. However, even though we wish that we would get a jury of our peers in cluefulness, most likely the jurors picked will have almost zero clue what a MAC address is, so a good prosecutor setting up a case can say something like it is impossible to forge with almost no real life cases. With this in mind, plus a "ignore the defense's mumbo-jumbo", and a jury with glazed eyes and a brain full of buzzwords they don't know or understand will likely convict... just so they can go back to Mike's Watering Hole and swill some Duff before traffic gets bad.
I should have been clearer: The write blocker is used to dd the hard disk to another drive (or virtual drive) for forensic research. This way, the contents of the original drive are guaranteed to be untouched.
This has been talked about on the TrueCrypt forums ad nauseum: A suggestion that the utility has a password that would erase volumes.
First, it is part of forensic practice to whip out a hardware write blocker. No hardware write blocker, and the evidence can be thrown out of court.
So, if someone hands a decent forensic analyzer a key, and it zaps the contents of the image, they just roll back the logs, add a destruction of evidence charge.
Realistically, it probably wouldn't affect a single sale. The reason is that companies buy SEP not because of its virus stomping capability. They buy it because it has good audit logging, works with Cisco's NAC, and checks that all-important little box off about "do these machines have antivirus on them?".
If SEP wasn't able to report that machines were up to date, didn't lock out "hack tools", and didn't work with the healthcheck features, then Symantec would be in a world of hurt.
As for security, even with source code out, it might hurt some things, but zero day exploits are still zero days, and few AV products actually protect against the primary source of infection these days, which would be infections through compromised ad servers that serve up attacks against Web browsers or browser add-ons. The only thing that comes close is Malwarebytes IP address blocking.
Some of those features are actually useful:
Compression comes into handy for dealing with directories full of log files.
File level encryption is useful for volumes where BitLocker can't be used.
Sparse files are extremely useful.
As for quotas, unless they have another layer for warning/enforcement, how will places keep users from filling up their home directories?
I'm hoping ReFS is up to ZFS with needed features, such as deduplication, encryption, an analog of RAID-Z, the filesystem working with the LVM layer (or even replacing it), and so on. Otherwise, people will just shrug and keep NTFS as their default fs of choice because it has been around for so long.
It isn't that 4E is bad per se, but there is a marked difference between a 3/3.5/4E campaign versus 1E, or even D&D (before the "A" was tacked on.) The big difference is that you have to be a better DM with 1E to deal with some gaps in the rules.
In general, a 1E campaign, magic items were relatively rare. Crafting one took a high level (perfect item + enchant + permanency + a possible wish spell if one wanted more than a "+x" bonus). 3+E, they can be crafted once people get up to a skill level fairly easily.
1E also had class imbalances, which the DM needed to be good enough to fudge around. Especially when characters got around level 10 and they had to bump off NPCs in order to advance in rank.
I'd probably go for DM-ing a 5E campaign. Mainly because it would be interesting converting a campaign that has been around for a long time to the latest rules and how it would work. Especially with magic being relatively rare at the outset, versus the player skill of being able to craft items.
30 minutes is good in the lab, but in reality, we need WORM technologies to be readable for a lot longer than the stated 10^5 seconds. We need readability in decades or centuries for the underlying medium, and that is before we slap the ECC layer on top to deal with bad sectors/blocks and such.
What might complement this technology would be developing a way to cause the DNA to polymerize (similar to how organic tissue is preserved in "Bodies: The Exhibition"), so once it is written, it stays in that form for a far longer period of time.
That makes me eel...
That is my complaint as well, that and the fact that classes really don't mean as much.
Call me old, but one of the things about First Edition is that you had to be a REALLY good player, or else you would die, die fast, and die permanently. +1 swords were not dug out of trash barrels, they were usually something obtained at the end of a module, and only if the hidden treasure trove was found.
There is something about old-school DM-ing. With the advent of MUDs and MMOs, people have become attached to their characters, so perma-death is something that isn't wanted these days. as a good DM, it took a balance between "oops, Flark is dead, thank you drive through" versus a Monty Haul campaign where the PCs could not be killed off.
What I do to get around 1E's fast character death (and trust me... in a 1E world, there isn't a Temple of Cant around the corner to pay a couple gold pieces at and res a comrade... once dead, finding a high level priest/priestess was a quest in itself,) was to have three types of characters that players could play (and other players did not know this info), "Meat/Red Shirt" characters which were meant to die immediately, to keep the "life is cheap" aspect going, "normal" characters, and "main" characters. If a player played a "meat" character, their "main" character got a boon to keep from dying. A "normal " character was halfway to a death prevention mechanic. This way, players could play one shot characters to add to the flavor of the game, or their "mains" which might get bounced around a lot, but it would take some significantly poor roleplay to get them killed.
It resulted in some interesting campaign questlines. The "meat" character with the ring of three wishes using it with the "gee, I wish something really exciting would happen to all of us" for example.
That reminds me of the old TRS-80s with MS-DOS in ROM. The version on the HDD not booting? Boot from ROM and even though it may be a "1.0" version with no updates, it will at least get you somewhere.
With flash so cheap, why can't this be on motherboards that are licensed for Windows? It would make needing recovery media a non-issue.
What I'd do is similar to what the parent suggested. The Windows 8 install media in ROM. No write access allowed, no way, no how. Another boot partition with Windows 8 that can be upgraded via signed updates (with the BIOS checking signatures, and with the option to load custom images so one can load another OS if they so chose.) Ideally, the updated OS install would not just be service packs, but monthly fixes, so if an install is required, it won't take numerous updates to get it to the latest security patch level.
This functionality could be mainly hidden, where on a reboot, the user could do the "press F11 to go into restore mode" and go from there. Since the "Press F11" bit would be done by the host OS, the only thing malware could do is try to do its own "Press F11" in hopes of catching the user after it is too late for a normal boot.
Heck, this could even be done in BIOS, where one can go into that to edit/delete/restore snapshots.
You are 100% right -- the guest OS shouldn't even know about the hypervisor, much less have access to it.
Of course, there would be an additional advantage of this hypervisor setup -- the ability to do completely hot image based backups to another drive. This way, a restore would just be pointing the hypervisor to the virtual disk and copying that back to the main drive.
Already going on. I've de-loused boxes where not just the original OS partition were infected, but files were copied over to the recovery area as well so that would cause a re-infection if the box was recovered from it.
To mitigate that, on one hand, it would be nice for BIOSes to have a way to recognize signed copies of install images, check the signature and report if something was tampered with. On the other hand, it would be yet another mechanism to lock out Linux and anything but Windows.
Maybe the solution would be a built in flash drive with a read-only (as in hardware enforced) copy of Windows + recovery tools. The BIOS could turn this on when asked, and when the box is completely installed, disable this drive (so as not to use up valuable drive letters.) It might suck having to install that, then go through the service pack process, but at least there is a known good install ready to go.
I wonder if MS might be better off using Hyper-V and having Windows 8 run under that, where the hypervisor can save off snapshots on a filesystem that is deduplicated. This way, it can save snapshots often of the machine while the user can go their merry way. If the user decides to do a "reset", it can be done immediately, but a snapshot of the current volume is taken just in case the user forgot to save off some critical documents, and needs to undo the reset.
Having Windows 8 run under Hyper-V and snapshot functionality might allow the user to completely roll back to a pristine OS copy, while leaving everything in \Users\username\Documents completely alone.
I'd consider keeping more than that: /usr/local should be kept, or at least renamed. /etc should be moved aside due to config files. /var usually has a bunch of data on it that might be useful, so if it gets tarred, compressed, and set aside, it can't hurt. /boot might be good to keep too, just in case a custom kernel is in use.
Of course, there is /opt, which can be independent of the OS, but might not be (as in the case of Solaris).
Maybe the best route would be those directories getting tarred and compressed (bzip2), and set some place, perhaps on their own logical volume that can be deleted and/or resized at any time.