I have to disagree with that. YouTube is a much friendlier and saner place since the integration. The integration did increase the noise on Google+, but all in all I think it's better.

What's to "come clean" about? Their privacy policy says they aggregate information about you from all your uses of their services. There you go. That's it. What else do you want to know? What they'll use it for? For providing you services, and for selling ads which they display to you.

Seems pretty obvious and straightforward to me.

(Disclosure: It's not really relevant to the content of my comment, but I'm a Google employee. I'm not, however, a Google spokesperson. The above is my own words and opinions only.)

You can also plead no contest, which has the same result as pleading guilty, but without admitting guilt.

As for the point about Microsoft not being a defendant, you're right that third parties don't have the same options... but they also don't have the same justification for refusal, since compliance will not implicate them in anything, unless, of course, it would implicate them in something else, in which case they can negotiate a deal for qualified immunity.

You have the former option as well, if you prefer. You can simply stipulate in court to the prosecution's allegations regarding the evidence. Where this is tantamount to pleading guilty, you can do that, too.

True, but irrelevant in cases like this. The US government does have jurisdiction over Microsoft's US operations, and Microsoft's US operations have the ability to retrieve the information from Microsoft's servers in Ireland. The mere fact that the data is in Ireland is no reason that the US company can't be ordered to retrieve the data they control and have access to.

Similarly, if you were being investigated for a crime you could be required by the courts to turn over the records of you Swiss bank account. The court couldn't issue orders to the Swiss bank (though they could make a request, which the bank might choose to honor, or they could ask the Swiss authorities to issue an order to the bank, which the bank would have to honor if the Swiss government chose to cooperate), but it absolutely could issue orders to you, a US person in the US, and your failure to comply would result in you being held in contempt of court, and jailed or otherwise punished until you do comply.

Actually, Curiosity's scheduled mission on Mars was for 668 mars days. It's been there for 724 mars days now.

Just because it hasn't (yet) vastly outlived it's scheduled mission, doesn't mean it's a failure.

Cool. I hadn't noticed that feature.

So there really is no advantage to browsing in physical stores.

Nonsense.

Look at Baen's model... the first few chapters of all of their books are available for free, all on-line, all trivially easy for you to browse and sample, at no risk, wherever and whenever it's convenient to you. For that matter, they offer full novels from their top authors for free. So you can read the first book of a 15-novel series at no cost, hooking you for the other 14.

How can book stores, with their limited shelf space and immobility, compete with that?

Of course, that's Baen, not Amazon. Because Baen is a publisher, they have the freedom to do things like offer the first ~50 pages free, while Amazon has to obey the publishers' rules. But in a world where browsing bookshelves is gone, Baen's approach, or something like it, will be necessary to generate sales, so it will be done.

Just because you're accustomed to one way of finding good reading material doesn't mean it's the only one, or even the best one.

I cancelled my Comcast cable service last week. Walked into the office, handed them my equipment and told them I wanted to cancel my account. The person behind the counter checked in the equipment, had me sign a form indicating I had returned all the equipment and pay the prorated amount I owed.

I was in and out in just over a minute. I waited in line significantly longer than that.

You're not an outlier, but you did do exactly the right thing. You cancelled in person, instead of over the phone.

The people you call on the phone are highly incentivized to keep you as a customer. The ones working behind the counter are not.

If you want to quit ANY cable service, then disconnect all the equipment, load it in your car, take it down to their local office, and tell them that you wish to drop their service immediately. No one will argue with you; at that point you have bypassed their normal customer retention script.

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.

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.

Meta godwin aside, I wish a major (market wise) fork would exist with grsecurity merged in by default, for example...