`.interaction` files require `.in.download` and `.ans.download`

[mzuenni]

I implemented the changes from #540 for BAPCtools and noticed that the changes imply that .interaction files require .in.download and .ans.download. So every multipass and interactive problem suddenly need this, and on all problems I tested these are just symlinks, which is an annoying overhead. I also think this is not what we intended?

[niemela]

Yes, I mentioned this in the PR:

Note that this ended up requiring a .in.download and a .ans.download file if you use a .interaction file. This is not what we discussed, and maybe not what we wanted, but it kinda logically follows from the rest.

This is a logical consequence of the rules we wanted (that one must always override both or neither of statement and download), but it certainly not a requirement that we originally wanted.

When you start to think about this though, it kinda makes sense. Downloads are already broken when you use .interaction files. You certainly don't want to download the .interaction file, so that easy (and clean) solution doesn't work, it could be the .in and .ans, but quite often it isn't. It could be the in and out "halves" of .interaction, but not always. It could also be "nothing", but again, not always.

I'm not at all against fixing this, but it's not clear how?

If we don't require download to be overridden when using .interaction, then there must be a logical default. What is that?

[mzuenni]

the default that was used for all legacy problems was that the .interaction does not overwrite downloads, i.e., even if there is a .interaction you get the .in as download and the .ans (which was always empty).

[niemela]

the default that was used for all legacy problems was that the .interaction does not overwrite downloads, i.e., even if there is a .interaction you get the .in as download and the .ans (which was always empty).

My assumption was that is kinda broken (most of the time). Is it not?

[Tagl]

My assumption was that is kinda broken (most of the time). Is it not?

Yes, the sample .ans file may include some "secret" information about how the output validator functions. I would say most of the time it is not an issue though.

[mzuenni]

My assumption was that is kinda broken (most of the time). Is it not?

This not an issue for any GCPC or NWERC problem in the past 5 years. The .in file was always identical to what the testing tool wanted and the .ans file was always empty. That is the reason why i think the current change is bad.
(BAPCtools even enforces that the .ans file is empty for interactive problems since you can just put that data in the .in)

