I have some files that say I'm the author (in the Windows file properties). I want to distribute these files, but I'll need a tool to change the authorship, because I want to be anonymous.

But I'm afraid that after I change it, if I copy the file onto the removable drive, it might revert to my name, because it would consider it to be a new file that I'm creating. If it does that, I'll have to change it again, but I do NOT want the file to have my information in it, while on the removable hard drive, even for a second, because supposedly there are ways to examine a hard drive to find what information used to be on it, and has been deleted or changed.

So my question is: will it revert the authorship, or keep it the new way I have changed it to, when I copy the file?

And by the way, is there an easy way to change the author for all new files I create, somewhere in the system settings? Please don't tell me I have to reformat the computer and reinstall Windows just to do that! The idiot who installed it in the first place put my name on it, even though I explicitly said NOT to do that!

There are many ways to interpret "authorship" here. Where, specifically, are you seeing the value you want changed?

The Explorer properties view (right-click a file, choose Properties) has a details tab that shows the owner, usually. This is not the same as "author" (it will generally always be the user of the computer, so it's not something that will transport your name along).

If you're looking at the properties of some DLL containing a C# assembly, you may be seeing values inserted by assembly attributes. You can just change the values of those attributes in your code if you'd like to change the displayed values; they're usually in AssemblyInfo.cs files.

Ownership information is stored on the NTFS filesystem metadata rather than the file itself. If your removable drive is formatted as MS-DOS than it should not retain the author metadata.

Another solution could be to zip up your files (in which case individual files will not store author details). If you encrypt your zip files then your data should also be very hard to recover.

If you upload to an FTP or upload site, this should also lose the NTFS author data.

One thing you might want to look into is using an encrypted filesystem. I rarely need to do this but when I do I tend to use this system on FreeBSD https://www.freebsd.org/doc/handbook/disks-encrypting.html

If you don't like your account name, you can either make a new account on Windows and use that. You can also remove the "RegisteredOwner" data from the registry at "[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion]"

Josh, but my question is, will it even try to revert to the old author, or not? And yes, I'm talking about in Windows properties. But that's a good point about the .NET assembly. I'll make sure to change that too. I hope that works.

Well thanks Karsten_, I'll look into that registry key.

As for encrypting and zipping and all that, it's not really an option, because I need to be able to put it onto removable storage, uncompressed, in the format that it will ultimately be used, so that the user can just open the EXE directly from there.

Edit: but wait a second. How can I edit attributes in the assembly programmatically? The assembly is part of the compiled program right? So the when my program runs, it's already compiled!

Josh, but my question is, will it even try to revert to the old author, or not?

No. If you give me a file through almost any likely distribution method, when I get it on my machine, I will be the owner of that file. Most methods of distributing files will not bring filesystem metadata like that, especially across local network boundaries; it doesn't make sense.

I need to be able to put it onto removable storage, uncompressed, in the format that it will ultimately be used, so that the user can just open the EXE directly from there.

In this case you are distributing the drive itself, which is an unconventional distribution mechanism. Depending on how the drive is formatted and configured, the filesystem may include metadata that identifies you. You'll likely want to change the owner of the files on the drive using the Advanced option under the Security tab visible when you view the properties of the drive in Explorer (or via a similar tool; you may be able to do this via the takeown command). Alternatively, choose a filesystem for the disk that isn't going to bring along ownership and permission metadata.

How can I edit attributes in the assembly programmatically? The assembly is part of the compiled program right? So the when my program runs, it's already compiled!

The assembly is a compiled thing, yes. But as I told you, the values of the assembly attributes are defined in source code. Just change them there; problem solved. It is possible to edit this data (which is embedded into the file) after the fact, using tools designed for that. But it's not necessary here since you have the source code.

No. If you give me a file through almost any likely distribution method, when I get it on my machine, I will be the owner of that file. Most methods of distributing files will not bring filesystem metadata like that, especially across local network boundaries; it doesn't make sense.

Yes, but I'm using my machine to copy the file onto the drive, so wouldn't it then exist on the drive with me as the author?

In this case you are distributing the drive itself, which is an unconventional distribution mechanism. Depending on how the drive is formatted and configured, the filesystem may include metadata that identifies you. You'll likely want to change the owner of the files on the drive using the Advanced option under the Security tab visible when you view the properties of the drive in Explorer (or via a similar tool; you may be able to do this via the takeown command). Alternatively, choose a filesystem for the disk that isn't going to bring along ownership and permission metadata.

What kind of file system? I'm using Windows 7, but it needs to be compatible with any version of Windows, and I'm not sure how to change the file system anyway, do I just reformat the drive?

The assembly is a compiled thing, yes. But as I told you, the values of the assembly attributes are defined in source code. Just change them there; problem solved. It is possible to edit this data (which is embedded into the file) after the fact, using tools designed for that. But it's not necessary here since you have the source code.

Okay, in that case, I guess what I don't understand is, how can the source code affect the compilation itself? How would it know to look in a specific function for a specific statement and then be like "oh, well now I'll compile differently"?

Yes, but I'm using my machine to copy the file onto the drive, so wouldn't it then exist on the drive with me as the author?

That does not matter for the cases I was referring to here (common distribution methods, which include things like uploading the file to some server or web host which users then download the file from). Distribution by USB thumbstick is not a particularly common way to distribute the software that most people on this board write (games).

In the upload, or similar, method, the contents of the file go to the remote machine. Not the metadata (such as who owns the file on your system). A file is created on the remote system, the web host, by whatever service account the webserver is running as. That account owns that copy of the file on that machine. When the webserver serves that file to some client via a browser download link or whatever, the browser, which is running under the user account of the operator of that machine, creates a file on the local disk. That file is owned by that account (again, the user of that machine) and the web browser fills it up with the contents of the file sent by the server (which does not include metadata).

What kind of file system? I'm using Windows 7, but it needs to be compatible with any version of Windows, and I'm not sure how to change the file system anyway, do I just reformat the drive?

Yes, reformat the drive. FAT32 is probably your best option. It doesn't support file permissions (they are determined by how the drive is mounted), and it probably doesn't support ownership metadata as a result, although I don't know enough to say for sure. No filesystem is supported by every version of Windows ever. FAT32 is old and creaky and mostly terrible, but modern versions of Windows will read it and it doesn't have file permissions.

You can also use NTFS (the likely default) and try to wipe out ownership of the file, assigning it to the Everyone or Administrators group using takeown, or to a dummy user.

Okay, in that case, I guess what I don't understand is, how can the source code affect the compilation itself? How would it know to look in a specific function for a specific statement and then be like "oh, well now I'll compile differently"?

Source code almost always has the capability to impact the compilation process, and certainly always directly contributes to the makeup of the compiled files. Languages like C++ and C# (although C# less so) have preprocessor directives that can control which portions of a source code file may be read. C++ has templates, which are a way to direct the compiler to perform certain transformations during the compilation process. Et cetera.

In this case, the things you are editing the AssemblyInfo.cs file are called attributes. They are a C# construct, you can identify them by the square brackets (in a context where arrays, the other use for square brackets, don't make sense). So, for example the copyright string attribute:

[assembly:AssemblyCopyrightAttribute("Whatever")]

The [] indicate an attribute. The "assembly:" indicates that the attribute is applied to the assembly. "AssemblyCopyrightAttribute" is the name of the attribute. ("Whatever") is the value; you can put whatever you want in here.

The C# compiler "knows" about attributes applied to the assembly and will write them into the correct place in the PE file (the DLL and executable file format used by Windows) when it produces the output file. It does this simply because it is written to do this; there's no particular magic.

You've asked the question a few weeks ago, with similar confusion.

Has this part changed?

I don't want anyone to know that I made the program, or various other files that the I or my program writes, hence the author name change, so I can be anonymous.

If you're putting it online then it has to be posted SOMEWHERE. While there can be a degree of anonymity through pseudonyms and masking yourself behind an IP address, anyone with sufficient resources can still track the source down.

You can avoid signing your name in the file by never typing in your name, but if you're distributing it on myvraccount.com it can be easily tracked back to you.

Even if you're posting through a computer at coffee shops or publishing from your public library, those with resources can still find you if they want.

The fundamental question of WHY, or what you hope to accomplish, is still unanswered. Who you are, or at least who your computer is, is fundamentally part of the Internet and can be tracked no matter what you do. Every internet-attached device can be identified uniquely, and there is no way around that part.

Understanding the real threat, the real people you are trying to protect yourself from, the real risks involved, that will help us understand what you are looking for. Protection from kids in school is easy. Protection from government agencies is not.

You've asked the question a few weeks ago, with similar confusion.

Actually, it was a similar question, but this one has other specific details.

If you're putting it online then it has to be posted SOMEWHERE. While there can be a degree of anonymity through pseudonyms and masking yourself behind an IP address, anyone with sufficient resources can still track the source down.

But I'm not putting it online at all.

Even if you're posting through a computer at coffee shops or publishing from your public library, those with resources can still find you if they want.

I'm not sure how that would be possible, but I would be VERY interested to know how?!

Understanding the real threat, the real people you are trying to protect yourself from, the real risks involved, that will help us understand what you are looking for. Protection from kids in school is easy. Protection from government agencies is not.

I want to give a removable drive to someone, which will contain a program and related files, and I don't want any eavesdropper who might steal the device or snoop and look on it to have any idea that it was from me, no matter how much of an expert hacker that person may be.

I'm not putting anything online AT ALL. And I don't want it to have my name attached to the files for any length of time, because if they're changed after they've been put on the drive, there may be residual information still there.

Edit: And Josh, I think I understand what you mean about changing the compilation attributes. I hadn't realized before that you were talking about a special file that's used for that purpose. I'll look into formatting to FAT 32. Are there any compatibility issues or other disadvantages to that? Most of the rest of what you said is with an inaccurate assumption that I'm going to be putting the stuff online, which I'm not.

I'm not sure how that would be possible, but I would be VERY interested to know how?!

It begins with an investigative budget of millions of dollars, perhaps tens of millions of dollars.

I want to give a removable drive to someone, which will contain a program and related files, and I don't want any eavesdropper who might steal the device or snoop and look on it to have any idea that it was from me, no matter how much of an expert hacker that person may be.

Who is the potential evesdropper?

If you are talking about a government (foreign or domestic) or major law enforcement agency who has already taken interest, then approximately 0% chance.

But honestly in the real world, nobody cares. Even moderately big organizations and prominent people can treat their everyday stuff casually.