Wabbajack-opt-out-of-modification-plan.md

Goal

To provide a method by which Wabajack can assist mod authors in maintaining creative control over their mods while still allowing for more rapid installation of mods

Current issues

• Users can download a mod, change it and create an installer with Wabbajack that publishes these changes via binary patching this goes against usage restrictions for "no modifications of this mod are allowed".
• Users can extract BSAs with Wabbajack, going against warnings for no BSA extraction
• The nexus doesn't seem to provide a good way to track a modder's desire to not allow end users to modify their files
• Wabbajack allows downloading from 3rd party sites that does not maintain author's rights. We currently have a "who cares" attitude, which isn't condusive to collaboration with the modding community. It would be good to improve this situation.

Plans for solving these issues

• Wabbajack maintain a list of authors/mods who have opted out of allowing their mods to be modified.
• This list will be editable via a GitHub PR (a hassle for authors), or by including a magic string WABBAJACK_OPT_OUT_OF_MODIFICATION (or something similar) to their mod summary page.
• Wabbajack will query this info during compilation and refuse to binary patch or extract BSAs for any mod in this list.
• Wabbajack will switch to using code signing for releases, and a non-exe distributed modlist. Modlists will become serialized blobs of data, and not executable code. This means users will know when they are using a unofficial build. And thus someone disabling these content control features will create a modlist that no official Wabbajack build will install.
• Wabbajack will scan files from 3rd party sites to try and find matches with the "opt-out" list. This matching will be done via SHA256 (not very useful) and via filename. So if author modder334 has opted out and his mod contains modder334s_immersive_cheese_reborn.esp, Wabbajack will never create a modlist that downloads opt-out files from a 3rd party site.

I don't know if this sort of thing helps but most mods on Nexus have a permissions box that looks like this right now: https://imgur.com/DVZZLC2 These options are set by the authors in their mod pages. Unfortunately that only works with mods that aren't using a custom message like USLEEP does. Ideally Nexus would include a way for API queries to be made to ask the site directly about these things. Most of us would just settle for them including a server-side opt-out for any mod authors who don't want their mods being downloaded with these tools at all.

Code signing is definitely a good idea. Right now trying to install your tool is completely blocked for a lot of Windows 10 users due to a UAC prompt that it won't let you bypass. Myself included. It's something I wasn't aware needed doing with the USLEEP installer either. It never hit me with a prompt when checking the exe.

I'm not sure what you mean by scanning 3rd party sites, but the more obvious solution to all of this is just to disallow the use of that sort of thing to begin with since it only promotes the use of pirated content. It's a very rare thing in Bethesda modding to find people using Mega or Mediafire for example. Not when they have reputable places like TESA and AFK Mods to use if Nexus doesn't suit them.

Thanks for taking the time to reply.

I agree, if the nexus adds a option for "don't patch or unpack this file" then I can use that instead of going through other hoops.

As far as 3rd party sites go, I'm fine with disallowing MEGA/Mediafire. But there are legitimate mods published via Google Drive (like 3DNPCs). This isn't an all or nothing point though, we could dis-allow MEGA/Mediafire and stick with only supporting Google Drive/Dropbox and Direct HTTP links.

The 3rd party scanning is this: if we know the files you (a mod author) produce, and know you've opt-ed out of allowing modifications to those files, then we can detect when those files show up in a link from a 3rd party site and refuse to download them. We already hash every file in every BSA and archive so it's possible to detect when a user has taken a BSA apart and uploaded part (or all) of it to Dropbox/Google Drive/or whatever.

Most of us would just settle for them including a server-side opt-out for any mod authors who don't want their mods being downloaded with these tools at all.

That will be the sticky part of this conversation, and one I hope we can reach some middle ground on: if Wabbajack can enforce a no-modification/no-reupload policy on these files, is it acceptable to auto-download them from the Nexus? It seems that in that case we start to standardize on a world where users of mods don't modify mods on their own machine, and exchange they get a faster setup and install experience.

There's reason to be leery of Google Drive and Dropbox too unless the mod author themselves is specifically promoting those avenues over the use of others, but in general those are regarded as likely safe whereas Mega and Mediafire are generally assumed to be illegitimate.

