Adobe does fine despite there being plenty of alternatives to their products and the relative ease of switching to them. Microsoft does fine because they have a captive audience to abuse.
You don't even have to personally, many email providers were blocked by Microsoft for no apparent reason.
We lost critical emails because Microsoft decided one day that alerts from one of our companies was mass spam and started blocking them, after getting their emails daily for 5+ years.
That is one of the ways how Microsoft acts evil. Email was never supposed to be this way. You have zero visibility into why some emails are blocked. One thing is to quarantine emails / put them into spam. But to reject them without any proper technical reason (like wrong SPF) is a nightmare from sysadmin standpoint.
Yea, that's pretty shady. Either don't call your service unlimited or bump up the prices so you can survive occasional datahoarder, called them out on it many years ago.
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.
reply