Jahava

> But there is still no way to use ndb from outside App Engine standard, right?

Shameless plug, but for Go, there is an unofficial third-party (Chromium team) datastore package that feature near-seamless AppEngine standard/flex datastore support: https://chromium.googlesource.com/infra/luci/gae/+/master

It currently couples to any hosted memcached service, but should be forward-compatible with AppEngine if/when they release a Flex-accessible cloud version of their hosted memcache.

"luci/gae" also features a fully-compliant in-memory datastore mock for 1000x+ faster datastore testing and uses a memcache implementation based on "qedus/nds" which fixes several consistency issues present in "ndb".

> What Google should consider doing is making App Engine "classic" services like Memcached, etc. available to any service running across GCP.

Many AppEngine standard services are accessible using the "cloud" versions of APIs/endpoints. You may have to do some more heavy lifting, although on Flex you get GCE self-authentication for free, and most "cloud" API packages know how to recognize and utilize this.

Memcache is apparently on the list to receive a cloud API, although it's been in the "pre-alpha" state for over a year now. See: https://cloud.google.com/appengine/docs/flexible/java/upgrad...

In all fairness...

> run rendering in a sandbox

Most major browsers, including Edge and Chrome, do this and are really good at it.

> closely monitor your deps for vulnerabilities and ship patches as quickly as possible

Most major browsers do this too, and they have well-established update pipelines that can patch vulnerabilities in short order.

> choose deps with a better security track record, when possible

Most major browsers do this (e.g., "boringssl").

> independently scan, test, and validate the deps you bring in

Most major browsers do this as part of QA and vulnerability scanning.

> things you can do in an electron app: > * pray

* leverage all of the work that thousands at Microsoft, Google, Mozilla, etc., put into deploying what I suspect are the most heavily-attacked, heavily-scrutinized, and heavily-audited software platforms in existence.

Not that I'm specifically advocating web apps over native apps, but I don't think your list does a good job outlining their advantages.

The blog mentions, "We’re considering argon2 for our next upgrade". I suppose they could do in-line upgrades: as users are signing in, the SHA512 is piped through the old pipeline for verification and through the new pipeline for migration. As far as I can tell, there's no way for them to swap bcrypt out for argon2 using just their cold store.

At some point I have to draw a line between the information that he leaked regarding questionable (and, ultimately, illegal) domestic US spying programs and the sizable remainder of the corpus detailing US tools, techniques, and strategy employed against foreign nations. The former is undoubtedly potentially patriotic, while the latter is a legitimate and legal function of the NSA and likely damaged its intelligence mission on a number of fronts (and is, ultimately, treasonous).

I have to ask myself: could he have leaked the former without the latter? In all available information, I have not seen a compelling reason to think that the two bodies of data were inseparable. A heroic Snowden with the best of intentions absolutely needed to invest the time and care into either not collecting the body of non-US data in the first place or, failing that, purging it from the body that he released to the world.

For me, his failure to do either inexorably poisons any heroic fallout with the treasonous side effects. One step further: why did he neglect to do something as simple and important? I find the heroic Snowden to be a hard sell, since it seems like he was at best grossly irresponsible and, more likely, motivated by something other than patriotism.