Coder Legion - Recent posts tagged service

How to Respond to Negative Google Reviews in the Philippines

Sat, 19 Sep 2026 15:50:00 +0000

Direct answer: acknowledge the review without arguing, confirm only facts you can safely make public, invite the reviewer to a private channel, and record the operational follow-up. If the review appears to violate Google Maps policy, preserve the evidence and report it, but do not report it merely because it is harsh or disputed. Never reveal an order history, medical detail, payment record, phone number, address, or employee file in the public reply.

A useful response is written for two audiences. The reviewer needs a clear route to resolution. Future customers need to see that the business listens, protects privacy, and fixes problems without turning the review section into a courtroom. This guide owns that single-incident response. The broader process for requesting, monitoring, assigning, and learning from reviews belongs in the separate review-management guide.

You need a verified Google Business Profile before you can reply. Google says an approved reply is posted publicly under the review, the reviewer is notified, and the reviewer may edit the review afterward. That makes a calm first response more useful than a fast emotional one. It does not guarantee a changed rating or removal.

Classify the review before choosing the response

What you see	Primary action	Public response
A recognizable service failure	Verify the event, assign an owner, and offer a specific private route	Acknowledge the experience and state the next step without exposing the record
A complaint you cannot match	Search by date, branch, service, and limited reference data	Say you could not identify the case from the public details and invite direct contact
Off-topic, fake engagement, impersonation, harassment, or exposed personal information	Capture evidence and report the policy category that actually applies	Reply only if a short privacy-safe clarification helps customers while the report is reviewed
A threat, extortion attempt, safety issue, or legal claim	Preserve evidence and escalate internally to the appropriate adviser or authority	Usually pause. Do not negotiate, accuse, or publish evidence in the review thread
A genuine opinion you strongly disagree with	Check whether a process or expectation failed	Respond to the experience. Do not demand removal or describe opinion as a policy violation

Google's removal standard is policy-based. Its Business Profile guidance says only reviews that violate policy are eligible for removal, and that a business should not report a review just because it dislikes or disagrees with it. A negative account can remain even when your internal record tells a different story.

1. Preserve the evidence and slow the response down

Save the review URL if available, reviewer name as displayed, rating, text, images, publication time, profile location, and a screenshot. Record who discovered it and when. If the text is later edited or removed, you still need an internal record of the original incident and the action taken.

Assign one response owner. A restaurant shift lead, clinic coordinator, or branch manager can gather facts, but only the designated person should publish the reply. This prevents parallel answers and makes the tone consistent. For an ordinary complaint, responding later the same business day or the next day is usually better than answering before the relevant staff can be heard.

Pause immediately when the review contains a threat, extortion demand, doxxing, or sensitive personal information. Limit internal access, preserve the evidence, and use the appropriate policy, safety, legal, or privacy escalation. Do not quote the harmful details in your reply.

2. Investigate with the minimum necessary data

Start with the smallest useful search: branch, service type, approximate date, staff on duty, and a non-sensitive reference the reviewer can provide privately. Ask the staff member what happened before deciding that the review is false. Separate facts from assumptions in the case note.

Review URL:
Profile / branch:
Received at:
Assigned owner:
Classification:
Verified facts:
Facts not yet verified:
Customer data consulted:
Public reply approved by:
Private follow-up channel:
Policy report / appeal status:
Operational correction:
Closed at:

In the Philippines, the National Privacy Commission's implementing rules require personal-data processing to follow transparency, legitimate purpose, and proportionality. The rules also say data should be adequate, relevant, and limited to what is necessary. Applied here, a public review does not authorize the business to publish everything it knows about the reviewer. Use private records to resolve the case, not to win a public argument.

3. Write a short public response

A strong first reply normally has four parts:

Acknowledge the experience. Thank the person for raising it or state that you are sorry the visit did not meet expectations.
State the standard or concern. Name the relevant service expectation without making an unverified admission.
Protect privacy. Explain that the team will not discuss customer details in a public thread.
Offer one owned route. Give a monitored email, phone line, or contact form and say what reference will help privately.

Do not paste the same generic paragraph under every complaint. Keep the structure consistent, but refer to the actual service category, branch, or issue when doing so is safe. The reply should be complete enough for an observer to understand the next step without exposing the investigation.

Response templates for common cases

Recognizable service problem

Thank you for raising this. I am sorry the visit did not meet the service standard we aim for. We are reviewing what happened with the team. To protect your privacy, please contact [monitored channel] with your visit date and reference number so [owner or role] can follow up directly.

Complaint you cannot match from the public details

We take this feedback seriously, but we have not been able to identify the visit from the details posted here. Please contact [monitored channel] with the date, branch, and reference number. We will review it privately and respond through that channel.

Privacy-sensitive business

Thank you for bringing this to our attention. We cannot discuss client records or service details in a public review. Please contact [privacy-safe channel] and ask for [role] so we can verify the matter and address it directly.

Review appears to describe another branch or business

We would like to check this carefully. The service described does not appear to match the records available to this location, but we will not make assumptions in public. Please contact [channel] with the date and branch so we can confirm where the issue belongs.

Replace the brackets with a channel that is actually monitored. Do not ask the reviewer to post an order number, phone number, full name, medical detail, or other personal data in the review thread.

4. Decide whether to report the review

Use the Google Maps prohibited and restricted content policy as the decision source. Relevant categories can include fake engagement, impersonation, off-topic content, harassment, doxxing, personal information, profanity, and unsubstantiated allegations of criminal or unethical conduct. Select the category supported by the content. Do not invent a privacy or spam reason simply because the business cannot find the customer.

Google provides reporting from the Business Profile and through its Reviews Management Tool. Its current help page says review evaluation typically takes several days. If the result is "no policy violation," the tool can offer a one-time appeal. The appeal is for a policy decision, not a second attempt to settle a factual disagreement with the reviewer.

Capture the review and the exact policy clause you believe applies.
Report the review from the profile or Reviews Management Tool.
Record the submission date and status in the incident note.
If eligible, use the one-time appeal with a concise policy explanation.
Continue the service-recovery process separately when a real customer issue may still exist.

If the review contains an extortion demand tied to removal or threatened reviews, use Google's dedicated extortion-reporting route linked from the inappropriate-review help page. Preserve messages and payment demands. Do not pay, bargain in public, or coordinate retaliatory reviews.

5. Move the resolution off the public thread

The private conversation should have an owner, a deadline, and a remedy boundary. Confirm the issue, explain what can and cannot be changed, and document the agreed action. A refund, replacement, correction, apology, or staff follow-up may be appropriate depending on the facts and the business's policy. Do not make compensation conditional on deleting or improving the review.

If the customer confirms the matter is resolved, you may politely say that they are free to update the review if they believe the new outcome changes their experience. Do not script the rating, offer an incentive, or pressure them. Google treats reviews influenced by payment, discounts, free goods, services, or conflicts of interest as incentivized or biased content.

6. Close the internal action, not just the conversation

A response without an operational correction is reputation theatre. Tag the root cause so recurring failures become visible: wait time, staff communication, billing, stock, handoff, cleanliness, scheduling, product quality, or expectation setting. Record the fix owner and the date it will be checked.

For one incident, a small case log is enough. When reviews arrive regularly, move from ad hoc replies to the full Google review management process for fair requests, monitoring, assignment, service recovery, and trend review. Build the workflow before buying software for it.

What not to do

Do not argue line by line. A long rebuttal gives private evidence a public audience and makes the business look defensive.
Do not identify the customer from internal records. Matching a username to an order does not give permission to publish the connection.
Do not promise removal. Google decides policy enforcement, and a compliant negative opinion may remain.
Do not accuse the reviewer of lying. Say what you could or could not verify, then provide a private route.
Do not threaten legal action in the reply. Preserve evidence and obtain appropriate advice away from the public thread.
Do not offer money, discounts, or free service for a changed rating. Resolve the service issue without buying the review outcome.
Do not outsource replies without access controls. An agency should not receive more customer data or profile permissions than the task requires.

Verify the response and follow-up

The reply appears under the correct profile and review.
No personal, medical, payment, employment, or order details are public.
The contact channel works and reaches the named owner.
The internal note separates verified facts from claims and assumptions.
Any Google report cites a real policy category and has a recorded status.
The service correction has an owner and review date.
The team checks whether the reviewer edited the text after resolution, without chasing or pressuring them.

A calm reply cannot erase a poor experience, and it should not try to. Its job is to protect the customer, show future readers how the business handles problems, and create a traceable route from complaint to correction. For the wider visibility baseline, use the local SEO guide for small businesses. To measure the profile and local search results without treating rank as the only outcome, see the local SEO tools guide.

Sources checked

Google Business Profile reply behavior, review reporting and appeals, Maps content policies, and the Philippine data privacy principles were verified against official sources on August 6, 2026.

Need a steadier local reputation process?

FloxoLab can review the profile, response ownership, local pages, and measurement path, then turn the gaps into a practical plan without ranking promises or invasive tracking.

Explore local SEO support

Originally published on FloxoLab.

Google Review Management for Small Business

Thu, 17 Sep 2026 15:50:00 +0000

Direct answer: start with Google Business Profile's own review link, customer-activity notifications, named profile access, and a simple weekly log. Ask every eligible customer with neutral wording after a completed service. Do not offer incentives, screen for happy customers, ask for a particular rating, or impose review quotas on staff. Assign each new review to an owner, move private details off the public thread, and review recurring themes monthly.

A small business usually does not need reputation software on day one. The native profile plus a spreadsheet or task board is enough when one person can review the queue regularly. Add automation only when requests come from several systems, multiple people need routing, or branches need shared reporting. The workflow should exist before software scales it.

This guide covers the full operating process. If one difficult review has already arrived, use the separate negative Google review response guide for incident classification, privacy boundaries, response templates, reporting, and appeal steps.

Use one policy-safe operating loop

Stage	Minimum process	Control
Eligibility	A real service, visit, order, or completed customer interaction	Use the same rule regardless of whether the customer appears happy
Request	One neutral message with the official review link or QR code	No incentive, rating instruction, staff script pressure, or required wording
Monitor	Customer-activity alerts plus a scheduled profile check	One accountable queue owner and a backup
Assign	Classify praise, question, service issue, privacy risk, or policy concern	Route sensitive incidents before publishing
Respond	Thank, clarify, or move resolution to a private channel	Do not expose customer or staff records
Learn	Group themes and record operational corrections	Measure process coverage, not a forced star target

1. Define who receives a review request

Write the eligibility rule before choosing the message. A practical rule might be: send one request after a completed appointment, delivered order, closed support case, finished job, or paid visit when the customer has not already been asked for that transaction. Exclude cancelled, fraudulent, duplicate, test, employee, supplier, and internal transactions.

Do not turn a satisfaction survey into a gate. Sending the public review link only to people who select a high satisfaction score is selective solicitation. Google Maps policy says merchants must not discourage negative reviews or selectively solicit positive reviews. Offer the same public review path to all customers who meet the neutral eligibility rule.

Eligible when:
- a real customer interaction is complete
- the business can identify the branch or service internally
- no review request was sent for the same transaction

Not eligible when:
- the interaction was cancelled, duplicated, fraudulent, or internal
- the person is an employee, contractor, supplier, family member, or competitor
- consent or channel rules do not allow the follow-up message

2. Create the official review link and QR code

