It's because chess is well-known around the world. Xiang Qi, not so much. Chess has a long and storied history in western society, so for China to produce a world-champion chess player would be like them saying to us, "We're beating you at your own game!" Ultimately, it's all about appearances.

These points were exactly what I was thinking as I reading the summary. I would mod you up if I had mod points.

Although as a partial counterpoint, if it is noticeably cheaper, it might indirectly allow the balance point between cost, speed, and yield of mass produced parts to be a bit faster...

I replaced the batteries in my 15c for the first time a couple of years ago. And just to be clear, it has three small non-rechargable button batteries, like you would find in a watch.

That comment in the summary probably could have been worded better, but I think it was intended to say that it does a better job of preserving image quality per amount of space used when compared to other image compression algorithms, such as .jpg (which is the defacto standard right now).

That would just reintroduce the problem that creating discrete time zones was intended to solve over a century ago. That being that when each locality has it's own clock, it becomes virtually impossible to coordinate scheduling between them (back then it was railroad schedules that were affected). Only now, in the 21st century and the amount of long distance and even international coordination that takes place via the internet, scheduling anything over a distance would become a nightmare in the system you propose.

I'm mildly curious what stories (and/or original headlines) go with some of these generated headlines, but I notice that neither TFA nor the TFS seems to have preserved that information.

In my case, $DAYJOB now uses gmail-hosted "G Suite" email, and has configured it to require either the web interface, or OAUTH2-based POP/IMAP/SMTP authentication. No app passwords or other options are available.

As mentioned by others, it generally seems really low security to trust your data to a server not directly under your control, regardless of whatever access controls it supposedly enforces.

It is debatable if all the extra hoops needed for OAUTH2 actually improve or degrade security, especially if you use a strong password (long randomly generated), protect it carefully (e.g. password manager), and also treat recovery questions the same way as the password (long randomly generated, stored securely).

To actually have usable, email, I wrote up some instructions, patches, and scripts to allow me to use any local email client while relaying through google with OAUTH2. In my case, I prefer mutt, but with this infrastructure, I could use any email client I wanted. Perhaps other people might find my instructions useful.

I, myself, hold a music degree and am working my way up an IT career. While I am not currently qualified to be the Chief Security Officer of a major company, it is a distinct possibility that in the future I will be. I don't like how the article and at least some of the comments are blasting her just because of her educational background.

Maybe she did something wrong in her position at Equifax. Maybe not. It's entirely possible that she was doing her job in the best way possible but was stonewalled by the business people out of properly implementing security. Either is possible. It's possible we'll find out as investigations are performed, but it's also possible that we'll never know. Her music degree has nothing to do with it.

For what it's worth, many of the musicians I know are very intelligent people who have been successful in IT or other technical fields.

(Honestly, I don't think I would want to be a Chief Security Officer. Even if you do your job perfectly, a breach is possible, and when it does happen you're the one to take the fall)

I live in Colorado, and have a 2-year-old daughter. She occasionally gets to play games on my wife's iPad, but we have to moderate how much because if she spends too much time on it she gets cranky. She won't have her own smartphone until she is at least 13 (probably older).

I can certainly see where this group is coming from, but I strongly disagree that it should be made a law. Every kid is different, and every family is different. Parents need to make decisions based on what's best for their kids and their family. Even if I happen to agree with them about keeping kids away from smartphones until they are old enough to mentally handle them, I disagree that it is something that should be forced. I do not support taking away parents' choice on the matter.

If I see one of those petitioners collecting signatures to put this on the ballot, I will refuse to sign. If it makes it to the ballot, I will be voting against it.

He did encrypt his laptop. The agents that arrested him watched him from a distance until he logged in. Then they moved in, making sure they didn't give him a chance to lock it.

Old but excellent article about the choice between organic growth vs get big fast, and how to implement the decision: https://www.joelonsoftware.com/2000/05/12/strategy-letter-i-ben-and-jerrys-vs-amazon/

The article's links seem to have better real experimental data backing them up, but I still think I prefer reading http://www.joelonsoftware.com/'s 15 year old article "Human Task Switches Considered Harmful". The second half of "Where do These People Get Their (Unoriginal) Ideas?" is also relevant.

In the last few years he has posted much less often, and when he posts, it is usually only announcing the latest product his company has made, but most of his older "reading list" articles (from the front page) are still excellent.

Properly implemented, SRP does not store the the secret on the server end. It only stores v=pow(g,x) mod N, where "x" is a secret needed on the client end (derived from the password), and can't be extracted from v without either using a brute-force algorithm (try all weak passwords), or solving the discrete logarithm problem. You may want to read https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol more carefully.

I hadn't looked at SCRAM before, but from at a quick glance it looks like the only thing preventing an attacker from brute forcing weak passwords from nothing but a passively captured login session is an expensive-to-compute hash function (PBKDF2). It isn't as bad if SCRAM is wrapped in an SSL/TLS session with associated certificate, but if you really trust nothing has MITMed (i.e. incorrectly trusted certificate) or otherwise broken TLS (from the perspective of the client authenticating the server), then why not just send the password directly through the tunnel (from client to server), and avoid extra complexity?

Note that capturing a login session is generally a much lower bar than obtaining the password database, and SRP does not allow brute forcing even trivially weak passwords from just a captured login exchange. (As long as there aren't any huge breakthroughs in quantum computing or other discrete logarithm algorithms.)

All that said, you are correct that SRP or other low level single-connection authentication mechanisms do nothing for the cross-party authentication issue discussed in the article.

They actually are. As of this writing, the non-retina Macbook Pro is still available for sale on Apple's site. Go to apple.com, click Mac -> Macbook Pro -> Buy and then scroll about halfway down the page. That model, which is being sold for $1099, hasn't been updated since June 2012, though it did have a $100 price cut in July 2014.

The vast majority of owners have signed it, yes.