Comment Re:Morale of the Story (Score 1) 217
Accepting the risk that it may never appear in stores or might cost more.
Accepting the risk that it may never appear in stores or might cost more.
And FYI, Kickstarter is not a donation platform as evidenced by the dozens of angry posts about "we want full refund."
Actually it is. The people demanding a full refund either don't know that (because they didn't bother to read) or they DO know that but choose to act as if they don't.
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.
The time limits are based on when the lagoon fills/empties. If they close the gates, they can delay the generation without losing anything.
At the same time, since the production is intermittent but reliable, they can make arrangements with commercial/industrial consumers to match demand with supply.
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.
The problem comes in when they happily accept a few excess deaths every year rather than the tiny risk of many deaths, even when the former adds up to more than the latter.
Actually, they will have some ability to decide when to generate the power. For example, if none is needed at the start of high tide they can close the gates. Then as demand grows they can open them wide. Presuming sufficiently large gates, they could do that and still capture maximum power for that cycle.
Same holds true as the tide goes out.
Since the energy input is free and never ending, they just need to do a cost/benefit analysis. If the storage is more expensive than the potential energy gains, they can just let some of the water flow freely.
I saw a 'gator right at the edge of the VAB parking lot last month. In a drainage ditch, up to the fence, cars parked right on the other side.
With luck, they'll start incorporating our radio transceivers. I hear that SpaceX flies with several USRPs now, so that's not completely unrealistic. That might be as close as I can get. Anyone who can get me a base invitation, though, would be greatly appreciated and I'd be happy to do some entertaining speeches while there. I need a base invite for Vandenberg, too. I got in to the official viewing site for the first try of the last launch (and that scrubbed too), but this next one is on Pad 6.
If it were a social network, it could be more popular than Google+.
The United States _won_ the war in Vietnam.
In what universe? I've been to Vietnam. If you think the US won you have no idea what actually happened there. There is no point at which you can claim the US "won" that war by any reasonable definition of the term. The US rarely lost battles in Vietnam but ultimately accomplished none of their objectives and the moment the US pulled out, South Vietnam fell.
The North Vietnamese were powerless, and the US left.
Really? Then explain why the Vietnam war ended with the fall of Saigon. The US did the largest air evacuation in history. That is not what you do when you have won a war. "North Vietnamese were powerless"? Don't make me laugh.
Is it good to cut off access to the modern equivalent of the public square just because we don't like what is being said?
Let's not pretend that anything this ISIL group does is in any way an attempt at a discussion. These are psychopaths who even other terrorist groups have cut ties with because they think they have gone too far. These are people who would subjugate and kill you in a brutal and public manner without a hint of remorse. This isn't a public square debate. This is a war. Never confuse the one with the other. This isn't two civilized groups agreeing to disagree. ISIS has engaged in genocidal activities. And you seriously think that is a situation where we should just sit back and respect their rights?
Is it a victory to beat them by cutting off their ability to speak?
Very possibly. While I don't pretend to understand everything about them, literally everything I've heard from this group leads me to believe these are people who promote extreme violence and use the islamic faith to justify their psychosis.
How is this different from cutting off Mega's cashflow via PayPal and the credit cards?
How many people has Mega executed?
Computer Science is merely the post-Turing decline in formal systems theory.
