> 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 clever in a way, but I wonder what the review process looks like on that team (I say that team because my experience at Adobe was that the company is very heterogeneous).
They’re still completely heterogeneous in my experience as someone who works with each of their teams. It’s like talking to completely different companies who have little idea what the others are doing.
Novel. A similar approach could be taken by other SaaS tools to comply with age verificaiton laws. Just write an entry to the client's hosts file that points to a subdomain corresponding to a particular birth year. Simple enough for legislative representatives to understand.
The underlying intent here (figure out if it's an existing customer of our locally installed apps when they visit our website) doesn't seem bad, but I certainly dislike both the hosts file and localhost detection options.
I dislike the intent too. A website should simply not be able to see which apps I've got installed. Imagine Facebook doing stuff like this in order to know what ads they should serve.
Yup. Just checked. Right now I have "com.adobe.acc.installer.v2" running as root on two threads. The other 3 background processes (at least those with adobe in the name) are under the user. The whole stack is using like 75mb ram at all times. You kill the process they restart. You delete the files from your launchd, open adobe software they come back.
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.
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 clever in a way, but I wonder what the review process looks like on that team (I say that team because my experience at Adobe was that the company is very heterogeneous).
They’re still completely heterogeneous in my experience as someone who works with each of their teams. It’s like talking to completely different companies who have little idea what the others are doing.
Novel. A similar approach could be taken by other SaaS tools to comply with age verificaiton laws. Just write an entry to the client's hosts file that points to a subdomain corresponding to a particular birth year. Simple enough for legislative representatives to understand.
/s
The underlying intent here (figure out if it's an existing customer of our locally installed apps when they visit our website) doesn't seem bad, but I certainly dislike both the hosts file and localhost detection options.
I'm curious if there's a "good" way to do this.
I dislike the intent too. A website should simply not be able to see which apps I've got installed. Imagine Facebook doing stuff like this in order to know what ads they should serve.
Fairly certain they already do, atleast on mobile.
Next they'll be installing a font like TeamViewer did... https://community.teamviewer.com/English/discussion/124507/s...
Just do it by asking users to log in. Am I missing something here ?
No that seems like the reasonable expectation to me too.
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?
Yup. Just checked. Right now I have "com.adobe.acc.installer.v2" running as root on two threads. The other 3 background processes (at least those with adobe in the name) are under the user. The whole stack is using like 75mb ram at all times. You kill the process they restart. You delete the files from your launchd, open adobe software they come back.
AGMServices it's optional but gets shoe horned at install time.
Even then, the installer itself has administrative access already, should they choose to do it then.
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.
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.
[dupe] https://news.ycombinator.com/item?id=47617463
[dead]