CC: Tweaked 1.97.0 added ability to upload files via simple drag and drop method directly into computer file system.

It was pointed out to me today that it allows someone with access to gui to overwrite the startup file even if current state of terminal would normally don't allow them to have any meaningful interaction. (Per example: running program that ignores user input and terminate event)

Would it make sense to either give ability from lua code level to disable drag and drop mechanic to disallow adding/overwriting files.
Or change how it works so that drag dropping file is a event that is handled by active shell prompt instead of something that happens in background. So uploading file(s) will only work in shell or if user of alternative shell supports/allows it?

Or is this whole thing not something that should really be considered an issue?

Yeah, I guess this does allow you to bypass a password door lock by overwriting the startup file and rebooting, which is not great. I'm not really sure what best to do about this:

• Some sort of option would definitely be possible. We can't easily read .settings on the Java side of things, so I guess we'd need some sort of function like os.setOption("allow_file_upload", false), which is Not Great.

• Events are a really nice idea in theory, and allow for customising behaviour (you could imagine dropping a file putting it in the current directory instead).

  What I'm not sure how to do here is handle the UX from the user/GUI side of things. For instance, if the current shell/program doesn't support file uploads there wouldn't be any feedback - the event will just be silently dropped. To be fair, this is pretty similar to how many real-world programs work, but doesn't feel great UX.

File uploads are really tricky to deal with is because they kinda break the fourth wall in acknowledging there's a computer "outside" of the CC one. The current setup kinda tries to handwave it away by making it part of the GUI and invisible to CraftOS. I don't really know of a good solution which really preserves this though.

Maybe instead of root, all files go into a subfolder? CC already has 'magic' folders, disk and startup come to mind, so one that kinda behaves like Bluetooth received files folder on Android phones is not out of place. Having an event could still be useful, maybe to preserve the current behaviour craftos moves the file to root by default when it receives the event.

Question is.. Do we need to preserve backwards compatibility for something that is handvawed and invisible by craftos? I mean just having a /uploads folder be place where all uploaded files go would solve all security issues. Everything else is something for user to implement if they want.

Yeah, this is a workflow change, so it's not going to break any programs - which is what I'm more worried about.

This may be the best solution we've got, though I don't feel great about it. We're still kinda acknowledging the presence of an upload system, which bleh.

Having an event could still be useful, maybe to preserve the current behaviour craftos moves the file to root by default when it receives the event.

I don't think we can really do this and have overwrite protection at the same time.

What if the drag and drop feature is implemented as a pullEvent which the shell pulls. This means any programs running would stop the shell from getting the event, but the drag and drop could also be used in text editors to drag in text, or files in-memory.

Although I don't believe the shell would react to the event, something like multishell could simply pass the event to the underlying shell of the open window, and that would react to the event if it was in the shell mode.

One way to be able to have the UI with events would be to drop the file at a temporary path, then queue an event with the temporary name as well as the real name that CC received once the file has completed uploading, at which point the shell or BIOS can move the file into place if allowed (or delete the file). This is similar to how iOS handles selecting photos: it copies the selected photos into the app's sandbox in a temporary location, then triggers a callback with the temporary path as well as some other metadata, including the canonical name of the file if present.

It may also be possible to have the shell report blocked files in the GUI by sending the event right after the upload completes, then waiting to report success/failure until the yield after the event is sent to the computer (or alternatively a tick-based timeout to avoid long pauses). If the temporary file still exists, the upload succeeded, and if it doesn't, the upload failed. (This would require waiting to delete the temporary file on success until after the next resume, however.)

One temporary workaround while we're hashing this out is abuse the fact that file uploads only write to the root directory and put any 'important' files in subdirectories.

So in practice:

• Create an empty startup.lua (and possibly .settings too) directory.
• Move your startup file to the startup/ directory.

Hmm settings folder sounds interesting, then the top level part of the setting name (bios in bios.strict_globals for example) might be the file name. Could make it easier to wipe the settings of a program.

all computers don't suddenly have a sandbox escape

When did this happen?

Sorry, I'm talking about the file uploads. I don't like the fact that it bypasses all running programs. I would much prefer it be something external like a disk that computers already have the option to ignore.

Maybe you could instead support file uploading to disks when you have the item in your hand. That way they can be used more like real disks + all computers don't suddenly have a sandbox escape

all computers don't suddenly have a sandbox escape

When did this happen?

File uploads are really tricky to deal with is because they kinda break the fourth wall in acknowledging there's a computer "outside" of the CC one.

I think it's worth noting that the paste event already does this. A file upload event wouldn't be too different. In fact, adding file dragover events as well (all with screen coordinates) could make for some pretty powerful experiences. For example, a file manager that allows you to drag and drop files into any directory on the system. And plus that wouldn't compromise the security of door locks or other similar programs.

Convenience and security would then outweigh the possible fourth wall concerns, in my opinion.