As a general principle, application developers should not have free rein to modify my system's configuration, and OS's should do their part to make it very difficult for developers. Installing your binaries into C:\Program Files\AppName or /usr/local/bin? Fine. Dumping crap all over C:\Windows or /usr or /boot or something? No way--the OS should make the developer obtain my consent to do these things. Sneakily modifying /etc/hosts to act against me? Get the hell outta here!
Oh well, as a teenager, blocking adobe servers in hosts file was how you got to "phone activation" and could generate a code. So I guess we're even, heh.
Most users won't care, especially if the Adobe installer warns them that a security warning might popup after installation. Besides, in practice, any malware editing the hosts file isn't going to get much because of HTTPS; one cannot simply redirect "google.com" traffic to their own IP without issue.
The hosts file is not sacred on Windows. Anyone who is administrator can just edit it. I've done it to add domain names to localhost.
For anyone hand-wringing over this, this used to be normal. The hosts file was invented a decade before DNS. The end user, or app, would edit their hosts file purposefully after downloading a master copy from the Stanford Research Institute which was occasionally updated.
> For anyone hand-wringing over this, this used to be normal.
People editing hosts files for other reasons was normal (a long time ago-- and it stopped being normal for valid reasons, as tech evolved and the shortcomings of that system were solved). A program automatically editing the hosts file and its website using that to detect information about the website visitor is not the same thing; that usage is novel and was never "normal."
In particular, manually editing the hosts file was a mostly-obsolete practice by the time the first version of Windows shipped, and certainly by the time Windows actually had a built-in networking stack. And it was always a red flag for a local app to mess with the hosts file.
Obsolete? My team has an onboard document that spells out lines that needed to be add to host file so they can access internal resources. These are machines directly bought/rented and maintained by the team, so we prefer to use host files instead of going through the company DNS, which is maintained by an entirely different team.
Whether it's run as root/administrator or not - you can disable this behavior by setting the immutable flag on /etc/hosts. No user, including root, can write to a file with the immutable flag set(although root could _remove_ the attribute and then write).
Oh helllll no. Let's imagine an analogy for Adobe leadership:
1. You hired a night janitor to clean and vacuum your executive offices.
2. That janitor secretly stops at every desk-phone to alter the settings of voicemail accounts.
3. After the change, any external caller can dial a certain sequence to get a message of "Yes, this office was serviced by Adobe Janitorial!"
What's your reaction when you discover it? Do you chuckle and say something like "boys will be boys"? No! You have a panic-call, Facilities revokes access, IT starts checking for other unauthorized surprises, HR looks into terminating contracts, and Legal advises whether you need to pursue data-breach notifications or lawsuits or criminal charges.
* Is it acceptable because they had some permission to touch objects in the rooms? No.
* Is it acceptable because the final effect is innocuous? No.
* Is it acceptable because the employment contract had some vague sentence about "enhancing office communication experiences"? No.
* Is it acceptable if they were just dumb instead of malicious? No.
No person that would blithely cross those lines can be trusted near your stuff, full-stop.
> 3. After the change, any external caller can dial a certain sequence to get a message of "Yes, this office was serviced by Adobe Janitorial!"
Theoretically, it's not "any external caller." Only the janitor's department calling in can dial that sequence and get "Yes, you serviced this office!" If anyone else tries to dial the extension, the desk-phone pretends it doesn't know what it means. (Because it seems Adobe's server serving the analytics image checks the request origin and only serves the image if the origin is Adobe's own website.)
The origin "security" doesn't excuse the complexity and the potential for both exploits and human-error breakage in the future.
> Only the janitor's department calling in can dial that sequence
Is this the case though? Cannot any website use the same trick Adobe does to check whether you have Creative Cloud installed? Like, the entries in /etc/hosts are not magically scoped to work just on Adobe's web, no?
They're doing this because the localhost shenanigans got blocked. This is pure internet requests, but the IP changes (or fails to resolve) based on what's in your hosts file.
Also a lot of recent features are AI related and rely on talking to Adobe servers, which would require a valid subscription. They're probably betting the AI features are valuable enough that local only pirated copies aren't a threat long term.
Looks like they got a wildcard certificate for *.creativecloud.adobe.com[0] so that the HTTPS connection works and so they don't have to publish DNS records for the "detect-ccd" subdomain to obtain a cert. Pretty neat setup, but also kinda hacky.
Honestly a pretty nifty way to detect if it's installed. I'm sure this can power a lot of nice features, like linking directly into adobe products if they're installed.
I don't know anything about Thom, but I've kind of grown to prefer the pissy opinionated tones of blog posts. I think impartiality is difficult or impossible for a lot of tasks, and I'd rather people lay out their opinions plainly than trying to pretend that what they're saying is "objective".
Also, I think writing only when you have things to criticize is a valid enough thing to do; what's the point of writing a glorified "I agree!" article?
I only ever blog when I have something that I think is unique to say, and as such a lot of the time my posts end up being kind of negative. I don't think I'm that negative of a person, I just don't see the point of flooding the internet with more echo-chambers.
> No, it's not a stupid reason. Reason is OK, the execution is controversial.
This is a muddled statement. It is a stupid reason to "execute" the act of silently modifying your host file.
If I murder somebody to keep them from stepping on my foot, and the judge says that it's a stupid reason to murder somebody, it's silly to say that the reason is "OK" because it hurts to have one's foot stepped on.
And even then, only controversial to nerds with opinions. Nothing else about it is controversial.
If anything, knowing whether the app is installed or not is kinda important? If you open a file shared with you in the browser, the option to "Open in Desktop" versus "Install Desktop App" actually works correctly?
You can't detect whether a URL handler worked correctly in a browser; otherwise Windows will appear with a "Select an app to open YOURPROTOCOLHERE://" which is completely nonsensical to the user.
As for option 2; ask them every time, or edit their hosts file. Easiest decision in the world: Edit their hosts file, every time, no question. The 1% of nerds who care, and oddly enough don't buy Adobe software, are completely meaningless to the 99% of customers who experience the decision positively.
Why does Adobe need to exfiltrate some information from my machine anyway? If I'm a customer, then they should know this when I sign into my account. They absolutely don't need this information if I'm visiting their website without logging in.
Modifying a global system file is something their software shouldn't be doing in the first place, but relying on this abuse to track me on their website is on another level of insidious behavior.
If you're worried about device fingerprinting, Adobe has far more reliable ways to do it already. Canvas fingerprinting, IP tracking, cookies. A hosts entry tells them almost nothing they couldn't get elsewhere, provides them with almost no entropy, and attributing insidious intent to what is most plausibly a UX feature is conspiratorial.
I'm not worried about this, since I don't use Adobe products. I'm just calling out what's clearly user hostile behavior. Considering the amount of hostility Adobe has exhibited towards its users over the years, I'm inclined to believe this is yet another example. Nothing conspiratorial about that. If anything, calling this a "UX feature" without any evidence either way is suspiciously dismissive.
> If anything, knowing whether the app is installed or not is kinda important? If you open a file shared with you in the browser, the option to "Open in Desktop" versus "Install Desktop App" actually works correctly?
This is not an approach any other app on any platform has historically used, and it doesn't seem sustainable if every app you install has to modify your hosts file to use a hack like this to detect whether it should handle files or not.
If you want the browser to be able to give the OS a file handler and have the OS present an option to install the app if it's not installed, that should be handled at the platform level, not on the website using a hack like this.
Why can a file not simply be downloaded with a page displayed showing a link to install the app and also instructions to open the file, trusting the user will know if they already have it installed? At best, you're talking about a very small UX optimization. Emphasis on the "kinda" in "kinda important."
> This is not an approach any other app on any platform has historically used, and it doesn't seem sustainable if every app you install has to modify your hosts file to use a hack like this to detect whether it should handle files or not.
How many apps are you installing that it becomes "unsustainable"? Host file entries are extremely cheap, and it's not like the app needs more than one. Of all the arguments against this, sustainability is a comically weak one. If anything, it's using less contested resources than the "hitting random ports on localhost" approach...
The "sustainable" comment wasn't about the hosts file ballooning to the point of causing performance problems. It was more about the engineering effort required for every program ever (or at least every commercial program that might want this sort of analytic) to have to parse and edit a text file on both installation and removal, without messing that important text file up.
Do you really not see scripted editing of shared system-wide text files as a step back compared to the general containerization that app development has moved towards? This sort of approach would be explicitly incompatible with sandboxes. Adobe can only get away with it because they're already very entrenched with their own app store on their users' machines.
> This is not an approach any other app on any platform has historically used, and it doesn't seem sustainable if every app you install has to modify your hosts file to use a hack like this to detect whether it should handle files or not.
Actually it's completely sustainable. DNS was invented a decade after hosts files. The idea of your host file being almost completely empty is a modern aberration from the days it used to be thousands of lines long.
Do I wish there was a better mechanism? Sure. Would HN ever agree on a OS-level app-detection API for the browser? Never.
> Why can a file not simply be downloaded with a page displayed showing a link to install the app and also instructions to open the file, trusting the user will know if they already have it installed? At best, you're talking about a very small UX optimization. Emphasis on the "kinda" in "kinda important."
A small UX decision, adding up to tens of millions of times per day, affecting 99.9% of people who don't give a darn - versus a matter of slight software engineering principles of "we just don't do it that way." Easiest decision ever.