The Hayward fault seems to have the most seismic activity lately. You'll feel them 2+ times a year in the East Bay--especially if you're in an older, multi-story building when it strikes.
Your making a lot of assumptions. For example, who said anything about a product. Not all "players" small or large are selling something. Sometimes people just like to make stuff that works well for themselves and others.
Things like gsyn.ch will just not be written. Google already throws scary warnings about unverified apps using OAuth tokens when you use this service, but Google's use of non-standard CSV entries rather than vCards for sharing contacts has made for a terrible user experience if you want to use your phonebook outside an Android phone/Gmail.
At $10 a month, that’s only 125 users. How many apps with less than 125 users have we seen become a target for hackers? Has there ever been a case like that?
Startups and open source projects get screwed because of Google's lack of nuance on this issue. Google could have created a tiered fee structure based on number of users, threat vector, etc. but didn't for whatever reason.
Goal #2: Don't have a solution that requires an army of people to manage.
If no one's willing to help fund your idea, you're out of luck. That seems... really understandable, given that every major government is literally investing millions trying to hack into Google's user data.
To elaborate: The spirit of a one-pager isn't to cram everything onto "one page", but rather to have a "single document" that contains all the context/content you need instead of having hyperlinks to large swaths of other documents (doing a depth-first search in documentation at Google can be a huge time-sink).
Source: Another Googler that wastes time on memegen
I'm a Full-Stack developer at Google, which is fairly uncommon given the complexity of systems here.
The chief trait of a Full Stack developer, in my opinion, is often just growing into the needs of the team/moment. I've been weighted in different directions because that's where the product needed me; I'm currently the Front-End domain expert on my team.
Self-adulating thought leaders who throw shade at Full-Stack are themselves just really bad at using more than one language, let alone thinking about different parts of a large system.
(I'd also expect a Full-Stack developer to understand systems and resource provisioning/monitoring. Not just JS vs. Java.)
Getting rid of say outlook support would greatly weaken Gmail.
Furthermore if you have an up to date sync on the day imap support ends then you have all your email and need face only changing over to a new address or if you already use a custom domain logging on and changing the email provider.
For select users that are willing to advocate for themselves against Google and are covered under a binding, unexpired contract Google will likely let them continue using said APIs. Everyone else is likely to see APIs break at Google's whim, as most users aren't covered by custom GSuite contracts.
On a related note: LED light bulbs often emit radio frequencies and all of the ones I’ve tried so far interfere with my garage door. Which was insanely hard to figure out.
(Garage door openers have spots for 2 light bulbs.)
This is hilarious. Every single Google conspiracy is basically because some Google Engineer tried to DRY up functionality in an insanely complicated system.
So, I think that's probably quite right in general, and it's no "conspiracy". But it can still be a barrier to privacy. Rather than a conspiracy, it's evidence of priorities. You don't eliminate a development affordance when DRYing something up for something you know is a priority -- or if you do, it'll get refactored to fix it soon enough, if it is a priority.
Which is perhaps generally applicable to "conspiracies" in fact. There are some instances of powerful people making plans; but there are even more instances of results from systemic rewards and punishments, people acting independently with certain interests, from just how the system works. It doesn't make em always great. Systems can be changed.
How can you explain this: in Android 5.1, every time you enable GPS, a popup appears asking you to share location with Google. There is a checkbox titled "Don't show again", but if you tick it, the button "Decline" gets disabled [1].
I don't have the exact screenshot, but the popup looks approximately like this [2].
They intentionally wrote the code to make sure that the user doesn't make the wrong choice. And this popup is not really necessary for the user, mostly for Google.
Also, this reminds me of Google's "Amateur Hour" story with Firefox. Every time they make a mistake, it's in the favour of Google, what a coincidence.
It's funny, though, how every single "conspiracy" just randomly ends up falling in the "fine if you give them full access, fails if you turn off location services" quadrant. Like, I've not once seen a mistake in the direction of "eh just turn off that data collection point and it'll fix it."
Imagine you have ~billions of users and 99.9% of them use the default. Do you put your eng effort towards power-user flexibility for the tinfoil hat crowd or do you improve popular features?
In the case mentioned, searching "your locations" appears to be just all on or all off (I have no insider knowledge of Maps). That greatly reduces the surface area for heisenbugs in a high QPS system.
The reason for that is pretty obvious isn't it? Very few systems depend on an absence of data to work. However, many systems can be designed which depend on the presence of data. If a setting affects the presence of data in some Google-internal databases, turning that setting off will disable any features that depend on the presence of that data in that database.
Unless they demonstrate a conscious, consistent effort to be privacy aware and let you control you data, the way Apple does, for example, those conspiracies will keep coming.
The only way out for Google is to actually start paying attention to that issue and make a conscious effort. And it'll take time before they'll regain the trust.
