Lilt does have free reign, since this is the normal expectation for a command-line scripting language interpreter.
For Decker itself, everything potentially hazardous would definitely be packaged in an interface (sort of like rtext, sys, or app) so that decks can easily test for its presence or absence. Beyond this, there are several possibilities:
- Add a checkbox to the Decker menu that can enable or disable access at any time. Applications can whine at the user to check the box, but are powerless to modify the setting themselves. This is pretty annoying for users.
- Provide a function that must be called to enable access, which would prompt a user once (per deck-opened) to manually confirm. Still annoying, but less so than the above.
- Offer users esoteric rituals to opt into hazards: for example, creating a "lock-file" with a specific name relative to the decker executable and/or providing Decker with a command-line flag at startup. This has extremely low discoverability and so would be used only by experts, but would pose minimal annoyance to said experts. The major downside is that this would naturally have granularity for an entire work session, rather than scoping access to a specific deck.
- Instead, offer users similar esoteric rituals to opt-out, instead of opt-in.
- Offer a compile-time flag for including the hazardous interface. Similar to the above, but higher barriers to entry. A number of fancy IO features would be a lot easier to offer if I only had to do so for POSIX operating systems, and this would be a convenient way to avoid dealing with any of this stuff on Windows.
- Offer a compile-time flag for excluding the hazardous interface. A bare minimum affordance to the privacy/security conscious desktop user.