Since the SoC functions are still a black box, I rather just go with a ROM on a moddable handset like the HTC One M8 with XPrivacy installed, where even if a basic fleshlight app demanded every priv under the sun, it won't get it. When it comes to phones, having the ability to block apps from phoning home is a major security feature.

Even better, why can't a company work on virtualization on a handset? That way, one can have a VM for web browsing, one for work stuff, one for home/personal, and one for clients? This is more important and would be more useful (especially if the hardware supported two SIM cards) then yet another black box phone. With online deduplication and having the hypervisor do the encryption, decent security can be maintained on a device without much fuss from the user.

I'm not attached to any of these ideas I posted, so if proven wrong, that is just fine with me... again, they were just thoughts of something that might be useful. TPM 2.0 is part of the Windows Certification spec, but oftentimes, there are many computers that will run Windows 8.1, but are not certified for it. Here is the link: https://msdn.microsoft.com/en-...

I've had phish attempts back in 1993 on Solaris and IRIX... Not good ones, but people fakemailing, pretending to be from "root", asking to run a shell script that would send the /etc/passwd file off to an anonymizer address... well before abuse forced Julf to shut down penet's remailer for good.

Easily detected, because I was the only person with root access, but I'm sure college students probably follow directions and kicked the university's passwd files there (although with NIS/NIS+, as well as the real password hashes stashed in /etc/shadow ) there wasn't much to attack, even back then.

To address points 1-3, TPM 2.0 is an item that is required for a machine to pass Windows 8.1 hardware certification, so even though it isn't explicit, the technology will be there. For better, or worse, it will be with us, so might as well make it useful. If BitLocker can be made as easy to use as FileVault, it would be a big bump in the security reputation of both the hardware vendor, as well as MS.

For point 2, a good example of doing it "right" is Boxcryptor. It is a pretty UI over EncFS, but it does work and works decently well. Most customers don't care about encryption, but it can be used in a way to provide clientside protection that is pretty much transparent. The perfect is the enemy of the good, so there would need to be something done to make recovery usable... but this is a solvable problem, similar to how Apple deals with FileVault 2 recovery issues.

For point 3, it isn't a perfect solution, but it can be implemented "right". A MicroSD card slot is one way, where the slot the card is, is permanently set to be read-only (this is part of the SD spec.) To prevent altering data, the encrypted section of the card could be used to store the OS data. Even with this, it still isn't 100% (as an evil maid could pull the card, go to a place that has the SD spec for decoding the encrypted partition, and modify things), but it is secure from most things.

For point 4, 10GB boards and modules (well, over twisted pair copper that is... NICs that use SFPs are still not inexpensive) are falling in price, so it will not be surprising to see them appearing on consumer level motherboards in a few years, perhaps with some TCP offload functionality. Done right, it would be useful, and if worse comes to worst, the functionality can be shut off entirely.

It would be nice to see Lenovo go a step ahead in the consumer market and not just stop with shovelware, but maybe bundle some security features with their products. This would go a long way to fixing their black eye in the press:

1: A TPM chip shipped off and disabled (as per the spec) on all machines would be useful. Windows Vista and newer can take advantage of this and offer solid encryption that is highly resistant to brute force attack.

2: Add clientside encryption to Reachit with a public format, perhaps getting other vendors on board. This way, users have cloud access... but files are transparently encrypted, similar to BoxCryptor.

3: Have a small SSD read-only volume with a custom WIM present for install media as well as drivers. This way, if a machine needs to be reinstalled from scratch due to a HDD or SSD replacement, this can be done anywhere, and no OS media would be needed. This also is useful for recovery as well, especially if there is a way to get to a PE environment which can be used to save off files, run an offline AV scanner, or fix a haywire application.

4: Add firewalling onto the NICs themselves. Around 10 years ago, some nVidia motherboard chipsets had this capability where the onboard NICs were intelligent enough to have the ability to have their own rulesets. This was quite useful, both to keep the OS protected with IP blacklists, as well as to limit the damage a compromised OS can do (for example, block all outgoing port 25 traffic.) As an added benefit, if someone is worried about vPro or other "ring -1" management tools, those can easily be blocked at the NIC.

