I like conditional infohazard. I also think “Infohazard if true (but probably false)” is actually just not that long and it may often be best to just say the whole thing.
I agree that it’s not that long phonetically, but it’s longer in tokens, and I think anything with a word boundary that leads into a phrase may get cut at that boundary in practice and leave us back where we started—put from the other side, the point of having a new wording is to create and encourage the bundling effect. More specifically:
It seems like the most salient reader-perspective difference between “infohazard” and the concept being proposed is “don’t make the passive inference that we are in the world where this is an active hazard”, and blocking a passive inference wants to be early in word order (in English).
Many statements can be reasonably discussed as their negations. Further, many infohazardous ideas center around a concept or construction moreso than a statement: an idea that could be applied to a process to make it more dangerous, say, or a previously hidden phenomenon that will destabilize harmfully if people take actions based on knowledge of it. “if true” wants a more precise referent as worded, whereas “conditional” or equivalent is robust to all this by both allowing and forcing reconstruction of the polarity, which I think is usually going to be unambiguous given the specific information. (Though I now notice many cases are separately fixable by replacing “true” with the slightly more general “correct”.)
If you want to be more specific, you can add words to the beginning: “truth-conditional” or “falsity-conditional”. Those seem likely to erode to the nonspecific form before eroding back to “infohazard” bare.
This is independent of whether it’s worth smithing the concept boundary more first. It’s possible for instance that just treating “infohazard” as referring to the broader set is better and leaving “true infohazard” or “verified infohazard” as the opposite subset is better, especially since when discussing infohazards specifically, having the easiest means of reference reveal less about the thing itself is good by default. However, that may not be feasible if people are indeed already inferring truth-value from hazard-description—which is a good question for another comment, come to think of it.
I like conditional infohazard. I also think “Infohazard if true (but probably false)” is actually just not that long and it may often be best to just say the whole thing.
How about a “Schrodinger’s Infohazard?”
I agree that it’s not that long phonetically, but it’s longer in tokens, and I think anything with a word boundary that leads into a phrase may get cut at that boundary in practice and leave us back where we started—put from the other side, the point of having a new wording is to create and encourage the bundling effect. More specifically:
It seems like the most salient reader-perspective difference between “infohazard” and the concept being proposed is “don’t make the passive inference that we are in the world where this is an active hazard”, and blocking a passive inference wants to be early in word order (in English).
Many statements can be reasonably discussed as their negations. Further, many infohazardous ideas center around a concept or construction moreso than a statement: an idea that could be applied to a process to make it more dangerous, say, or a previously hidden phenomenon that will destabilize harmfully if people take actions based on knowledge of it. “if true” wants a more precise referent as worded, whereas “conditional” or equivalent is robust to all this by both allowing and forcing reconstruction of the polarity, which I think is usually going to be unambiguous given the specific information. (Though I now notice many cases are separately fixable by replacing “true” with the slightly more general “correct”.)
If you want to be more specific, you can add words to the beginning: “truth-conditional” or “falsity-conditional”. Those seem likely to erode to the nonspecific form before eroding back to “infohazard” bare.
This is independent of whether it’s worth smithing the concept boundary more first. It’s possible for instance that just treating “infohazard” as referring to the broader set is better and leaving “true infohazard” or “verified infohazard” as the opposite subset is better, especially since when discussing infohazards specifically, having the easiest means of reference reveal less about the thing itself is good by default. However, that may not be feasible if people are indeed already inferring truth-value from hazard-description—which is a good question for another comment, come to think of it.