Even for the BAPC problems that used the interactor just to be able to randomly generate .in files this was not an issue since those did not use .interaction (those problems don't actually mention that they are interactive).

[Matistjati]

For reference, the default in Kattis is that .interaction implies that .in and .ans are not downloadable. The Swedish IOI selection has depended on this historically to not leak data.

I personally think it's at least a little bit of a footgun to have the default be to make .in and .ans available for download. With Kattis' UI, most people never realize that samples are available for download at all. So I could easily see a beginner judge assuming that their .in and .ans files in sample are safe, since they don't show up in the statement. And leaking such things could be very bad. For example, BAPC 2023King of the Hill has descriptive strategy names such as sparse-diagonal-zigzag or sparse-spiral.

IMO, the fact that we disagree is exactly the reason why you should be forced to specify it. It's a tiny annoyance that ensures higher quality. Personally, I'd gladly make that trade-off.

[Tagl]

I think a good default, if any, is the input and output part of the interaction. Should be easy to generate that as well.

…

On Sun, Dec 14, 2025, 03:14 Joshua Bergman Andersson < ***@***.***> wrote: *Matistjati* left a comment (Kattis/problem-package-format#542) <#542 (comment)> For reference, the default in Kattis is that .interaction implies that .in and .ans are not downloadable. The Swedish IOI selection has depended on this historically to not leak data. I personally think it's at least a little bit of a footgun to have the default be to make .in and .ans available for download. With Kattis' UI, most people never realize that samples are available for download at all. So I could easily see a beginner judge assuming that their .in and .ans files in sample are safe, since they don't show up in the statement. And leaking such things could be *very* bad (an extreme hypothetical being that the strategy is a string such as anti_matching or similar, which reveals a lot about the problem). IMO, the fact that we disagree is exactly the reason why you should be forced to specify it. It's a tiny annoyance that ensures higher quality. Personally, I'd gladly make that trade-off. — Reply to this email directly, view it on GitHub <#542 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB2ZBKSGZOVVB3J7HZVEBTD4BTIXZAVCNFSM6AAAAACO6S7MS6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMNJQGEZDSOJSGM> . You are receiving this because you commented.Message ID: ***@***.***>

[mzuenni]

If other people do not want a default/use a different one, I am fine with having no default (and I prefer it over extracting stuff from the .interaction, that is not really consistent since .statement files are no longer used as override for download).

I assumed that most people write the testing_tool in a way that it uses the same input as the sample and than just ensure that the sample is non adversary/do not leak strategies.

[Tagl]

That does assume you have a testing tool. It's not always the case, and also not always the case that the contents of the .in file matches what you'd provide the testing tool. I do feel like the safe option is to force the one setting up the package to explicitly provide what the downloaded files should contain.

…

On Sun, Dec 14, 2025, 14:34 mzuenni ***@***.***> wrote: *mzuenni* left a comment (Kattis/problem-package-format#542) <#542 (comment)> If other people do not want a default/use a different one, I am fine with having no default (and prefer it over extracting stuff from the .interaction). I assumed that most people write the testing_tool in a way that it uses the same input as the sample and than just ensure that the sample is non adversary/do not leak strategies. — Reply to this email directly, view it on GitHub <#542 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB2ZBKX723L63T62J6XCZFL4BVYQXAVCNFSM6AAAAACO6S7MS6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMNJRGIZTAOJUGA> . You are receiving this because you commented.Message ID: ***@***.***>

[niemela]

For reference, the default in Kattis is that .interaction implies that .in and .ans are not downloadable. The Swedish IOI selection has depended on this historically to not leak data.

Right, but that's because in the legacy version there is no way to specify what should be downloadable, and the .in and .ans files typically contained secret information so the Kattis handling is a fix (or workaround) for this issue.

I personally think it's at least a little bit of a footgun to have the default be to make .in and .ans available for download.

Yes, I agree.

With Kattis' UI, most people never realize that samples are available for download at all. So I could easily see a beginner judge assuming that their .in and .ans files in sample are safe, since they don't show up in the statement.

Yes, this is the entire argument for requiring that you to specify what the download should be when you have overridden the statement (and I think it's a very sound argument).

In fact, when you put it this way, I'm starting to question if this needs to be symmetrical. I..e I think it makes prefect sense to say that you must specify what to do with downloads when you override statement, but the argument for having to specify what to do with statement, when you override downloads is not quite as clear. I can't really think of a good reason why you would want to override download and not statement though, and maybe that's the argument? Can y'all think of any such examples?

And leaking such things could be very bad. For example, BAPC 2023King of the Hill has descriptive strategy names such as sparse-diagonal-zigzag or sparse-spiral.

Yes, agreed.

IMO, the fact that we disagree is exactly the reason why you should be forced to specify it. It's a tiny annoyance that ensures higher quality. Personally, I'd gladly make that trade-off.

👍

Especially since it's very easy for tooling to help you with this.

[niemela]

I think a good default, if any, is the input and output part of the interaction. Should be easy to generate that as well.

Yes, that was the default I prefer if we have one.

That said, how often would it actually be relevant?

[niemela]

If other people do not want a default/use a different one, I am fine with having no default (and I prefer it over extracting stuff from the .interaction,

That's fair. Extracting "virtual" .in and .ans files from .interaction is a bit magic and arguably unexpected.

that is not really consistent since .statement files are no longer used as override for download).

How do you mean? What is it inconsistent with?

I assumed that most people write the testing_tool in a way that it uses the same input as the sample and than just ensure that the sample is non adversary/do not leak strategies.

I don't think that assumption is correct.

[niemela]

It sounds like the consensus is starting to coalesce on requiring explicit declaration of the download files. I.e. the current status quo.

[mzuenni]

Yes, I think so. Just one more question:

In the past it was fine to have a .interaction without a .in and without a .ans is that still valid (from my reading I would say no)