There are generally two schools of thought: one is that the programmer should know better, memorize the documention and specs. The other one is that if it violates the principle of least astonishment it's just badly designed. Personally I believe that the truth is somewhere in the middle. It's good to know one's tools (including docs and specs) but I wouldn't call this kind of "clever" code maintainable.
Auditing binaries wouldn't really do anything as it's their hardware that'd run the binary. So the hardware can be programmed to lie or to still have some backdoor.
I wouldn't recommend XPS. I have version 9350 and it constantly have one problem after another. In no particular order: slow boot time (it can take 7 seconds to see dell logo after pressing power button), coil whine, a firmware update killed the laptop once. I don't know how much of these problems can be attributed to Intel but I fear hardware manufacturers have adopted "release early fix later through firmware" mind-set. Good things about Dell: next business day warranty where a guy will come and replace the motherboard in case the update renders it useless.
Actually I read the rechargeable section but there is no explicit mention there of how quickly does the rechargeable battery provide power. Is this implied that it's not in quick bursts because it's rechargeable? Or maybe I missed something? (I re-read the section again now).
> There are some kinds of battery that only work at those temperatures - molten salt batteries. Used on earth for a few types of missile and some grid batteries.
Not an expert in batteries but Wikipedia says molten salt batteries provide high amount of power only for a short period of time:
> Once activated, they provide a burst of high power for a short period (a few tens of seconds to 60 minutes or more), with output ranging from watts to kilowatts.
> There are no standards and protocols in place for this, and there's no browser that enforces this.
And there will never be especially for web apps because there are no parties interested in this. Look at what happened with HPKP. It looked good on the surface but it turned out that extreme security is a little bit too extreme.
> If you think that taking something that's 80% there and filling in the last 20% for yourself counts as something that's "already" possible, then nothing is new and everything is already possible.
I'm just pointing out that you can already construct a scheme with the same security properties as what you described. If you'd rather wait for some hypothetical standard and implementation that will probably never happen then that's your decision.
> This is really janky and not at all what I'm talking about. What I'm talking about is as simple as what happens now, e.g., "GitLab/Mastodon/Whatever XX.x Released".
Perfect is the enemy of good and "GitLab/Mastodon/Whatever XX.x Released" seems to be just good enough. For paranoid people OpenPGP is there to verify build artifacts.
I don't want to sound negative but I guess almost 100% of the web relies on quickly updating resources and being fresh so I wouldn't hold my breath for when "resource pinning" would happen.
For the record one can already do it if all resources would use Subresource Integrity. Hashes of leaf resources would be embedded in parent resources up to the root document that you could announce out-of-band (e.g. https://example.com on 23rd of November 2017 has hash 1234566...). Then you'd have a cryptographic proof (like a Merkle tree) that nothing in the page changed.
> The webcrypto api also can't stop the server from sending malicious javascript to a user which when run uses the webcrypto key to decrypt the user's data and send it back to the server.
Yes, but virtually nothing protects against proxying requests. Non-exportable keys protect against using them when the device is powered off.
> Also, if the server is malicious on the first connection, then the server could just not use the webcrypto api to begin with, and just make use a key that the server knows instead.
Agreed, but it's kind of like Trust On First Use. I guess it depends on one's trust model if they consider it a good trade-off.
> CACert is a weird example because their model was completely at odds with how everybody else (yes now including Let's Encrypt) does things.
Well, CACert insisted on validating people but it turns out that it's not really necessary to know your customer to issue DV certs according to Baseline Requirements. Let's encrypt understood it and just did a minimal required job to be accepted (it's still a lot of work).
Instead of verifying people I'd gladly see X.509 replaced with OpenPGP w.r.t. trust model so that I could see who trusts who and why. OpenPGP has a mode of hierarchical trust with trust signatures, additionally they can be limited to a domain, that could be used to give people power to issue their own certificates for their own domains.
It's not that easy. I mean the code is there but the infrastructure needs to be provisioned and it takes time to gain trust in the CA world, see CACert.
DeX is quite good but unfortunately only available on the top Samsung phones. I think the target market would be people that don't necessarily need a PC for most of the time. Someone that needs a bigger screen to easily do banking or word processing.
DeX has one HDMI port (1080p), two USB 2.0 and one Ethernet.
I can't wait for the Linux on Galaxy project to see how working with Ubuntu through DeX would feel like.
I'm not the author but probably the intention there is to have a minimal one executable container and before the recent multistage builds feature it was kind of a pain to implement.