In this case, I personally believe that she was discriminated against by the jury, because she was a Native American. She was tried many many miles from where she lived and worked, and did not have a jury of her peers.

1. She wasn't "convicted" of anything; this wasn't a criminal case. She was found liable for copyright infringement by making copies through downloading, thus violating the record companies' exclusive reproduction rights.
2. She was also sued for "distributing" and "making available for distributing", but the judge threw out the "making available for distributing" claim, and there was no evidence offered of the "distributing" claim.

So yes, the only thing she was found liable for was downloading.

1. Capitol is but one of the plaintiffs.
2. The RIAA was in fact running the case, with the aid of the record company plaintiffs.
3. Capitol is a record company, not a music publisher.
4. The case was about the recordings of several different companies.

Chrome uses a passphrase to encrypt sync data. By default it will use your Google account password, but you can change it to use any passphrase. If the Chrome devs are doing it right, they should be running the passphrase through PBKDF2 to derive an AES symmetric key. It's worth noting, though, that the Dashboard for "Chrome sync" shows counts for the number of synced items of each type. Assuming they're doing the crypto correctly, I see only two ways the Dashboard could know those numbers: (a) if Chome sends the counts in plaintext as part of the sync, or (b) if the items are individually encrypted (which is generally a bad idea due to known plaintext).

I do know from personal experience that you're SOL if you lose the Chrome sync passphrase (or if you simply want to change it). You have to click the "Stop sync and delete data from Google" link in the Dashboard, wait 5 or 10 minutes for the delete to finish, then set up sync again for all your Chrome instances. Oh, and Chrome sync still doesn't support OAuth login, so setting up sync is a pain if you have 2-factor auth set up on your account (as you should).

Disclaimer: I happen to work at Google, but I don't interact with Chrome except as a user. I'm using knowledge gleaned only from using Chrome sync with my personal account.

No, that's actually not bad. Online cost of living calculators don't grok SF. When I moved to SF 5 years ago for a tech job I started out on $75k/year, and I did fine for myself living solo. Sure, you're probably going to drop an extra $15k-$20k/year on rent -- I moved into a ~650ft 1BR apartment for $2100/month, a bit of a premium for a good neighborhood -- but Craigslist is booming with roommate offers, and most other living expenses are about the same as other cities. Utilities are less (milder weather), eating out is more (higher wages, trendier places), groceries are the same. Entertainment is less (lots of free/cheap shows) but there's more of it, so you may wind up spending more.

Beyond rent, the only other thing that's noticeably more expensive than elsewhere is car ownership; parking garage fees of $300/month aren't uncommon if you work downtown and expect to park there every day, and there's the perennial delight of California gas prices if you're moving from out of state. But even before costing out the parking surprise, a $65/month Muni "M" pass is hella cheaper than gas + insurance + maintenance for owning your own car anyway. Throw in a ~$4/month ZipCar annual membership (partially or fully subsidized by some employers) and you can still have access to a car when transit won't cut it; the rental itself runs about $12/hour, which includes the cost of gas, insurance, and all the maintenance headaches. Even without an employer subsidy, that annual ZipCar fee is 1/3 the price of a WoW subscription, i.e. totally worth it at $75k/year.

Not quite. You've never had the experience of remembering having done something, then having someone contradict you, then asking around and finding out that your memory is faulty? If you were certain of your memory, no finite amount of evidence would ever convince you that you were mistaken. Your example instead demonstrates that we pick the most probable (most "familiar") explanation without conscious consideration of alternatives, and we only backtrack to alternatives when the first explanation is sufficiently falsified to demote it from the best explanation.

That's not to say that this has any bearing on Judea Pearl's research into causal networks. Causal networks complement a probabilistic approach, as each causal node operates on purely Bayesian principles; the only difference is the added operation of graph surgery to represent counterfactuals. It's certainly true that the naïve extension of Bayesian probability to a decision theory (Evidential Decision Theory) is silly -- it results in "Speeding on the way to work is correlated with being late to work, therefore if I don't speed I can't be late!", and it's also true that causal graphs naïvely extend to a decision theory (Causal Decision Theory) that fixes the most egregious silliness. But Bayesian probability is still a key piece of CDT, and even CDT doesn't fix everything (look up Newcomb's paradox).

In the real world, as opposed to whatever fantasy or corner-case scenario you have in mind, a task of significance will involve dealing with people outside a specialist's specialism. I want my brain surgeon to listen to the anaesthetist because the drugs s/he is using may affect the bloodflow in the brain, for example. I also want my brain surgeon to listen to me because there might something in my family history which makes my brain unusual and isn't picked up on an MRI scan.

Primadonnas are a pain the rear when people want to do something of significance.

Uh, no. MaCHOs were supposed to be Jupiter-size to brown dwarf-size lumps of mass, careening through galaxies without being associated with stars or other luminous matter. A black hole *can* count as a MaCHO *if* it has no accretion disk, but we think most black holes have accretion disks and therefore emit X-rays (and thus don't count as dark matter). This black hole is firmly in the not-a-MaCHO category; for that matter, what we today know about Big Bang baryogenesis pretty strongly rules out MaCHOs being the dominant type of dark matter, so they've mostly fallen by the wayside in modern cosmological thinking.

Believe me, that's a risk I worry about every day. But I recently discovered that there are other frequencies that can cause such damage! I now refuse to allow my family within a mile of any restaurant with so-called "heat lamps" (or as I prefer, "death lamps"), and I'm seriously considering banning from my household anything that emits between 400 and 790 THz. I heard one of my neighbors actually bought an Easy-Bake Oven for their kids. An Easy-Bake Oven! Won't somebody please think of the children?

(Seriously, though, if you pour significantly more than a kilowatt per meter square of EM into living tissue, you're gonna have a bad time. There are a handful of cases, e.g. VHF, where you might be able to bump that figure by an order of magnitude (maaaybe two) because humans are reasonably transparent at those frequencies. But as a rule of thumb, all non-ionizing EM from visible light down cooks you the same way.)

Uhh, that sounds like an extremely convoluted reinvention of TCP SACK (RFC 2018) using some knockoff of Reed-Solomon instead of, y'know, "I got packets 1-4 and 6-10, please retransmit #5".

/facepalm
https://www.google.com/search?q=sputnik

The scheme you describe is a Message Authentication Code, not a salted hash. If you use a salted hash when you actually need a MAC, you're potentially compromising your system's security.

You don't bring nukes to a knife fight. Sure, you win the knife fight, but now everyone else knows to nuke you first and ask questions later.