Jump to content











Photo
- - - - -

Rufus 3.0 has been released

rufus

  • Please log in to reply
77 replies to this topic

#76 TheHive

TheHive

    Platinum Member

  • .script developer
  • 4186 posts

Posted 02 July 2022 - 10:14 AM

Rufus mentioned at
5:24

https://youtu.be/S9gQ4His98c

In order for someone to use the iso downloader, they need to allow updates when running Rufus. Otherwise there will be no options shown to download. Took awhile to read thru some people reporting this on another site and getting it to work.

#77 Akeo

Akeo

    Frequent Member

  • Developer
  • 358 posts
  •  
    Ireland

Posted 02 July 2022 - 10:52 AM

Yeah, the reason for that is that in order to download ISOs, Rufus downloads and runs a remote PowerShell script, and we consider that someone who chose not to enable Rufus to connect to the Internet to check for updates is very unlikely to want to have the application to connect to the Internet and run a script (NB: For those wondering how we secure this remote execution against malicious attacks, please see our Security Note about it).

 

In short, if you choose not to trust Rufus with updates (which are designed not to be in your face and can be set to be ran at a frequency of your choosing, so please don't serve me the "Oh but I only disable the check for updates because I don't want to be pestered by it"), it makes sense to consider that you choose not to trust the application to execute a remote script.

 

Oh, and I should also mention that there is a FAQ entry about this very topic.



#78 Akeo

Akeo

    Frequent Member

  • Developer
  • 358 posts
  •  
    Ireland

Posted A week ago

Rufus 3.20 has been released.

 

Per the Changelog, this is mostly a bugfix release, sprinkled with some improvements over existing features:

  • Enable applicable Windows User Experience options for Windows 10
  • Remember last Windows User Experience selection between sessions
  • Add automatic local account creation and regional options duplication (This is limited to creating an account with the same name as the current user and with an empty password that the user will be prompted to change after first reboot)
  • Add a workaround for ISOs that have a syslinux symbolic link to /isolinux/ (Knoppix)
  • Revert to offline insertion of registry keys for the TPM/SB/RAM bypass where possible
  • Remove storage bypass, since this is a bogus bypass that doesn't do anything
  • Improve BIOS compatibility when displaying the "UEFI boot only" alert message
  • Fix Windows User Experience dialog appearing twice for Windows To Go
  • Fix Windows User Experience options not being applied for ARM64
  • Fix Microsoft Account bypass not being applied unless TPM/SB/RAM bypass is selected
  • Fix overeager detection of GRUB2 bootloaders with nonstandard prefixes

 

With regards to the one thing of notice, which is the automatic local account creation and regional options duplication, I will mention the following:

 

If you use the option to create a local account, you will be able to skip the MSA account requirement of Windows 11 22H2 even if you are connected to Internet during setup (which is different from the MSA bypass, where you have to make sure that you are disconnected from the Internet to be proposed a local account creation).

 

And yes, I hear you: "Why not also let the user enter a name of their choosing for the account instead of duplicating the current name?"

The reason is mostly because this would require a significant UI change which, for varied reasons, it makes little sense to go through at this stage and also because it's super easy (barely an inconvenience) to change an account name once Windows is installed.

 

Especially, you need to understand that the established goal of these options is to streamline the OOBE process so that, if you do select Create local account + Duplicate regional settings + Skip privacy questions you should get straight into your first Windows logon after the PE phase is complete, without being prompted by anything. Oh and you sure won't have to answer Microsoft's obnoxious questions about your first pet name and whatnot when creating a local account (C'mon Microsoft, it's okay to admit that you're pissed off about not being able to harvest the user's juicy search and browsing history, instead of being passive aggressive about it by forcing people into answering bullshit questions).

 

In my opinion, this makes for a much nicer installation experience, as it's a lot better to sort out the rest of the customization from a final and fully running Windows environment, than from a bunch of "I'ma stop you right there until you give me an answer" unending sequence of prompts during setup (which actually is part of the reason I didn't even add an extra prompt to fill a user name for the local account in Rufus).

 

Oh and as to the reason why we create an account with an empty password, and notwithstanding the extra UI prompt element, it's primarily because, despite our best efforts to make sure that users can be assuaged that Rufus is 100% trustworthy, we're pretty confident that, the minute we were to ask users to fill in their Windows password into the Rufus application, we'd get a bunch of folks accusing us of collecting passwords in order to do something nefarious. Heck, you should just see some of the comments I get when yet another stupid antivirus finds nothing better than to flag a false positive against Rufus. So we just don't do that, to sidestep the whole issue altogether and also because it simplifies our code.

 

Plus using a blank password enables autologon on first boot, and we can easily force the user to set a password the next time they boot, which is what we did (so you will see that, even if you forget to set a password during that first session, you will be prompted to change the password after you reboot the machine).

 

In short, while I understand that there might be some misgivings about why the latest version of Rufus is doing things one way and not some other way regarding OOBE, I'd encourage you to give it a try before coming to a specific conclusion, because seeing how it works in practice, and how elements that you might be considering as showstoppers are actually not any roadblocks at all, might give you a very different view of why we settled on the current approach.

 

Finally, I will point out that, because applying these settings during the windowsPE phase would result in the loss of the regular initial Windows Setup screens (including the one that asks you whether you want to repair your computer), we only apply the locale settings to OOBE and not to windowsPE. This is usually not an issue, because there's really only one actual installation language provided in retail ISOs, so whatever is applied during OOBE (which includes administrative i.e. global regional settings) will override the PE choices anyway, so it doesn't really matter what you choose there...







Also tagged with one or more of these keywords: rufus

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users