Google now provides a direct review link and QR code inside Business Profile. On a computer, open the profile, select Read reviews, then Get more reviews. Copy the link or save the QR code. Google documents receipts, thank-you emails, the end of a chat, and an in-store display as possible placements. The QR code is currently generated in a computer browser, not on mobile.

Use the link that belongs to the exact location. Test it while signed out or in a private browser window, confirm that it opens the intended profile, and store the approved link where staff cannot accidentally substitute a Maps search or a different branch. For several locations, keep one row per profile with its own owner and link, then connect that inventory to the wider multi-location local SEO operating model.

Never offer a discount, free item, loyalty point, competition entry, or other benefit for posting, changing, or removing a review. Google treats incentivized reviews as fake engagement and can remove the content or restrict the Business Profile.

3. Ask neutrally after the service is complete

The request should identify the business, connect to the genuine interaction, make honest feedback optional, and contain one direct link. Do not ask for five stars, mention a desired rating, require the review while the customer is still at the counter, or ask them to name a staff member. Google's policy specifically disallows pressure, requested content, and staff review quotas.

Email or message template

Thank you for choosing [Business] for [service]. If you would like to share your honest experience, you can leave a Google review here: [official review link]. Feedback is optional, and we read it to improve the service.

Receipt or printed card

How was your experience with [Business]? Share an honest Google review using this QR code. Feedback is optional.

A private support channel can appear beside the review link, but it should not replace the link for dissatisfied customers. For example: "For help with an unresolved order, contact support@example.com." Both routes remain visible to everyone.

4. Keep a minimal request log

The log prevents duplicate requests and shows whether the process runs consistently. It does not need the text of every customer conversation. Use an internal transaction reference rather than copying sensitive personal data into a new sheet.

completed_at
location
service_category
internal_reference
eligible: yes / no
request_sent_at
request_channel
request_owner
duplicate_check
follow_up_needed: yes / no
retention_delete_after

Do not try to match every public reviewer to a customer record for attribution. Track request volume and resulting public review volume at an aggregate level. Link an individual review to a private case only when service recovery, fraud, safety, or another legitimate operational purpose requires it.

For Philippine businesses, the National Privacy Commission's implementing rules require transparency, legitimate purpose, proportionality, appropriate safeguards, and retention only as long as necessary. Define why each field exists, who can access it, and when the row is deleted. A permanent marketing database is not the default purpose of a review request log.

5. Monitor with native alerts and an owned schedule

Google Business Profile can notify users about customer activity, including new reviews and photos. In the profile, open More, Notifications, then configure customer-activity alerts. Notifications are a signal, not the entire control. The queue owner should also open Read reviews on a defined schedule so a missed email does not become a missed complaint.

A workable starting rhythm is a quick check every business day and a weekly reconciliation of new reviews, replies, open service cases, and policy reports. Use a faster check for businesses where a complaint may involve health, safety, travel, regulated service, or a time-sensitive booking.

Give each person their own Google Account. Google supports Business Profile owners and managers so the primary owner does not need to share a password. Managers can handle daily profile work and replies, while owners retain user-management and removal controls. Review the access guide before adding an agency or contractor.

6. Assign the review before answering

Review type	Owner	Next action
Specific praise	Queue owner	Thank the reviewer without copying a generic sales pitch
Neutral comment or question	Queue owner or service lead	Answer the useful point and correct any public business information
Recognizable service failure	Service lead	Investigate, publish a privacy-safe acknowledgment, and open a private case
Privacy, safety, legal, or extortion concern	Designated escalation owner	Preserve evidence and pause the public reply until the risk is classified
Possible Google policy violation	Profile owner	Compare the exact content with policy before reporting it

Set internal service targets based on operational risk, not public promises. For example, acknowledge an ordinary new review within two business days, investigate a service complaint by the next business day, and escalate a privacy or safety issue immediately. The target is a management choice, not a Google ranking factor.

7. Use response patterns, not identical scripts

Positive review: thank the person and refer briefly to the service when safe. Avoid keyword stuffing, promotional offers, or revealing what they bought if the review does not already make it public.

Thank you for sharing your experience. We are glad the team could help, and we appreciate you taking the time to leave feedback.

Neutral review: acknowledge the useful observation and explain the next improvement or clarification.

Thank you for the specific feedback about the wait. We are reviewing the handoff between booking and arrival so the timing is clearer.

Negative review: do not improvise from a short template library. Classify the incident, protect personal data, and use the full negative review response workflow.

Google reviews business replies before publication. When approved, the reply appears publicly as the business and the reviewer receives a notification. Replies can take time to appear, so record the submission before publishing a duplicate.

8. Turn themes into operational corrections

Once a month, group reviews into a small stable taxonomy such as wait time, communication, billing, product quality, cleanliness, availability, scheduling, staff helpfulness, and expectation setting. Separate praise from problems, then count recurring themes by location or service without treating one loud review as a statistically complete survey.

For each repeated issue, record the evidence, owner, corrective action, due date, and validation method. A response closes the public communication. A process change closes the operational loop.

Theme: appointment wait time
Evidence period: July 2026
Reviews mentioning theme: 4
Locations affected: 1
Operational check: booking intervals vs actual service duration
Owner: clinic coordinator
Change: add a 10-minute buffer after long appointments
Validate: compare August wait-time mentions and front-desk log
Decision: keep / revise / revert

Measure the process without manipulating the rating

Request coverage: eligible completed interactions that received one request.
Duplicate rate: transactions or customers incorrectly asked twice.
Review volume: new public reviews by week or month, shown separately from requests.
Response coverage: reviews with a published business reply.
Response time: median time from review detection to published reply.
Open recovery cases: unresolved complaints with an accountable owner.
Theme recurrence: repeated operational issues by service or location.
Corrections validated: completed changes with evidence of whether they helped.

Keep rating and total review count in the report because customers see them, but do not turn a five-star target into pressure on staff or customers. Google policy prohibits quotas that require staff to solicit a certain number of reviews and prohibits attempts to influence the rating or review content.

When software or automation becomes useful

Stay with the native setup when one location has modest volume, one person owns the queue, and review requests can be triggered from an existing receipt or thank-you message. Add a shared tool or automation when any of these become true:

completed services originate in several booking, POS, CRM, or support systems;
duplicate suppression cannot be handled reliably by the existing system;
several branches need location-specific links and owners;
privacy or safety keywords need an escalation path before a draft is approved;
the team needs one audit trail across requests, replies, cases, and corrections;
manual monthly theme reporting takes more time than the resulting decisions justify.

Automation may prepare a request after a verified completion event, deduplicate it, select the correct branch link, and create an internal task when a review needs attention. Keep human approval for sensitive public replies. Do not use automation to generate fake reviews, identify only happy customers, publish unverified claims, or pressure staff toward rating targets.

What not to do

Do not review-gate. A satisfaction score must not decide who receives the Google link.
Do not buy, trade, or reward reviews. Discounts, gifts, free services, and contest entries are incentives.
Do not ask for five stars or named wording. Ask for an honest experience without influencing the rating or text.
Do not set staff review quotas. Measure whether the approved process runs, not how many reviews one employee extracts.
Do not share the primary owner's password. Add named owners or managers and remove access when responsibilities change.
Do not copy customer records into an unlimited spreadsheet. Keep only the fields, access, and retention the process needs.
Do not report every negative review. Policy reporting is for policy violations, not ordinary disagreement.
Do not auto-publish sensitive replies. Privacy, safety, legal, and extortion cases need human classification.

Verification checklist

The official review link opens the correct profile and location.
The same neutral eligibility rule covers positive and negative experiences.
No request offers an incentive, desired rating, required wording, or staff quota.
Customer-activity notifications reach the queue owner and backup.
Each profile user has an individual Google Account and appropriate role.
The request log has a declared purpose, minimal fields, restricted access, and deletion date.
Negative, privacy-sensitive, and policy cases have separate escalation paths.
Monthly review identifies recurring themes, owners, corrections, and validation.

Review management is not the same as maximizing a score. The useful system gives every eligible customer a fair opportunity to speak, protects private information, and turns feedback into accountable changes. Pair it with the broader local SEO baseline and use the local SEO tools guide only when native profile management no longer covers the job.

Sources checked

Google review-link, request, reply, notification, access, fake-engagement, and Business Profile restriction guidance, plus Philippine data privacy principles, were verified against official sources on August 6, 2026.

The Benefits of Security and Governance in the Cloud

Fri, 14 Aug 2026 08:44:28 +0000

Cloud providers offer built-in security capabilities that help organizations protect their applications and infrastructure. Depending on the cloud service model you choose, the level of security management changes.

For example, with Infrastructure as a Service (IaaS), the cloud provider secures the physical infrastructure, while you are responsible for managing the operating system, software, and security updates. In Platform as a Service (PaaS) and Software as a Service (SaaS), the cloud provider handles more of these maintenance tasks, reducing the operational burden on customers.

Cloud providers also offer protection against common threats such as Distributed Denial of Service (DDoS) attacks, helping applications remain available even during large-scale attacks.

Cloud Governance

Cloud governance is the process of managing cloud resources so they comply with organizational policies and regulatory requirements. Cloud platforms provide built-in tools that make governance easier throughout the lifecycle of your resources.

Resource Templates

Templates allow organizations to deploy resources using predefined configurations. This ensures that every deployment follows the same technical standards and reduces the chances of configuration errors.

Compliance Auditing

Cloud platforms continuously monitor deployed resources to check whether they meet your organization's compliance requirements. If a resource doesn't comply with established policies, auditing tools can identify the issue and suggest remediation steps.

Automatic Updates

Many cloud services automatically apply software patches and platform updates. Keeping systems up to date improves both security and governance while reducing the administrative effort required to maintain infrastructure.

Why Governance Matters

Establishing governance early helps organizations maintain a secure, compliant, and well-managed cloud environment as it grows. By using templates, compliance checks, and automated updates, teams can ensure resources remain consistent and aligned with organizational standards.

Conclusion

Security and governance are foundational pillars of a well-run cloud environment. Cloud providers shoulder a significant portion of security responsibilities — from protecting physical infrastructure to defending against DDoS attacks — but the extent of that coverage depends on the service model you adopt (IaaS, PaaS, or SaaS).

Cloud governance tools such as resource templates, compliance auditing, and automatic updates give organizations the controls they need to enforce consistent policies, reduce human error, and stay aligned with regulatory requirements — all without heavy manual overhead.

The key takeaway is simple: start governance early. Organizations that establish clear policies and leverage built-in cloud tooling from day one are far better positioned to scale securely and confidently as their infrastructure grows.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star git-lrc on GitHub

Stop Implementing Authentication Inside Containers on Kubernetes

Sat, 25 Jul 2026 10:00:00 +0000

You have ten microservices running in Kubernetes. Each one validates JWTs, checks scopes, maintains sessions, and implements its own RBAC rules. One team uses jsonwebtoken v8, another uses a custom Go library, a third rolled their own HMAC check because “it was simple.” They all accept alg: none. Three accept RS256 and HS256 simultaneously.

This is not a security posture. This is a distributed security liability — and Kubernetes makes the problem worse, because the cluster creates an illusion of isolation that encourages teams to treat each Pod as a security boundary it was never designed to be.

The pattern of embedding authentication and authorization logic inside individual containers is one of the most pervasive anti-patterns in Kubernetes-based microservices. It feels like ownership and simplicity. It is, in practice, inconsistency at scale — and the blast radius of a single misconfiguration is your entire service portfolio.