Some markets just come and go. It might just be that these lines of games might be just as viable as databases for one's Cabbage Patch dolls.

Would it make money? Maybe to a niche market. If I were to do something, I'd focus on price/quality as opposed to volume. For example, the guitar would not be a cheap piece of plastic, but perhaps a real one that can be strung and played as normal once someone got tired of the game.

Also, te game should go further than the last game types. Make different instruments. Allow multiple players to play the instruments at the same time, either coop, or one after the other in a battle of the bands. Even go with odd things, such as a chainsaw and doing WASP or Jackyl songs.

Mainstream-wise, no... this genre isn't going to be in vogue again, but there is still money to be made.

For a more pedestrian use, there is one thing that an engine like this that has a specific power band range would be ideal at... and that would be a generator. Here in the US, it would need to be geared to 3600 RPM unless an inverter is used.

If they were this efficient that they could get that much power output, it might be something to have as a backup generator for a house, as it could run from natural gas, propane, gasoline, or diesel.

Most of the scammers tend to be those casting a wide net. They bought an info dump with thousands of names, phone numbers, and such in it, feeding the numbers into a robodialer, and having people in a boiler room use names of relatives automatically on a scripted speech.

An anti-fraud device, or something asking for info to be called back at will be more than enough protection, because the scammer will just move to the next potential mark on the data dump and try them.

They try to be relatively quick about it. Eventually, bad number blocking sites like Mr. Number and others will have enough entries to have the fraudster's number blocked on devices subscribing to the service.

VoIP scams are easy to do. For example, callerID is fairly easy to forge and it doesn't cost much money to set up a boiler room and staff it with people who do this. This allows a company to be in India, but still call from a US number.

To boot, there are very stiff fines... but have you seen how a lot of the robocall firms are organized? Most have a lot of holding corporations that they work with, one owns the furniture, one pays the employees, one possesses the computer data, so when the main company, say XYZ corp, gets sued, they just file bankruptcy, then a new company, ABC corp gets created, and they are back in business the next day. To boot, all of these companies are registered offshore, so finding the true owners will be virtually impossible unless the company decides to hit a third rail in the US (drugs, guns, and IP violations.)

That is what I wonder about as well. Sintering requires heat, so that makes me wonder if the metal can handle the high temperatures that a turbine spins at.

However, TFA states a 3D printed rocket engine was made and actually used by UCSD researches in 2013, so there is a good chance that this can be made to function.

The rocket was 3D printed via DMLS, but then "hardened, polished, and assembled." I have zero clue on the hardening method, because non-ferrous metals can't be really heated and quenched.

I'm hoping this is something that can see actual use, because if done right, maybe we can get more people researching jet/turbine engines.

There is always the fact that a turbine engine can be used for a vehicle. With the 7+ speed transmissions available, as well as CVTs, the limitation of a turbine's narrow power band can be overcome at the gearbox.