I can't speak for other authors on this, but I think if Nexus meets it halfway and offers additional permission options that specify a no-modification and no-reupload policy (they already do, but hook them into the API) then I could live with Wabbajack being able to download the file. I just don't like the idea that this kind of download system strongly marginalizes the mod authors to the point where you end up with a community devoid of diversity like Minecraft.

Rather ironically, it's quite possible for Wabbajack to pull up the mod page before downloading and look at the Nexus permissions for the mod.

That would require opt-out authors to use the Nexus permissions system, however (I notice that USSLEP has custom permissions). But we can still provide a github repo for tracking permissions for those who want more fine-grained control.

If I were to implement this, it seems like this would be a logical interpretation of the existing Nexus rules:

• Upload permission
  You are not allowed to upload this file to other sites under any circumstance
  • (if set to no) Wabbajack would not download these files from anywhere but the nexus.
• Modification permission
  You are not allowed to modify my files, including creating bug fixes or improving on features under any circumstances
  • (if set to no) Wabbajack would not build patches for these mod files. BSA packing would be allowed (on the user's machine), but BSA un-packing is modification of source files, and so would be prohibited.
• Conversion permission
  You are not allowed to convert this file to work on other games under any circumstances
  • (if set to no) Wabbajack would not use these files in a modlist for another game (e.g. no porting from LE to SE)

Other situations Wabbajack handles that would need to be considered

• Smashed patches
  • Still require the source patch and simply provide better merging of records that given by default by the game engine. This would be allowed in all situations
• Hand-built patches
  • Not much we can do to track this except tell mod list authors to put them on the nexus and let the normal moderation system on the Nexus run its course.
• Merged Patches
  • This is like a smashed patch, but the originals are disabled. Allowing this seems unlikely to be a problem because most patches that would be merged are conflict resolution patches that normally have very permissive licenses.
• ESL flagging, form 44 conversion
  • This is modification, and will not be allowed unless modification permission is set to ok on the nexus
• LE to SE conversion via .nif conversion or BSA repacking
  • This is modification, and will not be allowed unless modification permission is set to ok on the nexus
• Making money with Wabbajack installers (and hence mod files)
  • Always forbidden.
• 3rd party sites
  • I realized today that xLODGen seems to be distributed exclusively through MEGA. It might be possible to white-list certain files for well known tools and mods. More thinking to do here.

Thanks for reading this, I'm really like where this is heading.

I've looked at quite a few mod licenses on the Nexus today, and it looks like this system would work for most cases.

ESL flagging, form 44 conversion

This is something you probably shouldn't attempt even if someone allows it. The CK needs to be what process the form conversion from 43 to 44. 3rd party scripts should never be trusted to handle this process correctly.

I agree, making those changes outside of CK is a bad idea, which is why Wabbajack uses binary patching instead. After the conversion/edit has been made on the modlist creator's machine, Wabbajack can compare the changed esp to the original from the nexus. This results in a patch that can be used to create that same result on a consumer's machine by applying the patch to the same file from the Nexus. WJ verifies this process afterwards via hashing the result. So in essence, WJ doesn't know anything about ESPs, nifs, dds files, etc. All it sees is that a file changed from the original downloaded archive, and it patches it. The one game file type WJ *does* understand is BSA files. Those are quite simple, and so we have our own logic for extracting and creating those files.

…

On Sun, Sep 29, 2019 at 1:25 PM Arthmoor ***@***.***> wrote: ESL flagging, form 44 conversion This is something you probably shouldn't attempt even if someone allows it. The CK needs to be what process the form conversion from 43 to 44. 3rd party scripts should never be trusted to handle this process correctly. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://gist.github.com/56e84beb1f985264648efb5f0f8cfdc9?email_source=notifications&email_token=AAE72HKGSRSG5VKUCNDBOQLQMD6JRA5CNFSM4I2U3VB2YY3PNVWWK3TUL52HS4DFVNDWS43UINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAFZSV4#gistcomment-3040606>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAE72HOQ2UTEE2MAFV3IIIDQMD6JRANCNFSM4I2U3VBQ> .

-- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth)