I have been an Adobe user since 1996. Starting with Photoshop 3. Then, using the rest of their programs since 1999.
Between this and the fact that they've just 1. Changed all the old accounts to "Adobe Creative Cloud Pro" 2. DOUBLED the monthly fee, now charging you for the AI features whether you want them or not, and 3. Removed any tiers that have full program access but no AI, I am walking away forever when my current month expires.
Not to mention, students now only get the old $19.99 membership for the first year.
I teach visualization and representation tools to architecture students. I had always taught them Adobe products before. Now I can't in good faith sign them up to have their expertise tied to using this program stack forever. So tomorrow I am giving them a lecture on free to use and FOSS versions of the same tools. And I'm going to teach the class from them in perpetuity. Congratulations, Adobe that's 50+ students a year who won't be using your products when they graduate.
No, the concepts are the same. The button you push is incidental.
For example, the GNU Image Manipulation Program now has non-destructive workflows and adjustment layers - and can easily easily be configured with photoshop-like keybinds anyway.
That's not to mention free-to-use tools like Affinity.
The things an architecture student needs it for are:
Photo adjustment:
Lightroom -> Darktable
Photo retouching:
Photoshop -> Affinity Pixel or Gnu Image Manipulation Program
Vector drawing (which for us is mostly processing from 3d modeling programs):
Illustrator -> Affinity Vector or Inkscape
Board and Book Layout
InDesign -> Affinity Layout or Scribus or VivaDesigner
Plus, for motion graphics and video processing, my partner and I have had great luck replacing AfterEffects and Premiere with Blender and DaVinci Resolve, respectively.
And ... believe it or not, I've had excellent luck with LibreOffice Draw as a PDF editor, so anything they would have needed Acrobat Pro for is covered by that (and / or PDF SAM).
The real "sticky wicket" is Revit. Autodesk has been a FAR more abusive company for FAR longer, but it's what we're stuck with - although the emergence of the BIM Workbench (Building Information Modeling) with the release of FreeCAD 1.0 [0] and the continued development of BlenderBIM (oh, now called BonsaiBIM) [1] at least gives some hope.
Anyway, for the Adobe replacements, here's more [2] based on [3]
> Autodesk has been a FAR more abusive company for FAR longer, but it's what we're stuck with - although the emergence of the BIM Workbench (Building Information Modeling) with the release of FreeCAD 1.0 [0] and the continued development of BlenderBIM (oh, now called BonsaiBIM) [1] at least gives some hope.
I believe AutoCAD is the epitome of what is wrong with Autodesk. It's expensive, there is no permanent license, there is basically no real alternative, and they aggressively go after pirated copies.
If I were a vibecoder, instead of silly toys like a half-broken compiler that nobody uses, I'd focus all my energy and tokens on creating a real Autodesk alternative. And if it really worked, including seamless witch, the authors would quickly make tons of money.
I think at the current level of LLM code I have observed there's basically zero chance they can produce a competitive cad/cas. Maybe they could approximate an open source kernel like opencascade but I don't see the point in that when freecad already exists.
Unfortunately it looks like BricsCAD has gone the SaaS way, but they are an extremely mature alternative to classic AutoCAD 2d and 3d [0]
Additionally, Rhino has always been a good drafting tool [1] but my understanding in the current WIP (which if I'm guessing will probably be released as 9.0, within the next 6-12 months) is making a huge push to include better drafting tools. McNeel, the developer, has no plans to go to a subscription model.
I think it is the opposite of detrimental and should have been best practice 10 years ago already. Same goes for software development, which I regard as a creative exercise as well. Today the software landscape is different and learning the common industry workflows is probably the least difficult part of any design curriculum.
Detrimental would be to subject students to the whims of Adobe, which doesn't really have that much moat any more.
Probably different at huge companies, but small employers I know don't care how you get your work done. If anything they're happy if they don't have to buy/rent licenses for you.
…now that I think about it, don't architects predominantly work in smaller companies?
Speaking as a lifelong graphic designer with over 20 years experience under my belt: it really doesn’t matter what kind of software you use, HOWEVER, not using the industry standard can bite you in the ass quite fast. PDF export can be finicky, colour management is hit or miss, collaboration is nearly impossible…
I wish someone would come and take Adobe’s monopoly down for good, but as it stands, shunting Adobe for something else in a professional environment is more trouble than it’s worth.
It's absolutely very important for students to understand what standard they'll be held to in industry. But few architects need an intricate understanding of the real publication-facing aspects of the programs. In our case, using these tools is pretty much always in support of getting the output of 3d modeling / BIM tools / photography of physical models into presentable shape. Going away from Adobe might be unwise were I teaching graphic design students, but for these students, those more sophisticated, domain-specific expertises are a lot less essential.
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 (not just a blanket sudo-like escalation) to do these things. Sneakily modifying /etc/hosts to act against me? Get the hell outta here!
> Installing your binaries into C:\Program Files\AppName or /usr/local/bin? Fine.
I used to have this opinion too.
Then I decided that I actually don't want random things to install to `/usr/local/bin`. They should install to `${HOME}/.local/bin`. I should be perfectly capable of installing any application without modifying the system for every user.
You should have that option, but you should also be able to install things for all users. That's a pretty common case - most of the time if you install something on your computer, you are the administrator of that computer and want the thing you installed to be available for all users of that computer.
> most of the time if you install something on your computer, you are the administrator of that computer and want the thing you installed to be available for all users of that computer
Speak for yourself. For installing via system packages, yes. Otherwise absolutely no.
Most of the time if I install something on my computer without using the package manager, I am the administrator of that computer and I want the thing I installed to be available to a specific run-user, not to all users.
If you set up dedicated run-users for specific programs then you're very much the exception rather than the rule. I think it's reasonable for tools to serve the common case by default.
> 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.
Funny enough macOS, iOS, iPadOS and Android do this and they are constantly attacked for it.
I do think there needs to be more strict adherence by developers to standards like XDG but I don’t know how it could be enforced.
From the operating system’s perspective, everything is the user. Or everything is an app developer. Depends on perspective. Disambiguating reliably, in a way you’d consider reasonable, is not trivial (and arguably impossible).
Phone-style isolation is more like giving each app a separate user account. With that level of isolation and robust permissions, apps can do very little "on your behalf".
How do you do anything on a computer that’s not via an app of some description? Do you make arbitrary exceptions for the likes of zsh and chmod? How does the OS know that chmod was knowingly run by the user, and not by some “sudo wget” exploit?
> How do you do anything on a computer that’s not via an app of some description? Do you make arbitrary exceptions for the likes of zsh and chmod? How does the OS know that chmod was knowingly run by the user, and not by some “sudo wget” exploit?
I'm not sure what the purpose of the question is, because a unixy command line doesn't use phone-style permissions. I didn't say everything works this way.
If I installed photoshop with phone-style permissions, it wouldn't be able to invoke chmod and wouldn't even be able to access my downloads folder.
(Trying to tighten down a command line shell ends up being a tangent, but the short answer is that zsh itself would need to be trusted and hardened, and wget would not be allowed to run chmod. When it comes to downloading a script and then running that script on purpose, you probably just have to accept that doing so bypasses the permission system. Thankfully I very rarely need to do something like that.)
If a user can do a thing, then an app can ask the user to delegate those permissions to it. And since 99% of users don’t read permission dialogs, the two ideas are completely equivalent. The only way to prevent an app from doing a thing is to make it impossible.
Even if users do read permission dialogues, how many Adobe users out there actually understand what modifying the hosts file means? There can be no informed consent if the person who's meant to consent doesn't have the tools to understand the information.
> I do think there needs to be more strict adherence by developers to standards like XDG but I don’t know how it could be enforced.
It can't be enforced. Developers can and will always do whatever they want with the tools available. For good ends (Adobe) or for ill (malware).
If you try to fix it with sandboxing and closed app stores (Apple forcing sandboxing and using SIP), you get attacked. If you don't try to fix it and let devs do as they please (Microsoft allowing host file editing), you get attacked. The conclusion of these incompatible goals? HN and nerds have zero relevance in policy discussions, because they don't have a consistent policy to offer [1].
[1] Unless, of course, you define "devs shouldn't be able to do anything bad even if they choose" and "users should be able to anything bad if they choose" and "users should be able to write their own software capable of bad things while simultaneously not being held to the standard of devs" as a compatible principled position.
I think somewhat sand boxed is fine, but the user should at the end of the day be allowed to let things out or get out if it.
The problem with things like iOS is the user can't make that choice. Also what you call 'bad' is up to the user. At the end of the day a user should be able to adjust things even at root level or request other software to do that on their behalf. Heck for iDevices owners should be able to load their own signing keys at a minimum for the Boot-ROM.
As for Adobe most people would not expect their software to touch the host file, so it's fine to call them out here. Someone using a utility or tool that you would expect to edit the host file that's fine, and people should be able to use or make such a tool. (The os should not prevent the user/owner if that's what they want).
Yea, that's what I was getting at. The user should be king. Not the application developer, not the OS vendor. The user should be able to easily say yes/no to these things and have the final say.
Meet macOS System Integrity Protection. Even root can’t do some things. Some hate it, I love it and would never turn it off. I know some parts of my system haven’t been gunked up by random vendors.
I thought the days if needing to "sudo" to install applications on windows were long gone; doesn't basically everything happily do user installations now? I would view a demand to escalate as basically proof that the application is about to do something janky, if not outright malicious. On linux, if I can't build and run software with just my user account, that software has some explaining to do. Virtually every desktop application should be able to run without escalated privileges.
Your impression is pretty far off, I think. Just naming a program setup.exe makes it escalate by default. Many installers can be used without escalation but going the traditional path isn't suspicious.
> On linux, if I can't build and run software with just my user account, that software has some explaining to do.
Yup same. The software I install as root are those shipping stock with the distro. Others I compile and run from user accounts (like Emacs, which I always compile from source).
on windows and mac they just get a prompt and a lot of people don't read it, care, nor wonder what it's actually doing they just want it to work.
I know you all know this but companies will do this knowing that exploiting all of us.
I use Linux and agreed on all those points. when I used adobe before it wanted to charge me a fee to cancel my subscription and wouldn't let me just 'cancel' in their system so I just blocked the payments on my card and dipped out.
"C:/Program Files" is still the recommended place to install programs, and it requires admin privileges to write to. Some programs (ab)use C:\ProgramData for that purpose instead and therefore don't need admin privliges. But even with that hack, ultimately Windows still uses the https://xkcd.com/1200/ permission model. (Everything runs with full access to all your data.)
On Windows enabling access control is 4 clicks. The problem with enabling it by default is that every time MS tries to harden the defaults there is much weeping and wailing and gnashing of teeth
I won't name names just in case I'm misremembering but I'm pretty sure a remote desktop program you've heard at one point was adding a global LD_PRELOAD and pointing it at a shared library that anyone could write to.
But I might be making this up so not being specific lest I do a cheeky libel
The problem is that you have 100 apps that want to overwrite system files for malware reasons and then you have 1 app that wants to do it for legit reasons and there's no blanket method to tell these two situations apart.
This is why I love iOS in many ways: it's very difficult for an app to have "action at a distance" inside your OS. If you force-quit the app it's pretty much like it never existed.
Well my point is that switching to a commit-based workflow with no runtime changes doesn't solve the problem of adobe setup including a malicious commit.
Isolating things to a specific folder is what actually gives any security here, and you can do that on a writable /etc too.
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.
Doing this again, now (well into adulthood): recently gifted a "broken" 2013 MacPro[0], and have set it up as my retro CS4 workhorse (decades old software on a decade old machine). Hosts/PiHole ready, blocking "*adobe*" entirely.
Only problem now is I cannot find four's `FCKGW-RHQQ2-`... my oldmanfish surfs onwards, Santiago remaining uncertain. For now I just don't quit and never shut down (fresh install allows limited launches).
[0] RAM slot was jamming, not allowing proper seating
The title of this article recalled that exact memory for me too. Not only Adobe but cracks for a few other expensive softwares needed the same.
...and then Adobe (unintentionally) gave away free downloads of CS2, with valid serial numbers, once they shut down the activation servers. You can still find them on the Internet Archive.
Most windows apps aren't sandboxed so the concept of "permissions" doesn't make any sense. The most there is is "asks to run as admin", but most installers do.
Software installers need Administrator privileges to edit C:\Program Files\. But once they get the permission, you can't really tell if they are "genuine", or if they also edit C:\Windows\ or messing around the registry.
It is just a really bad design without built-in sandboxing.
Software wants to be installed in C:\Program Files so that other software can’t modify their installation without admin permissions. Of course to do that your installer needs to be run as administrator which makes the whole thing rather silly.
>There’s no need to have an executable program just to essentially unzip some files to disk
What if you need to install some registry keys? What about installing shared dependencies (redistributables)? What if you want granny to install your app and left to her own devices, it'll end up in some random folder in the downloads folder?
Software installed through the Windows Store seem immutable enough even though they live in the user's AppData.
At least the system prevented me from seeing or modifying the files the last time I tried. I did not try very hard, admittedly, but by contrast modifying something in C:\Program Files is just one UAC confirmation away.
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."
Programs adding entries to the hosts file is still pretty normal, e.g. if something that uses a local webserver as its UI and wants you to be able to access it by name even if you don't have an internet connection or may be stuck behind a DNS server that mangles entries in the public DNS that resolve to localhost.
Programs like that should just be shipped with good documentation. And applications built to be used by normies should almost certainly never be built that way in the first place.
That seems like a pretty reasonable way to write a small cross-platform application which is intended to be a background service to begin with. You only have to create the UI once without needing to link in a heavy cross-platform UI framework and can then just put an HTTP shortcut to the local name in the start menu or equivalent. Normies can easily figure that out specifically because you're not telling them to read documentation to manually edit their hosts file.
There are also other reasons to do it, like if you want a device on the local network to be accessible via HTTPS. Getting the certificate these days is pretty easy (have the device generate a random hostname for itself and get a real certificate by having the developer's servers do a DNS challenge for that hostname under one of the developer's public domain names), but now you need the local client device to resolve the name to the LAN IP address even if the local DNS refuses to resolve to those addresses or you don't want the LAN IP leaked into the public DNS.
Or the app being installed is some kind of VPN that only provides access to a fixed set of devices and then you want some names to resolve to those VPN addresses, which the app can update if you change the VPN configuration.
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.
Your post reminded me when Yahoo IM updated their chat protocol to an incompatible version with a gradual rollout! Half their eight servers used v1 and half v2. A v1 only client would connect half the time depending on which server the round-robin DNS sent you to. This took me forever to figure out, but the fix was to put the IP address of the four v1 servers in the hosts file. (Until the client updated its support for v2.)
The person you replied to said mostly-obsolete. They were speaking in the same context as the earlier commenter claiming it's a normal practice because everyone used to have to update their hosts files all the time before DNS existed at all.
Your shadow IT example is perfectly valid, and also isn't a 1:1 comparison with a company doing it automatically for a much larger number of external users.
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 don't know whether is still does this, but 8-9 years ago I discovered that Acrobat overwrites the COM registry entries for Microsoft Active Accessibility (oleacc.dll) such that any application attempting to instantiate MSAA gets the Adobe DLL instead of the system DLL. This actually broke the stuff I was working on and had to override it in my app manifest to forcibly use the system version.
I inquired about it and got some BS about how they absolutely _had_ to do this to intercept MSAA instantiations across the system, when in reality they were using a global solution to solve a local problem.
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.
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?
> Cannot any website use the same trick Adobe does to check whether you have Creative Cloud installed?
That is specifically what I was talking about.
> (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.)
It's additional complexity on the server side, per a Reddit comment on the topic: https://old.reddit.com/r/webdev/comments/1sb6hzk/adobe_wrote... The example curl commands given seemed convincing to me, although they also demonstrate that you can fake the origin pretty easily on the client side.
The DNS lookup will take an indeterminate amount of time and the cors failure is cached. You can't really effectively do a timing attack, especially if the client and the real server take a random time to respond. You get exactly one sample.
It's not a client side configuration issue. You're not protecting against software the user has installed, you're protecting from arbitrary origins hitting the hostname. That's literally the exact reason cors exists.
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).
Are we sure this is to detect Creative Cloud instead of, trying to detect whether you have/had a pirated version of Adobe installed? Some reference material I've seen often involved blackholing adobe hosts to prevent installation software from verifying or otherwise talking to adobe.
Honestly, I've been dealing with crap like this for so many decades that I'm a fervent supporter of every "installer" just showing and logging a Git PR-styled diff to the user of every file and system change, everywhere in the system, complete with the ability to rollback from it.
I am tired of inconsistent logging, opaque system changes, and vendors generally being malicious with endpoint security in the name of protecting profit.
Screw the "show me the log" option that scrolls by in a flash and you can't get back to, show me the damn diff first.
If you have ever used certain pirated Adobe software, you would have realized this very early on: you can only use it while offline. Otherwise, it constantly throws up pop-ups that block it from launching, even if you try hard to modify the network settings.
Adobe has been user hostile since Create Suite launched. Where were you? They have been hiding backdoors in windows machines and Mac machines since at least 2010.
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.
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.
They implemented it in a way that it only responds with a valid image and a 200 status code, when the referrer is adobe.com. It's probably somewhat sane given the insanity that is the host files hack.
Agreed, at worst this is just vaguely icky feeling; realistically this is a nothing burger.
To exploit this kind of thing you'd either need to have access to someone's computer to change the hosts file yourself, pointing to a different IP address, or somehow gain control of Adobe's IP address and point it to a different server. For the former, if you have local root permission, you already own the machine, why bother with this slow of an option. And the latter is already such a takeover that the involvement of this hosts file change is basically irrelevant.
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.
It's one thing when it's the Associated Press, where they are trying to be a somewhat impartial source of news and reporting raw facts to the best of their ability; stuff like that probably should not have an opinionated tone at all.
But I think for things like blogs, without opinions being clear, posts can feel kind of soulless. Even before LLMs I felt that way, and now it has been amplified ten fold with people just cranking out low-effort posts with ChatGPT for reasons that I do not understand.
When I write stuff for my blog, I like to think of it as a time capsule of the entirety of the thing I'm writing about. This doesn't just include the raw subject matter, but also my mood and opinions about the subject matter. I'm egotistical enough to occasionally read through my old posts and the ones that I like the best are the ones where I feel like I was expressing myself the most, and where I make no effort whatsoever to try and be impartial.
> 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?
> 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.
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.
> There *already( is one. It just asks the user whether it's okay before it tells the website
The current implementation defines a way to launch (w/ the user's approval) but it lacks any signaling of success or failure of the request. Without such feedback, it falls short of being a detection API.
> 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.
> 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?
Sir, this is Windows. This is not Android, this is not iOS, this is not macOS. Wait until you learn about the registry.
Also, Microsoft has attempted to reign in and standardize app developers on numerous occasions over the past couple of decades, and their failure to do so doesn't impact my statement regarding the direction of app development in general (or the weaknesses of people doing whatever they want on Windows).
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.
I have been an Adobe user since 1996. Starting with Photoshop 3. Then, using the rest of their programs since 1999.
Between this and the fact that they've just 1. Changed all the old accounts to "Adobe Creative Cloud Pro" 2. DOUBLED the monthly fee, now charging you for the AI features whether you want them or not, and 3. Removed any tiers that have full program access but no AI, I am walking away forever when my current month expires.
Not to mention, students now only get the old $19.99 membership for the first year.
I teach visualization and representation tools to architecture students. I had always taught them Adobe products before. Now I can't in good faith sign them up to have their expertise tied to using this program stack forever. So tomorrow I am giving them a lecture on free to use and FOSS versions of the same tools. And I'm going to teach the class from them in perpetuity. Congratulations, Adobe that's 50+ students a year who won't be using your products when they graduate.
What alternatives do you suggest?
See my comment below, or here [0] and the same on github here [1].
[0] https://x.com/XdanielArt/status/1799474607055102257/photo/1
[1] https://github.com/KenneyNL/Adobe-Alternatives
Is that not potentially detrimental to your students if the use of Adobe products is a more common industry practice?
No, the concepts are the same. The button you push is incidental.
For example, the GNU Image Manipulation Program now has non-destructive workflows and adjustment layers - and can easily easily be configured with photoshop-like keybinds anyway.
That's not to mention free-to-use tools like Affinity.
The things an architecture student needs it for are:
Photo adjustment:
Lightroom -> Darktable
Photo retouching:
Photoshop -> Affinity Pixel or Gnu Image Manipulation Program
Vector drawing (which for us is mostly processing from 3d modeling programs):
Illustrator -> Affinity Vector or Inkscape
Board and Book Layout
InDesign -> Affinity Layout or Scribus or VivaDesigner
Plus, for motion graphics and video processing, my partner and I have had great luck replacing AfterEffects and Premiere with Blender and DaVinci Resolve, respectively.
And ... believe it or not, I've had excellent luck with LibreOffice Draw as a PDF editor, so anything they would have needed Acrobat Pro for is covered by that (and / or PDF SAM).
The real "sticky wicket" is Revit. Autodesk has been a FAR more abusive company for FAR longer, but it's what we're stuck with - although the emergence of the BIM Workbench (Building Information Modeling) with the release of FreeCAD 1.0 [0] and the continued development of BlenderBIM (oh, now called BonsaiBIM) [1] at least gives some hope.
Anyway, for the Adobe replacements, here's more [2] based on [3]
[0] https://wiki.freecad.org/BIM_Workbench
[1] https://bonsaibim.org/
[2] https://github.com/KenneyNL/Adobe-Alternatives?tab=readme-ov...
[3] https://x.com/XdanielArt/status/1799474607055102257/photo/1
> Autodesk has been a FAR more abusive company for FAR longer, but it's what we're stuck with - although the emergence of the BIM Workbench (Building Information Modeling) with the release of FreeCAD 1.0 [0] and the continued development of BlenderBIM (oh, now called BonsaiBIM) [1] at least gives some hope.
I believe AutoCAD is the epitome of what is wrong with Autodesk. It's expensive, there is no permanent license, there is basically no real alternative, and they aggressively go after pirated copies.
If I were a vibecoder, instead of silly toys like a half-broken compiler that nobody uses, I'd focus all my energy and tokens on creating a real Autodesk alternative. And if it really worked, including seamless witch, the authors would quickly make tons of money.
I think at the current level of LLM code I have observed there's basically zero chance they can produce a competitive cad/cas. Maybe they could approximate an open source kernel like opencascade but I don't see the point in that when freecad already exists.
Unfortunately it looks like BricsCAD has gone the SaaS way, but they are an extremely mature alternative to classic AutoCAD 2d and 3d [0]
Additionally, Rhino has always been a good drafting tool [1] but my understanding in the current WIP (which if I'm guessing will probably be released as 9.0, within the next 6-12 months) is making a huge push to include better drafting tools. McNeel, the developer, has no plans to go to a subscription model.
[0] https://www.bricsys.com/
[1] https://www.rhino3d.com/
I think it is the opposite of detrimental and should have been best practice 10 years ago already. Same goes for software development, which I regard as a creative exercise as well. Today the software landscape is different and learning the common industry workflows is probably the least difficult part of any design curriculum.
Detrimental would be to subject students to the whims of Adobe, which doesn't really have that much moat any more.
Probably different at huge companies, but small employers I know don't care how you get your work done. If anything they're happy if they don't have to buy/rent licenses for you.
…now that I think about it, don't architects predominantly work in smaller companies?
Speaking as a lifelong graphic designer with over 20 years experience under my belt: it really doesn’t matter what kind of software you use, HOWEVER, not using the industry standard can bite you in the ass quite fast. PDF export can be finicky, colour management is hit or miss, collaboration is nearly impossible…
I wish someone would come and take Adobe’s monopoly down for good, but as it stands, shunting Adobe for something else in a professional environment is more trouble than it’s worth.
It's absolutely very important for students to understand what standard they'll be held to in industry. But few architects need an intricate understanding of the real publication-facing aspects of the programs. In our case, using these tools is pretty much always in support of getting the output of 3d modeling / BIM tools / photography of physical models into presentable shape. Going away from Adobe might be unwise were I teaching graphic design students, but for these students, those more sophisticated, domain-specific expertises are a lot less essential.
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 (not just a blanket sudo-like escalation) to do these things. Sneakily modifying /etc/hosts to act against me? Get the hell outta here!
> Installing your binaries into C:\Program Files\AppName or /usr/local/bin? Fine.
I used to have this opinion too.
Then I decided that I actually don't want random things to install to `/usr/local/bin`. They should install to `${HOME}/.local/bin`. I should be perfectly capable of installing any application without modifying the system for every user.
You should have that option, but you should also be able to install things for all users. That's a pretty common case - most of the time if you install something on your computer, you are the administrator of that computer and want the thing you installed to be available for all users of that computer.
> most of the time if you install something on your computer, you are the administrator of that computer and want the thing you installed to be available for all users of that computer
Speak for yourself. For installing via system packages, yes. Otherwise absolutely no.
Most of the time if I install something on my computer without using the package manager, I am the administrator of that computer and I want the thing I installed to be available to a specific run-user, not to all users.
> I am the administrator of that computer and I want the thing I installed to be available to a specific run-user
Are you saying you use root access to install something to a specific user's home directory? That's gross.
A user installing something for themselves should not need administrator access. You only need admin access for making system-wide changes.
If you set up dedicated run-users for specific programs then you're very much the exception rather than the rule. I think it's reasonable for tools to serve the common case by default.
> Speak for yourself. For installing via system packages, yes. Otherwise absolutely no.
That's an overly strong rebuttal given they said "most" and weren't talking about a specific style of install.
> 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.
Funny enough macOS, iOS, iPadOS and Android do this and they are constantly attacked for it.
I do think there needs to be more strict adherence by developers to standards like XDG but I don’t know how it could be enforced.
They are constantly attacked because they prevent users from modifying the system configuration, not just app developers.
From the operating system’s perspective, everything is the user. Or everything is an app developer. Depends on perspective. Disambiguating reliably, in a way you’d consider reasonable, is not trivial (and arguably impossible).
Phone-style isolation is more like giving each app a separate user account. With that level of isolation and robust permissions, apps can do very little "on your behalf".
How do you do anything on a computer that’s not via an app of some description? Do you make arbitrary exceptions for the likes of zsh and chmod? How does the OS know that chmod was knowingly run by the user, and not by some “sudo wget” exploit?
> How do you do anything on a computer that’s not via an app of some description? Do you make arbitrary exceptions for the likes of zsh and chmod? How does the OS know that chmod was knowingly run by the user, and not by some “sudo wget” exploit?
I'm not sure what the purpose of the question is, because a unixy command line doesn't use phone-style permissions. I didn't say everything works this way.
If I installed photoshop with phone-style permissions, it wouldn't be able to invoke chmod and wouldn't even be able to access my downloads folder.
(Trying to tighten down a command line shell ends up being a tangent, but the short answer is that zsh itself would need to be trusted and hardened, and wget would not be allowed to run chmod. When it comes to downloading a script and then running that script on purpose, you probably just have to accept that doing so bypasses the permission system. Thankfully I very rarely need to do something like that.)
So you installed a text editor and wanted to edit /etc/hosts. Should the OS permit you to save your changes or not?
Now what should happen if the text editor decides to modify /etc/hosts without your knowledge?
The secure answer is that the OS gives you a trusted file picker and it grants access to that specific file to the text editor.
This works better with a GUI, but you can adapt it to a console too.
> Now what should happen if the text editor decides to modify /etc/hosts without your knowledge?
Pop up a UAC prompt of course. It worked so well for Vista.
I'm not sure I fully understand you. All those OSes try very, very hard to disambiguate between apps and the user itself?
A program touches a system file. Is it due to its own logic, or is it your editor saving a file?
Pretend you’re the operating system for a moment. What does “the user” look like, if not an app doing things?
If a user can do a thing, then an app can ask the user to delegate those permissions to it. And since 99% of users don’t read permission dialogs, the two ideas are completely equivalent. The only way to prevent an app from doing a thing is to make it impossible.
Even if users do read permission dialogues, how many Adobe users out there actually understand what modifying the hosts file means? There can be no informed consent if the person who's meant to consent doesn't have the tools to understand the information.
I think we agree.
You can put pressure on app developers to use standard installation methods that don't give unrestricted access.
Even if users don't read the permission dialogs, you can make one path a lot easier. And you can flag anything too tricky as malware behavior.
OSes are doing a bad job of this, but they could do much better. Linux is making the most progress on various package formats.
> I do think there needs to be more strict adherence by developers to standards like XDG but I don’t know how it could be enforced.
It can't be enforced. Developers can and will always do whatever they want with the tools available. For good ends (Adobe) or for ill (malware).
If you try to fix it with sandboxing and closed app stores (Apple forcing sandboxing and using SIP), you get attacked. If you don't try to fix it and let devs do as they please (Microsoft allowing host file editing), you get attacked. The conclusion of these incompatible goals? HN and nerds have zero relevance in policy discussions, because they don't have a consistent policy to offer [1].
[1] Unless, of course, you define "devs shouldn't be able to do anything bad even if they choose" and "users should be able to anything bad if they choose" and "users should be able to write their own software capable of bad things while simultaneously not being held to the standard of devs" as a compatible principled position.
I think somewhat sand boxed is fine, but the user should at the end of the day be allowed to let things out or get out if it.
The problem with things like iOS is the user can't make that choice. Also what you call 'bad' is up to the user. At the end of the day a user should be able to adjust things even at root level or request other software to do that on their behalf. Heck for iDevices owners should be able to load their own signing keys at a minimum for the Boot-ROM.
As for Adobe most people would not expect their software to touch the host file, so it's fine to call them out here. Someone using a utility or tool that you would expect to edit the host file that's fine, and people should be able to use or make such a tool. (The os should not prevent the user/owner if that's what they want).
Yea, that's what I was getting at. The user should be king. Not the application developer, not the OS vendor. The user should be able to easily say yes/no to these things and have the final say.
Meet macOS System Integrity Protection. Even root can’t do some things. Some hate it, I love it and would never turn it off. I know some parts of my system haven’t been gunked up by random vendors.
https://en.wikipedia.org/wiki/System_Integrity_Protection
I thought the days if needing to "sudo" to install applications on windows were long gone; doesn't basically everything happily do user installations now? I would view a demand to escalate as basically proof that the application is about to do something janky, if not outright malicious. On linux, if I can't build and run software with just my user account, that software has some explaining to do. Virtually every desktop application should be able to run without escalated privileges.
Your impression is pretty far off, I think. Just naming a program setup.exe makes it escalate by default. Many installers can be used without escalation but going the traditional path isn't suspicious.
> On linux, if I can't build and run software with just my user account, that software has some explaining to do.
Yup same. The software I install as root are those shipping stock with the distro. Others I compile and run from user accounts (like Emacs, which I always compile from source).
on windows and mac they just get a prompt and a lot of people don't read it, care, nor wonder what it's actually doing they just want it to work.
I know you all know this but companies will do this knowing that exploiting all of us.
I use Linux and agreed on all those points. when I used adobe before it wanted to charge me a fee to cancel my subscription and wouldn't let me just 'cancel' in their system so I just blocked the payments on my card and dipped out.
good software, garbage company
Heh, I had a similar situation once, but my bank wouldn't let me block the transactions.
So I switched banks. It was a interesting call with my previous banks support folks.
On linux they just use sudo and similary don't read, care or wonder.
"C:/Program Files" is still the recommended place to install programs, and it requires admin privileges to write to. Some programs (ab)use C:\ProgramData for that purpose instead and therefore don't need admin privliges. But even with that hack, ultimately Windows still uses the https://xkcd.com/1200/ permission model. (Everything runs with full access to all your data.)
On Windows enabling access control is 4 clicks. The problem with enabling it by default is that every time MS tries to harden the defaults there is much weeping and wailing and gnashing of teeth
I won't name names just in case I'm misremembering but I'm pretty sure a remote desktop program you've heard at one point was adding a global LD_PRELOAD and pointing it at a shared library that anyone could write to.
But I might be making this up so not being specific lest I do a cheeky libel
The problem is that you have 100 apps that want to overwrite system files for malware reasons and then you have 1 app that wants to do it for legit reasons and there's no blanket method to tell these two situations apart.
This is why I love iOS in many ways: it's very difficult for an app to have "action at a distance" inside your OS. If you force-quit the app it's pretty much like it never existed.
> developers should not have free rein to modify my system's configuration
s/free rein/the ability/
I am a big believer in read only operating systems. /etc should not be writable.
How do you configure things without something basically equivalent to writing to /etc?
And whatever you do use to configure things, what if photoshop accessed it directly? I'm sure you'd be upset with that even if it didn't touch /etc.
If something is system wide i want a commit based workflow (with minor exceptions like dhcp / ip)
Everything else should be in its own folder without the ability to change anything outside of that folder.
Well my point is that switching to a commit-based workflow with no runtime changes doesn't solve the problem of adobe setup including a malicious commit.
Isolating things to a specific folder is what actually gives any security here, and you can do that on a writable /etc too.
yes and you need shared read-only global state. like resolv.conf
We get it, you like Nix
NixOS is not a read only OS. There is an impermanence addon that can do this, though, for many partitions.
Nix has some good ideas but it is not exactly what I would love to have.
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.
I also did this as a teenager.
Doing this again, now (well into adulthood): recently gifted a "broken" 2013 MacPro[0], and have set it up as my retro CS4 workhorse (decades old software on a decade old machine). Hosts/PiHole ready, blocking "*adobe*" entirely.
Only problem now is I cannot find four's `FCKGW-RHQQ2-`... my oldmanfish surfs onwards, Santiago remaining uncertain. For now I just don't quit and never shut down (fresh install allows limited launches).
[0] RAM slot was jamming, not allowing proper seating
That CS2 torrent was a GOAT.
FCKGW-RHQQ2-…
Those particular neurons of mine haven't seen action in quite some time, thank you.
I worked at Gateway during this era and always saw that in the light of me quitting when XP came out and drove me crazy. FCKGW indeed.
The title of this article recalled that exact memory for me too. Not only Adobe but cracks for a few other expensive softwares needed the same.
...and then Adobe (unintentionally) gave away free downloads of CS2, with valid serial numbers, once they shut down the activation servers. You can still find them on the Internet Archive.
[dead]
How is defender not flagging this? Changing hosts file should raise alarms
Defender warns you this happened.
I didn't get this warning on MacOS
Did you expect to get a Windows Defender warning on macOS?
Sure, with Microsoft Defender for Endpoint, why not?
Can this not be blocked with file permissions? Or a symlink to a file in a ro folder?
Most software installers demand to be run as root/Administrator.
The fact that this is largely seen as acceptable or even sensible is rather silly in this day and age.
Yes, and when apps do request many permissios, I just estimate how reputable the company is. A name like Adobe must be ok, right?
>Yes, and when apps do request many permissios
Most windows apps aren't sandboxed so the concept of "permissions" doesn't make any sense. The most there is is "asks to run as admin", but most installers do.
Software installers need Administrator privileges to edit C:\Program Files\. But once they get the permission, you can't really tell if they are "genuine", or if they also edit C:\Windows\ or messing around the registry.
It is just a really bad design without built-in sandboxing.
Software wants to be installed in C:\Program Files so that other software can’t modify their installation without admin permissions. Of course to do that your installer needs to be run as administrator which makes the whole thing rather silly.
The fundamental issue is that installers shouldn’t exist
There’s no need to have an executable program just to essentially unzip some files to disk
>There’s no need to have an executable program just to essentially unzip some files to disk
What if you need to install some registry keys? What about installing shared dependencies (redistributables)? What if you want granny to install your app and left to her own devices, it'll end up in some random folder in the downloads folder?
Software installed through the Windows Store seem immutable enough even though they live in the user's AppData.
At least the system prevented me from seeing or modifying the files the last time I tried. I did not try very hard, admittedly, but by contrast modifying something in C:\Program Files is just one UAC confirmation away.
I wonder how this works on Windows, if any service overrides/resets it
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."
Programs adding entries to the hosts file is still pretty normal, e.g. if something that uses a local webserver as its UI and wants you to be able to access it by name even if you don't have an internet connection or may be stuck behind a DNS server that mangles entries in the public DNS that resolve to localhost.
Programs like that should just be shipped with good documentation. And applications built to be used by normies should almost certainly never be built that way in the first place.
That seems like a pretty reasonable way to write a small cross-platform application which is intended to be a background service to begin with. You only have to create the UI once without needing to link in a heavy cross-platform UI framework and can then just put an HTTP shortcut to the local name in the start menu or equivalent. Normies can easily figure that out specifically because you're not telling them to read documentation to manually edit their hosts file.
There are also other reasons to do it, like if you want a device on the local network to be accessible via HTTPS. Getting the certificate these days is pretty easy (have the device generate a random hostname for itself and get a real certificate by having the developer's servers do a DNS challenge for that hostname under one of the developer's public domain names), but now you need the local client device to resolve the name to the LAN IP address even if the local DNS refuses to resolve to those addresses or you don't want the LAN IP leaked into the public DNS.
Or the app being installed is some kind of VPN that only provides access to a fixed set of devices and then you want some names to resolve to those VPN addresses, which the app can update if you change the VPN configuration.
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.
You should get the company DNS to delegate a subdomain at my-team.example.com to you and then have an authoritative DNS server for it.
That's dysfunctional enough to qualify as "obsolete" in my book.
Your post reminded me when Yahoo IM updated their chat protocol to an incompatible version with a gradual rollout! Half their eight servers used v1 and half v2. A v1 only client would connect half the time depending on which server the round-robin DNS sent you to. This took me forever to figure out, but the fix was to put the IP address of the four v1 servers in the hosts file. (Until the client updated its support for v2.)
The person you replied to said mostly-obsolete. They were speaking in the same context as the earlier commenter claiming it's a normal practice because everyone used to have to update their hosts files all the time before DNS existed at all.
Your shadow IT example is perfectly valid, and also isn't a 1:1 comparison with a company doing it automatically for a much larger number of external users.
> 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.
Particularly since the first version of Windows shipped in what -1985? Contemporary with 4.2BSD? Did 4.2BSD even use /etc/hosts the same way or DNS?
Yeah, I've had to manually edit hosts for every work and personal windows machine I've had in the last 20 years, I think. At least desktops.
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 don't know whether is still does this, but 8-9 years ago I discovered that Acrobat overwrites the COM registry entries for Microsoft Active Accessibility (oleacc.dll) such that any application attempting to instantiate MSAA gets the Adobe DLL instead of the system DLL. This actually broke the stuff I was working on and had to override it in my app manifest to forcibly use the system version.
I inquired about it and got some BS about how they absolutely _had_ to do this to intercept MSAA instantiations across the system, when in reality they were using a global solution to solve a local problem.
I'd like to answer the closing question
> At what point does a commercial software suite become malware?
The vast majority of commercial software is malware.
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.
0: https://crt.sh/?q=creativecloud.adobe.com
Adobe really relishes being a villain. I don't understand how one company can be so anti-consumer.
Consumers keep buying adobe.
Recycling a comment from prior discussion (4 days, 68 points, 13 comments): https://news.ycombinator.com/item?id=47617463
_______
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.
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.
> 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?
> Cannot any website use the same trick Adobe does to check whether you have Creative Cloud installed?
That is specifically what I was talking about.
> (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.)
It's additional complexity on the server side, per a Reddit comment on the topic: https://old.reddit.com/r/webdev/comments/1sb6hzk/adobe_wrote... The example curl commands given seemed convincing to me, although they also demonstrate that you can fake the origin pretty easily on the client side.
I think cors can prevent that. You can't make a cross origin request from an origin that isn't allowlisted
Timing attack on the preflight.
The DNS lookup will take an indeterminate amount of time and the cors failure is cached. You can't really effectively do a timing attack, especially if the client and the real server take a random time to respond. You get exactly one sample.
detect-ccd.creativecloud.adobe.com returns NXDOMAIN. Why can't you request a different resource to get more than one attempt?
You really think a server-controlled CORS list will protect you from a client-side configuration issue?
It's not a client side configuration issue. You're not protecting against software the user has installed, you're protecting from arbitrary origins hitting the hostname. That's literally the exact reason cors exists.
It's more like when you join a company the laptop is given the ability to connect to an internal network for employees.
This is an extremely common practice.
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).
Are we sure this is to detect Creative Cloud instead of, trying to detect whether you have/had a pirated version of Adobe installed? Some reference material I've seen often involved blackholing adobe hosts to prevent installation software from verifying or otherwise talking to adobe.
I installed Creative Cloud just last week. No such entry was created in the hosts file on my macOs system.
[dupe] https://news.ycombinator.com/item?id=47617463
https://news.ycombinator.com/item?id=47624990
Honestly, I've been dealing with crap like this for so many decades that I'm a fervent supporter of every "installer" just showing and logging a Git PR-styled diff to the user of every file and system change, everywhere in the system, complete with the ability to rollback from it.
I am tired of inconsistent logging, opaque system changes, and vendors generally being malicious with endpoint security in the name of protecting profit.
Screw the "show me the log" option that scrolls by in a flash and you can't get back to, show me the damn diff first.
I owe thousands of dollars to amtlib.dll.
If you don't like Adobe modifying your hosts file then I'd not use them. The checking for the software this way is kinda interesting though.
I wonder how many Adobe users are aware of this sketchy behavior tho
My guess is most Adobe users have no idea there is a hosts file nor what it does.
If you have ever used certain pirated Adobe software, you would have realized this very early on: you can only use it while offline. Otherwise, it constantly throws up pop-ups that block it from launching, even if you try hard to modify the network settings.
https://devblogs.microsoft.com/oldnewthing/20061101-03/?p=29...
There are no suspicious entries in my /etc/hosts just what I put there.
Would it be possible (practical) to uniquely identify large numbers of users and even bypass anonymization efforts like tor and VPNs with this?
Yearly reminder that Adobe CC is malware. Open your Activity Monitor on your Mac and see how much craps CC run on your computer
Adobe has been user hostile since Create Suite launched. Where were you? They have been hiding backdoors in windows machines and Mac machines since at least 2010.
So can I fool the website that I have CC installed?
Browsers could still do something about mixed Internet and LAN/Localhost requests by IP address regardless of the domain name.
Did you misread the post?
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.
This does not request a local/LAN file, it's a remote server but without any DNS entry unless the hosts file entry is present.
To be fair, to crack all adobe products requires a few reg keys. It's wild that they have just given up on pirates.
They don't want to be too hard on piracy, its their new/young user on ramp method
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.
Can't even reproduce it when setting location to Belgium, or CA or AZ.
I must be missing something.
The most difficult of tasks is trying to un-unstall this pos app on windows.
Make affinity sound like a smarter and smarter choice.
what happens if you happen to use a DNS server that resolves this domain to the correct IP?
"Correct IP" wins ;)
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.
It can power even more security issues too. This is absolutely horrendous.
I’m wondering how this can be exploited.
They implemented it in a way that it only responds with a valid image and a 200 status code, when the referrer is adobe.com. It's probably somewhat sane given the insanity that is the host files hack.
Agreed, at worst this is just vaguely icky feeling; realistically this is a nothing burger.
To exploit this kind of thing you'd either need to have access to someone's computer to change the hosts file yourself, pointing to a different IP address, or somehow gain control of Adobe's IP address and point it to a different server. For the former, if you have local root permission, you already own the machine, why bother with this slow of an option. And the latter is already such a takeover that the involvement of this hosts file change is basically irrelevant.
As much as I dislike what AI slop is doing to visual design, I wouldn’t mind seeing Adobe get hurt for being the comically terrible company it is.
I vote we all add that HOSTS entry to poison their despicably dark-pattern detection algorithm.
[dead]
> for a very stupid reason.
I cannot stomach Thom's articles. So borderline judgmental, holier than thou, feels like he only writes whenever there's something to criticize.
No, it's not a stupid reason. Reason is OK, the execution is controversial.
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.
I like his tone too. It also is easier to identify that it isn’t LLM generated text.
(I have nothing against LLMs but have little interest in reading text generated from them.)
It's one thing when it's the Associated Press, where they are trying to be a somewhat impartial source of news and reporting raw facts to the best of their ability; stuff like that probably should not have an opinionated tone at all.
But I think for things like blogs, without opinions being clear, posts can feel kind of soulless. Even before LLMs I felt that way, and now it has been amplified ten fold with people just cranking out low-effort posts with ChatGPT for reasons that I do not understand.
When I write stuff for my blog, I like to think of it as a time capsule of the entirety of the thing I'm writing about. This doesn't just include the raw subject matter, but also my mood and opinions about the subject matter. I'm egotistical enough to occasionally read through my old posts and the ones that I like the best are the ones where I feel like I was expressing myself the most, and where I make no effort whatsoever to try and be impartial.
> 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"
> 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?
> 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.
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.
> 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.
> There *already( is one. It just asks the user whether it's okay before it tells the website
The current implementation defines a way to launch (w/ the user's approval) but it lacks any signaling of success or failure of the request. Without such feedback, it falls short of being a detection API.
> 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.
> 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?
Sir, this is Windows. This is not Android, this is not iOS, this is not macOS. Wait until you learn about the registry.
> this is not macOS.
From the first sentence of the featured article:
> If you’re using Windows or macOS
Also, Microsoft has attempted to reign in and standardize app developers on numerous occasions over the past couple of decades, and their failure to do so doesn't impact my statement regarding the direction of app development in general (or the weaknesses of people doing whatever they want on Windows).
> In which case, how else would you propose doing it?
- Registering an url handler?
- Asking the user?
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.
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.