I think their next step is going to be wringing their hands in front of Congress asking for tougher laws against "hackers". Laws demanding hardware DRM stacks, ACTA, Son-of-ACTA, and other stuff (which have little to do with hacking, but a lot to do with basic free speech.) I'm sure they will be labelling the people who "jailbroke" the PS3 as the same people who stole their credit card data.
I doubt it. Come September, things will be exactly business as usual with the PSN breach completely forgotten about by then.
I also doubt Sony lost much money. They might have lost a little bit handing out subscription time to compensate, as well as hiring some consultants to maybe add an IDS/IPS system in some places. However, realistically, their losses from the PSN breach are negligible, probably less than it costs to do a promotion of a new game.
Call me cynical, but a lot of firms know that they can skimp on security because it doesn't make them money. If they get breached, they make a token effort to "clean it up", and business goes on. It is going to take governments stepping in, and having nasty criminal/civil consequences happen to companies who go lax on internal security for this to ever change.
That looks interesting. I'd like to see some type of hybrid between Apple's model of each app has its own filespace and can't touch any others unless via a few links, and Android's where an app with permissions can do stuff with another app's files.
Perhaps a two tiered model? Most apps wouldn't need to see anything out of their own filespace anyway, especially games. Then another tier for apps that need to see outside their own filespace such as backup programs, UNIX commands and the command shell/terminal emulator. This way, most apps function like standard iOS apps, but when a user wants to just pop open a command shell and edit files manually, they are free to do so.
Apple really needs to toss some of the cash it is sitting on for enterprise level features. Some ideas:
1: No, the XServes didn't sell. How about a redesigned Mac Pro case that can work vertically, as well as have the ability to have rack ears attached and work horizontally, sliding out on drawer slides? Add to it two power supplies, keep a RAID chassis, and it can be enterprise level for servers. This way, one model serves two niches.
2: 24/7/365 support for the model mentioned in #1, with 4 hour response.
3: More enterprise management tools for Windows-based IT shops.
4: TPM chips, plus a BitLocker-like way of pulling a key out of the TPM. Combine that with Lion's hard disk encryption, and it can make a decently secure laptop, suitable enough for the enterprise.
5: Backend apps. I'd love to see a true and complete replacement for Exchange that used OpenDirectory or OpenLDAP, and supported the Exchange features (replication, edge/hub transport, archiving, retention, etc.)
6: Real SAN support. Not just FC HBAs, but supported FCoE CNAs in pairs (for redundant pathing.)
7: TRIM support in the OS, so it can work with enterprise SSDs.
8: More SAN friendly features. It would be nice to completely boot Macs from the local EMC or NetApp backend.
9: ZFS, or a ZFS-like filesystem, with encryption, compression, deduplication, snapshotting, dynamic resizing, etc.
10: Lights out management/remote consoles on a hardware level. This way, a Mac that is dead in the water at a remote site can have its NVRAM cleared, pointed to bootable media, and restarted.
11: A SAN solution. The case should be similar to #1 with a case that works as a tower, or sliders attached and stuck in the rack. It should have disk connections (FCoE, 8GB FC, Thunderbolt), but also network connections (CIFS, AFS, etc.) The advantage of having a case that doubles as a tower/rackmount is that it can work perfectly as desktop disk expansion similar to a Drobo, except sport midrange SAN features (LUN presenting, snapshots, autotiering, replication between two SAN boxes, etc.)
For a large enterprise, the TCO of Windows may be lower because of all the management tools available for the platform.
For a home user, the TCO of a Mac may be lower because Macs tend not to have to be reinstalled (few home users actually keep their Windows media, so it necessitates a new copy of the OS). Combine this with the fact that Apple is the only game in town for decent consumer level CS [1], and at that level, Macs can be worth the price of admission.
If I was sitting on 1000 computers and needed policies to make the legal eagles happy, with finance getting one set of rules, dev another, IT another, etc., I'd go Windows, because in this arena, it is the best for ease of managing on a large scale.
If I was going with a department that just needed office/clerical applications, I'd go Mac. On a small scale, it gives fewer headaches, and I can define policies (password changes, etc) in OpenDirectory. If I needed Exchange capabilities (most companies do after a certain size [1]), I could hang the machines off of AD as well.
If I wanted a Windows alternative for basic desktop work, and the hardware was generic PC stuff, and I wasn't worried about 100% Word compatibility, I'd go RedHat or SuSE on desktops.
Easiest to manage on a departmental scale -- Linux.
Best combination for application compatibility plus security and manageability on the department/workgroup level, while giving few malware headaches -- OS X.
Best for enterprises where one has to deal with Sarbanes-Oxley, audits, ISOyadda checks, etc. -- Windows.
[1]: I'm not a fan of Exchange, but realistically, it is the only game in town if you need tools for archiving, SOX/HIPAA/FERPA compliance, replication, and other things the PHBs want.
There are better explanations of the fragmentation down below, but one needs to remember, these 35 people are all volunteers. These are people who try to give their time when possible, but may not be giving as many hours that a full time developer would be doing for earning his/her main income.
It only applies to rooted devices. The su mechanism consists of two items:
The binary, natively compiled from ARM.
The app, which is a Dalvik VM.
When a program invokes the su binary, it checks to see if the app is allowed or denied access without prompting, if denied, just denies it, moves on. If neither denied or allowed is listed, it prompts the user to allow or deny the app, as well as save the decision. If the user allows it, or if the app is listed as being allowed without prompting, the program gets access as UID 0.
Some apps (like the 1.0 Blizzard Authenticator) try to su to root to determine if the phone is rooted, and print out a warning message or even stop working. Other apps might ask for root for legit reasons (a file manager, or a terminal emulator), still other apps will ask for root for nefarious purposes.
I am not sure the best way to test where in your code the su dialog is popping up... perhaps root a test Android device and set breakpoints?
The Cyanogen people have a lot to lose if their ROMs are found to be corrupt. Same with a lot of other top tier ROM "cooks". However, it wouldn't take much for someone to upload a bongoed ROM. That is why its good to see if someone updates a ROM and what people think of the package. Of course, this isn't a 100% guide, but better than nothing.
As always, you can just root the phone without changing ROMs.
If you have good front end encryption [1] with a solid implementation, it shouldn't matter if you store your files on a public FTP server. DB has been discussed about security, but this is mitigated almost completely by proper encryption.
Of course, this doesn't prevent big names from either using a (theoretical weakness) in the algorithm, or resort to rubber hose decryption, but if done right with encryption, and a suitably long passphrase (TC states 20+ characters), storing data on the cloud can be made relatively secure.
[1]: Solid algorithms (AES, RSA), done in a proper fashion (NOT ECB), with a salt, proper HMAC, etc.
Don't forget that Thunderbolt will also replace the VGA/DVI connector on a machine, either directly, or using an adapter. Because an adapter can be used, PC and motherboard makers have zero to lose by changing to this for video out on laptops, where space is a premium. Desktop video is still a tossup, but a video connector that takes less space and also supports a high speed interface would be welcomed.
It is a Linux kernel, but the userland is very different. Root is there, but apps have their own UIDs, and almost all the UNIX command lines are links from busybox [1]. To prove this, try getting gcc to work natively on Android.
It really can't be run like a Ubuntu box -- users by default don't even have root access on almost all Android devices. Instead, you have to be careful on the app level.
[1]: Busybox is (IMHO) one of the few programs that just is pure awesomeness in its functionality.
Take these for what they are worth, but here are my security practices:
1: Install DroidWall and use that to lock down everything except the apps you do want going out.
2: Use TouchDown or a discrete app for secure Exchange email. This allows you to keep contacts separate from the rest of the device, and the app can keep the contacts encrypted. If it is work E-mail, it is good to keep it separated anyway.
3: Consider a PIN protecting app for #2 above, as well as your terminal, settings, and su app.
4: Use Titanium Backup with the encryption feature and store on Dropbox. If you look at TB, you will find that the way it does encryption using RSA keys is pretty well designed, so storing backups of apps on DB can be done securely.
5: Get a utility (I use WaveSecure out of habit, but there are others) that will lock the phone if the SIM card is changed, airplane mode is put on, and even allow one to remotely wipe the device and SD card. I'd like a utility that would give the ability to wipe the device and SD card if the phone has not seen Net access in "x" amount of time, similar to what BlackberryOS provides.
6: Look at reviews before buying apps.
7: Look at what the app asks for security permissions. If a notepad app wants access to your contacts, phone, SMS, or perhaps even pops up the su dialog, get rid of it ASAP.
8: If you use nandroid, consider some type of file encryption. This sucks when restoring a ROM image, but there are ways around that (decrypting the image while the SD card is mounted via USB, using a temporary ROM image with no data for decrypting, etc.)
9: Use AdBlock with Dolphin Browser. Ad rotation services are a noted source of malware.
10: Use known ROMs. The ROM ecosystem has been astoundingly clean for now, but it is only a matter of time before blackhats start adding their own "functionality" and putting ROMs on xda-developers and other sites.
11: Consider PIN protecting your SIM card. This way, when you do a remote erase, the thief might have a clean phone, but won't have free access to bandwidth, SMS, or calling capabilities.
12: Consider a "stuffbak" sticker. If the phone is found, at least there is a small chance it might get back to you, as opposed to 0 chance without it.
13: Keep backups. This way, if you do lose your phone, you can get another Android phone, fire up Titanium Backup, log onto DropBox, type in your decryption key, and restore your apps with their saved data.
14: Bug Google for them to put volume encryption (LUKS) into Android, so it can be used on the SD cards.
More specifically, root your Android phone (no, it will not lessen security unless you are stupid and click "allow" on any app that pops up the su dialog unless you KNOW it needs the root permission.)
Install DroidWall and allow it full su access. Then when you install a new app, make sure to allow it out, because by default, new apps are not allowed to phone anywhere. LVL is handled by another mechanism, so apps should know they are licensed even if you block them with DroidWall.
After installing DroidWall, and selecting the apps you know that need to communicate, that will provide a decent measure of protection.
I have seen hardware failure in every offering, given enough of them. Name the computer maker, given enough time and enough machines, some will have problems. However, this is why a company purchases premium support and business-grade machines so a DOA box is minimized.
A consumer doesn't have that luxury of buying enterprise level 24/7/365 support. So, if something goes TU, being able to take it to a physical location (or have someone come onsite) and get it taken care of (versus having to package it up and sent it to a depot for 6-8 weeks) is a big difference. Especially for computers that people depend on for daily income.
The coolest anon server I saw was one that would check files once the connection was closed. If they were not encrypted with a PGP key assigned to the server, the file was wiped on the spot. The checking mechanism was in multiple parts too, so it would do a quick PGP/gpg header check, if that wasn't present, chuck the file, then check to see if it was encrypted to a certain key ID.
Users that needed to upload files could easily do so. Combining normal write only permissions with the fact the server erased contents if they were not encrypted to the server's key (making the files unusable to anyone else) also ensured that the warez hounds seek storage elsewhere.
Apple's CS by itself, is a big sell in its favor. Bought a Mac, bad RAM... they did a machine exchange on the spot. iPhone had some bad flash storage... 10 minutes, the SIM card was swapped and I was good to go with a replacement unit.
For nontechnical people, being able to call one number for a problem, be it hardware, OS, or even the app makes the Apple Tax worth it, especially if they make their living from the computer.
PC makers also offer good support, but you have to buy their business line of machines (Precisions, Optiplexes), and their top tier support contracts. This is the par for companies, but for individuals, Apple has the best CS for the large computer makers.
That sums it up right there. Why? Lots of reasons:
1: A honeypot might get someone in legal hot water if someone then launches criminal activity from it. For example, if someone's honeypot was used for torrents or CP, it will be tough explaining to cops (or the RIAA's pet judge) that the owner knowingly allowed such activity to happen and hoping not to get found culpable/convicted.
2: FTP for anonymous downloads is one thing (assuming a hardened FTP server.) Anonymous uploads can be done too, provided you clean the incoming directory. FTP for users with passwords sent plaintext is just bad form. Use sftp, or scp for this.
3: Before '97, you could call an ISP or other domain and deal with someone who would be ready/willing/able to stop someone hacking from a site. These days, nobody cares, especially offshore domains. IP address banning is noble, but just not running the service unless needed is the best bet.
4: Even with IP banning, it won't do much. Blackhats have a crapload of bots on wide IP ranges. Better to just figure out what ranges to allow and deny everyone else.
5: Passwords should never be used anyway. Use S/Key or OPIE if one can't authenticate using two factor stuff. Best of all, use public key authentication over ssh. This way, there is no way a brute force attack could succeed, if the SSHGuard program or other anti-guessing daemon doesn't work.
You hit the nail on the head. Most users keep their valuable stuff in the same user account as what they use for Web browsing. Because of this, a Web browser that is always dealing with untrusted and potentially malicious code runs in the same context as someone's financial applications.
What is needed is a finer grained context mechanism. Perhaps give apps their "home directory" where not just their preferences files go, but documents as well. Essentially combine AppData and Documents on Windows. This way, a Web browser cannot access Excel's files by default.
For users to simplify things, an abstraction layer for the Documents directory can be created, essentially creating links from all the application/Document subdirs to one Document directory. This way, the user doesn't have to care if the file is in the Excel data directory or the Word one.
Of course, there have to be ways to get around this, for example allowing archiving utilities to do their job, or to allow Acrobat to parse Word documents for PDF creation. Ideally, asking for permissions at install would be the best way, with the ability to deny permissions (so it isn't all or nothing as it is with Android.)
If done right, the user wouldn't notice anything different -- his documents are in the Documents folder, or perhaps on the desktop. However, malicious software that takes over an app would be hard pressed to try to get to the user's other files.
A brick and mortar "Linux Store" would be cool, especially if in a tech savvy area. I can see it carrying:
Distributions (need a copy of RHEL? Grab a box with the media and a 1-5 year subscription. Some Internet connections, it is faster to drive back with the DVDs than to download and burn the ISOs.)
Bare bones appliance PCs: Need a server that can do routing/firewalling/NAT/squid cache/wireless/Junkbusters/etc? Here is a biscuit PC with a SSD all ready to go. Need a file server? Here is a tower with 16 SATA drives in a RAID 6 configuration, with eight 10GB ports on the back. Need an insanely fast database server? Here is a box with a TB or RAM, a caseful of SSDs, two FCoE CNA cards for hookup to a SAN with multipathing, and the latest Xeon CPUs. Need a box to serve VMs? Already specced out and ready to go.
Books for taking the RHCE or other certifications.
Testing place for RHCE, A+, and other certs.
A place to host the town's LUG, as well as a trading post for people to find or offer work.
Rentable computer labs for being able to do various testing.
A suitable pub. UNIX admins in general demand a suitable establishment that not just has decent drink, but good food. We are not developers, so cheap pizza does not cut it. Linux and homebrew/microbreweries go hand in hand, so a complete Linux shop must sport a high quality brewpub.
To us, asking more than the GNP of the world may seem silly. However, to lawyers, and to a judge that may be extremely loyal to people, that insane verdict may get a rubber stamp.
This is what I fear as well with this case -- like the auto commercial, I fear that the plaintiff in this case will have their motions, "approved, approved, approved" under the guise of "teaching students respect for the law", and with the Supreme Court's decision record, those judgements may even be uphold by them.
People say that, but if one compares the number of security issues in Apache (which is the #1 webserver out there) compared to issues people report in IIS, the argument that Linux or Mac are "secure" because of their marketshare has been disproven.
On the desktop, if Macs had a proportionate share of malware that Windows does, we would know about it, as people would be screaming at Apple on their forums, as well as sites like Macrumors. There is no screaming, so OS X has far less than what the marketshare would expect.
Want to know why Windows gets nailed all the time? It is because on platforms like AIX, OS X, Linux, and others, developers don't shit where they sleep. They know that users can leave their platform if it got a bad reputation. Not so with Windows, and the bad guys know it, so they can churn out the malware without a second thought.
Slashdot Mirror
Show me a FPS where the Red Guard is a target.
The only recent game where I know of where Chinese soldiers were the target of violence was Command & Conquer: Generals, and the Zero Hour expansion.
I think their next step is going to be wringing their hands in front of Congress asking for tougher laws against "hackers". Laws demanding hardware DRM stacks, ACTA, Son-of-ACTA, and other stuff (which have little to do with hacking, but a lot to do with basic free speech.) I'm sure they will be labelling the people who "jailbroke" the PS3 as the same people who stole their credit card data.
I doubt it. Come September, things will be exactly business as usual with the PSN breach completely forgotten about by then.
I also doubt Sony lost much money. They might have lost a little bit handing out subscription time to compensate, as well as hiring some consultants to maybe add an IDS/IPS system in some places. However, realistically, their losses from the PSN breach are negligible, probably less than it costs to do a promotion of a new game.
Call me cynical, but a lot of firms know that they can skimp on security because it doesn't make them money. If they get breached, they make a token effort to "clean it up", and business goes on. It is going to take governments stepping in, and having nasty criminal/civil consequences happen to companies who go lax on internal security for this to ever change.
That looks interesting. I'd like to see some type of hybrid between Apple's model of each app has its own filespace and can't touch any others unless via a few links, and Android's where an app with permissions can do stuff with another app's files.
Perhaps a two tiered model? Most apps wouldn't need to see anything out of their own filespace anyway, especially games. Then another tier for apps that need to see outside their own filespace such as backup programs, UNIX commands and the command shell/terminal emulator. This way, most apps function like standard iOS apps, but when a user wants to just pop open a command shell and edit files manually, they are free to do so.
Apple really needs to toss some of the cash it is sitting on for enterprise level features. Some ideas:
1: No, the XServes didn't sell. How about a redesigned Mac Pro case that can work vertically, as well as have the ability to have rack ears attached and work horizontally, sliding out on drawer slides? Add to it two power supplies, keep a RAID chassis, and it can be enterprise level for servers. This way, one model serves two niches.
2: 24/7/365 support for the model mentioned in #1, with 4 hour response.
3: More enterprise management tools for Windows-based IT shops.
4: TPM chips, plus a BitLocker-like way of pulling a key out of the TPM. Combine that with Lion's hard disk encryption, and it can make a decently secure laptop, suitable enough for the enterprise.
5: Backend apps. I'd love to see a true and complete replacement for Exchange that used OpenDirectory or OpenLDAP, and supported the Exchange features (replication, edge/hub transport, archiving, retention, etc.)
6: Real SAN support. Not just FC HBAs, but supported FCoE CNAs in pairs (for redundant pathing.)
7: TRIM support in the OS, so it can work with enterprise SSDs.
8: More SAN friendly features. It would be nice to completely boot Macs from the local EMC or NetApp backend.
9: ZFS, or a ZFS-like filesystem, with encryption, compression, deduplication, snapshotting, dynamic resizing, etc.
10: Lights out management/remote consoles on a hardware level. This way, a Mac that is dead in the water at a remote site can have its NVRAM cleared, pointed to bootable media, and restarted.
11: A SAN solution. The case should be similar to #1 with a case that works as a tower, or sliders attached and stuck in the rack. It should have disk connections (FCoE, 8GB FC, Thunderbolt), but also network connections (CIFS, AFS, etc.) The advantage of having a case that doubles as a tower/rackmount is that it can work perfectly as desktop disk expansion similar to a Drobo, except sport midrange SAN features (LUN presenting, snapshots, autotiering, replication between two SAN boxes, etc.)
The TCO is so dependant on conditions.
For a large enterprise, the TCO of Windows may be lower because of all the management tools available for the platform.
For a home user, the TCO of a Mac may be lower because Macs tend not to have to be reinstalled (few home users actually keep their Windows media, so it necessitates a new copy of the OS). Combine this with the fact that Apple is the only game in town for decent consumer level CS [1], and at that level, Macs can be worth the price of admission.
For home/SOHO users, yes. However, it is not licensed for 10+ installations. Those, Forefront client does a good job.
I'd argue differently:
Each platform has different strengths:
If I was sitting on 1000 computers and needed policies to make the legal eagles happy, with finance getting one set of rules, dev another, IT another, etc., I'd go Windows, because in this arena, it is the best for ease of managing on a large scale.
If I was going with a department that just needed office/clerical applications, I'd go Mac. On a small scale, it gives fewer headaches, and I can define policies (password changes, etc) in OpenDirectory. If I needed Exchange capabilities (most companies do after a certain size [1]), I could hang the machines off of AD as well.
If I wanted a Windows alternative for basic desktop work, and the hardware was generic PC stuff, and I wasn't worried about 100% Word compatibility, I'd go RedHat or SuSE on desktops.
Easiest to manage on a departmental scale -- Linux.
Best combination for application compatibility plus security and manageability on the department/workgroup level, while giving few malware headaches -- OS X.
Best for enterprises where one has to deal with Sarbanes-Oxley, audits, ISOyadda checks, etc. -- Windows.
[1]: I'm not a fan of Exchange, but realistically, it is the only game in town if you need tools for archiving, SOX/HIPAA/FERPA compliance, replication, and other things the PHBs want.
There are better explanations of the fragmentation down below, but one needs to remember, these 35 people are all volunteers. These are people who try to give their time when possible, but may not be giving as many hours that a full time developer would be doing for earning his/her main income.
It only applies to rooted devices. The su mechanism consists of two items:
The binary, natively compiled from ARM.
The app, which is a Dalvik VM.
When a program invokes the su binary, it checks to see if the app is allowed or denied access without prompting, if denied, just denies it, moves on. If neither denied or allowed is listed, it prompts the user to allow or deny the app, as well as save the decision. If the user allows it, or if the app is listed as being allowed without prompting, the program gets access as UID 0.
Some apps (like the 1.0 Blizzard Authenticator) try to su to root to determine if the phone is rooted, and print out a warning message or even stop working. Other apps might ask for root for legit reasons (a file manager, or a terminal emulator), still other apps will ask for root for nefarious purposes.
I am not sure the best way to test where in your code the su dialog is popping up... perhaps root a test Android device and set breakpoints?
The Cyanogen people have a lot to lose if their ROMs are found to be corrupt. Same with a lot of other top tier ROM "cooks". However, it wouldn't take much for someone to upload a bongoed ROM. That is why its good to see if someone updates a ROM and what people think of the package. Of course, this isn't a 100% guide, but better than nothing.
As always, you can just root the phone without changing ROMs.
If you have good front end encryption [1] with a solid implementation, it shouldn't matter if you store your files on a public FTP server. DB has been discussed about security, but this is mitigated almost completely by proper encryption.
Of course, this doesn't prevent big names from either using a (theoretical weakness) in the algorithm, or resort to rubber hose decryption, but if done right with encryption, and a suitably long passphrase (TC states 20+ characters), storing data on the cloud can be made relatively secure.
[1]: Solid algorithms (AES, RSA), done in a proper fashion (NOT ECB), with a salt, proper HMAC, etc.
Don't forget that Thunderbolt will also replace the VGA/DVI connector on a machine, either directly, or using an adapter. Because an adapter can be used, PC and motherboard makers have zero to lose by changing to this for video out on laptops, where space is a premium. Desktop video is still a tossup, but a video connector that takes less space and also supports a high speed interface would be welcomed.
It is a Linux kernel, but the userland is very different. Root is there, but apps have their own UIDs, and almost all the UNIX command lines are links from busybox [1]. To prove this, try getting gcc to work natively on Android.
It really can't be run like a Ubuntu box -- users by default don't even have root access on almost all Android devices. Instead, you have to be careful on the app level.
[1]: Busybox is (IMHO) one of the few programs that just is pure awesomeness in its functionality.
Take these for what they are worth, but here are my security practices:
1: Install DroidWall and use that to lock down everything except the apps you do want going out.
2: Use TouchDown or a discrete app for secure Exchange email. This allows you to keep contacts separate from the rest of the device, and the app can keep the contacts encrypted. If it is work E-mail, it is good to keep it separated anyway.
3: Consider a PIN protecting app for #2 above, as well as your terminal, settings, and su app.
4: Use Titanium Backup with the encryption feature and store on Dropbox. If you look at TB, you will find that the way it does encryption using RSA keys is pretty well designed, so storing backups of apps on DB can be done securely.
5: Get a utility (I use WaveSecure out of habit, but there are others) that will lock the phone if the SIM card is changed, airplane mode is put on, and even allow one to remotely wipe the device and SD card. I'd like a utility that would give the ability to wipe the device and SD card if the phone has not seen Net access in "x" amount of time, similar to what BlackberryOS provides.
6: Look at reviews before buying apps.
7: Look at what the app asks for security permissions. If a notepad app wants access to your contacts, phone, SMS, or perhaps even pops up the su dialog, get rid of it ASAP.
8: If you use nandroid, consider some type of file encryption. This sucks when restoring a ROM image, but there are ways around that (decrypting the image while the SD card is mounted via USB, using a temporary ROM image with no data for decrypting, etc.)
9: Use AdBlock with Dolphin Browser. Ad rotation services are a noted source of malware.
10: Use known ROMs. The ROM ecosystem has been astoundingly clean for now, but it is only a matter of time before blackhats start adding their own "functionality" and putting ROMs on xda-developers and other sites.
11: Consider PIN protecting your SIM card. This way, when you do a remote erase, the thief might have a clean phone, but won't have free access to bandwidth, SMS, or calling capabilities.
12: Consider a "stuffbak" sticker. If the phone is found, at least there is a small chance it might get back to you, as opposed to 0 chance without it.
13: Keep backups. This way, if you do lose your phone, you can get another Android phone, fire up Titanium Backup, log onto DropBox, type in your decryption key, and restore your apps with their saved data.
14: Bug Google for them to put volume encryption (LUKS) into Android, so it can be used on the SD cards.
More specifically, root your Android phone (no, it will not lessen security unless you are stupid and click "allow" on any app that pops up the su dialog unless you KNOW it needs the root permission.)
Install DroidWall and allow it full su access. Then when you install a new app, make sure to allow it out, because by default, new apps are not allowed to phone anywhere. LVL is handled by another mechanism, so apps should know they are licensed even if you block them with DroidWall.
After installing DroidWall, and selecting the apps you know that need to communicate, that will provide a decent measure of protection.
HP 50g?
I have seen hardware failure in every offering, given enough of them. Name the computer maker, given enough time and enough machines, some will have problems. However, this is why a company purchases premium support and business-grade machines so a DOA box is minimized.
A consumer doesn't have that luxury of buying enterprise level 24/7/365 support. So, if something goes TU, being able to take it to a physical location (or have someone come onsite) and get it taken care of (versus having to package it up and sent it to a depot for 6-8 weeks) is a big difference. Especially for computers that people depend on for daily income.
The coolest anon server I saw was one that would check files once the connection was closed. If they were not encrypted with a PGP key assigned to the server, the file was wiped on the spot. The checking mechanism was in multiple parts too, so it would do a quick PGP/gpg header check, if that wasn't present, chuck the file, then check to see if it was encrypted to a certain key ID.
Users that needed to upload files could easily do so. Combining normal write only permissions with the fact the server erased contents if they were not encrypted to the server's key (making the files unusable to anyone else) also ensured that the warez hounds seek storage elsewhere.
Apple's CS by itself, is a big sell in its favor. Bought a Mac, bad RAM... they did a machine exchange on the spot. iPhone had some bad flash storage... 10 minutes, the SIM card was swapped and I was good to go with a replacement unit.
For nontechnical people, being able to call one number for a problem, be it hardware, OS, or even the app makes the Apple Tax worth it, especially if they make their living from the computer.
PC makers also offer good support, but you have to buy their business line of machines (Precisions, Optiplexes), and their top tier support contracts. This is the par for companies, but for individuals, Apple has the best CS for the large computer makers.
That sums it up right there. Why? Lots of reasons:
1: A honeypot might get someone in legal hot water if someone then launches criminal activity from it. For example, if someone's honeypot was used for torrents or CP, it will be tough explaining to cops (or the RIAA's pet judge) that the owner knowingly allowed such activity to happen and hoping not to get found culpable/convicted.
2: FTP for anonymous downloads is one thing (assuming a hardened FTP server.) Anonymous uploads can be done too, provided you clean the incoming directory. FTP for users with passwords sent plaintext is just bad form. Use sftp, or scp for this.
3: Before '97, you could call an ISP or other domain and deal with someone who would be ready/willing/able to stop someone hacking from a site. These days, nobody cares, especially offshore domains. IP address banning is noble, but just not running the service unless needed is the best bet.
4: Even with IP banning, it won't do much. Blackhats have a crapload of bots on wide IP ranges. Better to just figure out what ranges to allow and deny everyone else.
5: Passwords should never be used anyway. Use S/Key or OPIE if one can't authenticate using two factor stuff. Best of all, use public key authentication over ssh. This way, there is no way a brute force attack could succeed, if the SSHGuard program or other anti-guessing daemon doesn't work.
You hit the nail on the head. Most users keep their valuable stuff in the same user account as what they use for Web browsing. Because of this, a Web browser that is always dealing with untrusted and potentially malicious code runs in the same context as someone's financial applications.
What is needed is a finer grained context mechanism. Perhaps give apps their "home directory" where not just their preferences files go, but documents as well. Essentially combine AppData and Documents on Windows. This way, a Web browser cannot access Excel's files by default.
For users to simplify things, an abstraction layer for the Documents directory can be created, essentially creating links from all the application/Document subdirs to one Document directory. This way, the user doesn't have to care if the file is in the Excel data directory or the Word one.
Of course, there have to be ways to get around this, for example allowing archiving utilities to do their job, or to allow Acrobat to parse Word documents for PDF creation. Ideally, asking for permissions at install would be the best way, with the ability to deny permissions (so it isn't all or nothing as it is with Android.)
If done right, the user wouldn't notice anything different -- his documents are in the Documents folder, or perhaps on the desktop. However, malicious software that takes over an app would be hard pressed to try to get to the user's other files.
A brick and mortar "Linux Store" would be cool, especially if in a tech savvy area. I can see it carrying:
Distributions (need a copy of RHEL? Grab a box with the media and a 1-5 year subscription. Some Internet connections, it is faster to drive back with the DVDs than to download and burn the ISOs.)
Bare bones appliance PCs: Need a server that can do routing/firewalling/NAT/squid cache/wireless/Junkbusters/etc? Here is a biscuit PC with a SSD all ready to go. Need a file server? Here is a tower with 16 SATA drives in a RAID 6 configuration, with eight 10GB ports on the back. Need an insanely fast database server? Here is a box with a TB or RAM, a caseful of SSDs, two FCoE CNA cards for hookup to a SAN with multipathing, and the latest Xeon CPUs. Need a box to serve VMs? Already specced out and ready to go.
Books for taking the RHCE or other certifications.
Testing place for RHCE, A+, and other certs.
A place to host the town's LUG, as well as a trading post for people to find or offer work.
Rentable computer labs for being able to do various testing.
A suitable pub. UNIX admins in general demand a suitable establishment that not just has decent drink, but good food. We are not developers, so cheap pizza does not cut it. Linux and homebrew/microbreweries go hand in hand, so a complete Linux shop must sport a high quality brewpub.
To us, asking more than the GNP of the world may seem silly. However, to lawyers, and to a judge that may be extremely loyal to people, that insane verdict may get a rubber stamp.
This is what I fear as well with this case -- like the auto commercial, I fear that the plaintiff in this case will have their motions, "approved, approved, approved" under the guise of "teaching students respect for the law", and with the Supreme Court's decision record, those judgements may even be uphold by them.
People say that, but if one compares the number of security issues in Apache (which is the #1 webserver out there) compared to issues people report in IIS, the argument that Linux or Mac are "secure" because of their marketshare has been disproven.
On the desktop, if Macs had a proportionate share of malware that Windows does, we would know about it, as people would be screaming at Apple on their forums, as well as sites like Macrumors. There is no screaming, so OS X has far less than what the marketshare would expect.
Want to know why Windows gets nailed all the time? It is because on platforms like AIX, OS X, Linux, and others, developers don't shit where they sleep. They know that users can leave their platform if it got a bad reputation. Not so with Windows, and the bad guys know it, so they can churn out the malware without a second thought.