sayhello

Counter-Strike was a mod of Half Life, not Halo.

When I was a Google employee, I helped a friend go through their account lockout issue. It was because they used MFA to a phone number, but later changed their phone number, which made them unable to login. He tried so many times that some velocity threshold was hit, further limiting the possibilities.

My friend needed to respond to some interview scheduling, so, it was a stressful situation.

Part of the problem was that it was hard for my friend to find a way to create a support ticket. He did in the end and got in a line of communication via an alternate email.

There were many miscommunications from both my friend and the support agent. While Account Recovery or even basic identification are hard to navigate for technically-minded folks, it's even more challenging for non-technical folks, including the support agent.

In the end, I got in touch with the support person, helped translate what they wanted to know to my friend, and likewise, translated what my friend was saying in a way that the support person could understand.

I don't think I was able to see the support ticket itself, because of PII restrictions. In the end, my friend was able to restore service. I doubt he'd have been able to without my support in time to respond to the interview scheduling.

It still took a couple of days.

We made sure that the activation of the API is gated by:

1) User Activation checks 2) When access to the file system is requested, a File Picker is necessary 3) When the API is in use, there are plenty of indication that it's being used

We put a lot of thought in Privacy and Security, as we do for all APIs.

Precisely. You'll also gain the ability to update your apps cheaply (via the web) and bonus security points by not being beholden to Electron updates.

Why does it have to be sad? When software becomes easier to develop, it enables everyone to benefit.

More developers, more applications of software.

At the same time, performance has a tangential relationship with computer code being interpreted or compiled to native.

After all, Java is compiled to byte code and powers plenty of high traffic servers efficiently.

Many AAA games use ActionScript, Python, Lua, etc for their UIs and scripting for mods.

While it's true that there is no substitute for code compiled to native when high performance is called for, I think it's justified for native development to be last resort.

This is coming from someone who codes primarily in C++, where high performance is important. I wish I didn't have to.

About web APIs, didn’t want to imply that blink was used instead of WebKit for that reason, it was just an example that rendering engines could still evolve independently.

Disclosure: I work at Google on Chrome. Opinions are my own.

Using chromium as a base, browsers will have to differentiate by offering a better product.

“Better” is less likely to be better performance, compatibility, or accessibility.

By using much of the same code as another browser implementer, any browser vendor [hint hint] that still makes their own engine could reduce the resources they put on the foundations and web platform and put more of it on the product itself.

Perhaps we’ll have more groundbreaking innovations to move browsers forward. The last few big ones: multi-process architecture, tabs.

In effect, by using the same foundations, the browser wars could in fact be reignited and the users could be the winners.

On the web platform side, I.e., the stuff you see on MDN and w3c specs, using the same “base” doesn’t mean the browsers won’t have different implementations of future APIs if the vendors’ opinions diverge strongly. Case in point: Chromium used to use WebKit as its renderer and now uses blink, a fork of WebKit.

Because the scammer may be using this as a way to launder money or to extract money from stolen credit cards.

They may not be scamming legitimate bookers, but rather, using the listing for other kinds of scams.

Good point. The current widely used kernels seem to make some assumptions about ‘owning’ the hardware and implicitly trust any running programs at a certain level.

There is a need, however, for some pragmatism.

While a capabilities-based OS could be the right solution, it doesn’t exist today.

What we have is code built for some flavor of POSIX. People demand cost efficiency today.

So, engineers do what’s practical: build a multi-tenant system running code that expects to be the owner of the hardware.

It works good enough! For most people, the cost efficiency math works out. The sand boxing overhead is worth it, as it pales in comparison to the headcount required to manage your machines, or even VMs, if you replace them with Serverless products.

Did the BSD jails provide enough isolation? Would memory from a process truly be isolated from another? How about FD’s?

Could there be side channel attacks? At what level?

Perhaps the whole kernel design needs to be revisited, which I assume is what’s being taken on by Fuchsia.

Did the Windows Server isolation bundle a slim kernel?

One of the core elements of this for the Serverless fast boot requirement is using a kernel that has legacy modules excised.