Apparently it's using a rooted background process installed at software installation time.

This whole practice needs to be exposed since it essentially gives any piece of software complete control over the machine simply because the user was supposedly asked to "temporarily" provide admin/root access to the installer in order to install some app.

But in addition to that, it also installed a rooted background process that essentially grants them access to read/write anything on the machine, forever.

Redditor thenickdude commented:

> I found that in my hosts file the other day too, and I investigated to find why they're doing it at all.

> They're using this to detect if you have Creative Cloud already installed when you visit on their website.

> When you visit https://www.adobe.com/home, they load this image using JavaScript: https://detect-ccd.creativecloud.adobe.com/cc.png

> If the DNS entry in your hosts file is present, your browser will therefore connect to their server, so they know you have Creative Cloud installed, otherwise the load fails, which they detect.

> They used to just hit http://localhost:<various ports>/cc.png which connected to your Creative Cloud app directly, but then Chrome started blocking Local Network Access, so they had to do this hosts file hack instead.

This is the kind of thing that erodes trust slowly. Most users will never notice, and that's exactly the point. Would be interesting to know if this is documented anywhere in Adobe's ToS or if it's purely undisclosed behavior.

The same Adobe that is squatting my /documents folder on my Mac ?

How is Adobe modifying a system file at all? Does Adobe run a background process with root privileges?

[dupe] https://news.ycombinator.com/item?id=47617463

Ddev does this too, to set up local domains when you’re offline. Asks for permission at least.

Sounds like a job for chattr +i, though who knows what will happen someday if a macOS installer script tries to modify it.

Well, Tailscale does this during install on Windows :-))

[dead]