It might not be the memory concern it once was, but today it might very well be a power concern. Modern laptop display pipelines can save power if they don't have to redraw any of the screen: constantly updating status bar animations break that.[1]
Neither Chrome or Firefox support HLS on the desktop despite providing support on mobile (since Android 3.0 I believe). They have categorically refused to add desktop support, if you have any complaints I would take it up with them.
I can't find any reference for them supporting it on mobile, and it doesn't work in either on my phone (Android 7.0, for what it's worth). In fact, in Chrome it even fails to display the "not supported" message.
Besides that, I would rather complain that Apple is using an obscure format than complain that Mozilla and Google don't support an obscure format.
EDIT: sorry, it seems mobile Chrome is supposed to work, but it just... doesn't. Still don't see any reference for firefox, though.
There's code for it in Darwin's libmalloc, but it's not exposed as API.
reallocarray() has some difficulties as an interface, mostly inherited from realloc(). I'm a bigger fan of reallocarr(), but that's NetBSD only. We (the operating systems community) need to find a consensus here, but I'm not convinced that reallocarray() is that consensus yet.
You give the HSM the pin, it returns the key used to encrypt the data, applying the rules to that interaction with you. Emulating the HSM doesn't help since it is that phone's specific HSM with the key it knows that you need to access.
As far as "modern signal handling" goes: On OS X, you can also just create a dispatch source of type DISPATCH_SOURCE_TYPE_SIGNAL. If your code already uses dispatch, this is much easier than trying to wire up to kqueue directly.
Only the specialized economists who suggest people would ever need to have signs, surely. Also, the rare restaurant that wants to garner advocates. Then perhaps amateur entomologists. Works engineers who want to know when something erodes would surely bury fiber optics rather than a RFID or battery device with 30 year lifetime.
I think the hesitations about passphrase being subject to brute force, rainbow table, etc. are warranted, but I have another concern:
If my passphrase gets compromised, I have to retire the keypair.
That's true of a key file with current asymmetric systems; but, presently if the passphrase of my GPG private key is compromised (e.g. by a hardware key logger), I only have to change the passphrase and ensure the old keyfiles are destroyed.
With MiniLock, if my passphrase is compromised the entire key material is compromised and I need to revoke the public key. But how do I revoke it? Do I tweet a message with the private key saying the public key is revoked? Will there be a centralized place to publish revocation messages? Efficient key revocation will be absolutely critical to this system and that's hard if the key distribution mechanism is tweets or some other ad hoc mechanism. This is one thing that PGP key servers really help with.
I actually approached Kobeissi with this point in the meeting in Noisy Square right after the talk, suggesting he integrate a TPM into his key management system (like how you can call out to one in Firefox for SSL with libpkcs5.so or some similarly named library). He responded that the specs were open enough that anyone could add that in. As to a centralized place your guess is as good as mine. Also can MacBook users even access their TPMs?
Yeah, I wouldn't trust the TPM - certainly not from a Windows machine, and not even an Apple one after the recent revelations/research, which shows Apple tries to make the device secure against "regular" hackers, but very easy to access by Apple itself or the US government.
My current one is from atmel in 2008, before atmel quit making them, so I figure at least in this case I'm safe. I would probably not use a newer one if I was worried about TLAs though. As I am currently in the market for an MBP, where do I find this information about Apple TPMs?
