Responses to various ideas on how to get people to stop using that leaked build


Some time ago, I told the story of how we used psychology to get people to stop using a leaked build and upgrade to a newer build. People had suggestsions for other ways this could have been done.

One suggestion to avoid the problem in the first place was to have internal builds refuse to activate from an IP address that is not assigned ot Microsoft. This would stop people from installing and activating a build, but of course you can use a build without activating it, and by resetting the activation timer, you can extend the lifetime of an unactivated system to quite a few months. That's quite a few months of potentially messing up the Internet.

So you might say that internal builds should simply refuse to run unless activated. That would prevent these systems from getting off the ground. Unfortunately, it would also prevent our software development partners from installing and activating the builds. Hardware partners wouldn't be able to develop new drivers for the upcoming version of Windows to take advantage of whatever new features are being added. Software partners wouldn't be able to send the Windows team feedback on a proposed new feature, and they wouldn't be able to have an updated version of their software ready to go on release day.

Another suggestion was to have Windows perform an online check at startup to determine whether the build has been declared "fatally broken", and if so, refuse to boot or at least time-limit the build so the user can upgrade to a non-broken version before time runs out.

Well, first of all, that solution would have to be applied retroactively. Somebody ahead of time would have to convince management to devote engineering effort (as well as dedicate bandwidth in our servicing stack) to handle the case that a build at some point in the future needs to be blocked. Seeing as nothing this horrific has happened before in the thirty years of Windows, it might be a hard sell.

Besides, even if such a feature were implemented, you could imagine the PR disaster if it were discovered or deployed: "ZOMG Windows has a remote kill switch!"

And then there were the suggestions to do something that Microsoft was already doing.

"Maybe it's the time to put up somewhere a disclaimer that a build not intended to be public is more likely to corrupt the system, malfunction or not even boot, and it's better to wait for a proper build from Microsoft to the public."

Yup, that's what Microsoft does. You see that statement any time somebody asks for a comment about a leaked build. It goes roughly, "We don't recommend installing unofficial builds because who knows what's in them."

Another superfluous suggestion was to include a warning in all pre-release builds saying that, you know, it's a pre-release build and anything can happen.

Yup, that warning already exists for pre-release builds. But the warning has been around for so long that people have gotten inured to it and don't pay it much heed. It has sort of become the boy who cried wolf: Every single pre-release build comes with this warning, and every single pre-release build manages not to destroy your computer.

Another suggestion was to announce that the build contains a potentially fatal flaw that could cripple your computer and disrupt any networks it is connected to. "We don't care how you acquired this build. We simply do not want you bricking your computer."

People would probably say, "Wow, Microsoft is really worried about this build. There must be some secret feature in that build that they don't want us looking for, and they're using this lame excuse to get us to stop using that build. Hey everybody, make sure you keep your ISOs because there's gold hiding in there somewhere!"

And they'd be right, too. Because the feature that had the fatal flaw was not yet publically announced. If you're installing leaked builds, it's because you're the sort of person who wants to get at non-public information, and unannounced features are the best kind of non-public information. This is basically an announcement that says, "Hey everybody, I strongly recommend that you crawl through every single option dialog you can find, because buried somewhere is going to be a new checkbox that reveals an unannounced feature. Happy hunting!"

The Windows team ultimately decided to solve the underlying problem of people itching for builds in a different way: Make the internal builds public, via the Windows Insiders Program.

Bonus chatter: Ultimately, most of the proposals ended up just over-engineering the solution. If you can solve a problem in ten minutes with psychology, what's the point of spending hundreds of hours trying to solve it with technology?

Comments (12)
  1. DWalker07 says:

    Yep, the Windows Insiders builds are pretty cool. I have seen some things that don’t work quite right, but I knew that could happen, and the problem is not fatal, just cosmetic. I only run an Insider build on one of my five computers.

  2. Shaftway says:

    I mean, I wouldn’t have commented on the psychology approach, but now I feel like I have to engineer a solution… On boot (or maybe on screen unlock), require someone type in constantly changing text, forcing them to read and type something:

    This is a pre-release build and may be broken. To continue type ‘prerelease-{random 16 characters}’:
    ┌──────────────────────┐
    └──────────────────────┘

  3. Martin Bonner says:

    If you can solve a problem in ten minutes with psychology, what’s the point of spending hundreds of hours trying to solve it with technology?

    But, but, but …. we should revoke your programming licence for that!

  4. cheong00 says:

    [what’s the point of spending hundreds of hours trying to solve it with technology?]
    Maybe someone would get a nice bonus because of that? [/j]

    Btw, if I were really assigned to solve this problem with technology, I’d simply make the internal builds can’t live without a debug symbol server on local subnet. You know, for nearly all the intended purpose of internal builds, you want to work with debug symbols. And for those who have it, I think it could be safely assume they understand the consequence to use leaked internal builds for daily use.

    After that, just make the ver.exe on these machines show the current and latest available build numbers is good enough.

    1. That would mean that internal builds “phone home” (look for a debug server), which is bad PR. It would also prevent internal builds from being used outside of the Microsoft corporate network, which means (1) developer partners couldn’t use them even though we want them to, and (2) we wouldn’t be able to test domain controllers and other things which need to run on an isolated network.

      1. Doug says:

        >That would mean that internal builds “phone home” (look for a debug server), which is bad PR

        It’s not like windows already does that

        /snark

      2. cheong00 says:

        That’s why I say “debug symbol server **on local subnet**”. In that case it’s much like KMS. When that is acceptable, I can’t see why it is not.

        And btw, I’m not stopping them to use “localhost” as debug symbol server if that’s applicable.

        1. cheong00 says:

          Okay I now understand what is missing here… a debug symbol server relay much like WSUS to the public Windows Update server.

          1. cheong00 says:

            Now think about it a bit, it sounds like something with (dubious) value to have such debug symbol server integrated with PXE boot server so they download the selected internal build images along with corresponding debug symbols. When need to test something on latest build, just use the UEFI boot option menu to select PXE boot then install a newer build of Windows. ( https://technet.microsoft.com/en-us/library/2008.07.desktopfiles.aspx ) Sounds convenient enough to worth all the trouble to install such server to me.

      3. DWalker07 says:

        I disagree that symbols are needed. One purpose of the Windows Insider program for Windows 10, as far as I can tell, is to let people who understand that they are using prerelease software, to look at the early iterations of new features. It ‘s not always (or only) for debugging.

        1. cheong00 says:

          Compare and contrast “leaked builds” and “public previews”.

          “Public previews” are intentionally released to public for the said testing purpose and it’s intended audience are general users. In the other hand. “leaked builds” are nightly builds or builds sent to vendors for driver/application development. The purpose is different. Even testers for QA will want debug symbols in order to generate more meaningful dumps.

  5. MarcK4096 says:

    I think they made a great decision moving to the Insider program.

Comments are closed.

Skip to main content