I much rather have people as stakeholders rather than shareholders in a corporation. Shareholders can just drop and run at any time, and really tend to not care about the long term future, assuming they have a sign of when to sell. Stakeholders are in it for the long haul.
Sadly, due to the hedge fund BS and the shareholder lawsuits if a company decides to put off some quarterly profits into R&D, the long term road tends to be ignored. Hopefully this will change.
I'm glad Dell is off the public exchange. They may not be as glamorous as Apple, but they are a major part of a lot of businesses, so if they are not subject to the constant lash of earnings, maybe they can make solid machines for business.
I am pretty sure that NeXT took it out because crypto was classified as a munition back then under ITAR, so it was yanked out in a subsequent version. Instead, it had this pseudo public key applet where one could type a password, and the public key was something generated from the password, so when you wanted to sign or decode something, the password was the private key.
I think it was the NSA or someone who goaded Apple into having decent security put in, from the improvements in how passwords were stored in OS X (first hashed, now salted and hashed with multiple rounds), to having decent full disk encryption.
I don't think any large company wants to be particularly crypto-friendly unless they are selling to a niche enterprise market. There is always a fear that one of the Four Horsemen of the Infocalypse would use their product and the police/LEOs will be saying to the press that if it were not for foobar's product, these criminals would have been caught and lives of children not lost, or why is their security product so good that only "terrorists" would use it.
I do agree about trying to get gpg [1] on a Mac. One either is forced to trust the mac port, or have to fetch a ton of libraries and build the prereqs to compile a usable gpg binary. Of course, one can use the commercial product from Symantec, Symantec Encryption Desktop Professional, but the price of that is pretty steep (think around $258.25.)
iOS is even worse. Good luck deleting root certificates from the device that you don't want. You trust what Apple says you need to trust, or go find another device to use. PGP/gpg apps are available for iOS, but the quality of the apps is "meh" at best, especially if you want to encrypt files before throwing them on an archive server, or use more advanced OpenPGP functionality like storing multiple files in one packet.
Most companies seem to have gone the "BYOC" (bring your own crypto) route other than Linux distributions and BSD variants. Yes, one -can- grab a binary, but how can you trust it, unless you download the binary to a trusted system with an existing copy and validate it there.
[1] PGP [2] is a very mundane, boring tool. However, it has stood the test of time, being standalone and not dependent on an OS, a CA system, a licensing model, or other factors. It has become so boring that it has been largely ignored except as a signing tool for OS distributions. It would be nice to see PGP keysigning parties again, or other ways to build one's personal web of trust.
[1]: I'm stating PGP as a superset of NetPGP, PGP, and gpg -- a utility that groks OpenPGP files, basically.
I stand corrected. That is the right function for calculating the number of node connections. Ten nodes maintaining 45 different OTPs isn't as bad as 3,628,800 (10!) OTPs, but it still is a lot to manage, and grows out of control the more offices added.
I don't know about ECC, but with RSA, big-O is n^3 for signing and encryption.
That means that if I have a 2048 bit key, doing signatures and encryptions take eight times as long as if I had a 1024 bit key. An 8192 bit key takes 512 times as long as a 1024 bit key.
RSA has been secure so far, but adding keylength is making it burn up a lot of space and CPU cycles (a 16384 bit key takes up a lot of space, especially on a keyserver.) Having another protocol that is as secure but uses a 256 to 384 bit keylength and perhaps a doubling or quadrupling of time when a keysize doubles will help things out immensely.
The main thing is that ECC keys are a lot smaller than RSA keys. A 384 bit ECC key is more secure (supposedly) than an 8192 bit RSA key.
The ironic thing is that ECC is not new. NeXTStep 3.0 had Fast ECC as part of a mail protocol around '92, but apparently that got killed in short order.
What I'd like to see (although there may be weaknesses lurking) is to use multiple asymmetric algorithms so if one fails, others hold. For signing, this is easy. Have three signatures instead of one, each signing the same info with different algorithms. For encryption, this may be an issue. Likely the best way would be to generate multiple symmetric keys, encrypt each with the different algorithm, and the session key for the rest of the data is the symmetric keys XOR-ed together. That way, if one algorithm is broken easily, the summed key is still out of reach.
You could use a hub-and-spoke topology, assuming the hub can be trusted (it falls into the all eggs in one basket issue.) That way, each office only needs one OTP to worry about, and the hub needs one OTP for each office.
It isn't perfect, but it sure beats needing (n-1)! one time pads for each office, n being the number of offices.
There is also using the OTP as part of a Diffie-Hellman key exchange to protect the session key. This way, very little pad gets used and the remainder of the transaction can be done with conventional symmetric encryption using chained [1] ciphers. Of course, very secure info can always be transferred via OTP, but a lot of data can be moved across with conventional encryption and be secure enough.
[1]: One uses multiple cyphers not for more bits on a key, but as a way to ensure that if AES fails, Serpent will still protect the data, and if both fail, there is always Twofish.
I also live in Austin, there is a Tesla servicing depot across the street from a Waterloo Icehouse on Burnet Road.
I think what people are doing is heading to another state, buying their Tesla there, then getting it registered in TX.
My beef against dealers is the fact that I have to play the negotiation game, pretend to walk out, actually walk out, go to another dealer, etc. I don't have to negotiate the best price when buying a refrigerator, why do I have to when buying a car?
European dealers have a "real" price, no dickering. No highly inflated MSRP/sticker that is a starting point.
RV-ing isn't really camping. They have similar skillsets, but are not really the same.
To me, camping is when I take a backpack, reduce weight to as low as I can (even using the toothbrushes that go on the finger from jail supply houses to save volume), hike a number of miles, find a level spot that isn't in a flood-prone area, nor is a meeting place for the local fauna, and plop down a tent for the night. Then, after done, strike camp and move on, packing everything out that was packed in.
RV-ing is a different beast altogether. There, it is finding a secluded place to set up shop, drop the awning, and then go for a hike, or just read a book or watch something on Netflix far away from the rest of the world. When dry camping, one wants to run a generator as little as possible, just because the darn things are loud when compared to a dead-quiet area, not to mention the fuel consumption. So figuring out how to get the most out of every battery charge is important. Things like switching to LED lighting, adding a solar charging system, using a propane heater like a Buddy heater come nightfall to minimize use of the propane furnace [1], and so on.
Because power is so valuable when dry camping, fewer watts is important, but so is a 12 volt appliance, so an inverter isn't needed (they use some energy in the conversion process.) With this in mind, it is good to have all low-current appliances be 12 volts. Higher-draw appliances (coffee maker) should be 120 volts because it takes large wires for 12 volt items.
Dry camping with an RV is useful in more mundane settings, such as using a campervan and staying overnight in the driveway at a friend's place in another city without needing to find a RV park.
[1]: A RV furnace burns propane and exhausts all the air to the outside, using a heat exchanger to warm inside air without adding exhaust, but requires fans to move air (taking about 10 amp-hours on a battery, a fairly heavy load when boondocking.)
I also am glad Apple didn't go the phablet route. Maybe it might be OK for one model to have the 6" screen, but for a number of people, even the iPhone 5's screen is pushing it.
We have already lost some useful features (the Lightning connector and the loss of ability to have a dock with structural support for the device built into the connector.) A larger phone in general means more space needed in drink holders, pockets, docks, and many other places, and makes the device unwieldy.
It doesn't make a financial sense, but having a new TV that is low power, especially one that runs off of 12 volts is a good thing to do when RV-ing, where when boondocking, one needs to save on every watt that comes from the battery bank.
A 60 watt TV's energy use can be mostly compensated for by a decent 200-300 watt solar panel and a good charge controller. A TV that uses three times that will be pushing things unless one also charges with generator power.
For home use, it doesn't matter that much. However, when camping away from everything, it can mean the difference between kicking back on a quiet day to watch a DVD, or having to fire up a generator (and even the quieter Hondas/Yamahas can be loud in a forest.)
IMHO, what is wrong with another authentication mechanism? Provided the fingerprint scanner is resistant to gummi bears and other trivial methods, when combined with the usual PIN, it means that even if someone shoulder-surfs, they are not getting into the device, and the fingerprint scanner can be used for a quick (but decently secure) confirmation of buy transactions, or to access an app that has photos stored out of the Camera Roll.
The NSA is very low on my list of people I'm worried about. I'm far more concerned about the security implications of getting pickpocketed while in line at a local S-Mart [1] than I am with the latest boogeyman of the week. The fingerprint scanner is a way that even if the phone was not locked when picked up, an unauthorized user wouldn't be able to get access to data stored by various apps.
What I am curious about is how really secure this fingerprint scanner is.
[1]: Even with the upcoming iOS 7 coming out which prevents activation unless the account password is used, phones will still be extremely valuable parted out.
Wonder how well the drive can take constant shocks and jostling that tablets are subject to. I may not be a HDD expert, but I wonder if just the tapping on a screen might be enough to cause a head crash, especially on a higher RPM drive.
In some companies (mainly seen this in educational institutions), there can be fault finding, "What, there is a vulnerability? Who was the last man in charge? Fire them!"
I've seen many people in IT who stepped up and reported security issues, only to get a target painted squarely into their backs and pretty soon after, shown the door with a black mark for their resume of "communicating to others about bypassing company security controls" or some other tales.
A lot of places will not hesitate to shoot the messenger.
In cases like these, if the hole has to be fixed ASAP, one can send anonymous E-mail to all IT people (through a long Mixmaster chain) about the hole. Then, it will get cleared up quickly, but most likely a witch hunt would ensue internally. Of course, this has a high chance of backfiring since a blamestorming session will soon to follow with someone getting to boot.
I believe in having a relatively small speed bump and keeping DRM to a minimum. For an application, just enough to make keygens [1] useless and require the app's executable to be patched, even if it is just a simple item that gets commented out. This breaks the signature of the program, and anyone pirating it will be at obvious risk of an added payload.
For games, I'd just have a multiplayer mode/library for easily downloaded levels/maps/etc. To access it, a valid key is needed and if two keys (assuming each key is one license) are used, the newer one will not be allowed on. Since this is handled by the server, modified clients are not an issue. Yes, one can always mirror/emulate the server's functionality, but it is a big enough barrier to get people to consider buying a key. Closest game to this was Neverwinter 1 which ditched the CD protection fairly early on.
[1]: Embed a public key in the program, and the key would include the licensing info with a netpgp signature.
If done, someone running diffs would spot it pretty soon. What is to worry about would be a site that offers binaries (RPMs for example) to have those from a different built tree than where the source comes from.
Maybe we need to move to a superset of the existing CA system, to a WoT. That way, CAs can suggest that a key offered from somewhere is legit, but are not the be all and end all. Plus, a CA can be trusted, semi-trusted, or left untrusted. Semi-trusted would mean that if multiple CAs in different countries all signed a cert, then that cert is likely OK and hasn't been tampered with.
The problem, as always, is end user education. The days of just assuming that a green lock icon on a webpage meaning complete assurance are gone, although one can always show trust level with some method. However, and end user might just not bother if it gets in the way of him getting to his bank or whatnot.
I also found that the dynamic IP addresses provided tend to be in a blacklist so E-mail will get shitcanned the moment it hits someone else's SMTP port. Of course, the trick is to use the ISP's or a third party's SMTP server as a relay.
Even with clearing cookies, there is still plenty of identifiable stuff in a browser, such as order of plugins, order of the font list, etc. The EFF has their Panopticlick which pretty much shows that almost every browser is unique.
If one wants to keep two accounts completely separate, I'd go to the length of having the second account in a completely different VM.
If that statement is taken to the real world, with the usual car/vehicle analogy, that means that a mining cart must have access to public roads or it is valueless, same with the extremely large trucks which move the tons of rocks at a quarry.
Not everything has to be connected to everything else. You can have people connect to interact with a database front-end without having to interact with the DB itself, or have people interact with a VDI that gives a barrier against untrusted code in a company's core.
Air-gapping is a very good security measure. Yes, it was gotten around by physical "boots on the ground", but for almost (and I repeat almost) all other attacks, if it isn't connected, it isn't hackable.
My server with my PGP/gpg keys and my domain CA root keys is not going on the Internet anytime soon, and receives patches via updates burned to DVD. Does that mean it is 100% secure? Nope. It means that I have taken steps to minimize intrusion possibilities which are hard to bypass unless someone wanted the data on that box enough to black-bag it.
NIST isn't all bad. They publish pretty good security checklists (NIST SCAP guides) for major operating systems and routers. Most of it is common sense, but there are a few things which are something to consider (AIX's trustchk capability for example to at least warn about new/tampered binaries and shell scripts.) They are mainly intended for FISMA [1] compliance, but they are an excellent reference for anyone needing a good checklist to consider. It isn't a one size fits all, but is a good place to start.
[1]: It would be nice if all cloud services would be FISMA compliant. This is mainly for USG interests, but it does show active security monitoring and at least trying to follow some good security steps other than the usual "security has no ROI" drumbeat.
In the early to mid 1990s, intrusions did happen, but it would take some doing because someone on DECNet would have to take some doing to jump to a machine on a private x.25 network.
These days, I've wondered about following the US government's lead with SIPRNet and NIPRNet, and having a "BIPRNet", which would be a switched network using leased lines among companies. Unless access between two machines was prearranged in advance, the boxes will not be allowed to connect to each other or forward packets. For security, the machines either share a symmetric key (like WPA2-AES-PSK), or are paired using public keys similar to Bluetooth pairing. This gives two layers of security. First, the core switch would have to be compromised to allow a third machine to connect, and then both machines would have to be compromised so they would bother interacting with the third machine and not ignore it outright. It isn't perfect, but it would be far stronger for B2B communications than the usual VPNs or SSL/TLS which can be hijacked by compromised CAs.
This won't replace the Internet by any means, but will provide a way for businesses or internal departments to communicate that is highly resistant to mass IP probing and other attacks.
There are some exceptions: We poor IT people who see Windows Server 2012 R2 and its bump of Hyper-V heading right for our data centers, and want to be able to start testing on it as soon as possible.
A preview release won't do, as there almost definitely will be changes between it and RTM versions.
Yes, on Windows 8, it is a lot of cosmetic changes, but Windows Server 2012 R2 has a number of new features that need to be evaluated and scoped out, testbeds created, tickets to vendors made (so they can fix incompatibilities), build documents updated, AD policies checked, tests to see if the OS will work on existing hardware, and so on.
All this OS testing has to be done and well documented before anything hits the production floor. Yes, one can sit on Windows Server 2003 and not bother trying to throw anything newer, but things change, and even though ESXi might be the mainstay of virtualization now, the deduplication and VM handoff (similar to vMotion) capabilities of the 2012 R2 Hyper-V will make it extremely attractive as a competitor. This all has to be well tested and documented.
Not doing so will eventually result in a day when the auditors come by, find obsolete versions on products, demand they be upgraded... which forces the business to go head-long to the latest OS or else. Might as well ease the pain and take time to get things tested, bugs found, and workarounds documented as early as possible.
Of course, this varies from business to business. Some companies can remain on NT 4.0 and be well off. Others have lots of software and regulatory issues, which means that not keeping updated means failing security audits.
I think a would-be thief still has to fight the battle with the engine anti-theft system to get the vehicle on and moving.
Tesla has some teething pains, as they are in completely new territory, and are not in the usual good ol' boy club with the other automakers, so they have to fight tooth and nail for everything.
For this to be their biggest issue, and in the scheme of things, it isn't that big a deal, it shows that their vehicles are pretty well engineered.
What I'd love to have as an option not just on a Tesla, but on all cars is a master key switch, or a menu option if the car's key is a fob and not a mechanical device. Flip the switch on, the vehicle disables all antennas except the close range one needed to detect if the key is in range (if it is fob), or the passive RFID antenna, if the key is mechanical. That way, when the vehicle is parked in a fairly nasty location, tricks via websites, scanners, et. al. would not work.
If the autopilots have a common database they can reference, if one vehicle has trouble with an area, it can be noted and placed on a GPS map, so subsequent vehicles can take precautions (such as changing to the left lane to avoid potholes, noting that bicycles tend to be on a road, so slow down at a crest of a hill, etc.)
Of course, this info can be hacked to cause abuse, but that that is a solvable problem.
I bought a Nook HD because the price was right. Yes, it is sans camera and 3G, but it does make for a fairly inexpensive tablet, and you can easily run a recent version of Android on it. For security, there are apps that implement EncFS so I just create a volume and stash my files in that.
As for an E-reader, it does the job decently, although for long texts, I prefer my e-Ink display Kindle Keyboard.
Only two downsides are its funky charging connector, and the fact that if it fails to boot eight times, it will erase and reinstall itself, which means one forced upate, then the second update so it has the Google Play Store usable.
Slashdot Mirror
I much rather have people as stakeholders rather than shareholders in a corporation. Shareholders can just drop and run at any time, and really tend to not care about the long term future, assuming they have a sign of when to sell. Stakeholders are in it for the long haul.
Sadly, due to the hedge fund BS and the shareholder lawsuits if a company decides to put off some quarterly profits into R&D, the long term road tends to be ignored. Hopefully this will change.
I'm glad Dell is off the public exchange. They may not be as glamorous as Apple, but they are a major part of a lot of businesses, so if they are not subject to the constant lash of earnings, maybe they can make solid machines for business.
I am pretty sure that NeXT took it out because crypto was classified as a munition back then under ITAR, so it was yanked out in a subsequent version. Instead, it had this pseudo public key applet where one could type a password, and the public key was something generated from the password, so when you wanted to sign or decode something, the password was the private key.
I think it was the NSA or someone who goaded Apple into having decent security put in, from the improvements in how passwords were stored in OS X (first hashed, now salted and hashed with multiple rounds), to having decent full disk encryption.
I don't think any large company wants to be particularly crypto-friendly unless they are selling to a niche enterprise market. There is always a fear that one of the Four Horsemen of the Infocalypse would use their product and the police/LEOs will be saying to the press that if it were not for foobar's product, these criminals would have been caught and lives of children not lost, or why is their security product so good that only "terrorists" would use it.
I do agree about trying to get gpg [1] on a Mac. One either is forced to trust the mac port, or have to fetch a ton of libraries and build the prereqs to compile a usable gpg binary. Of course, one can use the commercial product from Symantec, Symantec Encryption Desktop Professional, but the price of that is pretty steep (think around $258.25.)
iOS is even worse. Good luck deleting root certificates from the device that you don't want. You trust what Apple says you need to trust, or go find another device to use. PGP/gpg apps are available for iOS, but the quality of the apps is "meh" at best, especially if you want to encrypt files before throwing them on an archive server, or use more advanced OpenPGP functionality like storing multiple files in one packet.
Most companies seem to have gone the "BYOC" (bring your own crypto) route other than Linux distributions and BSD variants. Yes, one -can- grab a binary, but how can you trust it, unless you download the binary to a trusted system with an existing copy and validate it there.
[1] PGP [2] is a very mundane, boring tool. However, it has stood the test of time, being standalone and not dependent on an OS, a CA system, a licensing model, or other factors. It has become so boring that it has been largely ignored except as a signing tool for OS distributions. It would be nice to see PGP keysigning parties again, or other ways to build one's personal web of trust.
[1]: I'm stating PGP as a superset of NetPGP, PGP, and gpg -- a utility that groks OpenPGP files, basically.
I stand corrected. That is the right function for calculating the number of node connections. Ten nodes maintaining 45 different OTPs isn't as bad as 3,628,800 (10!) OTPs, but it still is a lot to manage, and grows out of control the more offices added.
I don't know about ECC, but with RSA, big-O is n^3 for signing and encryption.
That means that if I have a 2048 bit key, doing signatures and encryptions take eight times as long as if I had a 1024 bit key. An 8192 bit key takes 512 times as long as a 1024 bit key.
RSA has been secure so far, but adding keylength is making it burn up a lot of space and CPU cycles (a 16384 bit key takes up a lot of space, especially on a keyserver.) Having another protocol that is as secure but uses a 256 to 384 bit keylength and perhaps a doubling or quadrupling of time when a keysize doubles will help things out immensely.
The main thing is that ECC keys are a lot smaller than RSA keys. A 384 bit ECC key is more secure (supposedly) than an 8192 bit RSA key.
The ironic thing is that ECC is not new. NeXTStep 3.0 had Fast ECC as part of a mail protocol around '92, but apparently that got killed in short order.
What I'd like to see (although there may be weaknesses lurking) is to use multiple asymmetric algorithms so if one fails, others hold. For signing, this is easy. Have three signatures instead of one, each signing the same info with different algorithms. For encryption, this may be an issue. Likely the best way would be to generate multiple symmetric keys, encrypt each with the different algorithm, and the session key for the rest of the data is the symmetric keys XOR-ed together. That way, if one algorithm is broken easily, the summed key is still out of reach.
You could use a hub-and-spoke topology, assuming the hub can be trusted (it falls into the all eggs in one basket issue.) That way, each office only needs one OTP to worry about, and the hub needs one OTP for each office.
It isn't perfect, but it sure beats needing (n-1)! one time pads for each office, n being the number of offices.
There is also using the OTP as part of a Diffie-Hellman key exchange to protect the session key. This way, very little pad gets used and the remainder of the transaction can be done with conventional symmetric encryption using chained [1] ciphers. Of course, very secure info can always be transferred via OTP, but a lot of data can be moved across with conventional encryption and be secure enough.
[1]: One uses multiple cyphers not for more bits on a key, but as a way to ensure that if AES fails, Serpent will still protect the data, and if both fail, there is always Twofish.
I also live in Austin, there is a Tesla servicing depot across the street from a Waterloo Icehouse on Burnet Road.
I think what people are doing is heading to another state, buying their Tesla there, then getting it registered in TX.
My beef against dealers is the fact that I have to play the negotiation game, pretend to walk out, actually walk out, go to another dealer, etc. I don't have to negotiate the best price when buying a refrigerator, why do I have to when buying a car?
European dealers have a "real" price, no dickering. No highly inflated MSRP/sticker that is a starting point.
RV-ing isn't really camping. They have similar skillsets, but are not really the same.
To me, camping is when I take a backpack, reduce weight to as low as I can (even using the toothbrushes that go on the finger from jail supply houses to save volume), hike a number of miles, find a level spot that isn't in a flood-prone area, nor is a meeting place for the local fauna, and plop down a tent for the night. Then, after done, strike camp and move on, packing everything out that was packed in.
RV-ing is a different beast altogether. There, it is finding a secluded place to set up shop, drop the awning, and then go for a hike, or just read a book or watch something on Netflix far away from the rest of the world. When dry camping, one wants to run a generator as little as possible, just because the darn things are loud when compared to a dead-quiet area, not to mention the fuel consumption. So figuring out how to get the most out of every battery charge is important. Things like switching to LED lighting, adding a solar charging system, using a propane heater like a Buddy heater come nightfall to minimize use of the propane furnace [1], and so on.
Because power is so valuable when dry camping, fewer watts is important, but so is a 12 volt appliance, so an inverter isn't needed (they use some energy in the conversion process.) With this in mind, it is good to have all low-current appliances be 12 volts. Higher-draw appliances (coffee maker) should be 120 volts because it takes large wires for 12 volt items.
Dry camping with an RV is useful in more mundane settings, such as using a campervan and staying overnight in the driveway at a friend's place in another city without needing to find a RV park.
[1]: A RV furnace burns propane and exhausts all the air to the outside, using a heat exchanger to warm inside air without adding exhaust, but requires fans to move air (taking about 10 amp-hours on a battery, a fairly heavy load when boondocking.)
I also am glad Apple didn't go the phablet route. Maybe it might be OK for one model to have the 6" screen, but for a number of people, even the iPhone 5's screen is pushing it.
We have already lost some useful features (the Lightning connector and the loss of ability to have a dock with structural support for the device built into the connector.) A larger phone in general means more space needed in drink holders, pockets, docks, and many other places, and makes the device unwieldy.
It doesn't make a financial sense, but having a new TV that is low power, especially one that runs off of 12 volts is a good thing to do when RV-ing, where when boondocking, one needs to save on every watt that comes from the battery bank.
A 60 watt TV's energy use can be mostly compensated for by a decent 200-300 watt solar panel and a good charge controller. A TV that uses three times that will be pushing things unless one also charges with generator power.
For home use, it doesn't matter that much. However, when camping away from everything, it can mean the difference between kicking back on a quiet day to watch a DVD, or having to fire up a generator (and even the quieter Hondas/Yamahas can be loud in a forest.)
IMHO, what is wrong with another authentication mechanism? Provided the fingerprint scanner is resistant to gummi bears and other trivial methods, when combined with the usual PIN, it means that even if someone shoulder-surfs, they are not getting into the device, and the fingerprint scanner can be used for a quick (but decently secure) confirmation of buy transactions, or to access an app that has photos stored out of the Camera Roll.
The NSA is very low on my list of people I'm worried about. I'm far more concerned about the security implications of getting pickpocketed while in line at a local S-Mart [1] than I am with the latest boogeyman of the week. The fingerprint scanner is a way that even if the phone was not locked when picked up, an unauthorized user wouldn't be able to get access to data stored by various apps.
What I am curious about is how really secure this fingerprint scanner is.
[1]: Even with the upcoming iOS 7 coming out which prevents activation unless the account password is used, phones will still be extremely valuable parted out.
Wonder how well the drive can take constant shocks and jostling that tablets are subject to. I may not be a HDD expert, but I wonder if just the tapping on a screen might be enough to cause a head crash, especially on a higher RPM drive.
In some companies (mainly seen this in educational institutions), there can be fault finding, "What, there is a vulnerability? Who was the last man in charge? Fire them!"
I've seen many people in IT who stepped up and reported security issues, only to get a target painted squarely into their backs and pretty soon after, shown the door with a black mark for their resume of "communicating to others about bypassing company security controls" or some other tales.
A lot of places will not hesitate to shoot the messenger.
In cases like these, if the hole has to be fixed ASAP, one can send anonymous E-mail to all IT people (through a long Mixmaster chain) about the hole. Then, it will get cleared up quickly, but most likely a witch hunt would ensue internally. Of course, this has a high chance of backfiring since a blamestorming session will soon to follow with someone getting to boot.
I believe in having a relatively small speed bump and keeping DRM to a minimum. For an application, just enough to make keygens [1] useless and require the app's executable to be patched, even if it is just a simple item that gets commented out. This breaks the signature of the program, and anyone pirating it will be at obvious risk of an added payload.
For games, I'd just have a multiplayer mode/library for easily downloaded levels/maps/etc. To access it, a valid key is needed and if two keys (assuming each key is one license) are used, the newer one will not be allowed on. Since this is handled by the server, modified clients are not an issue. Yes, one can always mirror/emulate the server's functionality, but it is a big enough barrier to get people to consider buying a key. Closest game to this was Neverwinter 1 which ditched the CD protection fairly early on.
[1]: Embed a public key in the program, and the key would include the licensing info with a netpgp signature.
If done, someone running diffs would spot it pretty soon. What is to worry about would be a site that offers binaries (RPMs for example) to have those from a different built tree than where the source comes from.
Maybe we need to move to a superset of the existing CA system, to a WoT. That way, CAs can suggest that a key offered from somewhere is legit, but are not the be all and end all. Plus, a CA can be trusted, semi-trusted, or left untrusted. Semi-trusted would mean that if multiple CAs in different countries all signed a cert, then that cert is likely OK and hasn't been tampered with.
The problem, as always, is end user education. The days of just assuming that a green lock icon on a webpage meaning complete assurance are gone, although one can always show trust level with some method. However, and end user might just not bother if it gets in the way of him getting to his bank or whatnot.
I also found that the dynamic IP addresses provided tend to be in a blacklist so E-mail will get shitcanned the moment it hits someone else's SMTP port. Of course, the trick is to use the ISP's or a third party's SMTP server as a relay.
Even with clearing cookies, there is still plenty of identifiable stuff in a browser, such as order of plugins, order of the font list, etc. The EFF has their Panopticlick which pretty much shows that almost every browser is unique.
If one wants to keep two accounts completely separate, I'd go to the length of having the second account in a completely different VM.
If that statement is taken to the real world, with the usual car/vehicle analogy, that means that a mining cart must have access to public roads or it is valueless, same with the extremely large trucks which move the tons of rocks at a quarry.
Not everything has to be connected to everything else. You can have people connect to interact with a database front-end without having to interact with the DB itself, or have people interact with a VDI that gives a barrier against untrusted code in a company's core.
Air-gapping is a very good security measure. Yes, it was gotten around by physical "boots on the ground", but for almost (and I repeat almost) all other attacks, if it isn't connected, it isn't hackable.
My server with my PGP/gpg keys and my domain CA root keys is not going on the Internet anytime soon, and receives patches via updates burned to DVD. Does that mean it is 100% secure? Nope. It means that I have taken steps to minimize intrusion possibilities which are hard to bypass unless someone wanted the data on that box enough to black-bag it.
Devil's advocate here:
NIST isn't all bad. They publish pretty good security checklists (NIST SCAP guides) for major operating systems and routers. Most of it is common sense, but there are a few things which are something to consider (AIX's trustchk capability for example to at least warn about new/tampered binaries and shell scripts.) They are mainly intended for FISMA [1] compliance, but they are an excellent reference for anyone needing a good checklist to consider. It isn't a one size fits all, but is a good place to start.
[1]: It would be nice if all cloud services would be FISMA compliant. This is mainly for USG interests, but it does show active security monitoring and at least trying to follow some good security steps other than the usual "security has no ROI" drumbeat.
In the early to mid 1990s, intrusions did happen, but it would take some doing because someone on DECNet would have to take some doing to jump to a machine on a private x.25 network.
These days, I've wondered about following the US government's lead with SIPRNet and NIPRNet, and having a "BIPRNet", which would be a switched network using leased lines among companies. Unless access between two machines was prearranged in advance, the boxes will not be allowed to connect to each other or forward packets. For security, the machines either share a symmetric key (like WPA2-AES-PSK), or are paired using public keys similar to Bluetooth pairing. This gives two layers of security. First, the core switch would have to be compromised to allow a third machine to connect, and then both machines would have to be compromised so they would bother interacting with the third machine and not ignore it outright. It isn't perfect, but it would be far stronger for B2B communications than the usual VPNs or SSL/TLS which can be hijacked by compromised CAs.
This won't replace the Internet by any means, but will provide a way for businesses or internal departments to communicate that is highly resistant to mass IP probing and other attacks.
There are some exceptions: We poor IT people who see Windows Server 2012 R2 and its bump of Hyper-V heading right for our data centers, and want to be able to start testing on it as soon as possible.
A preview release won't do, as there almost definitely will be changes between it and RTM versions.
Yes, on Windows 8, it is a lot of cosmetic changes, but Windows Server 2012 R2 has a number of new features that need to be evaluated and scoped out, testbeds created, tickets to vendors made (so they can fix incompatibilities), build documents updated, AD policies checked, tests to see if the OS will work on existing hardware, and so on.
All this OS testing has to be done and well documented before anything hits the production floor. Yes, one can sit on Windows Server 2003 and not bother trying to throw anything newer, but things change, and even though ESXi might be the mainstay of virtualization now, the deduplication and VM handoff (similar to vMotion) capabilities of the 2012 R2 Hyper-V will make it extremely attractive as a competitor. This all has to be well tested and documented.
Not doing so will eventually result in a day when the auditors come by, find obsolete versions on products, demand they be upgraded... which forces the business to go head-long to the latest OS or else. Might as well ease the pain and take time to get things tested, bugs found, and workarounds documented as early as possible.
Of course, this varies from business to business. Some companies can remain on NT 4.0 and be well off. Others have lots of software and regulatory issues, which means that not keeping updated means failing security audits.
I think a would-be thief still has to fight the battle with the engine anti-theft system to get the vehicle on and moving.
Tesla has some teething pains, as they are in completely new territory, and are not in the usual good ol' boy club with the other automakers, so they have to fight tooth and nail for everything.
For this to be their biggest issue, and in the scheme of things, it isn't that big a deal, it shows that their vehicles are pretty well engineered.
What I'd love to have as an option not just on a Tesla, but on all cars is a master key switch, or a menu option if the car's key is a fob and not a mechanical device. Flip the switch on, the vehicle disables all antennas except the close range one needed to detect if the key is in range (if it is fob), or the passive RFID antenna, if the key is mechanical. That way, when the vehicle is parked in a fairly nasty location, tricks via websites, scanners, et. al. would not work.
If the autopilots have a common database they can reference, if one vehicle has trouble with an area, it can be noted and placed on a GPS map, so subsequent vehicles can take precautions (such as changing to the left lane to avoid potholes, noting that bicycles tend to be on a road, so slow down at a crest of a hill, etc.)
Of course, this info can be hacked to cause abuse, but that that is a solvable problem.
I bought a Nook HD because the price was right. Yes, it is sans camera and 3G, but it does make for a fairly inexpensive tablet, and you can easily run a recent version of Android on it. For security, there are apps that implement EncFS so I just create a volume and stash my files in that.
As for an E-reader, it does the job decently, although for long texts, I prefer my e-Ink display Kindle Keyboard.
Only two downsides are its funky charging connector, and the fact that if it fails to boot eight times, it will erase and reinstall itself, which means one forced upate, then the second update so it has the Google Play Store usable.