Promarged

Thanks! This should be the canonical URL posted here.

I know it's javascriptjanuary.com but having this:

> node -e require('https').get('https://gist.githubusercontent.com/PurpleBooth/109311bb0361f..., b => b.on('data', c => process.stdout.write(c+'')))" > README.md

instead of plain curl seems weird to me.

Poland also wanted to remove daylight savings time (the project was in the lower house) but ultimately it was rejected because all EU countries need to use the same time (DST). It seems Finland is taking it further...

> The way the stylesheet makes the "rendered" form (especially section headings) resemble markdown source is pretty neat.

As far as I see it's just section headers, but I agree the stylesheet is very nice. The section header prefix (###) could be an anchor to the section though (<a href="#section">).

BeyondCorp is indeed complex but I don't know about outsourcing it to someone else. It's a core of one's company's infrastructure so that'd be extremely risky to let someone else manage it. But maybe it depends on the company size but if that's so a small company doesn't need this level of protection (device keys in TPM, device management and health checking service, etc).

Yes, but my point is that only when the corporation issues the hardware themselves they can be sure that the user did not tamper with it. (It's not clear to me if that's what you're saying...)

I'm not a Googler but reading from previous publications BYOD is not supported. This stems from the fact that for BeyondCorp to work they need to be sure the device has not been tampered with. Only having trusted-boot really ensures that.

Singularity used Software Isolated Processes. Basically the apps were distributed as .NET bytecode, compiled by Bartok on the target system to native code. That guaranteed that processes never accessed each other's memory so you wouldn't need regular process isolation.

I haven't thought about the implications to reading kernel memory but it'd be great to see a paper on the subject.

I don't know why but I'm actually less excited about Fuchsia than the old Singularity/Midori. As Joe Duffy said [0] when they worked on Midori they also wrote UI, editors, browsers and many more applications in months so it's not surprising Google engineers also managed that.

[0]: https://www.youtube.com/watch?v=CuD7SCqHB7k

For me it looks like the classic Not Invented Here syndrome - we already have microkernels, even formally verified ones (seL4) but AFAIK Google didn't want that to "be more flexible".

Using C for kernel also looks like a poor choice nowadays, unless Google has some magic static analysis (for example Singularity/Midori had custom languages with ownership tracking akin to Rust).

Maybe Fuchsia is for bringing microkernel architecture for masses using "boring technology"?

After PSD 2 directive comes into effect (expected 2019?) all European banks will have to have an API.

I think except the cryptography there is just trust calculations and encoding.

These two articles describe trust in detail:

https://www.linux.com/learn/pgp-web-trust-core-concepts-behi...

https://www.linuxfoundation.org/blog/pgp-web-of-trust-delega...

GPG esoteric options is also a good read:

https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoter...

Besides that... the RFC itself I suppose:

https://tools.ietf.org/html/rfc4880

I'm not from Amazon but I'd guess they want to protect the request from being replayed inside their own systems.