hdhzy

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.

These kind of hidden extensibility in built-in functions make even seemingly simple code not work as expected:

  ["1", "2", "3"].map(parseInt)

  > [1, NaN, NaN]

> ...it seems like a block chain would be ideal

If I could get just 1 satoshi every time I see this suggestion...

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.

A lot of them generate 404s but still it's a very valuable list, thanks!

  -2017-11-26 22:15:18--  http://www.oreilly.com/design/free/files/2016-design-salary-survey-report.epub
  Reusing existing connection to www.oreilly.com:80.
  HTTP request sent, awaiting response... 404 Not Found
  2017-11-26 22:15:18 ERROR 404: Not Found.

Out of curiosity which version do you have?

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 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.

> 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.

You don't need to think ME is a secret NSA backdoor to know it's a terrible "feature" from security point of view.