Apple devices have an additional "trick" beyond just PBKDF2 - There's a random AES key burned into the CPU, and it's wired such that it can be set/erased, but not directly read - it can only be fed as the key into an AES engine.

I am not sure if Apple's PBKDF2 has this AES engine as part of the loop, or if it just feeds the key that comes out of PBKDF2 through the AES engine, but the end result is, on any given device, the AES key that results from a given passphrase is unique to that device and cannot be reproduced off-device.

So if someone just clones the device's flash contents, they have to resort to brute-forcing AES directly, as opposed to trying to brute-force passcodes.

So you can only brute-force passcodes on-device (something like 80ms per try on this model, newer models have a 5 seconds per try limitation), and Apple's software doesn't even allow you to do that. The FBI wants to at LEAST get on-device brute-force capability.

Which might still take years if the user had a reasonably strong passphrase.

Most modern SoCs have the ability to verify u-boot prior to execution. Either the public key, or a hash of it (The little documentation I could find on TI's architecture was that to avoid storing 2048 bits in efuses, they stored a 128-bit hash of the 2048-bit key in efuses. The chip would verify the key (while in flash, could not be changed due to fixed hash), then use that key to verify uboot. TI had extensions to uboot to support hardware accelerated verification of the next stage in the boot chain.

Note: My bit counts might be off. Might be 1024/256, 4096/256, or ???

In nearly every SoC currently available now, the chain is:
IROM (or similar) bootloader baked into the SoC. This verifies the signature of uboot, and jumps to it for execution
Uboot then takes over, verifies the next step in the chain (if configured to do so), then jumps to it if it verifies.

Note: The IROM signature checks prevent you from replacing uboot with something that does not enforce signature verification.

I know the guy. Justin Case is NOT his real name. (I don't know what it is, I remember seeing him acknowledged by his real name once but I forget what it is, but I do know that it's not his real name - but many people think it is.)

Apache does not require release of source AND does not have the advertising clause of the "older" BSD licenses, so I'm not sure what about this project might be violating the Apache license. Overall Apache is pretty permissive and it's hard to violate except by providing source code but claiming said source code as your own (e.g. removing copyright notices and replacing them) - strangely, releasing a binary-only Apache component with no advertising (e.g. every Android device on the market except for Nexus devices) is more legal than releasing source for the component that removes all original author credit. I do recall the Android-x86 guys were pretty unhappy about RemixOS being effectively a for-profit kang, but the nature of Apache was such that there wasn't much they actually could do about it.

GPL is a whole other story. If they are failing to provide sources in compliance with the GPL then they can burn. (Technically they have to provide sources themselves, but I will let someone slide who says "We used unmodified upstream sources which can be found at X" when there is no evidence to the contrary.)

Yeah, as much as I like Android, it is not suitable for desktop systems except for a few special niches.

I can see it making sense for someone to do an HTPC build that was Android-based in order to run Android games. But to be honest a SHIELD Android TV would be an easier/better/likely cheaper solution for Android games, especially since many of them only have ARM native components and have a severe performance hit on x86.

It makes no sense as a desktop/educational OS right now - which is why the Pixel C has been slammed by so many for having an OS inappropriate to the type of product.

They advertise that. It costs $95/month and you get what you pay for.

(According to others, you CAN enable "binge on" with that plan, and you get "extra" stuff for doing so. Kind of like how Amazon gives Prime users movie rental credits if they choose "slowboat" shipping instead of the free 2-day)

It's pretty clearly specified that if you enable Binge On with your account, your data gets throttled.

The only hole seems to be that there are certain cases where having Binge On enabled results in a throttle but not "free" data from the sounds of it.

I have zero problems with this since you, as a user, CAN TURN IT OFF. (TFA indicates that the issue is users who have Binge On enabled causes throttling in cases of providers not part of Binge On.)

"Writing VLC in JavaScript and other Web technologies, as Chrome OS requires, is not an easy task by any stretch."

No... ChromeOS has ways to write native and semi-native apps:

NaCL - https://developer.chrome.com/n... and PNaCL

That said, if you already have a functional Android app, ARC is probably easier. Works great for Quasseldroid if you remove one socket configuration call (TCP_KEEPALIVE socket option) currently not supported by ARC.

That's probably part of it. The Netflix Connect box eliminates much of an ISP's backhaul costs.

In T-Mobile's case, their backhaul costs are probably not nearly as much as their spectrum/tower costs. (Although I know in the early LTE transition days, tower backhaul WAS an issue, but I think Netflix's solution was more of a provider core network thing...) So perhaps I should treat "backhaul from Internet to core network" as different from "backhaul from core network to tower". This system helps them manage the backhaul from the core network to towers and then on to the phone, as that's where most of their costs lie.

