Rufus Entwickler hier.
Die Dinge sind so viel einfacher, wenn man sich ein Problem nicht genau anschaut.
Der Grund, warum wir die Bootloader nicht außerhalb der Hauptpartition verschieben konnten, ist, dass bis zum Windows 10 Creators Update einfach 2 Partitionen auf einem Wechseldatenträger nicht zugänglich waren, während die überwiegende Mehrheit der USB-Flash-Laufwerke für Verbraucher wechselbar und nicht fest ist (und dies ist eine Hardware-Eigenschaft, die also nicht durch Software geändert werden kann).
Das bedeutete, dass wir zwar gut wussten, dass man eine NTFS-Partition auf einer Seite und eine FAT32 mit den Bootloader-Dateien auf den anderen haben könnte, dies aber praktisch ohne einen großen Hack nicht möglich war. Man müsste eine temporäre VHD irgendwo auf der Benutzerlaufwerkes erstellen, die Dateien dort aufteilen und dann diese Partition Sektor für Sektor zurück auf den Datenträger schreiben.
Die bessere Lösung bestand also darin,
UEFI:NTFS zu entwickeln, was all das löste. Dafür mussten wir einen NTFS-Treiber schreiben. Den haben wir aus einer GPLv3-Quelle erstellt. Microsoft weigert sich jedoch, diesen aus Gründen, die keinerlei Überprüfung standhalten, für
Secure Boot zu signieren. Also mussten wir letztendlich, statt Microsoft wegen offensichtlichen Machtmissbrauchs anzuprangern (denn wenn man die Bedingungen der GPLv3-Lizenz tatsächlich liest und insbesondere Abschnitt 6 über das "Übermitteln (von) Nicht-Quellformen" und die tatsächliche Beschreibung von "Installationsinformationen" und trotz dessen, was Microsoft behauptet, gibt es absolut KEINEN WEG, wie die Bedingungen der GPLv3-Lizenz jemals jemanden zwingen könnten, seine Secure Boot Signierungsschlüssel aufzugeben, solange das System Secure Boot deaktivieren lässt), den Entwickler von Rufus anzuprangern. Ich musste nachgeben und Monate damit verbringen, einen neuen NTFS-Treiber zu schreiben, den Microsoft akzeptieren würde.
Aber wie wir damals ausführlich erklärten (Rufus hatte eine Meldung, die auf einen FAQ-Eintrag verlinkte und detailliert darlegte, warum das vorübergehende Deaktivieren von Secure Boot kein so großes Risiko darstellt, im Gegensatz zu den Reflexreaktionen à la "Wie DARE du uns bitten, vorübergehend etwas zu deaktivieren, das 'sicher' in seinem Namen führt und daher sicher sein muss!"), sahen wir das immer noch als die bessere Lösung im Vergleich zu allen anderen Lösungen, die wir untersucht haben, denn alle anderen Lösungen, einschließlich der von dir vorgeschlagenen, hatten erhebliche Mängel für den Endbenutzer.
Was du als "3rdparty-Dateien" bezeichnest, hast du auch nicht genau angesehen. Was Rufus auf den Datenträger hinzufügt (was nur für BIOS-Boot, nicht für UEFI-Boot erfolgt), sind die Disk-Boot-Äquivalente der optischen Boot-ONLY-GRUB- oder Syslinux-Bootloader, die in ISO-Dateien zu finden sind, weil ohne diese das Medium beim Schreiben mit der Dateisystemübersetzung (was Rufus standardmäßig verwendet, im Gegensatz zum DD-Modus, für den eine ISOHybrid erforderlich ist und der wiederum weit entfernt von der Allheilmittel ist, das sich die Leute vorstellen) nicht starten wird, Punkt.
Und das sind Dateien, die wir generieren. Dies sind keine Dateien von Drittanbietern, die wir von irgendwoher herunterladen.
Die Behauptung, dass wir "Installer und Betriebssysteme patchen", ist genauso uninformiert von dir. Alles, was wir tun -- wieder einmal dank der Schönheit von Open Source --, ist dokumentiert und für alle sichtbar. Wir fügen eine bekannte Windows-Antwortdatei (für Windows-Umgehung oder Benutzerkonfiguration) zum Medium hinzu oder fügen bei Bedarf eine "persistent"/"persistence"-Option zu Syslinux/GRUB-Konfigurationsdateien oder aktualisieren den Referenzpfad zum Medium, damit das unveränderte Betriebssystem oder der Installer das Medium und/oder die persistente Partition finden kann.
Und ja, standardmäßig machen wir "Installer, die nur für BIOS/CSM oder UEFI funktionieren" (nur für Windows, Linux funktioniert für beide, und wir bieten eine Option, um Installationsprogramme zu erstellen, die für Dual-BIOS+UEFI für Windows funktionieren), weil wir behaupten, dass Microsofts Standardoption dort Probleme für Benutzer verursacht, und wir haben daher eine sehr bewusste Designentscheidung getroffen, Dual-BIOS+UEFI für Windows standardmäßig nicht zu aktivieren.
Abschließend, da wir entgegen deiner Aussage die UEFI-Installer nicht verändern, wie sie von den Quellmedien bereitgestellt werden (es sei denn, du möchtest über UEFI:NTFS sprechen, aber das ist kein Installer, und selbst wenn das der Fall ist und trotz des sehr öffentlichen Issue-Trackers berichten die Leute aus irgendeinem Grund offensichtliche Inkompatibilitäten mit vielen älteren Laptop-UEFI-Implementierungen nicht), dann solltest du bei Unverträglichkeiten mit vielen älteren Laptop-UEFI-Implementierungen nicht fälschlicherweise annehmen, dass Rufus daran Schuld ist, sondern dich an die Personen wenden, die diese Installer erstellt haben.
Zum Abschluss bitte verwechsle nicht "gesunden Menschenverstand" mit "Übervereinfachung, die in sich zusammenfällt, sobald man genauer hinsieht".
Ah, und für Leute, die immer noch Fragen zu Rufus und Sicherheit haben, kann ich nur empfehlen, unsere sehr umfangreiche Security Page zu lesen, in der wir ausführlich erläutern, warum du Vertrauen in Rufus haben solltest (und warum du uns nicht einfach beim Wort nehmen musst, sondern diese Behauptungen tatsächlich überprüfen kannst).