You missed one major technical rule: all browsers on iOS that support local rendering are required to use the system rendering engine.

Actually, no, I'm pretty sure they're just not allowed to use any JavaScript engine other than the built-in JavaScriptCore. And as of iOS 7, it's theoretically possible to actually do so without using WebKit.

It's not willful ignorance. It's actually a legitimate question. From everything I've read, there are roughly two types of revenge porn:

• Fake revenge porn, in which someone pretends that he or she is getting revenge on a former significant other so that people will be more turned on, but in reality, it's just commercial porn, and legal.
• Fake revenge porn, in which someone surreptitiously cracks into the victim's computer and records that person in his or her own home, which is already illegal. And this is what the lawsuits have mainly been about.

I suspect that the real revenge porn, if it even exists, is just about lost in the noise caused by the two forms listed above.

... the homeowner does NOT automatically gain the right to record the guest WITHOUT permission.

If that were true, then "NannyCam" footage would be inadmissable. Different states have different laws that carve out specific places where recording is not allowed—most forbid recording in bathrooms, for example—but as a rule, if you're in someone else's home, you should generally assume that you have little or no right to privacy.

I was referring to normal traffic lights that lack any indication of when the light is about to change, not the rare lights with countdown timers or the hypothetical lights with a dashboard assist. The split-second decision to floor it or slam on the brakes is a bigger problem when you're accelerating from a stop as the light changes to yellow, not when you're going way over the speed limit, for two reasons: A. there may not be any choice that doesn't result in either getting rear-ended or being in the middle of the light when it turns green in the other direction, and B. your foot is on the wrong pedal to stop, adding critical latency to that decision, should you choose to stop.

Actually, it's the opposite. The worst speed to be entering a traffic light is near zero. You've slowed down to a low speed because of someone slowing to turn right ahead of you. The traffic behind you collapses to be nearly bumper to bumper at 15 MPH in a 40 zone. The light is timed for 40 MPH. You don't realize that the light is about to turn yellow, so rather than just coming to a stop, you decide to enter the intersection. Then the light turns yellow and you're moving at a speed that will put you and the two cars behind you in the middle of the intersection when it turns green in the other direction. Whether you floor it to get through the light legally or slam on the brakes and get rear-ended, the car behind you is screwed.

I will gladly contribute money to the election campaign of any otherwise-electable congressional candidate who makes this one of his or her campaign promises.

Well, it is kind of an April Fools story. It says he came out against Prop 8 (a gay marriage ban), which would mean that he was in favor of gay marriage. Unless all the previous stories I've read were wrong, I'm pretty sure they got that backwards.

There's nothing wrong with JavaScript, language-wise. I mean, sure, I'd prefer for closures to be explicit rather than implicit, in part because it tends to confuse the newbies a bit, but otherwise, it's a reasonable language. The problems mostly stem from:

• All the built-in functions—the JavaScript DOM, XHR, etc.—which are designed in strange ways that assume everyone understands closures
• The single-threaded design (not inherent in the language, but mandated by the DOM spec, IIRC)
• Overuse of completion handlers even for things that really don't need them, mainly to workaround the lack of threading

None of those things would improve with a different language except possibly the first one.

What do you call someone who goes around saying things that they know are untrue?

A politician.

It wasn't a bad episode, though in retrospect, it kind of felt like a ripoff of Enemy Mine in a lot of ways (the book, that is).

... all of them? Seriously the inclusion of a trained Shakespearian actor (Stewart) was the only saving grace of that branch-off of TOS.

come on... it's not like the series didn't have any redeeming qualities at all... is it?

I can think of one really good episode. It involved the captain getting his brain rewired and living an entire lifetime on another planed in a dream induced by an alien probe. Why was it good? Because it focused on one character (played by Patrick Stewart) and really developed him.

The one with Picard leading the kids up the lift shaft was also good.

And I enjoyed the whole "Sometimes a cake is just a cake" episode. I mean, it was absurd, but it was amusing.

Worst episode? Anything with Wesley Crusher. They were almost all painfully written. How many times can a single kid put everybody in mortal danger and then somehow manage to save the day in some contrived fashion?

Why would they need to compromise your CAs? They can compromise any CA, because unless the client uses a tighter-than-normal designated requirement, it will trust any cert for your domain as long as it is signed by any of dozens of CAs. That's what makes TLS so flawed.

The boss doesn't ask employees to leave. The employee just gets to work one day and find their desk on the front lawn.

You mean we get to keep the desk? If I had known that, I'd have gotten myself fired a long time ago!

Self checkout is just making the customer do the cashiers job for free before realizing that customers suck at doing these things correctly because it's not their job.

So what's the cashiers' excuse for not doing it correctly? :-D

No, seriously. I tend to order things with various customizations (e.g. no [insert ingredient]). I haven't done the math, but I suspect that I have at least a 10% return rate at many businesses. How hard is it to push "Only" followed by the ingredients that the customer specifies? Point-of-sales systems suck, but at least if I'm in control of it, I can see that the order is right, and if it is wrong, it's my fault.

You're on the right track, but that implementation is way more complicated than it needs to be. Any PIN should be handled by the device itself, and should be easy to change to any arbitrary PIN. Or you might even use a fingerprint reader.

You should be able to basically eliminate any additional risk from a modified device or payment terminal (except perhaps the risk of someone physically stealing the device and using it) by doing the crypto as follows:

• The business generates the transaction receipt and signs it with its public key.
• The user pushes the button on the card to initiate the payment handshake. This causes the device to broadcast a Bluetooth Low Energy beacon.
• The payment terminal (computer, POS terminal, cell phone) detects the beacon and sends the transaction receipt to the card.
• The device shows the business info, dollar amount, etc. on its screen.
• The user presses a button to authorize the transaction.
• The device signs the transaction using its private key and sends its response back to the payment terminal.
• The payment terminal sends the doubly signed receipt back to a payment processor.
• The payment processor verifies the signatures using public keys stored in the business's account and the user's account and verifies whether funds are available.
• The payment processor sends back a signed response containing the transaction receipt and a status field that indicates whether the transaction was authorized or not.
• The payment terminal provides the signed response to the device so that the user can verify that the payment was accepted or rejected. (This prevents double charging fraud.)
• If the signatures are valid and funds are available, the payment processor automatically transfers the funds to the business.

In an ideal world, the transaction would then be applied to the default credit card in your online account profile, but you should have the ability (up to a few days after the transaction) to redirect the transaction to a different card by logging in to your online payments account and saying "Bill it to X". Alternatively, you could have multiple PK pairs, one for each account, and you could choose the account on the device itself.

The way you handle offline sales with this model is also pretty straightforward. You use either a mobile app on your phone or a website on your computer (requires browser support), as follows:

• Enter the name of the business.
• The payment app provides a list of matching businesses. Choose the right one.
• Enter the amount of the payment.
• The payment app generates a transaction.
• You push a button on the device, and the payment app does the BTLE handshake.
• You push another button to authorize the transaction, and the payment app sends it to the payment processor.
• The payment app issues a funds hold against your account and gives you a unique transaction ID for that hold. You give that transaction ID to the store.
• The store, upon accepting the order, uses that transaction ID to convert the hold into an actual charge.

The existence of that transaction ID in the merchant's account is proof that the payment occurred. At most, the only thing the merchant would have to do to prevent fraud would be to ensure that nobody uses the same transaction ID to pay for more than one purchase. This is, of course, a trivial local database lookup.

You would also need an app (mobile or desktop) that can download the public key from the device (if the device gets stolen, you'll need to associate the new device's public key with your payment account) and occasionally update its firmware to fix any bugs in the crypto code.