Ironically, it's the people who disable all telemetry out of ignorance and paranoia that end up crying every time a developer deprecates their favorite feature or they have an issue with a new release. If you don't vote you don't get to complain. Mozilla's PM's in particular have repeatedly published and cited telemetry data in their decision making, and have referenced crash reports in proactively filed bugs.

There's no such thing as Airglow Browser. The entire article describes in great detail something that doesn't exist. Then it provides a link to "download the binary at airglow.dev."

airglow.dev is nothing but a link to a vibe coded Chrome extension that uses Claude to write user scripts.

I think the post both directly and indirectly answers its own question when it states that the app does two things:

>It reports tracking data associated with your Google Account back to the developers. >It shows you advertisements (which they call “inspirations”) for other trips organised by the same agency.

It's a lot easier to be user-hostile with an app than a website, and a lot harder for the average user to detect or block the bad behavior. Just about everyone at this point knows how to install a content blocker, open dev tools, and block stuff with their browser. The number of people with the ability, time, and energy to circumvent cert-pinning and inspect an app's traffic like this guy did is significantly smaller.

There's a reason why every company is constantly shoving apps down our throats and telling us all the cool young people are mobile-first.

Meanwhile, real users are shadowbanned all over the place, often just for the crime of being new to the site or not self-censoring. If you use the report function linked at the end of the article, the AI-generated content you're reporting will frequently pass their poorly engineered automated sniff-test, and instead the reporter ends up with their own account flagged for "abuse" or "bullying."

The OC collectively monitored everything across the company. Each alert that paged had an associated runbook. If they couldn't clear the alert with the runbook, they'd escalate to the SRE responsible for the alerting server/component. Our job was essentially to fix anything that broke that OC couldn't solve. For my domain this often just came down to basic Linux troubleshooting, but sometimes would actually involve specific knowledge about our component. For others (e.g. networking) I imagine the ratio of domain-specific-knowledge problems was higher.

If we determined something was fundamentally broken, like someone pushed an update and now the service won't start, we'd escalate that to PE. PE did a lot of what I think falls under SRE purview at other places: Managing deployments, building out infrastructure, etc. At Yahoo we were really just "tier 2 ops."

We'd also be paged for outages if our service went down or another team was blaming our service for their outage. The job here was essentially the same thing, just with more pressure and people yelling at you; or arguing and trying to prove your stuff was working, please find someone else to blame. If we were involved in an outage, we'd also have to join the "post mortem" (I'll never be able to say that without air quotes) and help with RCA/take on remediation tasks.

Secondarily, we created the monitoring/alerts that went to OC and wrote and maintained their runbooks. In our downtime we were also supposed to do simple automation/scripting to help us or OC with redundant tasks. Sometimes I think I made useful stuff, but often this felt like self-imposed busy work, because we always - especially under Marissa's stack ranking regime - had to demonstrate that we were doing more than just our job. I swear one quarter between us and OC we ended up with like 10 redundant Slack bots because everyone was rushing to make something to pad their review with.