The things that have triggered many of the big NN debates have been providers throttling their connectivity to the rest of the world - "core-to-Internet" backhaul. Many of these providers have more than enough core-to-customer bandwidth.

That doesn't seem to be the case for Binge On, since T-Mo states their criterial in a public document:

http://www.t-mobile.com/conten...

In some ways, the way I read it is that T-Mo will effectively spend money (in terms of engineering resources/staffing) in working with a content provider to come up with a proper solution.

It sounds a lot like how some people have described our wired Internet infrastructure in large hubs works - frequently engineers from multiple providers would work together to come up with the optimal solution, sometimes with one provider loaning equipment to the provider connecting to them. At least - that's the way it worked until Verizon or Comcast started pulling their shenanigans. (There was a really good writeup 1-2 years ago shaming one of the providers that was trying to extort Netflix by intentionally not upgrading any link to one of Netflix's backbone providers, which would also punish anyone ELSE on the same provider. Verizon said it was too expensive, the backbone provider replied along the lines of, "bullshit, it requires $20k of equipment we're happy to provide ourselves that we have sitting on a shelf 10 feet away from where it needs to be, we just need permission to install it."

The "kickbacks" could be in the forms of "technical support".

While the theory posted in the article (that automatic rate adjustment) indicates that this should be OK with any content provider, the truth is, rate detection of some providers (think cbs.com in 2014 for example, and SlingTV at all times) is REALLY horrible.

Let's face it - you're going to get much better rate detection (for example, not even bothering to try a 720p stream) if you can explicitly tell the content server - this connection will NEVER go above X mbps.

One use case they could be specifically trying to avoid is: Server automatically attempts 720p. User gets stuttery/buffering video for a few seconds before the ratelimiter detects the actual bandwidth of the connection and drops down. Some ratelimiters (just like TCP's congestion control) may be very aggressive and might drop to 360p before going to 480p after some period of reliable 360p video. If the carrier (I'm guessing they're implementing a proxy in this case based on how they're describing it...) explicitly states they have a ratelimit of X mbps, the streaming server can automatically choose a quality setting just under this limit, rather than spending 10-20 seconds or more trying to determine what it is.

Yup. I've always been surprised at how a proprietary and closed standard (Z-Wave) provided superior interoperability to an open one (ZigBee Lighting Link).

ZLL interoperability is rare. I purchased the Hue specifically because it had the capability to add "other" ZLL lights such as Cree's bulbs. I also 100% ditched Greenwave's crap because it had zero interoperability with anything and they broke the ability for any other HA system to command their gateway.

I tried a few "Connected by TCP" lights (actually made by Greenwave IIRC) and had them working well with my Vera.

A firmware update for the controller rendered them unusable with anything but Greenwave's own app.

So I bought a few Cree smartbulbs to replace them and use with my Hue system - they have been working great for over a year.

Now Philips is going to block these perfectly-functioning lights? FU Philips. The only reason I use your products is that they integrated well into my home system. If you force me to use your products separately from the rest of my home control systems - you'll force me to ditch your products.

Huh, that IS a regular lancet device...

Well, at least as someone who has been a Type I diabetic for over 20 years, that's what I consider "regular"...