We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
Of course, a fair and impartial trial will also require him to accept a very high likeliness of losing the case, based on the current evidence against him.
Yup. When the law is immoral, only the immoral are innocent of breaking the law.
Is this supported if you don't set a screen lock password/etc?
I'd love to have FDE, but I have no desire to enter a password when driving/etc. The two should be completely independent.
Whether Android does this I have no idea, but the device could be configured to power off if the wrong screen PIN was entered too many times. A FDE password has to withstand offline attack, which means unlimited attempts at a high rate.
It is completely appropriate to use a different level of security for each.
You're dropping out of Obj-C for cross platform compatibility, because you're dealing with a low level Apple API, or because you want maximum speed for some part of the code. All these things are usually best served by C.
Cross-platform compatibility of C++ code is excellent these days, C++ can call low-level Apple APIs exactly as well as C, and there is no performance cost to C++ unless you choose it.
Unless you're concerned that you may need to target a platform not supported by a decent C++ compiler (which is really rare, given that gcc is basically everywhere), the only reason to choose C over C++ is personal preference or concern that some of the users of the code may not know C++.
The issue with FDE in Android has for long been the lack of combining strong passwords with a pattern lock or pin lock for unlocking the screen. In other words, your encryption key is only as strong as the pin code or password you are willing to put in every time you open your screen lock.
No, it doesn't. At least in Lollipop FDE-password is separate and you enter it at boot.
It's not separate. In stock Lollipop there is only one password, and it's used both for FDE and for screen unlock. Some customized ROMs (e.g. CM) have separated it, which allows you to choose a strong boot password and a more convenient unlock password. Stock Android didn't go that direction because too many users would set a strong boot password which they only use once every few weeks and therefore forget, losing all of their data.
Had I jumped to the Nexus 6 at the same time, however, that may not have been an issue.
As a recent Nexus 6 owner, I can confirm that encryption is enabled by default. I have not noticed any performance lag and the battery life has been really good. I will admit, I'm coming from an 'ancient' phone, so maybe that's why I think it's fast enough; way faster than my old phone.
As mentioned by Gaygirlie, a big factor is the AES-NI instruction in the ARMv8 instruction set supported by your Nexus 6. It dramatically reduces the performance and power hit of AES operations.
(I'm a member Android Security team who worked on bits of Lollipop FDE)
The issue with FDE in Android has for long been the lack of combining strong passwords with a pattern lock or pin lock for unlocking the screen. In other words, your encryption key is only as strong as the pin code or password you are willing to put in every time you open your screen lock.
This isn't completely true on Lollipop devices that have hardware-backed credential storage. (Well, it's not really "hardware-backed", but it's in a Trusted Execution Environment, typically ARM TrustZone.)
For Lollipop, a big change to FDE was the inclusion of a hardware-backed key in the key derivation function (KDF) for the FDE master key encryption key. This provides two benefits:
1) It means that a dump of the contents of your encrypted flash is useless without the device.
2) It means that brute force search of your PIN/pattern/password space is serialized and rate-limited by the performance of the device. In a way this means that faster devices are less secure, though we also apply a device-tuned scrypt function as part of the KDF, which compensates in the case of an attacker who tries to perform the entire attack on-device.
The best attack against Lollipop FDE, on a device with HW-backed credentials, is to dump the data from the device flash, then flash a custom OS which makes calls into the HW crypto to create an oracle, processing a stream of requests and returning the responses. Then you do a brute force attack with a mixture of on-device and off-device resources, computing the first scrypt function offline, then performing the on-device crypto operation, then taking the results of that and performing the second scrypt function offline, which you then use to try to decrypt the FDE master key, offline.
The fastest devices on the market today will perform the HW-backed crypto operation in about 50 ms. Assuming everything is pipelined properly, this is the brute force attempt rate: 20 attempts per second. With a four-digit PIN, this is negligible: the entire space can be searched in 8 minutes. However, a six-character alphanumeric password (random, all lowercase) would take 630 days, on average, to break. That's pretty reasonable security.
In theory. In practice it would take much longer than that. I tried running this test on a Nexus 9 and found the device kept throttling itself because it got too hot, plus even with a 2A charger it consumed more power than was being provided to it, so I had to stop when the battery died and wait for it to recharge.
Pre-Lollipop, and even on Lollipop devices that lack HW-backed crypto, you can conduct the entire attack off-line, parallelized, on however much hardware you care to throw at it. I can't make any promises about the future, but I will say that I, personally, really want to significantly improve Android FDE in the future. I have changes in mind that will make brute force essentially impossible, unless you can break into the Trusted Execution Environment.
Bah. Outright falsehood-pushing "journalism" is as old as journalism, and the online version of it as old as online journalism. Wikipedia has been abused as long as it has existed, and the Woozle Effect is also nothing new -- indeed the name and awareness of the phenomenon predates the existence of ARPANET, much less the Internet.
C++ can be clean. The problem is really Macro metaprogramming madness tends to lead to some really strange code and sometimes straight up gibberish. I much prefer Objective C as well, I think its terse, readable and *usually* fairly resistant to a lot of the gunk C++ has accumulated. HOWEVER with that said C++ *can* be well written and clear. Hell even PERL can be. Its just that often it isn't.
More than a head per side? It's been attempted, and turned out it's not really worth it. It's a lot of extra complication for not that much benefit. Heads are expensive and generate heat, so it works out to close 2X the price anyway, plus an increased change of failure. Easier and safer to just add another drive.
These days there are SSDs too.
When was that part of SV culture? Even if you go back to the old-school SV firms, they were pretty negative on telecommuting, and ran regular offices. What era and kind of company do you have in mind? If you go back to the '60s-'90s even, Silicon Valley companies like Intel, Sun, Apple, SGI, Oracle, etc. required regular office time. You could certainly shift your schedule at many of them (e.g. come in at 10am, not 8am, as long as you stay late too), but you couldn't work from home, or get away with less than 40+ hours in the office (often 50+).
From a monetary, stock-price perspective, at the moment the main value in Yahoo is that they own a significant stake in Alibaba, a huge Chinese conglomerate. Their stake in Alibaba at current prices is worth about $34 billion, and Yahoo's current market cap is ~$40 billion. Even assuming a discount on their Alibaba stake due to some overhead that would be involved in unwinding it, it still represents more than half of Yahoo's stock value.
It's depressing that morons are willing to do so much damage for so little gain.
Here is the thing - they're not morons - they're sociopaths. The morons are the rest of us for not making simple legal changes to prevent this nonsense, largely because the beneficiaries of this theft want it to continue.
Well, I don't know what they're planning, but ISTM that if they divide the storage area they can greatly extend the time at which they're generating energy in exchange for nearly halving the peak generation capability...and without much pumping (which adds an additional inefficiency or three).
OTOH, the amount of energy that can be generated by water stored at a particular height depends on the fall distance. So the potential generation capability will vary a lot as the tide changes. Maybe some of the inflow could be used to drive a hydralic ram to lift some of the water higher than max high tide level. But that *does* introduce additional inefficiencies.
All in all, I don't know, but it looks pretty iffy.
You don't need a huge tide, that just makes it more efficient, and cheaper to build, and requiring less land and construction. So perhaps it's only feasible in a few places, but any country with a coast on the Atlantic, the Pacific, or the Indian Oceans should be able to make it work with enough effort and expense. Most of them just wouldnt' find it practical.
Committees have become so important nowadays that subcommittees have to be appointed to do the work.
