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.
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.
I worked on this. The quote is true, in all honesty. Same as downloading and running applications from the web.
We do our best to make sure the scenario listed doesn't happen. For instance, on Windows, after a writer is closed, we apply the Mark-of-the-Web, apply SafeBrowsing checks and finally call a system API which may trigger an anti-virus check.
On the Mac, we apply the equivalent of Mark-of-the-Web. You may have noticed that when you open the file, sometimes it asks you to ensure the provenance of the file?
Basically, it's a similar procedure as for file downloads.
Edit:
I forgot to say that "sensitive" directories are not allowed.
Think C:\Windows, etc.
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.
And it's nice that the web app only has a narrow set of permissions.
You could imagine the same for an unzipping app. It theory, an unzipping app doesn't need anything else than specific file system permissions, i.e. read for a specific set of bytes and write access to a specific filepath.
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.
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.