Defender warns you this happened.

Can this not be blocked with file permissions? Or a symlink to a file in a ro folder?

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.

I wonder how this works on Windows, if any service overrides/resets it

To be fair, your analogy has one flaw:

> 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.

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.

I wonder how many Adobe users are aware of this sketchy behavior tho

They don't want to be too hard on piracy, its their new/young user on ramp method

My guess is most Adobe users have no idea there is a hosts file nor what it does.

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.

> 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."

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.

It's literally a 2 sentence article. Might as well have just tweeted "Adobe makes me mad"

It can power even more security issues too. This is absolutely horrendous.

> Reason is OK, the execution is controversial.

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?

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.

I’m wondering how this can be exploited.

> manually editing the hosts file was a mostly-obsolete practice by the time the first version of Windows shipped

This claim strikes me as obviously wrong.

> In which case, how else would you propose doing it?

- Registering an url handler?

- Asking the user?

> 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...

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.

> 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.

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.

> Would HN ever agree on a OS-level app-detection API for the browser? Never.

There already is one. It just asks the user whether it's okay before it tells the website, as you acknowledged: https://news.ycombinator.com/item?id=47664546

What you're arguing for is not good UX. It's lack of user privacy & control. You just think you're being hip or whatever for being blasé about it.

What a ridiculous conclusion.

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.