The biggest issue that people have is app compatibility, and without apps, the entire ecosystem winds up marginalized, as it did with Maemo/Meego (which were excellent operating systems, but without popular support, just didn't continue on.)

The good news is that we have tools to fix this, especially with containers, virtualization, and btrfs that offers online and offline deduplication.

Virtualization is important. With this, one can have their apps for work in one VM which is up to corporate policies when it comes to encryption and access control, and a second VM for personal stuff. It would be nice if US phones had more dual SIM card support, so one could use two numbers at once, and "never the twain shall meet".

Containers are useful as well, mainly as a way to isolate and secure apps.

Of course, having deduplication saves space, so one can have 2-3 VMs, with most of the Android footprint (mainly /system) being shared between them.

This is a good thing. In the past, a company would get breached, and it would have a minimal impact after paying for a PR campaign, definitely forgotten after six months.

However, the Sony hack with E-mails leaked which got celebs mad and data destroyed is different. Before that, a company got hacked... but their data was still there, so a lot of managers just brushed it off. However, if an intrusion means that the entire company is unable to do business and likely will fail in days to weeks [1], security goes from something in the backseat that is perceived as having no ROI, to a major concern.

This is a good thing. We have had solid security concepts since the 1970s, and most enterprise applications and devices can be well locked down. It is just using the functionality involved and making it work for that company/organization's culture.

It also might get vendors focused on security, perhaps being able to standardize on things. For example, it would be nice to have a style of USB cryptographic token that works with anything, be it an AIX machine or a Windows box.

Which means more money for those who can keep pace with security.

[1]: There are a lot of businesses who decided to follow the hype and drop tape, and instead, go with tiers of SANs for backups. Backing up to SANs does provide decent protection against hardware faults.

However, all data accessible comes at a cost. A bad guy can log onto the SAN's backend and purge all data with just a single command. Once this is done, the data is gone, and because there are no backup tapes... there is no recovery possible. Even with SANs that replicate to different physical locations, the deletion will be replicated. Even more insidious is tampering over time where someone logs on a SAN, and just starts overwriting stored data that nobody ever accesses.

It makes me wonder if tape will go from being laughed at as "retro" to being a primary medium for storage again. A pile of tapes stored offline will require physical access to destroy, as opposed to zeroing out everything with just one button. Even cloud "media" is easily destroyed if a blackhat gets enough access.

Devil's advocate here:

What about DISA/NIST and their publications/guidelines? This is paid for by the taxpayers, and can be very useful, even though the info might be obvious in some places [1]. They have decent checklist guides on recent operating systems under their national vulnerability database.

It is nice to be able to fetch info, even if one doesn't have to worry about stuff like FISMA and SCAP, just to have a decent baseline of security.

[1]: Things like using group policies, not allowing multiple users use the same account, etc.

One of the best examples of abuses of patent reform is part of the history of refrigeration.

Refrigeration, and air conditioning as we know it was locked down for over 25 years because the ice industry was gigantic, purchased patents or had them granted (a metal tube with stuff flowing through it that chances phase, for example), which effectively blocked the refrigerator from becoming a household appliance until after World War 1.

There are two items when people mention PGP:

The OpenPGP format.

The PGP implementation applications, like archaic PGP versions, NetPGP, APG, OpenKeyChain, GNU Privacy Guard, Symantec Encryption Desktop, and a number of others.

As far as I know, all the above have their source code available under various licenses, even the Symantec stuff either has, or used to have, its source available for examination.

I do agree that a revamp in some of the OpenPGP implementation programs is direly needed, because as of now, the most usable implementation (IMHO) is Symantec's version, which is a commercial product.

It might be nice to see about breaking the OpenPGP implementation programs up into to parts -- two library frameworks (one for BSD, and one for GPL v3), and the code that accesses the libraries.

As for the OpenPGP format itself, it does need some incremental improvements:

1: Additional encryption and the ability to chain encryption algorithms. This isn't meant to win a bitsize war, but so that if one algorithm like SERPENT gets broken, there is still AES and Twofish. TrueCrypt implements this.

2: Splitting how much you trust a key versus how much you trust a key's owner to sign, introduce, and validate other people's keys, with both of these values exportable. This way, if you are 100% sure you have a key of a cretin, you can pass that along.

3: Newer compression protocols like LZMA2, bzip2, and others, so that data is further shrunk before encryption.

4: An error correction protocol applied after encryption and signing, with a user selectable amount of ECC applied. This way, a signed OpenPGP file that suffers some damage can likely be repaired, and the signature still be valid.

5: Share splitting. This way, a user can select x out of y pieces be required to recover an OpenPGP packet.

However, all and all, the OpenPGP protocol has stood the test of time when it comes to security. Its main strength is that it is not tied to a communications or messaging protocol, so an OpenPGP packet can be sent on a file on a SD card, via E-mail, AIM, SMS, MMS, posted on a newsgroup or forum, or virtually any other means. There are people who bash OpenPGP, but oftentimes, they have their own solution, and have a vested interest in getting people to leave OpenPGP for a closed system.

OpenPGP fills a crucial need. Not just securing data over communications, but protecting data stashed away. Few encryption protocols can secure both data at rest, and data in motion.