Unlikely to happen, in today's climate, though nothing is impossible.
If this keeps up, I would not be surprised if a Cuban-like restoration industry emerges, taking junked cars, just the chassis, adding the interior and a reasonable engine, and putting cars on the road with that, sans the Big Brother features. The chassis might be an older car, but essentially the vehicle would be completely rebuilt.
ext4 encryption has a lot of promise, and I consider this a big feature. It essentially functions like EncFS/CFS, but instead of being a secondary filesystem accessible via FUSE, it is part of the main filesystem. The closest thing it parallels is AIX's EFS.
I'm not surprised that Google coded this part. It makes perfect sense for Android. Encryption of/data can be turned on immediately during a device setup without having to worry about block level items, or if the device crashes during the/data encryption process.
Overall, an add-on which is definitely needed. Since Google mainly uses ext4, this is their best bang for the buck, and I hope the maintainers of other filesystems toss something similar in their code.
One reason why polling companies can't get usable info is that end users tend to be constantly barraged by robocalls, be it the GE security system, "polls" which actually turn out to be scammy sales pitches, or many other types of scams.
Because of this, people either use apps like Mr. Number which autoblocks, or just ignore any number not on their contacts list and area code. If someone does answer and gets a "hi, this is not a sales call", the "end" button on the phone gets pressed by instinct, just like one's hand draws back if they touch a hot pan.
I am not sure from reading the page what exactly Trapwire does. Does it sit, grab facial recognition data, and try to put two and two together if it notices a person at certain places at certain times, then sound an alert to the local security that "so and so is a risk" because they were first at Spatula City, then the Duct Tape Shoppe, now they are showing up at the Vend-A-Goat convention?
I wonder if this is a spinoff from the software used in LV gambling establishments where if someone is banned from one casino on the Strip, they are banned from all of them, and security heads for them the second they step in the door.
When I first read this article, I thought "Tripwire", which to me, is a useful product, and used properly, it wouldn't be surprising for people to tamper with some machines, Tripwire catch it on a subsequent system scan come audit time, and wind up getting caught, especially here in Texas.
Some servers (IBMs, HP ProLiants) have decent power management capabilities, so the boxes can stay on and be idle... but consume a relatively small amount of electricity and cooling. Add a SSD for local storage and swap (start the OS or hypervisor and let the SAN take it from there), and even the energy usage of spinning disks can be minimized.
However, with the many ways and layers to do HA, might as well do active/active if possible. On the VMWare side of the house, DRS comes to mind, and it also supports true fault tolerant VMs [1].
Generally, with modern applications (Oracle RAC, for example), active/passive configurations are tending to go the way of the dodo, replaced by active/active, where each server runs about 1/2 the workload. Other applications use a public IP or name, and load-balance, so that a dead box means stuff continues on, but just fewer machines to service the incoming items. Even the IBM mainframes that use Parallel Sysplex are active/active (as both units run all computations in lock-step with one another.)
Of course, there are some applications that are active/passive, such as the legacy IBM HA systems... but those are the exception.
1/3 of all servers not doing things might make sense... in the fact that there are times where a machine decides to eat itself, but the IT staff just doesn't know, or doesn't bother to fix it. For example, some machine that was a development machine for a long-forgotten project that fell out of favor. A lot of companies have internal policies to shut down physical servers, but in the smaller data centers that SMBs are likely using, those policies of decommissioning, or just auditing everything in the data center and yanking anything not being used are not there.
[1]: True fault tolerant, as in the VM actually has two instances of it, each on a different physical machine, so if the primary VM drops, the second takes over in milliseconds. The downside is that the VM can only have one vCPU, and there are a number of other limitations. However, for a licensing server or some other tasks which even the delay to reboot a VM and autostart processes might be too much, it is a useful tool.
Grr, quick addendum on #2: I can see a firm just tossing the OS and application on a machine and walking off, but in general that isn't a good practice.
I can see some machines snoozing for long periods of time, but not 1/3 of a place:
1: Hypervisor-level failover on VMWare or Hyper-V. Generally there are hypervisor updates, such as the recent SSL holes which required a update on ESXi, and other security items on Hyper-V [1]. However, these can sit for a good while untouched, and ready to handle a vMotion punt at a moment's notice.
2: Failure on an active/passive configuration at the DB level. With something like Oracle RAC that costs a lot for licensing, why not just got active/active? In general, the DB application and the OS should be upgraded more often, but I can see someone just tossing
3: IBM PowerHA. Since the virtualization firmware is generally upgraded during the latter months (when new TLs/MLs come out), these machines can probably sit around doing nothing for most of a year.
[1]: I'm meaning "raw" Hyper-V servers that are not part of a Windows Server OS install. Neglecting a Windows Server OS install is just asking for the box to become a "client" of another sort.
There are bands and musicians who have kept themselves relevant by maintaining their fan base, no matter how times change. Pink Floyd, Rush, Iron Maiden, Phish, ICP, and NIN come to mind.
However, it takes time to convert a fan base from "hey, that is a cool/trendy song" to "hey, $BAND is having a new album come out." Some musicians don't take the time to try to look at the long picture, and try to break from their genre into a unique area only they are present in. One can get heard via being the pop thing, but one either has to have their own style (almost enough to have a subgenre) in order to not be forgotten in 2-3 years.
One also doesn't have to be mainstream to eke out a decent fan base. The Austrian band Summoning has created a niche for themselves. Similar with the band Alestorm. Word of mouth and streaming services have gotten them heard, and merchandising sales is the revenue earner.
Of course, there are the security aspects as well. We already have been down this road with Java (which did have a lot of promise, especially with HotJava as an example of a browser written in the language, and prototype CPUs that could execute Java bytecode natively.) However, it fell apart, and now, code running on the same JVM on a Mac may just completely fail on Windows, and the other way around. Then, there is finding the right JVM.
Of course, there will be updates. A bytecode language is never finished. So, Web bytecode 7.0 either has to be compatible with every release before that, or break programs. Similar thing happened with Java, which makes it a pain sometimes when using a browser to access some hardware that used an embedded browser/Java interface, especially with the security issues of backlevel versions.
Finally, a security model needs to be put into place, or this will make an excellent tool for bad guys to inject code into the browser and compromise it without a trace (barring memory snapshots by the hypervisor.)
I'd rather either have an exception thrown or a "NaN" value used than a zero returned. A divide by zero error is nasty, but just "papering over" it by returning a zero is only going to introduce more subtle bugs in the code.
The public key allows for more flexibility than just a shared secret. For example, if one wants to store a blob on a untrusted cloud provider, they could store it encrypted to each device's public key. This can be made transparent to the user, since the user just has to "introduce" a device via another, already trusted device which would decrypt the data blob's master key with its own private key, add an encrypted entry for the public key of the device being introduced.
Another item is that if someone snatches hashes of passwords, all the users (or devices in this case) have to change their passwords next login, have their passwords locked out until they complete a recovery process, be be re-authenticated somehow that is different from the password. A list of key hashes gives no usable info to the intruder, as in they can't brute force a password that fits the hash.
Shared secrets have their place, but the advantage of going with the equivalent of client certs is that it lessens what amount of data is sensitive, and forces an intruder to modify data to add their public key for access. If the public keys are leaked, it doesn't do an attacker any good, unless they have broken RSA.
If phone makers (and phones are not cheap items) in general won't provide updates for more than a version or two at most, then I doubt IoT device makers would provide much, if any, about updates.
IMHO, the best thing about IoT is to just say no.
There are ways to design IoT devices securely (for example, having them use a hardened, central hub that handles the communication through the Internet, so attacks on individual devices end up having to be physically local), but since IoT is such a "fad", security is at best an afterthought after the product design is rushed out the door, so I expect zero security whatsoever.
Of course, I am leery of the next step above this... having to wait for an ad to play on the fridge before I can open the door, having to pay the stove manufacturer $29.99 a month so I can use the self-cleaning settings, finding my faucet won't turn on because it lost connection with the cellular tower as the telco dropped GSM for pure LTE, getting fined by my HOA because the freezer detected more than the alloted moving things via its camera in the house, and so on.
Then, there is the security nightmare. Think those IoT providers will pay more than lip service to ensuring their devices are not easy prey? Won't happen.
Finally, there are the higher prices. I don't feel like paying hundreds of dollars for a thermostat, or thousands of dollars for a fridge because it is "smart". If I wanted to pay top dollar for a fridge, depending on availability, I would get a propane or natural gas fridge, so my stuff stays cold even if there is a power outage.
With all the security available in device operating systems, there are better ways to do this:
When the app is created, have it generate a public/private keypair, store the private key in the OS's keystore (called KeyChain in both iOS and Android.) Then, on first authentication to the servers (you are using SSL/TLS for all communication, right?), the central server will store the device's public key's fingerprint. From then on, it functions like a client certificate, and can be optionally used with an app's PIN function for added security.
The benefit of this over a shared secret? Someone hacks the server, a list of key fingerprints will do an attacker no good to authenticate against (because they don't even have the key material that the fingerprint shows), and can be added/deleted per device. With iOS's and Android's keystore functionality, if the device is locked, the keystore is encrypted and inaccessible, providing another layer of protection on top of encrypting/data.
To the user, it functions exactly the same, but it is a lot more secure in virtually every way. The only way it would be less secure is if RSA or the public key algorithm in use was completely broken.
As for bans, you can easily do what Yik Yak and other apps do -- grab the IMEI (if available) and other serials (UDID), and ban by that. Then, even if the app is uninstalled, the phone is still blacklisted.
I prefer the VPS route, just because it gives some separation of data between myself and others. A shared hosting provider may have things (mis)configured to where a simple change in directory might allow another user access (if not modification) to my stuff, especially if they happen to find a way to get a shell.
Of course, VPSes are not perfect -- they can get hacked, but one has the ability to add 2FA and other items if need be.
Of course, there is one drawback... a lot of VPS sites don't allow you to set a cap on bandwidth used, so a DDoS might cost one dearly in money.
Right now, security is a purely defensive battle, at best we have the enemy at a stalemate, where their attacks are foiled. There is no way to "win", since the attacker usually is located in a country with little to no cyber-crime laws, or even in a hostile country that rewards it. At best, we tread water.
Would a long term solution be creating private networks like SIPRNet or NIPRNet, so that the barrier for entry is raised, so an attacker has to get onto that private network, and this might be something where physical access is needed. Not 100% secure, but it raises the bar so that attackers have to have "boots on the ground".
If not, what would be workable, other than just air-gapping as much as possible? Would it be wise for each nation to mimic China and have their own Great Firewall, so attacks have the ability to be be stopped well away from their intended targets?
Sennheiser (and to a lesser extent Sony) make pro-grade headphones. They may not be as glamorous as Beats, but they are not made to be. They are made to help with a job where people make money using their equipment.
I still use a set of Sony MDR-F1s. Definitely not showy, but still do a quite accurate job of sound reproduction while allowing you to still hear what's around you, and don't contact one's ears.
It does matter, especially with Lightning connectors, since non-certified devices will give a warning on the iDevice, either disallowing charging, or just not working at all.
Even if a device does work, I've encountered off-brand USB to Lightning adapters which spark when connected/disconnected to the point of leaving scorch marks on the connector. This does definitely not bode well for any circuitry.
I look for the "Certified with iDevice", because it means some hoop jumping was done and the device meets some standards, and for a 120/240 VAC to USB charger, this isn't a bad thing, since there are some really cheap, dangerous chargers on the market where their UL listing is dubious, fake, or just not there.
There is a point with audio that there is a split between "pro audio" (as in flat response monitor speakers), versus "audiophile audio" (speakers that have Bog knows what for response levels, but they look cool on their marble stands.)
While some cable making companies tout things that can't be quantified, there are items that can be, such as a proper gauge of wire, well soldered fittings that are properly shrink wrapped to prevent oxidation, good insulation, and other basics.
A gold alloy is harder, so it is more resistant to insertions.
There are places where this comes in handy. For example, some PCs have an internal USB cable which plugs into the motherboard, then goes to the front ports. The problem is often the contacts corrode over time, which gives a spotty connection after a while. This is why I wind up testing a faulty USB device by plugging it directly into the motherboard's ports before tossing it altogether. USB connectors are generally made to handle insertions and removals, where a layer of oxide is scraped off. For connections that are long term, but use USB, going with gold plating might be wise.
However, there are other ways to solve this problem. DeOxIt comes to mind which is good for not just removing corrosion, but putting a thin coating of oil over them to protect against oxidation. Other people who have analog studios solve this problem by evacuating the oxygen out of the control room when it isn't in use using nitrogen gas.
Easy fix: Have the ISP have a root cert one must put in their keystore, and the ISP uses a device like a BlueCoat appliance for real time MITM-scanning of all traffic.
Add an in-transit ad injector, and it will be a money maker for the ISP as well.
Make all devices that connect to the Internet have to pass a NAC healthcheck, with software similar to AV signature scanning, except it has signatures of encryption programs (except programs used for managing DRM), and uses heuristics to find what it considers encrypted files, then notifies the upstream to block the machine from the Net for good. Similar to how modded consoles get tossed off PSN or XBox Live, or how some printers will phone home if someone tries to print PDF files of currency.
Then mandate software as part of MTAs, messaging servers, and boards to also look for signatures of encryption (even if it is just a non compressible blob of data), and autoban the user that did it.
Of course, it won't make it impossible... but the barrier will be so high that the risk/rewards won't be worth it... and lets be honest... most people outside of the IT crowd really don't give a rat's ass about encryption or even privacy.
Of course, there is the blowback: Can't have it both ways. Either you have solid encryption and keep both the good guys and bad guys out, or ban encryption [1] and allow the bad guys free reign in the business, non-classified government, and other sectors as a cost of doing business. Can't have both.
[1]: We went through this with Clipper and Skipjack, so alt.security, sci.crypt, and Cypherpunks archives from the early 1990s go into this in much detail.
The ironic thing is that if more companies used an OpenPGP variant (Symantec's PGP, GnuPG, NetPGP, and so on), it really wouldn't matter what channel stuff was sent on. They could create a FB group and stash the files as attachments, but the contents would be secure, assuming keys of a proper length and the private keys properly used/secured, for example, having a key generated and stored in a Yubikey or other cryptographic token. Even just doing document processing in a secured environment like an iOS or Android device would reduce the level of compromise of files in transit quite a bit. Nowhere near as secure as an airgap, but for a lot of items, it brings down risk to acceptable levels.
Of course, if I had access to couriers, one possibility would be to use them to exchange DVDs or other media full of cryptographically secure random numbers, and both sides just use one time pads [1]. That way, a document can be sent via a number of routes, and still be reasonably secure (although it doesn't hurt to send the sensitive stuff via offline courier anyway.)
[1]: I'd not just exchange OTP files, but a few dedicated TrueCrypt keyfiles and OpenPGP public keys. That way, there are a number of security tools available for data that doesn't need the maximum security of a OTP.
Is it possible to separate the fields of the SF-86 form so after they get OCR-ed, the physical documents (if any) go to a secure site [1], and if electronic, it gets printed out. Hard copies are useful for long term archiving.
Then, the online data gets split up into different databases, each not connected to the other. This is done with banking, and has helped with limiting the scope of an intrusion.
By separating the data out (preferably into physically separate data centers, and then having a query be done from different DBs, this would make the job of grabbing everything a lot tougher.
Of course, it might be wise to have the data only accessible on NIPRNet or some other WAN that is not connected to the Internet, and the forms never available via the external web. Again, not a 100% measure, but it forces an attacker to have to resort to physical compromise.
[1]: Historically, governments are top notch at physical security, so reducing computer security issues to things that require a physical presence go a long way.
I'm actually surprised. The chip/PIN readers are gaining steam here in the US. Even Square has an EMV reader. The fact that vendors have to pay the cost is getting them to actually get off their buts and deploy these. Even ATMs are starting to have a mechanism for chips.
I just wonder how they are going to handle fraud via mail order or where the card isn't present. This will still be an issue.
Slashdot Mirror
Unlikely to happen, in today's climate, though nothing is impossible.
If this keeps up, I would not be surprised if a Cuban-like restoration industry emerges, taking junked cars, just the chassis, adding the interior and a reasonable engine, and putting cars on the road with that, sans the Big Brother features. The chassis might be an older car, but essentially the vehicle would be completely rebuilt.
ext4 encryption has a lot of promise, and I consider this a big feature. It essentially functions like EncFS/CFS, but instead of being a secondary filesystem accessible via FUSE, it is part of the main filesystem. The closest thing it parallels is AIX's EFS.
I'm not surprised that Google coded this part. It makes perfect sense for Android. Encryption of /data can be turned on immediately during a device setup without having to worry about block level items, or if the device crashes during the /data encryption process.
Overall, an add-on which is definitely needed. Since Google mainly uses ext4, this is their best bang for the buck, and I hope the maintainers of other filesystems toss something similar in their code.
One reason why polling companies can't get usable info is that end users tend to be constantly barraged by robocalls, be it the GE security system, "polls" which actually turn out to be scammy sales pitches, or many other types of scams.
Because of this, people either use apps like Mr. Number which autoblocks, or just ignore any number not on their contacts list and area code. If someone does answer and gets a "hi, this is not a sales call", the "end" button on the phone gets pressed by instinct, just like one's hand draws back if they touch a hot pan.
I am not sure from reading the page what exactly Trapwire does. Does it sit, grab facial recognition data, and try to put two and two together if it notices a person at certain places at certain times, then sound an alert to the local security that "so and so is a risk" because they were first at Spatula City, then the Duct Tape Shoppe, now they are showing up at the Vend-A-Goat convention?
I wonder if this is a spinoff from the software used in LV gambling establishments where if someone is banned from one casino on the Strip, they are banned from all of them, and security heads for them the second they step in the door.
When I first read this article, I thought "Tripwire", which to me, is a useful product, and used properly, it wouldn't be surprising for people to tamper with some machines, Tripwire catch it on a subsequent system scan come audit time, and wind up getting caught, especially here in Texas.
Some servers (IBMs, HP ProLiants) have decent power management capabilities, so the boxes can stay on and be idle... but consume a relatively small amount of electricity and cooling. Add a SSD for local storage and swap (start the OS or hypervisor and let the SAN take it from there), and even the energy usage of spinning disks can be minimized.
However, with the many ways and layers to do HA, might as well do active/active if possible. On the VMWare side of the house, DRS comes to mind, and it also supports true fault tolerant VMs [1].
Generally, with modern applications (Oracle RAC, for example), active/passive configurations are tending to go the way of the dodo, replaced by active/active, where each server runs about 1/2 the workload. Other applications use a public IP or name, and load-balance, so that a dead box means stuff continues on, but just fewer machines to service the incoming items. Even the IBM mainframes that use Parallel Sysplex are active/active (as both units run all computations in lock-step with one another.)
Of course, there are some applications that are active/passive, such as the legacy IBM HA systems... but those are the exception.
1/3 of all servers not doing things might make sense... in the fact that there are times where a machine decides to eat itself, but the IT staff just doesn't know, or doesn't bother to fix it. For example, some machine that was a development machine for a long-forgotten project that fell out of favor. A lot of companies have internal policies to shut down physical servers, but in the smaller data centers that SMBs are likely using, those policies of decommissioning, or just auditing everything in the data center and yanking anything not being used are not there.
[1]: True fault tolerant, as in the VM actually has two instances of it, each on a different physical machine, so if the primary VM drops, the second takes over in milliseconds. The downside is that the VM can only have one vCPU, and there are a number of other limitations. However, for a licensing server or some other tasks which even the delay to reboot a VM and autostart processes might be too much, it is a useful tool.
Grr, quick addendum on #2: I can see a firm just tossing the OS and application on a machine and walking off, but in general that isn't a good practice.
I can see some machines snoozing for long periods of time, but not 1/3 of a place:
1: Hypervisor-level failover on VMWare or Hyper-V. Generally there are hypervisor updates, such as the recent SSL holes which required a update on ESXi, and other security items on Hyper-V [1]. However, these can sit for a good while untouched, and ready to handle a vMotion punt at a moment's notice.
2: Failure on an active/passive configuration at the DB level. With something like Oracle RAC that costs a lot for licensing, why not just got active/active? In general, the DB application and the OS should be upgraded more often, but I can see someone just tossing
3: IBM PowerHA. Since the virtualization firmware is generally upgraded during the latter months (when new TLs/MLs come out), these machines can probably sit around doing nothing for most of a year.
[1]: I'm meaning "raw" Hyper-V servers that are not part of a Windows Server OS install. Neglecting a Windows Server OS install is just asking for the box to become a "client" of another sort.
There are bands and musicians who have kept themselves relevant by maintaining their fan base, no matter how times change. Pink Floyd, Rush, Iron Maiden, Phish, ICP, and NIN come to mind.
However, it takes time to convert a fan base from "hey, that is a cool/trendy song" to "hey, $BAND is having a new album come out." Some musicians don't take the time to try to look at the long picture, and try to break from their genre into a unique area only they are present in. One can get heard via being the pop thing, but one either has to have their own style (almost enough to have a subgenre) in order to not be forgotten in 2-3 years.
One also doesn't have to be mainstream to eke out a decent fan base. The Austrian band Summoning has created a niche for themselves. Similar with the band Alestorm. Word of mouth and streaming services have gotten them heard, and merchandising sales is the revenue earner.
Of course, there are the security aspects as well. We already have been down this road with Java (which did have a lot of promise, especially with HotJava as an example of a browser written in the language, and prototype CPUs that could execute Java bytecode natively.) However, it fell apart, and now, code running on the same JVM on a Mac may just completely fail on Windows, and the other way around. Then, there is finding the right JVM.
Of course, there will be updates. A bytecode language is never finished. So, Web bytecode 7.0 either has to be compatible with every release before that, or break programs. Similar thing happened with Java, which makes it a pain sometimes when using a browser to access some hardware that used an embedded browser/Java interface, especially with the security issues of backlevel versions.
Finally, a security model needs to be put into place, or this will make an excellent tool for bad guys to inject code into the browser and compromise it without a trace (barring memory snapshots by the hypervisor.)
Just say "no".
I'd rather either have an exception thrown or a "NaN" value used than a zero returned. A divide by zero error is nasty, but just "papering over" it by returning a zero is only going to introduce more subtle bugs in the code.
The public key allows for more flexibility than just a shared secret. For example, if one wants to store a blob on a untrusted cloud provider, they could store it encrypted to each device's public key. This can be made transparent to the user, since the user just has to "introduce" a device via another, already trusted device which would decrypt the data blob's master key with its own private key, add an encrypted entry for the public key of the device being introduced.
Another item is that if someone snatches hashes of passwords, all the users (or devices in this case) have to change their passwords next login, have their passwords locked out until they complete a recovery process, be be re-authenticated somehow that is different from the password. A list of key hashes gives no usable info to the intruder, as in they can't brute force a password that fits the hash.
Shared secrets have their place, but the advantage of going with the equivalent of client certs is that it lessens what amount of data is sensitive, and forces an intruder to modify data to add their public key for access. If the public keys are leaked, it doesn't do an attacker any good, unless they have broken RSA.
If phone makers (and phones are not cheap items) in general won't provide updates for more than a version or two at most, then I doubt IoT device makers would provide much, if any, about updates.
IMHO, the best thing about IoT is to just say no.
There are ways to design IoT devices securely (for example, having them use a hardened, central hub that handles the communication through the Internet, so attacks on individual devices end up having to be physically local), but since IoT is such a "fad", security is at best an afterthought after the product design is rushed out the door, so I expect zero security whatsoever.
Of course, I am leery of the next step above this... having to wait for an ad to play on the fridge before I can open the door, having to pay the stove manufacturer $29.99 a month so I can use the self-cleaning settings, finding my faucet won't turn on because it lost connection with the cellular tower as the telco dropped GSM for pure LTE, getting fined by my HOA because the freezer detected more than the alloted moving things via its camera in the house, and so on.
Then, there is the security nightmare. Think those IoT providers will pay more than lip service to ensuring their devices are not easy prey? Won't happen.
Finally, there are the higher prices. I don't feel like paying hundreds of dollars for a thermostat, or thousands of dollars for a fridge because it is "smart". If I wanted to pay top dollar for a fridge, depending on availability, I would get a propane or natural gas fridge, so my stuff stays cold even if there is a power outage.
With all the security available in device operating systems, there are better ways to do this:
When the app is created, have it generate a public/private keypair, store the private key in the OS's keystore (called KeyChain in both iOS and Android.) Then, on first authentication to the servers (you are using SSL/TLS for all communication, right?), the central server will store the device's public key's fingerprint. From then on, it functions like a client certificate, and can be optionally used with an app's PIN function for added security.
The benefit of this over a shared secret? Someone hacks the server, a list of key fingerprints will do an attacker no good to authenticate against (because they don't even have the key material that the fingerprint shows), and can be added/deleted per device. With iOS's and Android's keystore functionality, if the device is locked, the keystore is encrypted and inaccessible, providing another layer of protection on top of encrypting /data.
To the user, it functions exactly the same, but it is a lot more secure in virtually every way. The only way it would be less secure is if RSA or the public key algorithm in use was completely broken.
As for bans, you can easily do what Yik Yak and other apps do -- grab the IMEI (if available) and other serials (UDID), and ban by that. Then, even if the app is uninstalled, the phone is still blacklisted.
I prefer the VPS route, just because it gives some separation of data between myself and others. A shared hosting provider may have things (mis)configured to where a simple change in directory might allow another user access (if not modification) to my stuff, especially if they happen to find a way to get a shell.
Of course, VPSes are not perfect -- they can get hacked, but one has the ability to add 2FA and other items if need be.
Of course, there is one drawback... a lot of VPS sites don't allow you to set a cap on bandwidth used, so a DDoS might cost one dearly in money.
Right now, security is a purely defensive battle, at best we have the enemy at a stalemate, where their attacks are foiled. There is no way to "win", since the attacker usually is located in a country with little to no cyber-crime laws, or even in a hostile country that rewards it. At best, we tread water.
Would a long term solution be creating private networks like SIPRNet or NIPRNet, so that the barrier for entry is raised, so an attacker has to get onto that private network, and this might be something where physical access is needed. Not 100% secure, but it raises the bar so that attackers have to have "boots on the ground".
If not, what would be workable, other than just air-gapping as much as possible? Would it be wise for each nation to mimic China and have their own Great Firewall, so attacks have the ability to be be stopped well away from their intended targets?
Sennheiser (and to a lesser extent Sony) make pro-grade headphones. They may not be as glamorous as Beats, but they are not made to be. They are made to help with a job where people make money using their equipment.
I still use a set of Sony MDR-F1s. Definitely not showy, but still do a quite accurate job of sound reproduction while allowing you to still hear what's around you, and don't contact one's ears.
It does matter, especially with Lightning connectors, since non-certified devices will give a warning on the iDevice, either disallowing charging, or just not working at all.
Even if a device does work, I've encountered off-brand USB to Lightning adapters which spark when connected/disconnected to the point of leaving scorch marks on the connector. This does definitely not bode well for any circuitry.
I look for the "Certified with iDevice", because it means some hoop jumping was done and the device meets some standards, and for a 120/240 VAC to USB charger, this isn't a bad thing, since there are some really cheap, dangerous chargers on the market where their UL listing is dubious, fake, or just not there.
There is a point with audio that there is a split between "pro audio" (as in flat response monitor speakers), versus "audiophile audio" (speakers that have Bog knows what for response levels, but they look cool on their marble stands.)
While some cable making companies tout things that can't be quantified, there are items that can be, such as a proper gauge of wire, well soldered fittings that are properly shrink wrapped to prevent oxidation, good insulation, and other basics.
A gold alloy is harder, so it is more resistant to insertions.
There are places where this comes in handy. For example, some PCs have an internal USB cable which plugs into the motherboard, then goes to the front ports. The problem is often the contacts corrode over time, which gives a spotty connection after a while. This is why I wind up testing a faulty USB device by plugging it directly into the motherboard's ports before tossing it altogether. USB connectors are generally made to handle insertions and removals, where a layer of oxide is scraped off. For connections that are long term, but use USB, going with gold plating might be wise.
However, there are other ways to solve this problem. DeOxIt comes to mind which is good for not just removing corrosion, but putting a thin coating of oil over them to protect against oxidation. Other people who have analog studios solve this problem by evacuating the oxygen out of the control room when it isn't in use using nitrogen gas.
Easy fix: Have the ISP have a root cert one must put in their keystore, and the ISP uses a device like a BlueCoat appliance for real time MITM-scanning of all traffic.
Add an in-transit ad injector, and it will be a money maker for the ISP as well.
This is easy to enforce:
Make all devices that connect to the Internet have to pass a NAC healthcheck, with software similar to AV signature scanning, except it has signatures of encryption programs (except programs used for managing DRM), and uses heuristics to find what it considers encrypted files, then notifies the upstream to block the machine from the Net for good. Similar to how modded consoles get tossed off PSN or XBox Live, or how some printers will phone home if someone tries to print PDF files of currency.
Then mandate software as part of MTAs, messaging servers, and boards to also look for signatures of encryption (even if it is just a non compressible blob of data), and autoban the user that did it.
Of course, it won't make it impossible... but the barrier will be so high that the risk/rewards won't be worth it... and lets be honest... most people outside of the IT crowd really don't give a rat's ass about encryption or even privacy.
Of course, there is the blowback: Can't have it both ways. Either you have solid encryption and keep both the good guys and bad guys out, or ban encryption [1] and allow the bad guys free reign in the business, non-classified government, and other sectors as a cost of doing business. Can't have both.
[1]: We went through this with Clipper and Skipjack, so alt.security, sci.crypt, and Cypherpunks archives from the early 1990s go into this in much detail.
The ironic thing is that if more companies used an OpenPGP variant (Symantec's PGP, GnuPG, NetPGP, and so on), it really wouldn't matter what channel stuff was sent on. They could create a FB group and stash the files as attachments, but the contents would be secure, assuming keys of a proper length and the private keys properly used/secured, for example, having a key generated and stored in a Yubikey or other cryptographic token. Even just doing document processing in a secured environment like an iOS or Android device would reduce the level of compromise of files in transit quite a bit. Nowhere near as secure as an airgap, but for a lot of items, it brings down risk to acceptable levels.
Of course, if I had access to couriers, one possibility would be to use them to exchange DVDs or other media full of cryptographically secure random numbers, and both sides just use one time pads [1]. That way, a document can be sent via a number of routes, and still be reasonably secure (although it doesn't hurt to send the sensitive stuff via offline courier anyway.)
[1]: I'd not just exchange OTP files, but a few dedicated TrueCrypt keyfiles and OpenPGP public keys. That way, there are a number of security tools available for data that doesn't need the maximum security of a OTP.
This gets me wondering:
Is it possible to separate the fields of the SF-86 form so after they get OCR-ed, the physical documents (if any) go to a secure site [1], and if electronic, it gets printed out. Hard copies are useful for long term archiving.
Then, the online data gets split up into different databases, each not connected to the other. This is done with banking, and has helped with limiting the scope of an intrusion.
By separating the data out (preferably into physically separate data centers, and then having a query be done from different DBs, this would make the job of grabbing everything a lot tougher.
Of course, it might be wise to have the data only accessible on NIPRNet or some other WAN that is not connected to the Internet, and the forms never available via the external web. Again, not a 100% measure, but it forces an attacker to have to resort to physical compromise.
[1]: Historically, governments are top notch at physical security, so reducing computer security issues to things that require a physical presence go a long way.
I'm actually surprised. The chip/PIN readers are gaining steam here in the US. Even Square has an EMV reader. The fact that vendors have to pay the cost is getting them to actually get off their buts and deploy these. Even ATMs are starting to have a mechanism for chips.
I just wonder how they are going to handle fraud via mail order or where the card isn't present. This will still be an issue.