1. 11

  2. 8

    Also note that guy develops SumatraPDF too, which is probablyy most safe (I mean, as safe as it can gets) and lightweight PDF reader for Windows, greatly overperforming hogs like Acrobat or Foxit.

    1. 1

      God, I remember when foxit was the “lean alternative” to acrobat. The bloatware ratchet turns again.

    2. 4

      This is one of the aspects of Windows that blows my mind. I mean, relying on each program to do its own updates? To provide its own installer and dependency management? That just seems like a recipe for disaster.

      1. 3

        And it is, actualy. Try to look on some Windows installations older than year or two, especially for non-IT people (to exclude saner options like Scoop, Chocolatey, NuGet…)

        1. 1

          It’s the same on MacOS (Mac App Store is a delirious thing, even more freaky than Java Web Start). Like on Windows, update servers are being hacked to ship malware with updates.

          1. 1

            Doesn’t MacOS have the same issue? As far as I know the only operating systems that handle this correctly are Linux distros and mobile operating systems.

          2. 5

            Agree with everything he wrote here, although I think some points are missing. In addition to “code” things there are also “cost” things - the things you have to pay for in order to give desktop software away for free. This is so jarring to me that I don’t do it, even though it’s expected and people will avoid using my software as a result.

            1. Get a domain for a long period of time. This is important because your software updater is going to talk to that domain, so it becomes part of a stable API contract.
            2. Get an SSL cert for the domain. This is also part of the API contract, so you might want to think carefully before relying on Let’s Encrypt.
            3. Figure out hosting. There are free options available, but since the updater is going to talk to it and it’s part of the API contract, think carefully before relying on a free host that can’t guarantee some kind of stability over time.
            4. Get a certificate for signing software. This is largely just to ensure users aren’t greeted with a big scary warning suggesting they shouldn’t trust your software, since the user won’t know you personally and can’t really infer trust knowing that software written by a random person on the Internet hasn’t been tampered with by another random person on the internet. Note a normal cert gives a somewhat less scary warning, an EV cert is required to establish real trust, and those are pricey.
            5. Write code in your updater to validate that any new update comes from the same source as the original. Since your cert has finite lifetime, this implies some mechanism for handling cert rollover where multiple certs are considered trusted but you somehow know they’re all for the same source. In a lot of ways this exists as a validation step to ensure that nothing has gone wrong in steps 1-4 above.

            Even though I can afford these costs, it really irritates me that people working on software for free are expected to pay hundreds per year for the privilege of giving it away.

            1. 1

              Why would you rely on SSL? It comes with costs you describe and it also means you have to secure your host.

              You can also use your own validation where the private key never leaves your personal laptop.

              1. 0

                Why would you rely on SSL?

                We’ve trained customers to expect that in a trustworthy website. Google is also penalizing non-HTTPS sites in search.

                1. 1

                  This is about the validation of a software package. There is no browser involved.

                  1. 2

                    Yeah, I was skimming comments too fast at work. My bad for that and forgetting to reply to you. Ok, software updater with TLS or (my change) some secure tunnel before update. I stand by the recommendation. Why?

                    Well, an update system should be simple. We know even simple code uses the things people get wrong. Like other networked services, it will be taking input from the most hostile network on the planet. Instead, we can apply the high-security pattern to make the updater ignore all network inputs except what it takes to create a secure tunnel between it and the trusted source. The code creating that secure tunnel will be rigorously-assured code. As in, it will probably be better able to handle attacks than whatever a random developer with unknown expertise wrote.

                    Memory-safe languages help but attackers are aiming for abstraction gaps. Maybe better to make the TCB for the networked system effectively the tunneling libraries. Even if attacked, these will probably have fewer attacks over time than the other code. So, malicious input (direct or tampering) goes to trusted component that hopefully drops it (no authentication), that component creates a tunnel when asked, and good inputs come in through it. That’s not just updates: anything that can allow that layer of protection.

                    1. 1

                      So I think I’m repeating what nickpsecurity already said, but note there are two distinct scenarios:

                      1. When updating software that is already installed, I’d agree that code signing largely supersedes SSL as a mechanism to ensure integrity of the updated payload.
                      2. When a user is seeking out software for the first time, they still want a mechanism to ensure that the code they’re downloading is from the source they intended. Code signing can’t help with that because (per above rant) it merely attests that it’s written by a random person on the internet, so if somebody could MITM a website they could easily have it download malicious code signed with a totally different certificate. SSL/TLS is the mechanism to protect against that. Obviously it’s imperfect though; it can’t do anything to detect a compromised server, for example.
                      1. 1

                        On some setups it is easier to use https than normal http.

                2. 3

                  I have no clue about Windows, but couldn’t you use the Microsoft App Store to implement website, installer, and update?

                  1. 2

                    No clue either but I’m pretty sure it’s more work.

                    1. Work around the MS app sandbox if the app does anything special
                    2. Register as a developer, pay $19.-
                    3. Submit the application, this requires to create artwork that fits their general guidelines
                    4. Get the app approved, this can take multiple tries
                    5. Once in a while they will change something to the store and your app will have to be tweaked and re-submitted.

                    Have fun reading this just to get started: https://docs.microsoft.com/en-us/windows/uwp/publish/

                    1. 1

                      Also, if your app is in WinAPI, prepare for additional levels of crutches. AFAIK, support for WinAPI apps in Microsoft Store appeared only recently, and it might be not mature.

                      Not sure if this “UWP” thing is not dead, along with “Tiles” and “Windows Phone”, and all real practical apps still use Win32 API.

                  2. 2

                    That’s all true, and a little annoying, but the annoyances to ship your own small-time web software aren’t that much less. You still need all of the server and SSL stuff. Fixing bugs will be much easier if you set up transport of your logs to some service instead of just logging to the drive. Ditto if you set up a reasonably automated deployment system, so you can update to address, say, security issues without following a 3-page error-prone checklist. You’ll probably need to write a couple of semi-custom SystemD scripts or something too. And secure automated database backup. Some level of monitoring and auto-alerting. Keep an eye out for security alerts in any of the software you use. Periodically check for package updates.

                    And that’s all for a single server. Things get tricker yet if you need more than one.

                    1. 2

                      I think the real comparison should be with shipping desktop software on an operating system that uses a package manager, like most Linux distributions, or even MacOS for the most part (Homebrew, MacPorts, or the App Store). You write the program and perhaps provide packages, or OS distributions package it themselves. Maybe you write some metadata for the “store” page like in elementaryOS, but that’s all.

                      1. 2

                        Maybe it depends on experience and personal preference, but I’d say the “taxes” on web development are much worse than desktop development. There’s server configuration, hosting, database configuration, a million flavor-of-the-week Javascript frameworks to choose between, the server side language/runtime, etc. and all of it has to be baby sat to keep up to date with security patches and bugs. And the entire setup has to be duplicated in a testing environment and on each dev machine.

                        And desktop development isn’t even as bad as the article makes it out to be. Like why write your own installer and logging library? Use an existing library unless you have a good reason. And auto-update is a Windows problem - Linux package managers and Apple’s App Store mostly solve that.

                        That does leave the product website, but that’s kind of open ended and depends on the situation. It could be 15 minutes to write some HTML and take a few screenshots, or in a big organization it could be a months long project designing a fancy web portal and integrating it into an existing site.

                        1. 5

                          Writing a desktop app for a single OS / arch is dead easy even for a web guy like me. VB6 came out in 1998 and is still a better development environment than exists for the web today.

                          The ‘tax’ on desktop development is getting people to use the damn thing (see kazlumeus for stats on that), and supporting multiple platforms, and syncing user data across their multiple devices.

                          1. 2

                            VB6 came out in 1998 and is still a better development environment than exists for the web today.

                            All while programmers condemn RAD tools, and glorify doing the shit work by hand. It’s embarrassing that you need to get a real programmer for simple applications (CRUD, formulae, API callers, whatever).

                            1. 1

                              It’s a shame that Yahoo Pipes didn’t survive. I saw a lot of really interesting projects that were effectively huge chunks of APIs glued together with it, and it feels like it was an idea which was ahead of its time.

                            2. 1

                              I don’t know how much stock to put in the Bingo Card Generator example. The UI works well as a website, and though I don’t know his market, I feel like generating bingo cards might be a one off thing for many people - I can understand them being hesitant to install and buy a desktop app for something they might not do again. And his app used Java, which meant downloading the JRE from Oracle (or Sun back then), and that obviously complicates things a lot.

                              Syncing user data should be the user’s responsibility, IMO. There are plenty of options (DropBox, thumb drives, network drives) for them to do it themselves if they want to. The app should make it easy, but shouldn’t be the one doing it.

                              Supporting multiple platforms isn’t terrible, and it’s not unique to desktop apps (i.e. Chrome vs Firefox vs Safari vs mobile browser, etc.). Qt, FLTK, and wxWidgets work great across platforms, have bindings to a bunch of languages, and can be bundled with the app in most cases.

                              1. 2

                                That’s a perfectly reasonable approach to sync for some apps; for others it’s entirely wrong.

                                For instance, I have no use for a todo list or note-taking that doesn’t sync automatically across devices.

                        2. 1

                          Reminds me of https://equinox.io/ which solves some of the problems he mentions for go programs.

                          1. 1

                            This is a great resource to prevent common mistakes and omissions. I have saved it for later use.

                            It did remind me how much nicer (how much lower the “tax” is) it is to develop and deploy desktop software than web-based applications, which was a welcome reminder this week.