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.
This was more or less my exact same scenario as well. MFA with an old phone number makes account recovery from Google about close to impossible. I had a friend who worked at Google that was able to create a support ticket for me. Before talking to my friend, every single customer service support rep more or less confirmed that I was completely SOL.
It is the reason why I have transitioned from Google.
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.
From personal experience in my job, I've seen ad networks abusing the following APIs for privacy invasive fingerprinting:
- AudioContext API (introduced as recently as last year)
- Performance API
- Widevine DRM
- Speech Synthesis API
If you put a lot of thought into privacy and security, we certainly wouldn't be seeing this level of widespread abuse by ad networks.
Let's deep dive on AudioContext for a second.
Chrome's AudioContext API allows ad networks to pilfer latency information about the user's audio hardware (which is used in the wild for fingerprinting today) with zero user interaction, zero indication and zero approval. A web page that never plays audio (!!!) has access to this silently and without approval.
I feel dev's at Google, just turn blind eye, once a PM pitches an Idea, literally every API they build is abused by ad networks, and now they want us to believe native file system access is safe, and good enough to be allowed by default. I just want this to blow up and see how the same googlers defending this feature, come and answer again.
> We put a lot of thought in Privacy and Security, as we do for all APIs.
but somehow, data is heavily harvested thru browsers(chrome), apps(android). Do you even test your APIs with a sample audience, like real tech ignorant people and see how they are blind to all those and just click yes, and don't care?
> o you even test your APIs with a sample audience, like real tech ignorant people and see how they are blind to all those and just click yes, and don't care?
Yeah so there are few dozens of ways people are getting spammed, why not lets add more ways. Here's an Idea let me write a blog post on how to make windows look cooler and ask my 12YO user to point me to their windows directory and let me use my API to inject my DLLs, none of the defenders of this API are not estimating the level of social engineering, and how dumb users can be, and also the reason why Android failed in terms of privacy.
You forgot to read the part where they will block certain directories, and your 12 year old could easily install malware or give out his password, and Android did't fail in terms of privacy. Apple has failed by locking you into a closed-source ecosystem. Android is open source and has a lot of options, and a lot of open source apps you can review yourself and pick the best cryptography algorithms for password management, etc.
I get that you dislike electron, but that doesn't take away from the truth: don't like the latest version of an app? too bad, you just have to get used to it or stop using it
What a ridiculously user-hostile attitude.
It's not about Electron, it's about the loss of control. It's one of the big problems with any sort of forced-update software delivery: Web apps, SaaS, snaps, etc.
The new version drops a feature I need? "Too bad."
The new version doesn't work right on my computer? "Too bad."
The new version has a bug that is blocking my work? "Too bad."
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.
I'm sure you worked hard and thought a lot about the security of this, but you have to be really arrogant to think that this will be fine because you thought about everything. I'm pretty sure this will open up a lot more possibilities for malware, viruses, harmful web pages than the convenience it will provide.
Yeah, they sure thought about everything thats why ad networks abuse the hell out of every API they implemented to fingerprint people, like AudioContext Api, battery API and what not.
The alternatives arent that people just dont use it, the alternative is are that people download some random executable that has much larger security vector, ie some electron app that has unlimited file system access.
I have no idea why you were down-voted here. Non-technical people are downloading executable files on their systems by the millions every day.
People can argue about how scary the warning messages should be on this new API, but they can't argue that this is not the way forward to a more secure world.
With this new API in place we'll be one step closer to the goal of having all consumer applications running inside a progressively-permissioned sandbox. It's a dream come true and will allow the culture and OSes to even more strongly stigmatise the opening of executables which immediately gain full system access - something that's completely absurd, but was a necessary evil.
Which paths are "sensitive" depends on which other programs the user has installed. Would Chrome recognize ~/.mozilla as a sensitive path? How about adding arbitrary content to ~/.ssh/authorized_keys?
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.
I don't think anyone is suggesting writing game engines or the core of graphics processors or video renderers in React Native. It's for the frontend. The pattern of using React Native for the frontend and native moduels for the backend is a pattern being used by many companies. The difficult stuff can be written as a native cross platform library, while the front end can use React Native. This is what MS is doing with Office.
Java, JavaScript, .NET, forks of Lua, forks of Python, and others are JIT compiled.
So I am not sure what you are saying. Everyone that is able to is compiling their stuff to try to regain some efficiency.
The reason is that people wants to do more complex things with their software nowadays, and hardware can't keep up with the trend. There is also battery life, smartphones, tablets...
Those are the reasons we are seeing a resurgence of native development.
I’m not referring to “native” as in compiles down to x86 and doesn’t need a runtime. I’m referring to native as the opposite of a cross platform framework that produces apps that don’t take advantage of the native OS’s look and feel.
This isn’t just me being a Mac snob. I found Apple’s few Windows apps over the years to be just as bad.
IIRC there was a feud between Chrome developers who wanted raw file access and Firefox ones who didn't want it. W3C sided with FF, so we can't build proper desktop apps using PWA, even if WASM makes them quite fast these days. Now Chrome devs resuscitated the attempt with NFS API, so I'll grab my popcorn and watch their interaction one more time...
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.
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.
> 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.
In other words, throw out all the advantages that come from using Rust in the browser in favor of a codebase that has a policy forbidding any use of that language. No thanks.
Furthermore, I have to note the irony that you say nobody else should implement their own engine when your team is the one that forked Blink from WebKit in the first place.
Open browsers have been around for decades, Chromium didn't offer anything new there and as you say it even started off an open browser itself. If everyone did what you suggest there is a net loss for the user as where there used to be competition in browser backends there is now whatever Google considers in it's interest to merge into Chromium for others to also adopt (until the point someone manages a fork and we're back at the part where you say companies should drop their engines for what is popular instead).
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.
