Adobe modifies hosts file to detect whether Creative Cloud is installed

Adobe’s Creative Cloud installer has been found silently adding an entry to the system hosts file so Adobe websites can detect whether the desktop apps are installed and adjust “open in app” behavior. Commenters are split between seeing this as a minor, clever UX hack and condemning it as user‑hostile system tampering that bypasses consent and undermines privacy and sandboxing norms. The incident sparks broader criticism of Adobe’s practices and renewed calls for operating systems to better constrain what installers can do to global configuration files.

Purpose of the hosts-file modification

  • Adobe adds an entry for a special subdomain in the system hosts file.
  • The main claimed purpose: let Adobe web pages reliably detect whether Creative Cloud / desktop apps are installed, so they can show “Open in Desktop” vs “Install” and similar UX.
  • Some commenters think this is a small but real UX optimization at scale; others argue it’s trivial and unnecessary.

User-hostility, privacy, and consent

  • Many see silently editing a global system config file as user-hostile, especially when used for browser-visible detection.
  • Critics argue Adobe does not need this signal; it already knows what you’ve installed when logged in, and shouldn’t track install status when you’re not.
  • Supporters counter that the technique doesn’t meaningfully add to Adobe’s tracking capabilities compared to cookies, IP, canvas fingerprinting, etc.
  • There is disagreement whether this is “insidious surveillance” or a benign, if ugly, implementation detail.

Security and exploit concerns

  • Some fear new attack surface and fingerprinting opportunities; others call it a “nothing burger” because exploiting it requires local admin or already-compromised infrastructure.
  • The endpoint reportedly only returns a valid image for Adobe origins, reducing casual cross-site probing, but people point out origin checks and CORS are imperfect.
  • Suggestions include locking /etc/hosts with immutable flags, or stricter OS-level protections, though this conflicts with typical Windows/macOS norms.

Technical and historical context

  • Several note that editing hosts used to be common before DNS; others reply that widespread automatic modification by third-party apps was never normal and conflicts with modern sandbox/container trends.
  • Some point out that many Windows apps already request admin, modify system-wide config, and use similar hacks (registry, localhost ports, etc.).

Broader reactions to Adobe and alternatives

  • The behavior reinforces existing perceptions of Adobe as anti-consumer or “malware-like.”
  • Some long-time users say this, plus pricing and forced AI tiers, is pushing them and their students toward FOSS or non-Adobe alternatives.
  • Others caution that, in many design and architecture workflows, Adobe remains a de facto standard and replacing it can cause compatibility headaches.