Kubernetes provides the primitives to fix this at the infrastructure layer: Ingress controllers, the Gateway API, service mesh sidecars, admission webhooks, and workload identity via SPIFFE. None of these require a line of auth code inside your application containers.

This article explains why the anti-pattern exists, what’s wrong with it technically, and what the correct Kubernetes-native alternatives are — with concrete implementation guidance and references to the standards and incidents that validate the argument.

The Anti-Pattern: What It Looks Like

In-Application JWT Validation

Every service imports an auth library and validates tokens independently:

# Pattern seen in thousands of microservices
from jose import jwt

def authenticate(token: str):
    payload = jwt.decode(token, SECRET_KEY, algorithms=["HS256"])
    return payload["sub"]

Variations include:

Algorithm confusion: accepting both HS256 and RS256, or letting the token header drive verification behavior instead of pinning acceptable algorithms server-side. This is a distinct JWT implementation failure class, documented extensively by PortSwigger on JWT attacks and RFC 8725
alg: none bypass: libraries that accept unsigned tokens when alg is set to none. This is a documented attack vector in Auth0’s JWT security analysis
Missing exp / iss / aud validation: trusting a valid signature without checking whether the token is expired, for the right audience, or from the right issuer
Key confusion attacks: accepting a public RS256 key as an HS256 symmetric secret

Session State in Every Service

When services maintain session state directly, they duplicate logic that has no business being duplicated — cookie validation, refresh token flows, PKCE verification — and each implementation diverges over time.

RBAC Reimplemented Per Service

Authorization rules (“can this user access this resource?”) end up embedded in service logic, mixed with business logic, tested inconsistently, and impossible to audit across the portfolio.

Why This Is a Structural Problem

1. The Vulnerability Surface Scales With Your Service Count

Each new microservice is a new JWT validation surface. A single incorrect library configuration — an unvalidated alg, a missing aud check — is an authentication bypass affecting that entire service. With ten services, you have ten potential misconfigurations. With a hundred services, the probability that at least one is misconfigured approaches certainty.

The OWASP Kubernetes Security Cheat Sheet and OWASP Microservices Security Cheat Sheet both identify in-service auth as a primary attack surface in microservices environments. NIST SP 800-204 and its companion NIST SP 800-204A on DevSecOps make the same argument: security controls belong at infrastructure boundaries, not inside application code.

2. Maintenance Cost Is Multiplicative

When a JWT vulnerability is disclosed — and they are disclosed regularly — you update one library in one service. Then another. Then you discover service C is pinned to an old version because it has a transitive dependency conflict. Meanwhile the vulnerability is exploitable in production.

The CNCF Cloud Native Security Whitepaper frames this directly: security controls implemented redundantly across services create maintenance overhead that teams cannot sustain, leading to version drift and policy divergence.

3. Centralized Policy Is Impossible to Enforce

When policy is in code — even well-factored library code — it cannot be changed atomically across services. A policy update requires a coordinated deployment across every affected service. In practice, services deploy on different schedules, managed by different teams, with different testing cycles. The result is that at any given moment, some fraction of your services are running different authorization rules.

This is the core argument in Google’s BeyondCorp model and the Zero Trust Architecture guidance from NIST SP 800-207: authentication and authorization decisions should be made by a centralized, auditable policy enforcement point — not distributed across workloads.

4. Secrets Distribution Is a Problem You Don’t Need

If every service validates JWTs, every service needs the signing key (for symmetric algorithms) or the public key (for asymmetric). Distributing and rotating signing keys across a fleet of microservices is an operational burden with meaningful blast radius: a leaked symmetric key compromises every service holding it.

The CNCF SPIFFE/SPIRE project was built specifically to solve this class of problem: workload identity should be cryptographically attested, not rely on secrets distributed to application code.

The Real-World Incidents

The `alg: none` Class

In 2015, critical vulnerabilities in JWT libraries from Auth0 affecting Python, PHP, Node.js, Ruby, Java, and .NET allowed attackers to forge tokens by setting alg: none. The signature was not verified. The vulnerability was present in applications that had copied JWT validation code from tutorials or used unpatched libraries — exactly the pattern that in-service auth produces at scale.

Java’s Psychic Signatures (CVE-2022-21449)

CVE-2022-21449 affected ECDSA signature verification in Oracle Java SE and GraalVM, including java.security.Signature paths used by higher-level libraries. The bug allowed certain malformed ECDSA signatures to verify when they should not. JWT validation was in scope only when the deployment used an affected Java runtime and ECDSA-signed tokens, for example ES256. A gateway would help only if verification happened on a patched or unaffected runtime at the gateway instead of inside every Java service.

CVE-2023-2728 (Kubernetes Mountable Secrets Bypass)

CVE-2023-2728 was not an ImagePolicyWebhook outage behavior. It was a Kubernetes API server issue where users could use ephemeral containers to bypass the mountable secrets policy enforced by the ServiceAccount admission plugin. Clusters were affected only when the ServiceAccount admission plugin, the kubernetes.io/enforce-mountable-secrets annotation, and ephemeral containers were used together. The adjacent ImagePolicyWebhook issue was CVE-2023-2727, also involving ephemeral containers, but it is a separate CVE.

The Uber API Gateway Evolution

Uber’s engineering blog describes its API gateway as a centralized layer for routing, protocol conversion, rate limiting, load shedding, header propagation, security auditing, and user access blocking. That supports the architectural point here: high-volume platforms move cross-cutting controls into shared infrastructure. The public source does not prove that Uber migrated specifically from per-service authentication to gateway authentication, so that stronger claim should not be made.

Netflix Zuul

Netflix’s Zuul is an L7 gateway for dynamic routing, monitoring, resiliency, security, and related edge concerns. Netflix’s own Zuul posts list authentication among common edge-service uses, but they do not frame Zuul primarily as a case study in eliminating per-service auth. Treat it as evidence that authentication is a natural edge concern at scale, not as proof of a specific migration story.

The Alternatives

Use these as complementary controls, not as a single replacement for all authentication and authorization logic:

Alternative	When to use it	What it solves	Principal trade-off
API Gateway / Edge Auth	External API clients, public ingress, partner integrations, mixed auth mechanisms at the boundary	Central JWT/API-key/OAuth2 validation, rate limiting, request shaping, and identity header propagation before traffic reaches services	Does not secure east-west service calls by itself; trusted headers require strict network boundaries
Service Mesh mTLS	Service-to-service traffic inside the cluster, especially across teams or sensitive domains	Workload identity, automatic mTLS, peer authentication, and proxy-level authorization policy	Adds data-plane/control-plane complexity and operational coupling to sidecars or ambient mesh components
OAuth2 Proxy	Browser-facing internal apps that need OIDC login, redirects, cookies, and session handling	Delegates login/session management to a reverse proxy and forwards authenticated identity headers	Best for HTTP/browser flows; not a general machine-to-machine authorization system
OPA	Complex, auditable, frequently changing authorization rules	Separates policy decisions from application releases and can run as sidecar, service, ext_authz backend, or admission control via Gatekeeper	Policy/data distribution and failure behavior must be designed deliberately
SPIFFE/SPIRE	Multi-cluster, multi-cloud, or meshless environments that need portable workload identity	Issues short-lived workload identities without application-managed shared secrets	Provides identity, not business authorization; needs registration and attestation lifecycle management

Option 1: API Gateway (Edge Auth)

An API Gateway sits at the perimeter and handles authentication before a request reaches any downstream service. Services receive pre-validated identity in a trusted header.

What it does: – Validates JWTs, API keys, OAuth2 tokens – Enforces rate limiting per identity – Strips and re-adds Authorization headers as needed – Routes to upstream services with verified identity headers

When to use it: – North-south traffic (external clients → cluster) – Mixed authentication mechanisms (JWT + API key + mTLS) at the Ingress layer – Teams that want to centralize auth policy without rolling out a full service mesh

Tools:

Gravitee.io API Gateway can be deployed on Kubernetes via its Helm chart and integrates with the Kubernetes Gateway API:

helm repo add graviteeio https://helm.gravitee.io
helm install gravitee-apim graviteeio/apim \
  --namespace gravitee \
  --create-namespace \
  --set gateway.replicaCount=2 \
  --set gateway.ingress.enabled=true \
  --set gateway.ingress.hosts[0]=api.example.com

Once deployed, authentication policies are declared on the ApiV4 CRD — no application code involved:

apiVersion: gravitee.io/v1alpha1
kind: ApiV4
metadata:
  name: payment-api
  namespace: gravitee
spec:
  name: "Payment API"
  type: PROXY
  listeners:
    - type: HTTP
      paths:
        - path: /v1/payments
      entrypoints:
        - type: http-proxy
  endpointGroups:
    - name: default
      type: http-proxy
      endpoints:
        - name: upstream
          type: http-proxy
          configuration:
            target: http://payment-service.production.svc.cluster.local:8080
  flows:
    - name: JWT validation
      enabled: true
      request:
        - policy: jwt
          enabled: true
          configuration:
            signature: RSA_RS256
            publicKeyResolver: JWKS_URL
            jwksUrl: https://idp.example.com/.well-known/jwks.json
            checkTokenRevocation: true
            requiredClaims:
              - name: aud
                value: payment-api
        - policy: rate-limit
          enabled: true
          configuration:
            rate:
              limit: 100
              periodTime: 1
              periodTimeUnit: MINUTES

Gravitee’s Kubernetes operator reconciles ApiV4 resources against the gateway, making API policy a first-class GitOps object — versioned, reviewed, and deployed the same way as any other Kubernetes manifest.

Other Kubernetes-native options: Emissary-Ingress (formerly Ambassador) with its AuthService CRD; Traefik with ForwardAuth middleware on IngressRoute resources.

Limitations: API Gateways handle north-south traffic. They don’t address east-west (service-to-service) authentication inside the cluster.

Option 2: Service Mesh (East-West mTLS + Auth)

A service mesh provides mutual TLS between every service pair and enforces authorization policy at the sidecar proxy, without any application code changes.

What it does: – Automatic mTLS between all service-to-service calls – Workload identity via X.509 certificates (SPIFFE SVIDs) – Fine-grained AuthorizationPolicy at the Envoy sidecar – JWT validation at the proxy, not the application

Istio Implementation:

Istio uses Envoy’s ext_authz filter and native RequestAuthentication + AuthorizationPolicy CRDs:

<pre class="wp-block-c

You Don't Own Your Phone. You Don't Own Your Data. You Barely Own Your Opinions.

Fri, 24 Jul 2026 21:33:29 +0000

Fair warning before the disclaimers even start: this one's a little long, a little uncomfortable, and not really written for someone who's going to bounce after the first two paragraphs. If you're still here by the end, you'll know things about your own phone that most people never bother to check.

A disclaimer before we start, because apparently that's how it works now: this is one person's opinion, built on public facts and the collective paranoia of people who still bother reading terms of service. I'm not trying to cancel Google — please, Google, I'm a competent engineer, hire me, I'm kidding, I'm not kidding. I just think somebody should say the quiet part out loud before saying it becomes a compliance violation.

