A blockchain ledger relies on their being lots of nodes to maintain the ledger along with a mechanism to produce consensus. I think their idea is to produce something that could be used across all sorts of other "sharing economy" services and not just AirBnB. That is kind of the only way the idea would work using blockchains as AirBnB shouldn't control all of the nodes. I don't think the point is to avoid bad reviews, but to establish some level of trust in the source of the reviews. I'm largely speculating because the article doesn't have much detail.

It seems a lot easier to be consistent with your ideals when they are the same as your relatively small batch of constituents.

On citation for original design intent, thought I read that in a news article back when they announced iOS8, but can't locate it now, so maybe I'm wrong. Your description of the encryption mechanisms is a bit off regarding Secure Enclave.

Apple’s implementation of security with A7+ processors and the Secure Enclave also uses ARM TrustZone architecture with rather complicated composition of encryption keys. But there is a hardware key specific to the Secure Enclave chip and cannot be accessed or queried outside of it (I’m ignoring expensive physical xray or FIB methods etc) and is unique to each device. A piece of this is generated whenever iOS is reset or reinstalled. The Secure Enclave is a separate chip built into the SoC running its own microkernel. This is different the standard TrustZone architecture. It does indeed have its own firmware and isn’t even based on iOS. It is updated separate from the rest of iOS. However, it does require similar update process and must be appropriately signed. You are right that this is a current weakness, but there is reason to believe Apple could alter the update process such that the Secure Enclave firmware could behave distinctly and require the PIN to be entered correctly or it wipes part of the key.

First, sorry about all the italics before, I was in a hurry and didn't close a tag.

I just disagree. Yes, the basic mechanism of applying an OS/firmware update is the same, but the details are different enough. Apple previously designed the passcode/encryption in a way specifically to allow them to comply with police warrants and requests. It wasn't something new they designed but already had for the purpose of complying with warrants. They changed that in iOS8 such that Apple no longer had access to the decrypted hardware key. They implemented security restrictions on brute forcing in the firmware and later in the Secure Enclave hardware. This request is to implement a backdoor/weakness in their security implementation that did not previously exist. The fact that is would be relatively easy for them to do so is irrelevant.

Although not definitively established yet, there is evidence that the Secure Enclave is firmware updateable without enter the PIN. I expect Apple will udpate this such that future firmware updates cannot be loaded without the PIN unless the hardware key is wiped. That should eliminate the feasibility of these requests.

Apple isn't being asked to unlock the iPhone as in previous iOS versions. They are being asked to write a new version of the OS/firmware that removes security features protecting the hardware key from brute force attacks. They are also being asked to implement a completely new capability for electronically attempting to brute force the pass code to decrypt the hardware key. They aren't the ones that will be doing the brute forcing, the FBI is.

Besides that, you have to enter a passcode every 48 hours, if the phone is rebooted, or after just four misread fingerprint attempts.

Since this is an old iPhone 5c with the A6 SoC, you are mostly correct. This is not true of the newer phones with A7+ SoC's that have the Secure Enclave.

Actually, the passcode is merely used to encrypt the part of the stored decryption key. The decryption key which is a composite of a stored key and the etched CPU ID. (note Apple says they do not keep any record of the CPU ids when manufactured) The decryption key itself doesn't change unless the entire phone is reset. If the pass code was part of the decryption key, then the phone data would have to be decrypted /reencrypted every time the passcode was changed. As it is, they only have to decrypt/encrypt part of the stored decryption key.

Yup, and brute force decrypting the icloud backups would be much much more difficult than brute forcing the likely 4 or 6 digit PIN code on the device.

Even if it is fixed in homebrew, it's not like the system bash isn't still sitting there on your system vulnerable. Let's hope some day Apple will port in a fix to the system bash.

If you haven't tried it, you should try Firebug. It helps debugging Javascript in the browser quite a bit.

I don't think SSL/TLS works the way you think it does.

These companies don't by "SSL keys", they buy signatures on their own public keys. No one should be giving their private keys over to a certificate authority in order to get a signed certificate.

Now, if you meant the CAs may have provided some sort of intermediate CA to the government so it could sign their own certs and masquerade as anyone and act as a MITM, than that is more likely.

PFS is dependent on the cipher suite that is used. Safari and IE both *do* support some PFS suites, but not all PFS capable cipher suites. And for those they do like, they seem to prefer them less than some non PFS cipher suites. Safari seems to be better than IE at this as they support more suites but the non-elliptic-curve ones are used only as a last resort. So, the problem is web servers respecting the browser's preferences will end up selecting a non-PFS cipher suite even if the web server itself does support some PFS cipher suites.

So Safari/IE need to start favoring the PFS ones and/or web servers need to start only accepted the PFS suites.

Netcraft has some good research on the area.

I hope the ACLU suit succeeds or that Congress decides to fine tune the law (lol). But from the NSA's perspective, (or so I've heard from a talk by Gen. Alexander) they believe they are authorized to collect the data, but they "have a system in place" to protect access to the data. They require some sort of FISA court approval to actually search and use the data (which as I understand, the FISA court is basically a rubber stamp). He also referenced a specific number of times it had been accessed and how many terrorist events it provided information on (51 or so I think, don't remember the other numbers).
The fourth amendment isn't even being considered seriously because in 1989 the Supreme Court already ruled that a minimal invasion of privacy was justified in the government's need to combat an overriding public danger (the case was about drug testing of railway workers), but it has been interpreted, well.. broadly. The FISA judges have ruled that the NSA's collection and examination of communications data to track potential terrorists doesn't run afoul of the fourth amendment.
I don't see a clear path would put this in front of the Supreme Court to challenge it on constitutional grounds. Nobody can claim they have standing unless they know their information was accessed and no one knows that because the info is classified. catch-22 of sorts.

Then it should be challenged in court (the Patriot Act). Another commenter posted that the ACLU is challenging the NSA over its interpretation of the Patriot Act, but no one is challenging the activity on constitutional grounds (largely because of a 1989 Supreme Court "finding that a minimal intrusion on privacy was justified by the government’s need to combat an overriding public danger.")
http://www.nytimes.com/2013/07/07/us/in-secret-court-vastly-broadens-powers-of-nsa.html?_r=0&adxnnl=1&pagewanted=all&adxnnlx=1374778966-Bwk6gp9wV17MNPc2hI6YXg
Devils advocate for the NSA: Actually, this is from Gen. Alexander of the NSA directly when he spoke at an AFCEA conference I was attending: They are only collecting the data. In order to access or search it, they require a FISA court approval. (but which they almost always get)