No, it's not that it doesn't check certificates generally, it's that if there's an additional, extra certificate of a particular form in the list that forms an app's certificate chain (but isn't actually in the chain) then that extra certificate gets included in the list of signatures associated with an app... making other apps that query the signature list believe that the app is signed by a certificate it's not. This doesn't, for example, fool the Play store into believing an app is from developer A when it's really from developer B. But it can fool other apps. There are some apps that load others as plugins, and make decisions about which plugins to load based on whether they're signed by a particular key. This flaw allows malicious apps to subvert that, convincing the plugin-loading apps to execute them, thereby giving the malicious app the same permissions as the plugin-loading app.

It's a serious security flaw, no doubt. But it's a little more subtle and less obvious than the summary makes it appear. Also, it appears that no app in the Play store, nor any of the other apps that Google has scanned, attempt to exploit the flaw. It's very easy to identify them by scanning the certificates in the package.

I've implemented tests for certificate chain validation code several times (not in Android), and it never once occurred to me to test for this particular odd construction, nor, I think, would anyone else think to test for it without some specific reason. This sort of bug requires inspection of the code.

(Disclaimer: I'm a member of the Android security team, but I'm not speaking in an official capacity, just summarizing what I've read of the vulnerability -- which isn't a great deal. Others on my team are well-informed, but I haven't followed this issue closely.)

If the attacker has sufficient access to install system-level software, you're already completely screwed. Game over. Go home.

There is a "No True Scotsman" joke in here somewhere, but I just can't seem to find it.

It doesn't have to be linear to be useful. It simply has to be able to sort a set of choices into order -- like movie reviews. Nobody thinks a four star movie is "twice as good" as a two star movie, but people generally find the rank ordering of movies by stars useful provided they don't read to much into the rating. In fact the ordering needn't be unique; there can be other equally useful metrics which order the choices in a slightly different way. *Over certain domains of values* minor differences in orderings may not matter very much, especially as your understanding of your future requirements is always somewhat fuzzy (e.g. the future cost of bandwidth or computing power).

The problem with any metric occurs outside those domains; some parameters may have discontinuities in their marginal utility. A parameter's value may be good enough and further improvements yield no benefit; or the parmater's value may be poor enough to disqualify a choice altogether. In such cases such a metric based on continuous functions will objectively misorder choices.

For example Suppose A is fast enough but has poor compression ratios; B is not quite fast enough but has excellent compression ratios. There's really only one viable choice: A; but the metric may order the choices B,A.

On the other hand suppose A has better compression ratios than B; B is faster than A, but A is already so fast that it makes no practical difference. The rational ordering of choices is A,B but the metric might order them B,A.

This kind of thing is always a problem with boiling choices down to a single composite number. You have to understand what goes into that number and how those things relate to your needs. You have to avoid making your decisions on one number alone. But some people *will* fasten on a single number because it makes the job of choosing seem easier than it does. Just don't be one of those people.

Well, if you put yourself in his shoes you might well play hardball with other games in the hobby.

D&D as a system wasn't really all special; there were competing systems back in the days he was at TSR which were every bit as enjoyable and arguably easier to play. But D&D had two big things going for it. First, when the three basic manuals for AD&D were published it had by far the best organized and written materials. The Monster Manual was particularly useful. Second it had the network effect: it was the best system to learn to play because everyone else knew how to play it. You could start a campaign at a drop of a hat -- no need to bring everyone up to speed on yet another set of rules.

So put yourself in his position. The future success of D&D is contingent on no other game reaching critical mass. You're completely dependent on D&D, you have no other marketable skills or assets. You have a company with over a hundred employees (which is surely a mistake on your part), and that company has nothing else bringing in cash *but* D&D products. You've made D&D your life work. It's not a situation to bring out the best in people.

Not a universal compressor, a standard compressor, such as gzip. The metric is ultimately just a comparison between the compressor being evaluated and the compressor chosen as the standard, and it is unitless.

That said, I agree with you that the scaling constant has no reason to be present. As for using the logs of times... I don't know. It's essentially a base change, expressing the time of the compressor being evaluated in the base of the standard compressor, which is then multiplied by the ratio of the compression ratios. Handling the time relationship as a base change may have some useful properties, but I can't see what they would be.

The internal "SD Card" is formatted with a Unix-style file system that provides access controls to keep apps from being able to access one anothers' data. External SD Cards are formatted with FAT32, because that's what the whole world expects. Unfortunately, FAT has no concept of ownership or permissions, so the path-based restriction is necessary to ensure that apps can't muck with each others' data.

It's too late now, but if this device had been encrypted before it was broken, you'd have a lot less to worry about.

OTOH, it's worth pointing out that if the level of effort required to find the storage on the broken device so you can wipe or destroy it is too much to bother with, it will almost certainly be too much effort for anyone to go through the same effort in order to retrieve your data, on the off chance there might be something of value in there somewhere.

"Most" - You Keep Using That Word, I Do Not Think It Means What You Think It Means.

"Try to remember that most people don't use their cars to commute 15 minutes to work and back home every day." That's right, most people commute about 25 minutes or less. Still not a problem for an electric car.

"Try to remember that most people don't live within 5 miles of everything they need to get to. " Most people live in cities, and have the things they need within 5 miles.

"Try to remember that most people don't want to live in a huge city packed in like cattle." I don't know if they "want" to live in cities (neither do you), but most people do live in cities. In the USA 80% of people live in urban areas.

Different requirements drive different designs. Before WW2 seaplanes were common because of the lack of runways. After WW2 airports proliferated, and seaplanes couldn't keep up with technical advances due to the compromises involved in allowing them to land and take off from water. But that doesn't mean there aren't applications for aircraft with a flying boat's capabilities, it just means there isn't enough of a market in places like the US to support an industry. Even so, here in North America there are some 70 year-old WW2 Catalinas being used in aerial firefighting. China is a vast country which is prone to many kinds of natural disasters that could make airlifting in supplies difficult, so they may see potential applications we don't.

It's also interesting to note that seaplanes were highly useful in the pacific theater of WW2, and there hasn't been a protracted struggle for sea control *since* WW2. Also, China is a country with no operational aircraft carriers; aside from its training ship the Liaoning, it has a handful of amphibious assault ships that can carry a few helicopters. The US by contrast has ten supercarriers and nine amphibious assault ships that dwarf the aircraft carriers of WW2. The technology and expertise to run a carrier fleet like America's would take many years for China to develop. It's conceivable that the manufacturers imagine a military market for aircraft like this in the interim.

...or if he's using shell style wildcards, he could mean "pure and utter sherbet."

Reports of trains *not* running on time certainly decreased, but that's not quite the same thing...

That's a common misperception of what Gladwell write. His actual formulation was 10,000 hours + talent + opportunity.

Should be no surprise to anyone who's every played a videogame: he's in "flow" mode.

Which raises the question: how is this news for nerds?

Don't be ridiculous. The dinosaurs lived long before the GNU utils were written. They would have been compressed.