DroidWall is not a program that runs. It is a wrapper around iptables, making a list of what apps get allowed to connect out and which get denied. Unlike software firewalls, Droidwall can be resident, but it can happily be killed without losing any protection.
Maybe a good idea is to have three sets of ACLs an app needs to function:
The minimum set so the item can run: For a game, it would be no added permissions, although the user wouldn't be able to save their high scores on a networked server.
Typical permissions: Network access, etc.
Maximum permissions: This is to ensure that an app that is handed carte blanche is not given everything. For example, an app that stipulates that it does not need root permissions, etc. For example, a fleshlight app (unless it has a hidden SOCKS proxy) should not need access to the contact list, nor need to have incoming/outgoing SMS rights available to it.
There is the problem: People like you, me, and almost all Slashdot readers would click "no" if a generic fart app requires a slew of security privs (power, Net, access to SMS, access to contacts, ability to kill other apps, etc.), or even worse, prompted for root privs via su.
However, the dancing bunny problem strikes here. Joe Sixpack will click "Install" to install a cool app, only to find all his contacts being spammed with "I need $900 ransom" notices, a sky high SMS bill because the app grabs a list of phone numbers and starts sending out text messages with ads on it, maybe even drained bank accounts if he left his banking info and passwords in the Web browser.
I think Google made one mistake with Android, and that was assuming all users would be clued Linux types who know basic UNIX sanitation. I worry though, if there are more bad apples in the bunch that Android would be start being known as a hive for malware just because there is nothing stopping Joe Sixpack from installing a "pr0n viewer app" that reams his phone.
I like the walled garden idea, with a way to hop out, that is foreboding to a nontechnical person, but for someone with half a clue, wouldn't pose a problem. For example, the "oem unlock" command with the N1 phones and the warning staying to say buh-bye to the phone's warranty if the user wants to continue. Something to make Joe Sixpack not want to do it and actually pass on watching the dancing bunnies.
This is a very good reason to run Droidwall. However, the bad news is that Android apps are going to a model where they ping one of Google's servers to check if they are licensed for that user. Of course, Droidwall can be updated to allow any apps to connect to that server farm's IP address range even if they are disallowed from anywhere else, but that may take some programming.
Not just one off, but at least 2-3 decades behind the times due to fearmongering. If we had modern nuclear plants (Generation III, or even Generation IV), 16 cents/kwh can be easily undercut, and be able to be done 24/7/365 with support for a beefed up grid system to support electric car charging.
I would like to see the US go France's route. I can see nuclear plants used near the shore to power very large desalination plants, and combine that with decent pipeline technology, can allow for inland irrigation without exhausting the already depleted aquifers. Other uses would be for dealing with the garbage in the Pacific Gyre and using thermal depolymerization to recover usable crude oil which can be used for another round of plastic production.
Don't forget filesystems. UNIX filesystem performance goes into the toilet as soon as drives get over 85-90% full, because the filesystem can't locate contiguous space for things, nor can it pre-allocate space around a file easily, so fragmentation results.
Having games forgotten about is what is wanted. If a game gets forgotten about, it can easily be recycled and the IP reused. Because people vaguely heard about it, it can be, updated for the latest consoles and slung at the masses again. Maybe toss in a character that suits the gamers of the day, ship a beta copy, promise to fix any bugs, and then once it gets out on the market, move to something else, and hope the DRM is sophisticated enough to deter pirates that the game is again forgotten about.
Don't forget that newer stuff has DRM and suicide batteries which will make things almost impossible for future people to be able to keep today's stuff working.
Suicide batteries are a "feature" of newer arcade games, where after a couple years, essentially the whole arcade game bricks itself.
Another thing is to have two FB accounts. One a public profile for your boss, professors, and others to see which has nothing but some random intelligent comments on it. The other your private one for friends, where all the pictures of you with the beer bong are well secured (as well as they can be on FB) from prying eyes.
Like what the parent stated above, I've not bothered to do this because I feel that if it gets on FB, it will end up public anyways somehow.
The trick with FB is to have the default security settings set to only allow a certain group of friends see your wall, settings, personal info, pictures, and other stuff. This gives you two advantages:
1: Nobody sees your personal information unless you explicitly add them to the group. So if your professor or boss demands friend access, they can get it, but it won't give them much information.
2: You can remove people from seeing what you are doing without unfriending them. This way, someone you don't feel like speaking to can be off your list, and if that was a mistake, they can be re-added without the business of two-way re-friending them.
Depends on area. Older pickup trucks in the southern states (before Ford/GM/Dodge started using RFID codes in the ignition keys) are very high on the list of stolen vehicles.
This isn't far fetched. Anyone remember a few years back, a verdict against a P2P site where they were ordered to log every single change that happened even in RAM on a machine?
I can see a defendant arguing that the "DRM" for a flash game is the Flash shared objects, and if the judge isn't aware about issues, he or she might render a very punishing verdict which would take millions of dollars to appeal.
I agree with you though. This is a problem solved by a technological solution (BetterPrivacy, a shell script that runs and zaps the Flash directory, or something along those lines), than having it be litigated.
Litigation may even backfire, and a judge might rule that removing Flash cookies is considered circumventing DRM on Flash objects, and may make it even more difficult for utilities like BetterPrivacy or CCleaner to even exist.
+1 on BetterPrivacy. Install that as an add-on, and it works on Windows and OS X. No more worries about Flash shared objects because it can be set to zap them at very short time intervals, as well as when you open or close the browser.
Firefox + BetterPrivacy + AdBlock + NoScript probably do as much for keeping a Windows machine clear of malicious software as most AV programs.
Makes sense. Anatomical or not, the flaps will mean that Joe Sixpack has to defeat some type of safety system in order to burn his eyes out. However, Joe Sixpack Jr. will likely bypass it, and the maker will end up on the short end of a lawsuit because of the kid.
Perhaps a system that verifies the connection over the copper first, then starts the optical communication. This way, it will take some doing for Joe Sixpack or Aunt Tillie to be able to eyeball the laser diode.
I'd like to see a connector with both an optical connector (for two way communication) and a copper connection for power.
I worry though. Give Joe Sixpack a single mode fiber optic connector with a warning "do not look down connector with remaining eye", and he probably will need Braille to do his next computer stuff.
Patent violations are still IP infringement, even if it is for personal use. C&Ds can be easily issued for those just as easily as if someone is offering a pirated application for download.
There is always support. For example, if an OSS company makes and supports a product, it gets bought out and the company dissolved, then even though the product may be forked, there will be no way for customers to get support for the product. Of course, the ex-employees can form around the forked project, but it will take time and effort rebuilding the customer base and getting the support contracts back.
I can see Oracle easily buying RedHat. As of now, there is an exodus of people from Sun/Solaris to x86 hardware/RHEL. By buying RedHat and making the OS chargable, or just doing with RedHat altogether would be a major coup for Ellison. Where would people flee to? Essentially, either IBM and AIX for big iron, SuSE and Novell for another, or go Windows.
Careful, there are always patents. All it would take is for the OSS project purchased to have a patent awarded to it. Then the DMCA can be used to squash any forks of the project.
Yes, data is sent over, but the DB processing and storage should be in house. Another reason to keep data in house:
Jack, who has some basic Linux skills wants to make some money on the side in his job in a data center. He copies some credit card numbers from his work and sells them. His company takes the heat, does an audit of who had last access to that tablespace that wasn't normal, and finds that Jack was doing a SELECT on it. Jack almost definitely will end up facing civil/criminal repercussions for the action.
Joe who is working in a cloud provider does a strings on a.vmdk file, gets a similar list. He has no loyalty to the cloud provider's client... that's just some company or organization storing files at his workplace. So, he doesn't feel any reason why not. He sells the list, the cloud provider's client gets the heat for the compromise, and maybe the cloud company may be found responsible for the leak. However, there is no certain audit trail or chain of custody present like there is by keeping data in-house. Maybe sometime in the future some file audit or accounting daemon might show the read or some shell log show the strings command, but it may never happen.
Again, with data in-house, there is an access log record, a video log from the cameras, a log from the ACE servers of access, the audit logs from Active Directory, the logs from the routers. All of this ensures accountability for everyone involved. Outsourcing to a cloud provider? Got none of that. There is no solid chain of custody.
Maybe it is because I'm an old hand (and I'm speaking for myself here), but there is something about having physical control of data in house, in a data center. This way, unless there is a network intrusion, one knows where critical information resides.
With a cloud provider, all I have is a promise of security.
This isn't to say that Google isn't secure, but I personally trust good locks on the doors and all people who have access to the data having signed contracts more than just a piece of paper with a promise that things are secure.
In a sense, the Mac Pro is the only "UNIX workstation" on the market today. There are tower machines made by Sun and IBM which can be used as such, but not sold as this.
Supposedly, Autodesk is going to start getting their mainstream version of AutoCAD on OS X RSN.
Of course, the question is why a Mac Pro over another x86 machine such as a Dell Precision? Multiple reasons:
1: OS X tends to have lower latency than Windows out of the box (you can disable services in Windows to help things). This, combined with the fact that Macs do not need a CPU and I/O draining antivirus program resident 24/7 means that a Mac Pro can outperform a similarly configured Windows machine.
2: Known quantity. Application makers have a far smaller number of combinations of machines and graphic cards they need to test and support.
3: Piracy. Mac users tend to pirate a lot less, so there will be more paid seats sold.
4: Support. At this level, it is assumed that the workstations come with premium support, so it isn't like the consumer market where Apple just puts the other PC vendors to shame. However, it does help having one vendor sell and support the OS and hardware.
5: Education. Professors used to buy UNIX workstations because they needed them for SPSS, Maple, and other tasks. Because Apple gives a discount for universities, this means that Mac Pros will end up in the statistical computing labs.
6: Security. This is debatable, but it can be said that UNIX is more secure than Windows, although the difference narrows if the Windows admin knows what he or she is doing. Since high end workstations tend to work on items that are crucial trade secrets, having solid security is a must.
7: Resale value. Mac Pros are priced competitively with other workstation class machines, so having the machines worth more when they are changed out at the end of an amortization cycle doesn't hurt.
What I see happening is the HSM idea brought back, but done by a drive's firmware.
The first level would be either fast DRAM and used purely as a cache.
The second level would be SLC flash with TRIM done in hardware so the translation table doesn't get full over time, or the drive has 2-3 times as much flash so it can move data to another space, zero out the old space and have a translation table ready to go. This is where a VM swap file would live, as well as/boot or the kernel.
The third level would be MLC flash. Here is where ideally everything the computer needs to function will reside, the OS, the application, often used data, and home directories.
The fourth level would be holographic storage/spinning platters/optical or other media where access time is slow (measured in microseconds as opposed to nanoseconds), but can hold a lot of data. Here is where archive data goes, backups of the upper tiers, and files which are not often accessed, such as system logs about to be rotated out.
The fifth level would be tape, optical, or WORM holographic storage. This is an extremely slow medium compared to upper tiers, but has high capacity and long archival life. This would be used for backups. Perhaps the media would have a small amount of flash on it to support booting or storing encryption keys and other metadata. It would be ideal to have the ability to boot from this media for a fast bare metal restore.
Of course, the issue will be having an intelligent controller that can move data around in tiers. Additionally, data can be mirrored across tiers for redundancy, so if the SLC layer loses cells and ECC can't fix it, the files can be repaired from items stored on the MLC layer, or even prompt for a backup volume. Perhaps a ZFS-like filesystem would be ideal for this.
The way to protect against a dedicated attack is compartmentalization. Connectivity is important, but companies to structure not just machines, but the IT organization to resist compromise.
For example, log servers. These machines have to be *completely separated* from anything else in the company except the network. They can't use LUNs on a SAN (or else the storage admin can tamper with logs.) They can't use the corporate backup system (or else the backup admin can restore a tampered log.) They can't be run by the Windows or UNIX admins or else a compromised admin (or a blackhat) can compromise the machines, then the log server to completely hide tracks, or to perhaps cause damage. If you are running a program like Splunk, you don't run the thing on the log servers; you run it on a read-only mirror so people who have access to Splunk do not have access to tamper with the logs.
You can't "silo" the department where everyone works in little walled areas with no inter-group communication, but you have to have separation of duties so the damage done by a compromised employee can be mitigated.
Slashdot Mirror
DroidWall is not a program that runs. It is a wrapper around iptables, making a list of what apps get allowed to connect out and which get denied. Unlike software firewalls, Droidwall can be resident, but it can happily be killed without losing any protection.
Maybe a good idea is to have three sets of ACLs an app needs to function:
The minimum set so the item can run: For a game, it would be no added permissions, although the user wouldn't be able to save their high scores on a networked server.
Typical permissions: Network access, etc.
Maximum permissions: This is to ensure that an app that is handed carte blanche is not given everything. For example, an app that stipulates that it does not need root permissions, etc. For example, a fleshlight app (unless it has a hidden SOCKS proxy) should not need access to the contact list, nor need to have incoming/outgoing SMS rights available to it.
There is the problem: People like you, me, and almost all Slashdot readers would click "no" if a generic fart app requires a slew of security privs (power, Net, access to SMS, access to contacts, ability to kill other apps, etc.), or even worse, prompted for root privs via su.
However, the dancing bunny problem strikes here. Joe Sixpack will click "Install" to install a cool app, only to find all his contacts being spammed with "I need $900 ransom" notices, a sky high SMS bill because the app grabs a list of phone numbers and starts sending out text messages with ads on it, maybe even drained bank accounts if he left his banking info and passwords in the Web browser.
I think Google made one mistake with Android, and that was assuming all users would be clued Linux types who know basic UNIX sanitation. I worry though, if there are more bad apples in the bunch that Android would be start being known as a hive for malware just because there is nothing stopping Joe Sixpack from installing a "pr0n viewer app" that reams his phone.
I like the walled garden idea, with a way to hop out, that is foreboding to a nontechnical person, but for someone with half a clue, wouldn't pose a problem. For example, the "oem unlock" command with the N1 phones and the warning staying to say buh-bye to the phone's warranty if the user wants to continue. Something to make Joe Sixpack not want to do it and actually pass on watching the dancing bunnies.
This is a very good reason to run Droidwall. However, the bad news is that Android apps are going to a model where they ping one of Google's servers to check if they are licensed for that user. Of course, Droidwall can be updated to allow any apps to connect to that server farm's IP address range even if they are disallowed from anywhere else, but that may take some programming.
Droidwall also requires root access.
Not just one off, but at least 2-3 decades behind the times due to fearmongering. If we had modern nuclear plants (Generation III, or even Generation IV), 16 cents/kwh can be easily undercut, and be able to be done 24/7/365 with support for a beefed up grid system to support electric car charging.
I would like to see the US go France's route. I can see nuclear plants used near the shore to power very large desalination plants, and combine that with decent pipeline technology, can allow for inland irrigation without exhausting the already depleted aquifers. Other uses would be for dealing with the garbage in the Pacific Gyre and using thermal depolymerization to recover usable crude oil which can be used for another round of plastic production.
Don't forget filesystems. UNIX filesystem performance goes into the toilet as soon as drives get over 85-90% full, because the filesystem can't locate contiguous space for things, nor can it pre-allocate space around a file easily, so fragmentation results.
Having games forgotten about is what is wanted. If a game gets forgotten about, it can easily be recycled and the IP reused. Because people vaguely heard about it, it can be, updated for the latest consoles and slung at the masses again. Maybe toss in a character that suits the gamers of the day, ship a beta copy, promise to fix any bugs, and then once it gets out on the market, move to something else, and hope the DRM is sophisticated enough to deter pirates that the game is again forgotten about.
Don't forget that newer stuff has DRM and suicide batteries which will make things almost impossible for future people to be able to keep today's stuff working.
Suicide batteries are a "feature" of newer arcade games, where after a couple years, essentially the whole arcade game bricks itself.
Another thing is to have two FB accounts. One a public profile for your boss, professors, and others to see which has nothing but some random intelligent comments on it. The other your private one for friends, where all the pictures of you with the beer bong are well secured (as well as they can be on FB) from prying eyes.
Like what the parent stated above, I've not bothered to do this because I feel that if it gets on FB, it will end up public anyways somehow.
The trick with FB is to have the default security settings set to only allow a certain group of friends see your wall, settings, personal info, pictures, and other stuff. This gives you two advantages:
1: Nobody sees your personal information unless you explicitly add them to the group. So if your professor or boss demands friend access, they can get it, but it won't give them much information.
2: You can remove people from seeing what you are doing without unfriending them. This way, someone you don't feel like speaking to can be off your list, and if that was a mistake, they can be re-added without the business of two-way re-friending them.
Depends on area. Older pickup trucks in the southern states (before Ford/GM/Dodge started using RFID codes in the ignition keys) are very high on the list of stolen vehicles.
This isn't far fetched. Anyone remember a few years back, a verdict against a P2P site where they were ordered to log every single change that happened even in RAM on a machine?
I can see a defendant arguing that the "DRM" for a flash game is the Flash shared objects, and if the judge isn't aware about issues, he or she might render a very punishing verdict which would take millions of dollars to appeal.
I agree with you though. This is a problem solved by a technological solution (BetterPrivacy, a shell script that runs and zaps the Flash directory, or something along those lines), than having it be litigated.
Litigation may even backfire, and a judge might rule that removing Flash cookies is considered circumventing DRM on Flash objects, and may make it even more difficult for utilities like BetterPrivacy or CCleaner to even exist.
+1 on BetterPrivacy. Install that as an add-on, and it works on Windows and OS X. No more worries about Flash shared objects because it can be set to zap them at very short time intervals, as well as when you open or close the browser.
Firefox + BetterPrivacy + AdBlock + NoScript probably do as much for keeping a Windows machine clear of malicious software as most AV programs.
Makes sense. Anatomical or not, the flaps will mean that Joe Sixpack has to defeat some type of safety system in order to burn his eyes out. However, Joe Sixpack Jr. will likely bypass it, and the maker will end up on the short end of a lawsuit because of the kid.
Perhaps a system that verifies the connection over the copper first, then starts the optical communication. This way, it will take some doing for Joe Sixpack or Aunt Tillie to be able to eyeball the laser diode.
I'd like to see a connector with both an optical connector (for two way communication) and a copper connection for power.
I worry though. Give Joe Sixpack a single mode fiber optic connector with a warning "do not look down connector with remaining eye", and he probably will need Braille to do his next computer stuff.
Patent violations are still IP infringement, even if it is for personal use. C&Ds can be easily issued for those just as easily as if someone is offering a pirated application for download.
There is always support. For example, if an OSS company makes and supports a product, it gets bought out and the company dissolved, then even though the product may be forked, there will be no way for customers to get support for the product. Of course, the ex-employees can form around the forked project, but it will take time and effort rebuilding the customer base and getting the support contracts back.
I can see Oracle easily buying RedHat. As of now, there is an exodus of people from Sun/Solaris to x86 hardware/RHEL. By buying RedHat and making the OS chargable, or just doing with RedHat altogether would be a major coup for Ellison. Where would people flee to? Essentially, either IBM and AIX for big iron, SuSE and Novell for another, or go Windows.
Careful, there are always patents. All it would take is for the OSS project purchased to have a patent awarded to it. Then the DMCA can be used to squash any forks of the project.
Yes, data is sent over, but the DB processing and storage should be in house. Another reason to keep data in house:
Jack, who has some basic Linux skills wants to make some money on the side in his job in a data center. He copies some credit card numbers from his work and sells them. His company takes the heat, does an audit of who had last access to that tablespace that wasn't normal, and finds that Jack was doing a SELECT on it. Jack almost definitely will end up facing civil/criminal repercussions for the action.
Joe who is working in a cloud provider does a strings on a .vmdk file, gets a similar list. He has no loyalty to the cloud provider's client... that's just some company or organization storing files at his workplace. So, he doesn't feel any reason why not. He sells the list, the cloud provider's client gets the heat for the compromise, and maybe the cloud company may be found responsible for the leak. However, there is no certain audit trail or chain of custody present like there is by keeping data in-house. Maybe sometime in the future some file audit or accounting daemon might show the read or some shell log show the strings command, but it may never happen.
Again, with data in-house, there is an access log record, a video log from the cameras, a log from the ACE servers of access, the audit logs from Active Directory, the logs from the routers. All of this ensures accountability for everyone involved. Outsourcing to a cloud provider? Got none of that. There is no solid chain of custody.
Maybe it is because I'm an old hand (and I'm speaking for myself here), but there is something about having physical control of data in house, in a data center. This way, unless there is a network intrusion, one knows where critical information resides.
With a cloud provider, all I have is a promise of security.
This isn't to say that Google isn't secure, but I personally trust good locks on the doors and all people who have access to the data having signed contracts more than just a piece of paper with a promise that things are secure.
In a sense, the Mac Pro is the only "UNIX workstation" on the market today. There are tower machines made by Sun and IBM which can be used as such, but not sold as this.
Supposedly, Autodesk is going to start getting their mainstream version of AutoCAD on OS X RSN.
Of course, the question is why a Mac Pro over another x86 machine such as a Dell Precision? Multiple reasons:
1: OS X tends to have lower latency than Windows out of the box (you can disable services in Windows to help things). This, combined with the fact that Macs do not need a CPU and I/O draining antivirus program resident 24/7 means that a Mac Pro can outperform a similarly configured Windows machine.
2: Known quantity. Application makers have a far smaller number of combinations of machines and graphic cards they need to test and support.
3: Piracy. Mac users tend to pirate a lot less, so there will be more paid seats sold.
4: Support. At this level, it is assumed that the workstations come with premium support, so it isn't like the consumer market where Apple just puts the other PC vendors to shame. However, it does help having one vendor sell and support the OS and hardware.
5: Education. Professors used to buy UNIX workstations because they needed them for SPSS, Maple, and other tasks. Because Apple gives a discount for universities, this means that Mac Pros will end up in the statistical computing labs.
6: Security. This is debatable, but it can be said that UNIX is more secure than Windows, although the difference narrows if the Windows admin knows what he or she is doing. Since high end workstations tend to work on items that are crucial trade secrets, having solid security is a must.
7: Resale value. Mac Pros are priced competitively with other workstation class machines, so having the machines worth more when they are changed out at the end of an amortization cycle doesn't hurt.
What I see happening is the HSM idea brought back, but done by a drive's firmware.
The first level would be either fast DRAM and used purely as a cache.
The second level would be SLC flash with TRIM done in hardware so the translation table doesn't get full over time, or the drive has 2-3 times as much flash so it can move data to another space, zero out the old space and have a translation table ready to go. This is where a VM swap file would live, as well as /boot or the kernel.
The third level would be MLC flash. Here is where ideally everything the computer needs to function will reside, the OS, the application, often used data, and home directories.
The fourth level would be holographic storage/spinning platters/optical or other media where access time is slow (measured in microseconds as opposed to nanoseconds), but can hold a lot of data. Here is where archive data goes, backups of the upper tiers, and files which are not often accessed, such as system logs about to be rotated out.
The fifth level would be tape, optical, or WORM holographic storage. This is an extremely slow medium compared to upper tiers, but has high capacity and long archival life. This would be used for backups. Perhaps the media would have a small amount of flash on it to support booting or storing encryption keys and other metadata. It would be ideal to have the ability to boot from this media for a fast bare metal restore.
Of course, the issue will be having an intelligent controller that can move data around in tiers. Additionally, data can be mirrored across tiers for redundancy, so if the SLC layer loses cells and ECC can't fix it, the files can be repaired from items stored on the MLC layer, or even prompt for a backup volume. Perhaps a ZFS-like filesystem would be ideal for this.
The way to protect against a dedicated attack is compartmentalization. Connectivity is important, but companies to structure not just machines, but the IT organization to resist compromise.
For example, log servers. These machines have to be *completely separated* from anything else in the company except the network. They can't use LUNs on a SAN (or else the storage admin can tamper with logs.) They can't use the corporate backup system (or else the backup admin can restore a tampered log.) They can't be run by the Windows or UNIX admins or else a compromised admin (or a blackhat) can compromise the machines, then the log server to completely hide tracks, or to perhaps cause damage. If you are running a program like Splunk, you don't run the thing on the log servers; you run it on a read-only mirror so people who have access to Splunk do not have access to tamper with the logs.
You can't "silo" the department where everyone works in little walled areas with no inter-group communication, but you have to have separation of duties so the damage done by a compromised employee can be mitigated.