A bigger, more boring disclaimer, because this one actually matters: everything below is built on real, checkable sources — court verdicts, regulator fines, academic research, and independent audit tools like Exodus Privacy. Where a specific claim couldn't be independently verified, I've labeled it explicitly as a theory or an unverified report, not a fact, and I'd rather under-claim than dress up a rumor as a courtroom finding. I also touch on identity-verification laws and proposals from a few different countries — Vietnam, the EU, Russia — purely as a technical and factual comparison of what each is doing and when. That's not a scorecard, and it's not me passing judgment on any government, political system, or policy choice. I'm not qualified to rule on sovereign lawmaking and I'm not trying to. This is a breakdown of mechanisms, not a verdict on the people who built them.

The myth everyone gets wrong (so let's kill it properly)

Let's start with the thing you think you know: "my phone is listening to me." You said "air fryer" out loud once and an ad for an air fryer showed up. Spooky, right?

It's not spooky. It's worse.

Every major platform — Meta, Google, Apple — has said on record, repeatedly, under oath in Meta's case, that they don't use your microphone to target ads. Independent security researchers have tested this claim for years, tearing apart thousands of apps looking for secret always-on listening, and they keep finding basically nothing. No hidden audio pipeline running in the background of TikTok. No microphone spyware baked into Instagram.

Why? Because they don't need it. They already know you searched for kitchen gadgets three times last week, follow four cooking accounts, paused two seconds longer on a fryer ad last month, and that your friend with identical shopping habits just bought one. That's not surveillance through a microphone. That's a statistical ghost of you, built from years of clicks and dwell time, predicting your next move before you've made it. Ad tech doesn't need your voice. It has something better.

That said — the myth isn't entirely fantasy. A marketing outfit branded "Active Listening" got dragged in front of the FTC for claiming it could target ads via smart-device microphones in real time; the "service" turned out to be repackaged data-broker email lists sold at a markup, but the pitch decks named Google as a partner. Apple paid $95 million in a class-action settlement over Siri recordings potentially reaching third parties. Amazon is currently defending a federal class action in Seattle over Alexa recordings allegedly retained and used to train its AI models.

So no, your phone probably isn't listening to your dinner plans. The industry built entirely around not needing to listen is more unsettling, because there's no toggle for "please stop knowing me."

The receipts, because "trust me" isn't a source

If this sounds like tinfoil-hat energy, here's what regulators and juries have actually done about it in the last few years — not allegations, verdicts and settled fact:

Meta / Cambridge Analytica. A UK firm harvested the data of roughly 87 million Facebook users through a single quiz app, built psychological profiles from it, and sold political targeting off the back of it. The FTC fined Meta $5 billion — still one of the largest privacy penalties ever issued against a single company.
Meta / Flo period-tracking app. In August 2025, a federal jury found Meta liable under a 1967 California wiretapping law for secretly collecting menstrual and pregnancy data from the Flo app — cycle dates, whether users were trying to conceive — through an embedded software kit, then using it for ad targeting. The jury needed three hours to decide Meta had eavesdropped without consent. Damages could run into the billions once the full class is counted.
Google / "Web & App Activity." In September 2025, a San Francisco jury ordered Google to pay $425.7 million after finding it kept collecting data from about 98 million users across an eight-year stretch — even after those users had explicitly flipped the privacy switch meant to stop it.
Amazon / Alexa Voice ID. A federal judge in Chicago certified a class of roughly 1.18 million Illinois Alexa users in November 2025, over allegations that Amazon built biometric "voiceprints" from their voices without the written consent Illinois law requires.
Meta and Yandex / the localhost trick. In 2025, researchers caught Meta's Facebook and Instagram apps — and Yandex's apps, reportedly since 2017 — quietly listening on local network ports on Android phones. Any website with a Meta Pixel or Yandex Metrica tracker could use this to silently hand your anonymous browsing session to the app sitting on your phone and stitch it to your actual identity. It worked straight through incognito mode, cookie clearing, and ad-ID resets — the three things privacy-conscious people are told will protect them. Meta paused it within days of the research going public, calling it a "miscommunication" about Google's policies.
GDPR, cumulatively. European regulators have now handed out more than €7 billion in fines since 2018, including a €1.2 billion penalty against Meta for unlawful US data transfers and €530 million against TikTok for sending EU user data to China. Enforcement isn't slowing down — more fines have hit small and mid-sized companies in the last three years than in GDPR's entire first five.

None of this required a conspiracy theory. It required a courtroom, a jury, and people willing to read the fine print out loud.

VK: the eastern giant nobody in the West is watching

Everything above is Western Big Tech getting dragged into courtrooms, mostly because Western courtrooms exist for that purpose and Western journalists chase that beat. But swap hemispheres and you find a mirror image: VKontakte (VK), the dominant social network across Russia and much of the CIS, running the same playbook with a different flag on it.

Independent app-auditing tools like Exodus Privacy — which do static analysis on Android APKs to catalogue embedded tracking SDKs and requested permissions rather than take a developer's word for it — put VK's official Android app at 16 separate tracker SDKs and 99 requested permissions in its most recent scanned build (full report here — go look yourself, don't take my word for it). The tracker list alone reads like a cross-section of the entire ad industry: Google AdMob and Firebase Analytics, Yandex Ad, Huawei's HMS Core (which bundles location, advertising, and analytics in one package), plus ad-mediation networks like ironSource, Mintegral, and Unity3d Ads, alongside VK's own first-party identification SDK. The permissions list goes well past what a messaging-and-newsfeed app needs to function: precise GPS location, reading your call log, reading and writing your contacts and calendar (including a permission that explicitly lets the app "send email to guests without owners' knowledge" when it modifies calendar events), reading your phone number and device identity, recording audio, using the camera, and reading fitness data like step count and calories burned. Not all 99 are sinister on their own — plenty are mundane plumbing every app needs — but stacked together with 16 separate third-party trackers quietly reporting home, it's a genuinely large surface area for a platform whose stated job is "let people message their friends." Worth being precise about what VK actually is here, because it matters for how you read the rest of this: VK isn't just a private company that happens to be popular in Russia, it's a platform with formal ties to the Russian state and legal obligations to cooperate with its authorities on request, and unlike Meta or WhatsApp, VK's messages carry no end-to-end encryption at all — meaning that data, once collected, isn't just sitting in a corporate server somewhere abstract, it's structurally reachable by a government. That's a documented, publicly reported fact about how the platform is built and regulated, not a political opinion about Russia, and I'd say the exact same thing about any platform, in any country, built the same way. So if you're weighing which regional giant to worry about, the honest answer is: don't pick a side. East and West both built the same machine — they just answer to different governments when the machine gets audited.

A theory worth reading, not a verified fact

While we're here — a claim that's been floating around tech circles that I want to flag as a claim, not smuggle in as fact: reports have circulated alleging that in 2026, Meta ran an internal program collecting employee activity — keystrokes, screen content, even messages — from company laptops, ostensibly to train AI systems, and that some of those records ended up visible to a far larger internal audience than intended, triggering an employee petition. I haven't been able to independently verify the specifics — the numbers attached to it move depending on which forum you read — so take it exactly as advertised: an interesting, plausible-sounding story making the rounds, not a courtroom fact like the ones above. If true, it's the same surveillance logic Big Tech applies to its users, just pointed inward at the people building the tools. If it's exaggerated, it's still a useful thought experiment: what happens when the company that profiles you for a living starts applying the same instincts to its own staff?

The data doesn't have to be sold to end up in the wrong hands

Right now, while you're reading this sentence, a screenshot of somebody's desktop is sitting on a server they never explicitly agreed to. Somewhere, a password nobody's changed in five years is sitting in a database that already leaked once. Statistically, given how many billions of records are already circulating, the odds that none of it is yours are getting worse every year, not better.

Here's the part that ties everything above together, and it's arguably the most important one: none of this requires a company to be evil on purpose. Every dataset described in this post — location history, voiceprints, screenshots, browsing profiles, passport scans — sits somewhere on a server. And servers get breached. Constantly. At a scale that's honestly hard to hold in your head.

2025 alone produced the largest credential leak ever recorded: roughly 16 billion login records — usernames, passwords, session tokens — pulled together from infostealer malware infections across services including Apple, Google, Facebook, and Telegram, surfacing on criminal marketplaces in June 2025. Separately, a data broker called National Public Data lost roughly 2.9 billion records covering an estimated 170 million people — full names, Social Security numbers, decades of address history (IBM's writeup of the incident is worth a read) — and that dataset kept circulating on dark web markets throughout 2025, more than a year after the original breach. Qantas got hit in 2025 too: attackers social-engineered their way into a third-party customer service platform in June, and after the airline refused to pay a ransom, dumped roughly 5.7 million customer records — names, emails, birth dates, frequent-flyer numbers — onto the dark web that October (Qantas's own public breach timeline confirms it). None of these companies wanted this to happen. It happened anyway, because a large enough pile of valuable data is, by definition, a target worth attacking.

And this isn't hypothetical for the platform we just spent a whole section on. VK has been breached, leaked, or scraped repeatedly across more than a decade: around 100 million account credentials — plaintext passwords included — were stolen and put up for sale on the dark web for the price of a fast-food meal back in 2016 (Have I Been Pwned has the full record); over 32 million scraped and API-pulled records, including data from supposedly private and closed profiles, surfaced in a 2022 leak; more than 390 million user records were dumped on a hacking forum in September 2024 (Cybernews covered it in detail); and as recently as February 2026, researchers found malicious Chrome extensions had hijacked over half a million VK accounts to spread malware and manipulate security tokens. Whatever VK collects doesn't just sit in a vault under VK's control forever — history shows it eventually ends up copy-pasted onto a forum where anyone with a few dollars in cryptocurrency can buy it. And once your name, phone number, location history, or password is sitting in a criminal marketplace, it isn't used to sell you sneakers anymore. It's used for account takeovers, SIM-swap fraud, blackmail, and identity theft — by people with considerably worse intentions than an ad network.

This is the actual argument for minimizing what gets collected in the first place, and it has nothing to do with distrusting any single company's intentions. It's just math: the less data exists about you in any one place, the less there is to steal when — not if — that place eventually gets broken into.

Windows would like to remember everything you've ever looked at

Microsoft shipped a feature that screenshots your desktop every few seconds and uses on-device AI to let you search your own life like a browser history. It's called Recall. The first version stored everything in a folder, unencrypted, extractable by a two-minute script researchers named — I am not making this up — "TotalRecall." After the backlash, Microsoft rebuilt it: encrypted, tied to Windows Hello, wrapped in a hardware-isolated enclave, off by default.

Great. Except security researchers have gone back in more than once and found new ways to reach the stored data anyway — most recently in early 2026. The pattern repeats: Microsoft hardens it, someone breaks it again, Microsoft patches it. The core problem was never really the encryption implementation. A running photographic log of everything you've ever typed or clicked is an extraordinarily attractive target no matter how good the lock is. A vault is still a vault worth robbing.

Plot twist: your "no-logs" VPN might have a footnote

Quick detour, because you're probably thinking "fine, I'll just get a VPN." Good instinct. Bad ending, sometimes.

I actually did this — emailed a mid-market paid VPN provider (Russian-jurisdiction, "no-logs" is literally in their marketing) with one clean question: do you store IP addresses and connection timestamps, and can you confirm no-logs in writing?

Their first reply: "We don't store or share client data with third parties." Clean. Confident. Case closed, right?

So I sent back their own privacy policy. Turns out their own terms define "processing" — using the exact wording from Russia's data protection law — as including collection, storage, and retention. And their own clauses say IP addresses and login timestamps get "processed." And a separate clause says processing happens on Russian territory. And another says data gets handed over if Russian law requires it.

Their second reply, paraphrased because their actual answer ran three defensive paragraphs: "technically it's only in RAM, only for the session, destroyed after you disconnect, and we're legally required to use that wording from the law, we can't change it."

Here's the part that matters and takes five seconds to understand: RAM is still storage. If your IP and timestamp exist anywhere a system can read them — disk or memory, doesn't matter — while your session is active, and that system sits inside a jurisdiction that can legally compel a live extraction, then "no-logs" was never really a technical guarantee. It was a marketing sentence sitting on top of a legal document that says the opposite in its own words.

I'm not naming the company, and I'm not telling you every VPN does this — plenty of providers publish real, independently audited no-logs reports and mean it. I'm telling you to do exactly what I did: ask the pointed question, then actually read the policy they hand you afterward, especially the definitions section. If "processing" quietly includes "storage" and the company sits under a jurisdiction with broad data-access laws, you haven't bought anonymity. You've bought a very polite waiting room.

Your phone is a rental, and you're the tenant who can't change the locks

You paid full price — sometimes over a thousand dollars — for a device you don't fully control. Bootloaders are locked. Bloatware is preinstalled and often can't be removed without voiding a warranty or tripping hardware checks that quietly break your banking app. The manufacturer decides what OS you're allowed to run, which repair shops count as "authorized," and how long the device gets security updates before it's engineered into obsolescence. You're the owner on paper and the guest in practice. The device is the hook; your data and your next upgrade purchase are the actual product.

The passport paradox

Here's where it gets genuinely interesting, and where I want to be careful, because this isn't a story with a villain — it's a story with a trade-off, and different countries are answering it completely differently at the same time.

Vietnam just did something almost nobody expected: starting January 1, 2026, its new Law on Personal Data Protection bans social platforms operating there — local or foreign — from requiring users to upload a photo of their ID card or passport just to verify an account. It also bans platforms from reading private messages or recording calls without consent. That's a real, enforceable ban with serious financial penalties attached. At the same time, Vietnam is separately rolling out rules requiring accounts to be linked to a verified local phone number or national ID number for anti-fraud purposes. So the picture isn't "more privacy" or "less privacy" — it's "no more handing platforms a photo of your actual passport," while identity still gets tied to you through a different, arguably less exploitable channel. Genuinely nuanced, genuinely worth watching.

Europe took the opposite visual approach for an entirely different reason. In early 2026, a new EU-based platform called W Social launched as a deliberate alternative to X, built specifically to be bot-resistant: to post, you verify your identity by scanning a passport or national ID card and a selfie through a separate companion app. The pitch is that the scan and match happen on your own device, and the company says it doesn't store the document itself centrally — you can also browse anonymously with reduced functionality if you skip verification entirely. Whether "we process it locally and don't store it" survives contact with millions of users and a few years of pressure is exactly the kind of promise worth revisiting in twelve months. It's the same core question as always — how much of "prove you're human" ends up as "here's your permanent identity record" — just answered by a private company instead of a government this time.

Russia's telecom regulator, Roskomnadzor, put forward a proposal back in 2021 that would have required new social media and messenger users to submit passport details, home address, and contact information, cross-checked against the state's Gosuslugi portal, as part of consent-management infrastructure for personal data. To be clear about where this actually stands: it was a draft proposal, not a law that took effect, and it hasn't been implemented as originally floated. I'm not going to pretend to have a verdict on whether that specific idea was good policy or bad policy — plenty of countries debate identity requirements for online services, for all kinds of legitimate and illegitimate reasons, and that's a conversation about tradeoffs, not a referendum on any one government. What's actually worth sitting with is the pattern above it: state ID portals, private "trust and safety" platforms, and social networks are all reaching for the same solution — link your face and your legal identity to your online activity — at almost exactly the same moment, for reasons ranging from fighting bots to fighting fraud to fighting disinformation. Some of those reasons are good. The output is still the same: your passport, your biometrics, and your posting history increasingly living in the same place.

And that's the actual tension, stripped of any single country's politics: identity verification is a genuinely reasonable answer to bots, fraud, and disinformation. It is also, structurally, a new centralized target. So next time something asks you to prove you're human, the interesting question isn't whether they have a good reason today. It's what happens to that proof on the day their reason stops mattering. You don't need me to answer that one for you — but here's a hint: databases don't retire. They just wait.

So what do we actually do about it?

Here's the part where I disappoint anyone expecting a manifesto: I'm not telling you to throw your phone in a lake and move to a cabin. I use the apps too. I like fast information and dumb memes as much as anyone. This isn't a call to abandon convenience — it's a call to stop pretending the convenience is free.

You can also do nothing. Close the tab, keep scrolling, change nothing — that's a real option and nobody's coming to stop you. Or you can spend the next two minutes doing this, right now, before you close this tab:

Open your phone's settings.
Pick one app you use daily — VK, Instagram, whatever's already open in another tab.
Turn off its access to your microphone, contacts, and location if the app doesn't strictly need them to function.

Done. That's it. You just did more for your own privacy in two minutes than most people will do all year. Not a revolution. Not a lake cabin. Just one small door you closed that used to be wide open.

A few more things that cost five minutes each and nothing beyond that:

Turn off ad personalization in your Google, Meta, and TikTok settings. It doesn't stop collection, but it shrinks the targeting surface.
Use a real password manager and 2FA. Most "hacks" are just reused passwords from a breach nobody rotated.
Read one privacy policy this year. Just one. You'll never look at "free" the same way again.
If you're a developer, push back inside your own stack. You decide what telemetry ships in the product you build. That's more power than most people in this conversation will ever have.

Here's the uncomfortable part, though. You probably think of yourself as a person — opinions, habits, a face. Every system described in this post thinks of you as a row. A data point with a name attached purely for convenience. You don't have to agree with that framing. But once you've actually sat with it for a second, it's a little harder to just close the tab and pretend you didn't read this.

Now, about why you actually read this whole thing

Since we're being honest with each other: this post used a specific structure on purpose, and it's worth naming, because recognizing the pattern here is the same skill that protects you from the next one.

It opened with a myth I could confidently debunk — trust, earned fast.
It escalated with dollar figures and jury verdicts — specificity that reads as credibility, whether or not you checked it yourself (you should).
It made the threat feel like it's happening to you, right now, not to some abstract "user out there."
It gave you a way out that felt like a choice, not an order — do nothing, or spend two minutes. Either way, you decided.
It handed you one small, immediate action instead of a vague suggestion, because five minutes of resistance beats another lecture you'll forget by tomorrow.
It pulled you into an unresolved debate — the passport paradox — with no clean villain, because open loops keep people reading.
It's closing on a moment of "wait, is this article doing the thing it just described" — a little vertigo is what makes people screenshot something and send it to a friend.

None of that makes the verified parts above less true. The Flo verdict happened. The $425 million happened. The localhost tracking happened. I flagged the one item I couldn't fully verify as exactly that — a claim, not a fact — because the moment you stop distinguishing the two, you've become exactly the kind of unreliable narrator this whole post is warning you about. But the fact that true information can be arranged to hook you exactly like an ad can is, honestly, the whole point of this post. The mechanism doesn't care whether the payload is a sneaker ad or a privacy manifesto. Worth remembering the next time something online makes you feel like you have to keep scrolling — including this one.

One last note, plainly stated: everything in this piece is either a matter of public court record, a regulatory decision, published academic research, or the output of an open, independently verifiable auditing tool that anyone can run themselves — sources are linked or named where they exist specifically so you don't have to trust me. The one exception is flagged inline as an unverified claim, not presented as fact. This is a personal, informational write-up, not legal advice, not a security audit of any product named here, and not a statement about the character, intentions, or legitimacy of any company or government mentioned. Company names, product names, and country names appear because they're the ones with public data behind them — not because I'm accusing anyone of anything beyond what's already a matter of public record. If something here is factually wrong, I'd rather be corrected than be right — go check the sources, that's what they're there for.

What is the shared responsibility model in cloud computing?

Tue, 14 Jul 2026 22:00:08 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star git-lrc on GitHub to help more developers discover the project. Do give it a try and share your feedback for improving the product.
One of the biggest misconceptions about cloud computing is that once you move to the cloud, the cloud provider takes care of everything.

While cloud providers manage a significant portion of the infrastructure, customers still have important security and operational responsibilities.

This concept is known as the Shared Responsibility Model.

The division of responsibilities changes depending on whether you're running workloads On-Premises, using Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS).

Let's break it down.

On-Premises: You Manage Everything

When your applications run in your own data center, every component is your responsibility.

Customer Responsibilities

Data
Devices
Accounts
Identity and Access Management (IAM)
Applications
Network controls
Operating systems
Infrastructure
Physical servers
Physical networking
Datacenter facilities

What the Provider Manages

Nothing.

Since everything is hosted on your own infrastructure, there is no cloud provider to share operational responsibilities.

Infrastructure as a Service (IaaS)

Examples include virtual machines such as Amazon EC2, Azure Virtual Machines, and Google Compute Engine.

With IaaS, the provider supplies the infrastructure while you manage everything running on top of it.

Customer Responsibilities

Data
Devices
Accounts
Identity and Access Management
Applications
Network controls (firewalls, security groups, etc.)
Operating systems

Cloud Provider Responsibilities

Physical infrastructure
Physical hosts
Physical networking
Datacenters

IaaS gives you the most flexibility among cloud service models, but it also requires the most operational management.

Platform as a Service (PaaS)

Examples include Azure App Service, AWS Elastic Beanstalk, Google App Engine, and Heroku.

PaaS removes the burden of managing operating systems and infrastructure, allowing developers to focus on building applications.

Customer Responsibilities

Data
Devices
Accounts

Shared Responsibilities

Identity and Access Management
Applications
Network controls

Cloud Provider Responsibilities

Operating systems
Infrastructure
Physical hosts
Physical networking
Datacenters

PaaS strikes a balance between flexibility and convenience, making it an excellent choice for many modern application deployments.

Software as a Service (SaaS)

Examples include Microsoft 365, Salesforce, Google Workspace, and Dropbox.

With SaaS, the provider delivers a complete application that users simply access through a web browser or client application.

Customer Responsibilities

Data
Devices
Accounts

Shared Responsibilities

Identity and Access Management

Cloud Provider Responsibilities

Applications
Network controls
Operating systems
Infrastructure
Physical hosts
Physical networking
Datacenters

SaaS offers the lowest operational overhead because the provider manages nearly the entire technology stack.

Shared Responsibility at a Glance

Service Model	Customer Manages	Shared	Provider Manages
On-Premises	Everything	None	Nothing
IaaS	OS, applications, IAM, network controls, data	None	Infrastructure & physical hardware
PaaS	Data, devices, accounts	IAM, applications, network controls	OS, infrastructure & physical hardware
SaaS	Data, devices, accounts	IAM	Applications, OS, infrastructure & physical hardware

Conclusion

No matter which cloud service model you choose, your data, devices, and user accounts remain your responsibility.

As you move from On-Premises → IaaS → PaaS → SaaS, the cloud provider takes on progressively more responsibility, reducing your operational burden. However, protecting your users, managing access, and securing your data always remain critical tasks.

Understanding where your responsibilities begin—and where the provider's responsibilities end—is essential for building secure, reliable cloud solutions.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star git-lrc on GitHub

Understanding Systemd.exec—Part 3: Disabling the COPY TO PROGRAM feature in Postgres.

Sat, 02 May 2026 23:50:26 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

In previous article we discussed how this feature may be attacker entry point to server.

So, now let's implment custom systemd configuration to disable this feature.

Securing Postgres with systemd.exec options

I found only way for now to disable this feature is to create custom systemd configuration.

Let's identify the postgres version.

gk@jarvis:~$ psql --version
psql (PostgreSQL) 16.13 (Ubuntu 16.13-0ubuntu0.24.04.1)
gk@jarvis:~$

Based on postgress version we can use different postgresctl command.

We can add custom systemd configuration for each postgres version.

So, How attacker mostly use copy function to get inside the server?

Here, how simple funtion can be used to get inside the server.

using shell
using curl
using wget
using bash

Still goes on Many ways you can use copy function to get inside the server.

Based on my analysis and continuous retry on disable feature on by one.
I got working configureation which will disconnect from postgres access.

Available options In systemd.exec For postgres

Let's analyze these options and try to disable them using systemd.exec options.

we can use

TemporaryFileSystem
This will create read only filesystem for specific directory.
We can make sure they don't have direct access to system utilities.
BindReadOnlyPaths
Re-expose only what's needed by postgres. Example postgres binaries, libraries etc.
ProtectSystem
Block /usr, /boot, /etc from write access
ProtectHome
This will block access to /home directory.
PrivateTmp
This will create temporary /tmp and /var/tmp directories for the service.
ReadWritePaths
This is main thing as we disabled all the feature postgress data should be writable to some directory. Which can be:

/var/lib/postgresql
/var/run/postgresql
/var/log/postgresql

Just have a look based on your version.

NoNewPrivileges
If a service process tries to gain more privileges, the kernel will deny it.
This can prevent attackers from escalating privileges even if they compromise the service.
RestrictNamespaces
This option can be used to restrict the namespaces that a service can access.
This is mainly for if they try to break out from the container/VM.
RestrictAddressFamilies
This option can be used to restrict the address families that a service can access.
ProtectKernelTunables
This option can be used to prevent a service from modifying kernel tunables.
ProtectKernelModules
This option can be used to prevent a service from loading kernel modules.
ProtectControlGroups
This will prevent the service from accessing the cgroups of other processes.
ProtectProc
This will prevent the service from accessing the process information of other processes.
UMask
This will set the umask of the service.
CapabilityBoundingSet
This will set the capability bounding set of the service.
AmbientCapabilities
This will set the ambient capabilities of the service.
SystemCallFilter
This will set the system call filter of the service.
SystemCallErrorNumber
This will set the system call error number of the service.
MemoryDenyWriteExecute
This will set the memory deny write execute of the service.
LockPersonality
This will lock the personality of the service.
RestrictSUIDSGID
This will prevent the service from using SUID and SGID bits.

Configuring Systemd for postgres

So, Now let's create custom configuration for postgres.

mkdir -p /etc/systemd/system/postgresql@16-main.service.d
sudo vim /etc/systemd/system/postgresql@16-main.service.d/override.conf

Now add these options to the file.

[Service]
# ── BYPASS pg_ctlcluster (it's a perl script — breaks TemporaryFileSystem) ──
ExecStart=
ExecStart=/usr/lib/postgresql/16/bin/postgres \
  -D /var/lib/postgresql/16/main \
  -c config_file=/etc/postgresql/16/main/postgresql.conf \
  -c hba_file=/etc/postgresql/16/main/pg_hba.conf \
  -c ident_file=/etc/postgresql/16/main/pg_ident.conf \
  -c external_pid_file=/run/postgresql/16-main.pid
ExecStop=
ExecStop=/usr/lib/postgresql/16/bin/pg_ctl stop -D /var/lib/postgresql/16/main -m fast
ExecReload=
ExecReload=/usr/lib/postgresql/16/bin/pg_ctl reload -D /var/lib/postgresql/16/main

User=postgres
Group=postgres

# ── BLANK ALL EXECUTABLE DIRS ────────────────────────
TemporaryFileSystem=/usr/bin:ro
TemporaryFileSystem=/bin:ro
TemporaryFileSystem=/usr/sbin:ro
TemporaryFileSystem=/sbin:ro
TemporaryFileSystem=/usr/local/bin:ro
TemporaryFileSystem=/usr/local/sbin:ro
TemporaryFileSystem=/snap:ro
TemporaryFileSystem=/opt:ro

# ── RE-EXPOSE ONLY WHAT'S NEEDED ─────────────────────
BindReadOnlyPaths=/usr/lib/postgresql/16/bin/postgres:/usr/lib/postgresql/16/bin/postgres
BindReadOnlyPaths=/usr/lib/postgresql/16/bin/pg_ctl:/usr/lib/postgresql/16/bin/pg_ctl
BindReadOnlyPaths=/usr/lib/postgresql/16/lib:/usr/lib/postgresql/16/lib
BindReadOnlyPaths=/lib/x86_64-linux-gnu:/lib/x86_64-linux-gnu
BindReadOnlyPaths=/usr/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu

# ── FILESYSTEM ───────────────────────────────────────
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
ReadWritePaths=/var/lib/postgresql /var/run/postgresql /var/log/postgresql

# ── BEHAVIORAL ───────────────────────────────────────
NoNewPrivileges=yes
RestrictNamespaces=yes
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
ProtectProc=invisible
UMask=0027
CapabilityBoundingSet=
AmbientCapabilities=

# ── SYSCALL FILTER ────────────────────────────────────
SystemCallFilter=@system-service @file-system @network-io
SystemCallErrorNumber=EPERM
MemoryDenyWriteExecute=yes
LockPersonality=yes
RestrictSUIDSGID=yes

Note: There may many issues setting up this configuration. So, make sure this only done on Staging env and test it thoroughly.

sudo systemctl daemon-reload
sudo systemctl restart postgresql@16-main.service

So, If you check status

sudo systemctl status postgresql@16-main.service

You will see all the options are enabled.

If there any issues just check logs

sudo journalctl -u postgresql@16-main.service -f -n 50

Reverting Configuration

Finaly to remove this configuration just run

First we have remove the conf file.

And restart daemon and restart service.

sudo rm /etc/systemd/system/postgresql@16-main.service.d/override.conf
sudo systemctl daemon-reload
sudo systemctl restart postgresql@16-main.service

Conclusion

This is the only way I found to disable copy function in postgres. This may be experimental but still worth for adding this config if you want disable postgress copy to program function.

Reference Man Page Systemd : https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html

Discussion in HN: https://news.ycombinator.com/item?id=37164115
PostgreSQL Discussion : https://www.postgresql.org/message-id/CAKFQuwZZ0zAMpp2KjBr5bUS7RvBqouD2Kqne6YtbgZn%3DnzL1xA%40mail.gmail.com

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

Understanding Systemd.exec - Part 1: How to Secure Applications Running in Systemd?

Sat, 02 May 2026 02:27:26 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on GitHub. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

If you are running applications with systemd and want to restrict how they interact with Linux kernel features (like filesystem, processes, and capabilities), you can use the systemd.exec configuration options.

In this article I will be going to explain how to use these options to secure your application.

What are systemd.exec options?

Systemd.exec options are a set of configuration options that are used to configure how a systemd service interacts with the Linux kernel.

This feature is mainly used to provide security for the applications running in systemd.

Why we need this option in first place?

Hardening services (Postgres, Nginx, workers, etc) which are mostly open to the internet
Reducing blast radius after compromise
Lightweight (no container overhead)

How is this different from Docker?

Works on a single process/service.
Applies restrictions on top of the host.
Uses kernel features (namespaces, cgroups, capabilities)
Shares the same root filesystem (by default)
No packaging, no images

What is the real usecase?

Let's take an example of service.

/etc/systemd/system/myapp.service

Inside this file, we can control:

Where the app runs
Which user it runs as
What it can access
How secure / isolated it is
What resources it can use

Most common options

Run a service as non-root (security)

Set User= Group= to a non-privileged user (e.g. postgres, www-data).
This will prevent the service from running as root, which can lead to security vulnerabilities.

For example:

[Service]
User=postgres
Group=postgres

Restrict filesystem access

Set ProtectSystem= ProtectHome= ReadWritePaths= ReadOnlyPaths= to control filesystem access.
This will make service only read/ write specifed directory.

Example:

[Service]
ProtectSystem=strict
ProtectHome=yes
ReadWritePaths=/var/lib/postgresql
ReadOnlyPaths=/var/lib/postgresql/16/bin

Isolate runtime environment (like lightweight container)

Set PrivateTmp=yes NoNewPrivileges=yes to isolate runtime environment.
As there is no container like docker this will be running in the host but under private tmp and no new privileges.

Example:

[Service]
PrivateTmp=yes
NoNewPrivileges=yes

Limit resources (avoid abuse / crashes)

Set CPUQuota= MemoryMax= MemoryHigh= MemoryLimit= MemoryAccounting= to limit resources.
If we want specific service to use only limited resources, we can use these options.

Example:

[Service]
CPUQuota=50%
MemoryMax=512M

Provide controlled writable directories Set ReadWritePaths= ReadOnlyPaths= to control filesystem access. This will make service only read/ write specifed directory.

Example:

[Service]
ReadWritePaths=/var/lib/postgresql
ReadOnlyPaths=/var/lib/postgresql/16/bin

Drop dangerous privileges

Set CapabilityBoundingSet= to drop dangerous privileges.
This will make service only able to run commands with specific privileges.

Example:

[Service]
CapabilityBoundingSet=CAP_NET_BIND_SERVICE

Run temporary / ephemeral services Set RuntimeDirectory= StateDirectory= LogsDirectory= to run temporary / ephemeral services. This will run the service in a temporary / ephemeral directory.

Example:

[Service]
RuntimeDirectory=myapp
StateDirectory=myapp
LogsDirectory=myapp

Limit process / thread count Set TasksMax= to limit process / thread count. This will make service only able to run with specific process / thread count.

Example:

[Service]
TasksMax=100

Restrict access to system calls Set SystemCallFilter= SystemCallArchitectures= to restrict access to system calls. This will make service only able to use specific system calls.

Example:

[Service]
SystemCallFilter=open,read,write,close
SystemCallArchitectures=amd64

Security measures for Docker Engine Set Delegate=yes to run Docker Engine with specific privileges. This will make Docker Engine only able to run with specific privileges.

Example:

[Service]
Delegate=yes

Conclusion

We could able to use systemd.exec options to secure application running in systemd.

But Until we integrate with real application and test these options, we can't be sure about the security.

In the next article we will see how service react with integrations of these options.

Reference Man Page Systemd : https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

How OTP Authentication Streamlines Service Delivery for HVAC Companies

Mon, 20 Apr 2026 11:50:01 +0000

Photo courtesy of Freepik

As HVAC businesses grow and expand into new areas, they need to find ways to manage more customers and staff. One of the biggest challenges is making sure that service delivery and payments are secure and efficient, especially when working with new customers in different locations.

A simple solution to this problem is one-time password (OTP) authentication. OTP authentication makes it easy to verify customers and payments quickly and securely that helps HVAC companies improve their overall service process.

In this article, we’ll explore how OTP authentication helps HVAC companies streamline service delivery by improving customer verification, appointment scheduling, payments, and service completion, all while keeping things secure and simple.

1. Simplified Customer Verification

OTP (One-Time Password) authentication replaces traditional login methods by sending a unique code to a customer’s phone or email, which they use to verify their identity instantly. For HVAC service appointments, customers can receive an OTP to confirm their identity, eliminating the need for passwords or lengthy forms.

2. Enhanced Service Appointment Scheduling

OTP authentication helps verify and confirm HVAC service appointments, ensuring both the customer and service provider are clear on the timing and details. When a customer schedules a service, they receive an OTP confirmation, which confirms the appointment and reduces the risk of any misunderstandings.

This process ensures that appointments are tracked accurately, leading to fewer scheduling errors and improved customer satisfaction. As you invest in marketing or HVAC SEO services to generate more leads, it’s essential to have a reliable system for booking appointments to avoid confusion and ensure a smooth customer experience.

3. Improved Payment and Transaction Security

OTP authentication adds a layer of security to payments and transactions, protecting HVAC businesses and their customers. When a payment is made, an OTP is sent to the customer's phone or email to verify the transaction, ensuring it’s legitimate. This reduces the risk of fraud or unauthorized charges.

Additionally, OTP can prevent fraud from service vendors by confirming that payments are processed correctly and only authorized transactions are completed. This enhances security, builds trust, and ensures a reliable payment system for HVAC companies and their clients.

4. Streamlined Service Completion Confirmation

OTP authentication simplifies service completion verification. After an HVAC service is completed, an OTP is sent to the customer’s phone or email to confirm the work was done. This ensures clear communication and prevents any disputes about the service, making the process quicker and more reliable.

5. Seamless Communication for Customer Support

OTP authentication streamlines customer support by ensuring secure communication. When a customer contacts the HVAC company for assistance, they can verify their identity through OTP, confirming they are the account holder. This prevents unauthorized access to support channels and ensures that customer queries are handled by the right team.

Endnote

OTP authentication enhances security and simplifies key processes for HVAC businesses. By streamlining customer verification, service confirmations, and payments, it improves efficiency and builds trust.

Adopting OTP ensures smoother operations, better customer experience, and strengthens the company's competitive edge in a growing market. It’s a valuable investment for long-term success.

Architectural Design for a Ride App such as OLA, UBER, RAPIDO

Sat, 18 Apr 2026 11:02:58 +0000

A ride-sharing app needs to match riders with drivers in real-time, track locations, process payments, and handle all of this at scale across a city. This is my take on how to architect such a system using microservices — and where a simpler approach might actually be better.

Why microservices for a ride app

The core challenge is that different parts of the system have very different scaling requirements:

Geo-location tracking needs to handle thousands of location updates per second with sub-100ms latency
Payment processing needs strong consistency and idempotency but handles far fewer requests
Notifications are fire-and-forget at high volume
User authentication is read-heavy with infrequent writes

A monolith would force all of these to scale together. Microservices let you scale the geo-location service to 50 instances while keeping the payment service at 3.

That said, if you're building an MVP or serving a single city, start with a monolith. Uber itself started as a monolith. Extract services only when specific components hit scaling bottlenecks.

Service boundaries

Each service owns its data and exposes a clear API:

User Service — Manages rider and driver accounts, authentication (OAuth2/OIDC), profile data, and session management. Backed by PostgreSQL.

Ride Service — The core coordination service. Handles ride requests, matches riders with nearby available drivers, tracks ride state (requested → matched → in-progress → completed), and calculates fares. Backed by PostgreSQL with Redis for active ride state.

Driver Service — Manages driver availability, approval status, vehicle information, and earnings. Tracks which drivers are online, idle, or on a ride. Backed by PostgreSQL.

Geo-Location Service — The highest-throughput service. Receives GPS coordinates from driver and rider apps every 3–5 seconds, stores them in a spatial index (Redis with geospatial commands or a dedicated service like H3), and answers proximity queries ("find the 5 nearest available drivers within 3km"). This is the service that needs the most aggressive scaling.

Payment Service — Integrates with payment gateways (Razorpay, Stripe). Processes charges after ride completion, handles refunds, and manages driver payouts. Must be idempotent — a network retry should never charge a rider twice.

Notification Service — Sends push notifications (ride matched, driver arriving, ride completed), SMS fallbacks, and email receipts. Consumes events from a message queue rather than being called directly.

How the services communicate

Not all communication should use the same pattern:

Pattern	Use case	Why
REST/HTTP	Client → API Gateway → Services	Simple request/response for CRUD operations
gRPC	Service-to-service (e.g., Ride Service → Geo-Location Service)	Low latency, typed contracts, streaming support
Message queue (Kafka/RabbitMQ)	Ride Service → Notification Service, Ride Service → Analytics	Async, decoupled, no backpressure on the producer

The API Gateway sits in front of all services and handles routing, rate limiting, and authentication token validation. Clients never talk directly to internal services.

A critical design decision: the Ride Service publishes a ride.completed event to Kafka. The Payment Service, Notification Service, and Analytics Service all consume this event independently. This means adding a new consumer (say, a driver-rating prompt) doesn't require changing the Ride Service at all.

Scaling and fault tolerance

Load balancing. An L7 load balancer (like AWS ALB or Envoy) distributes requests across service instances. The Geo-Location Service gets its own load balancer with sticky sessions disabled (since requests are stateless).

Auto-scaling. Kubernetes Horizontal Pod Autoscaler watches CPU and custom metrics (like queue depth for the Notification Service). The Geo-Location Service might scale from 10 pods at 2 AM to 80 pods at 6 PM during rush hour.

Circuit breakers. If the Payment Service is down, the Ride Service shouldn't hang waiting for it. A circuit breaker (e.g., via Istio or a library like resilience4j) fails fast after N consecutive errors and falls back to queuing the payment for later processing.

Health checks. Every service exposes /healthz (liveness) and /readyz (readiness) endpoints. Kubernetes restarts crashed pods automatically and stops routing traffic to pods that aren't ready.

Security considerations

Authentication: OAuth2 with JWTs for user-facing APIs. Service-to-service calls use mTLS within the Kubernetes cluster.
Data encryption: AES-256 at rest, TLS 1.3 in transit. Payment card data never touches your services — use the payment gateway's tokenization.
Rate limiting: Applied at the API Gateway level. Geo-location updates are rate-limited per device to prevent abuse.
Secrets management: HashiCorp Vault or AWS Secrets Manager. No secrets in environment variables or config files.

Deployment

Containerization: Each service is a Docker image with a multi-stage build (builder → runtime). Images are scanned for vulnerabilities in CI.
Orchestration: Kubernetes with namespaces per environment (dev, staging, prod). Services declare resource requests and limits.
CI/CD: GitHub Actions or GitLab CI runs tests, builds images, pushes to a container registry, and deploys via Helm charts or ArgoCD.
Observability: Prometheus + Grafana for metrics, Jaeger for distributed tracing, Fluentd/Loki for centralized logs. Every service emits structured JSON logs with a correlation ID.

What I'd do differently at different scales

Scale	Approach
MVP (1 city, < 1K rides/day)	Monolith with a single PostgreSQL database. Extract the geo-location queries into a background worker if they slow down the main app.
Growth (5 cities, 10K rides/day)	Extract Geo-Location and Notification as separate services. Keep everything else in the monolith. Add Redis for caching.
Scale (50+ cities, 100K+ rides/day)	Full microservices as described above. Invest in Kafka for event-driven architecture, dedicated SRE team, and per-service databases.

The biggest mistake is building for the third row when you're at the first row. Start simple, measure, and extract when the pain is real.

Kubernetes HPA Best Practices: When CPU Works, Why Memory Almost Never Does

Mon, 13 Apr 2026 23:51:55 +0000

There is a configuration that appears in virtually every Kubernetes cluster: a HorizontalPodAutoscaler targeting 70% CPU utilization and 70% memory utilization. It looks reasonable. It follows the examples in the official documentation. And in many cases, it silently causes more harm than good.

The problems surface in predictable ways: workloads that do nothing get scaled up because their memory footprint is naturally high. Latency-sensitive APIs scale too slowly because the CPU spike is already over by the time new pods are ready. Batch jobs oscillate between scaling up and down during normal operation. And teams spend hours debugging autoscaling behavior that should have been straightforward.

This article is about understanding why the default HPA configuration fails, under which exact conditions memory-based HPA is appropriate (and when it is not), and what alternative metrics — custom metrics, event-driven triggers, and external signals — produce autoscaling behavior that actually matches workload demand.

How HPA Actually Decides to Scale

Before diagnosing the problems, it is worth understanding the mechanics precisely. HPA computes a desired replica count using this formula:

desiredReplicas = ceil(currentReplicas × (currentMetricValue / desiredMetricValue))

For a CPU target of 70%, with 2 replicas currently consuming an average of 140% of their CPU request, HPA computes ceil(2 × (140 / 70)) = 4 replicas. This is conceptually simple but has a critical dependency that most configurations ignore: the metric value is expressed relative to the resource request, not the resource limit.

This distinction is fundamental to understanding every failure mode that follows. If a container has a CPU request of 100m and a limit of 2000m, and it is currently consuming 80m, HPA sees 80% utilization — even though the container is using only 4% of its allowed ceiling. Set an HPA threshold of 70% on a container with a CPU request of 100m and any nontrivial workload will trigger scaling immediately.

The HPA controller polls metrics every 15 seconds by default (--horizontal-pod-autoscaler-sync-period). Scale-up happens quickly — within one to three polling cycles when the threshold is consistently exceeded. Scale-down is deliberately slow: by default the controller waits 5 minutes (--horizontal-pod-autoscaler-downscale-stabilization) before reducing replicas, to avoid thrashing. This asymmetry matters when debugging oscillation.

CPU-Based HPA: When It Works and When It Doesn’t

CPU is a compressible resource. When a container hits its CPU limit, the kernel throttles it — the process slows down but does not crash or get evicted. This property makes CPU a reasonable proxy for load in many, but not all, scenarios.

Where CPU HPA Works Well

Stateless request-processing workloads are the sweet spot for CPU-based HPA. If your service does CPU-bound work per request — REST APIs performing data transformation, compute-heavy business logic, image processing — then CPU utilization correlates strongly with request volume. More requests means more CPU consumed, which means HPA adds replicas, which distributes the load.

The key prerequisites for CPU HPA to work correctly are:

Accurate CPU requests. Set requests to the actual sustained consumption of the workload under normal load, not a low placeholder. Use VPA in recommendation mode or historical Prometheus data to right-size requests before enabling HPA.
Reasonable request-to-limit ratio. A ratio of 1:4 or less keeps HPA thresholds meaningful. A container with request 100m and limit 4000m makes percentage-based thresholds nearly useless.
CPU consumption that tracks user load linearly. If your service does CPU-heavy background work independent of incoming requests, CPU utilization will trigger scaling regardless of actual demand.

Where CPU HPA Fails

Latency-sensitive services with sharp traffic spikes. HPA reacts to average CPU utilization measured over the polling window. For a service that handles traffic bursts — a flash sale, a cron-triggered batch of API calls, a notification broadcast — by the time the HPA controller detects the spike, queues new pods, and those pods pass readiness checks, the burst may already be over. The result is replicas added after the damage is done, with the added cost of a scale-down cycle afterward.

I/O-bound workloads. A service that spends most of its time waiting on database queries, external API calls, or message queue reads will show low CPU utilization even under heavy load. HPA will not add replicas while the service is degraded — it sees idle CPUs while goroutines or threads are blocked waiting on I/O.

Workloads with cold-start costs. If a new replica takes 30-60 seconds to warm up (loading ML models, establishing connection pools, populating caches), scaling decisions need to happen earlier — before CPU peaks — not in reaction to it.

Memory-Based HPA: Why It Almost Always Breaks

Memory is an incompressible resource. Unlike CPU — which can be throttled without killing a process — when a container exhausts its memory limit, the OOM killer terminates it. This single property cascades into a set of fundamental problems with using memory as an HPA trigger.

The Core Problem: Memory Doesn’t Naturally Correlate With Load

For most well-architected services, memory consumption is relatively stable. A Go service allocates memory at startup for its runtime structures, connection pools, and caches — and then maintains roughly that footprint regardless of traffic. A JVM application allocates a heap at startup and uses garbage collection to manage it. In both cases, memory usage under 10 requests per second and under 10,000 requests per second may be nearly identical.

This means a memory-based HPA with a 70% threshold will either:

Never trigger, because the workload’s memory is stable and always below the threshold — rendering the HPA useless.
Always trigger, because the workload’s baseline memory consumption is naturally above the threshold — causing the workload to scale out permanently and never scale back in.

Neither outcome corresponds to actual scaling need.

The Request Misconfiguration Trap

This is the failure mode the user mentioned, and it is the most common cause of “my workload scales up for no reason.” Consider a Java service that needs 512Mi of heap to run normally. The team sets memory request to 256Mi — too conservative, either to save cost or because the initial estimate was wrong. The service immediately consumes 200% of its memory request just by being alive. An HPA with a 70% memory target will scale this workload to maximum replicas within minutes of deployment, and it will stay there forever.

The fix is never “adjust the HPA threshold.” The fix is right-sizing the memory request. But this reveals the deeper issue: memory-based HPA is extremely sensitive to the accuracy of your resource requests, and most teams do not have accurate requests — especially for newer workloads or after code changes that alter memory footprint.

JVM and Go Runtime Memory Behavior

JVM workloads are particularly problematic. By default, the JVM allocates heap up to a maximum (-Xmx) and then holds that memory — it does not release heap back to the OS aggressively, even after garbage collection. A JVM service that handles one request per hour will show nearly the same memory footprint as one handling thousands of requests per minute. Furthermore, the JVM’s garbage collector introduces memory spikes during collection cycles that are unrelated to load.

In containerized JVM environments, you also need to account for the container memory limit aware flag (-XX:+UseContainerSupport, enabled by default since JDK 11) which affects how the JVM calculates its heap ceiling relative to the container limit. Without proper tuning, the JVM may allocate a heap that fills 80-90% of the container’s memory limit — immediately triggering any memory-based HPA.

Go workloads behave differently but also poorly with memory HPA. Go’s garbage collector is designed to maintain low latency rather than minimal memory use. The runtime may hold memory above what is strictly needed, and the memory footprint can vary based on GC tuning parameters (GOGC, GOMEMLIMIT) in ways that are not correlated with incoming request load.

When Memory HPA Is Actually Appropriate

There are narrow cases where memory-based HPA makes sense:

Workloads where memory consumption genuinely tracks with load linearly. Some data processing pipelines, in-memory caches that grow with request volume, or streaming applications that buffer data proportionally to throughput. If you can demonstrate from metrics that memory and load have a strong linear correlation, memory HPA is defensible.
As a safety valve alongside CPU HPA. Using memory as a secondary metric (not primary) to protect against memory leaks or runaway allocations in a service that normally scales on CPU. In this case, set the memory threshold high — 85-90% — so it only triggers in genuine overconsumption scenarios.
Caching services where eviction is not desirable. If a service uses memory as a performance cache and you want to scale out before memory pressure causes cache eviction, memory utilization can be a useful trigger — provided requests are accurately sized.

Outside these specific cases, removing memory from your HPA spec and relying on the signals below will produce better behavior in virtually every scenario.

Right-Sizing Requests Before You Add HPA

No HPA strategy works correctly without accurate resource requests. Before adding any autoscaler — CPU, memory, or custom metrics — run your workload under representative load and measure actual consumption. The easiest way to do this is with VPA in recommendation mode:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-service-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-service
  updatePolicy:
    updateMode: "Off"   # Recommendation only — don't auto-apply

After 24-48 hours of traffic, check the VPA recommendations:

kubectl describe vpa my-service-vpa

The lowerBound, target, and upperBound values give you a data-driven baseline for setting requests. Set your requests at or near the VPA target value before configuring HPA. This single step eliminates the most common cause of HPA misbehavior.

Note that VPA and HPA cannot both manage the same resource metric simultaneously. If VPA is set to auto-update CPU or memory, and HPA is also scaling on those metrics, the two controllers will fight each other. The safe combination is: HPA on CPU/memory + VPA in recommendation-only mode, or HPA on custom metrics + VPA on CPU/memory in auto mode. See the Kubernetes VPA guide for the full details.

Better Signals: What to Scale On Instead

The fundamental shift is moving from resource consumption metrics (which describe the past) to demand metrics (which describe what the workload is being asked to do right now or will be asked to do in seconds).

Requests Per Second (RPS)

For HTTP services, requests per second per replica is usually the most accurate proxy for load. Unlike CPU, it measures demand directly — not a side-effect of demand. An HPA that maintains 500 RPS per replica will scale predictably as traffic grows, regardless of whether the service is CPU-bound, memory-bound, or I/O-bound.

RPS is available as a custom metric from your service mesh (Istio exposes it as istio_requests_total), from your ingress controller (NGINX exposes request rates via Prometheus), or from your application’s own Prometheus metrics. Configuring HPA on custom metrics requires the Prometheus Adapter or a compatible custom metrics API implementation.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-service
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "500"   # 500 RPS per replica

Queue Depth and Lag

For consumer workloads — services reading from Kafka, RabbitMQ, SQS, or any message queue — the right scaling signal is consumer lag: how many messages are waiting to be processed. A lag of zero means consumers are keeping up; a growing lag means you need more consumers.

CPU will not give you this signal reliably. A consumer blocked on a slow database write will show low CPU but growing lag. An idle consumer will show low CPU even if the queue contains millions of unprocessed messages. Scaling on lag directly solves both problems.

This is precisely the use case that KEDA was built for. KEDA’s Kafka scaler, for example, reads consumer group lag directly and scales replicas to maintain a configurable lag threshold — no custom metrics pipeline required.

Latency

P99 latency per replica is an excellent scaling signal for latency-sensitive services. If your SLO is a 200ms P99 response time and latency starts climbing toward 400ms, that is a direct signal that the service is overloaded — regardless of what CPU or memory shows.

Latency-based autoscaling requires custom metrics from your service mesh or APM tool, but the added complexity is often justified for user-facing APIs where latency directly impacts experience.

Scheduled and Predictive Scaling

For workloads with predictable traffic patterns — business-hours services, weekly batch jobs, end-of-month processing peaks — proactive scaling outperforms reactive scaling by definition. Rather than waiting for CPU to spike and then scrambling to add replicas, you pre-scale before the expected load increase.

KEDA’s Cron scaler enables this pattern declaratively, defining scale rules based on time windows rather than observed metrics.

HPA Configuration Best Practices

Always Set minReplicas ≥ 2 for Production

A minReplicas: 1 HPA means your service has a single point of failure during scale-in events. When HPA scales down to 1 replica and that pod is evicted for node maintenance, your service has zero available instances for the duration of the new pod’s startup time. For any production workload, set minReplicas: 2 as a baseline.

Tune Stabilization Windows

The default 5-minute scale-down stabilization window is too aggressive for many workloads. A service that processes jobs in 3-minute batches will show a predictable CPU trough between batches — HPA will attempt to scale down, only to scale back up when the next batch arrives. Increase the stabilization window to match your workload’s natural cycle:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-service
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 600   # 10 minutes
      policies:
      - type: Percent
        value: 25                        # Scale down max 25% of replicas at once
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0     # Scale up immediately
      policies:
      - type: Percent
        value: 100
        periodSeconds: 30

The behavior block (available in HPA v2, GA since Kubernetes 1.23) gives you independent control over scale-up and scale-down behavior. Aggressive scale-up with conservative scale-down is the right default for most production services.

API Gateway vs Service Mesh: Beyond the North–South/East–West Myth

Wed, 26 Nov 2025 14:38:07 +0000

There is a limit of some characters and I could not publish the page here for API Gateway vs Service Mesh.

Article Link: https://dev.to/rajkundalia/api-gateway-vs-service-mesh-beyond-the-north-southeast-west-myth-2mpg

Code Link: https://github.com/rajkundalia/api-gateway-service-mesh-sample

Coder Legion - Recent posts tagged service

How to Respond to Negative Google Reviews in the Philippines

Classify the review before choosing the response

1. Preserve the evidence and slow the response down

2. Investigate with the minimum necessary data

3. Write a short public response

Response templates for common cases

4. Decide whether to report the review

5. Move the resolution off the public thread

6. Close the internal action, not just the conversation

What not to do

Verify the response and follow-up

Sources checked

Google Review Management for Small Business

Use one policy-safe operating loop

1. Define who receives a review request

2. Create the official review link and QR code

3. Ask neutrally after the service is complete

4. Keep a minimal request log

5. Monitor with native alerts and an owned schedule

6. Assign the review before answering

7. Use response patterns, not identical scripts

8. Turn themes into operational corrections

Measure the process without manipulating the rating

When software or automation becomes useful

What not to do

Verification checklist

Sources checked

The Benefits of Security and Governance in the Cloud

Cloud Governance

Resource Templates

Compliance Auditing

Automatic Updates

Why Governance Matters

Conclusion

Stop Implementing Authentication Inside Containers on Kubernetes

The Anti-Pattern: What It Looks Like

In-Application JWT Validation

Session State in Every Service

RBAC Reimplemented Per Service

Why This Is a Structural Problem

1. The Vulnerability Surface Scales With Your Service Count

2. Maintenance Cost Is Multiplicative

3. Centralized Policy Is Impossible to Enforce

4. Secrets Distribution Is a Problem You Don’t Need

The Real-World Incidents

The alg: none Class

Java’s Psychic Signatures (CVE-2022-21449)

CVE-2023-2728 (Kubernetes Mountable Secrets Bypass)

The Uber API Gateway Evolution

Netflix Zuul

The Alternatives

Option 1: API Gateway (Edge Auth)

Option 2: Service Mesh (East-West mTLS + Auth)

You Don't Own Your Phone. You Don't Own Your Data. You Barely Own Your Opinions.

The myth everyone gets wrong (so let's kill it properly)

The receipts, because "trust me" isn't a source

VK: the eastern giant nobody in the West is watching

A theory worth reading, not a verified fact

The data doesn't have to be sold to end up in the wrong hands

Windows would like to remember everything you've ever looked at

Plot twist: your "no-logs" VPN might have a footnote

Your phone is a rental, and you're the tenant who can't change the locks

The passport paradox

So what do we actually do about it?

Now, about why you actually read this whole thing

What is the shared responsibility model in cloud computing?

On-Premises: You Manage Everything

Customer Responsibilities

What the Provider Manages

Infrastructure as a Service (IaaS)

Customer Responsibilities

Cloud Provider Responsibilities

Platform as a Service (PaaS)

Customer Responsibilities

Shared Responsibilities

Cloud Provider Responsibilities

Software as a Service (SaaS)

Customer Responsibilities

Shared Responsibilities

The `alg: none` Class