Simplest way to make missing tiddlers display:none or visibility:invisible?

[Springer]

@TW_Tones

Or here there could be a private encryption key rather than a password, used to decrypt the students private information for use only in the browser memory.

Please note that one thing that drove me to the current permaview-iframe approach is that I do NOT have to create, disseminate, and manage separate encryption keys for each student (egads, there are dozens… and they would have to be separate, since one central point is to give students a reasonable sense of privacy vis-a-vis their peers, when it comes to things like exam grades).

Instead, the “virtual tiddlers” in each student’s permalink hash include two different numeric strings plus a text string (all pulled from the LMS with help of generico plugin), and I create a key (for use in list fields) based on a mathematical function that leverages these student-specific strings.

Putting this non-recognizable key value into list fields, etc., allows “back-door” access via filters (and these filters only produce results when the right permalink-tiddlers-at-startup conditions are met — again unless someone with TW savvy does some set-field operations, which means hacking past the read-only css).

Since students don’t even see the url of their iframes (not without an enormous deal of hacking the LMS), they don’t easily know what their starting metadata points are… And, since they don’t know the “secret sauce” that converts their unique combination of LMS user-metadata into a keyfield, I believe the privacy is reasonable. (That is, a user might be able to deduce what their OWN key value is and see where it appears within JSONs in source code, they can’t easily reverse-engineer WHY their key value is what it is, nor how to crab-walk from appearances of their own key value string (in source code) to connect others’ online results to any meaningful student-specific string found on the university servers. )

Good enough for banking security? No. Then again, my office windows, where grades appear in paper form, aren’t secured like the windows of banks either.

[Scott_Sauyet]

@TW_Tones

@Scott_Sauyet

To log into the latter you have to have the password matching that student id, as recognized by the school.

• Or here there could be a private encryption key rather than a password, used to decrypt the students private information for use only in the browser memory.
• See encrypted tiddlers.

The only way I know to make that secure would involve a different form of encrypted tiddler than is available now. The students would have to generate their own public-private keys, distribute the public one to the professor or somehow to the back-end system, and make sure that they keep track of their private keys. Then the back-end could encrypt the tiddlers with their public keys so that the students could decrypt them at the appropriate time. This is all well-trodden ground, but it more work to administer, bloats the shared wiki with lots of data irrelevant to the user, and has a serious issue if it’s used like the current encryption, where you would need to re-encrypt the tiddler before saving your changes or risk others seeing it.

My suggestion is simpler for the students, for the professor, and probably much simpler to code as well. It does not have to use the query parameters; that is only one possible scheme. But the main point was that something like this would require that the client not try to repurpose the query string. By doing so, you’re making undue assumptions about what the back-end might want to do.

@Springer

Please note that one thing that drove me to the current permaview-iframe approach is that I do NOT have to create, disseminate, and manage separate encryption keys for each student (egads, there are dozens… and they would have to be separate, since one central point is to give students a reasonable sense of privacy vis-a-vis their peers, when it comes to things like exam grades).

As we’ve discussed off-line, I think there are probably decent ways to do this without Rube Goldberg tooling, and at some time, I would like to look into them. But I really doubt it will be before next semester starts.

@TW_Tones

But we are again straying from the OT.

Long ago. I’m sorry, I started us down a path entirely irrelevant to the original question.

[Springer]

@Scott_Sauyet

I started us down a path entirely irrelevant to the original question.

In a sense, yes. But also — as @TW_Tones frequently points out — many posts start with a surface question (“How do I produce a certain behavior? (How can I put missing tiddlers below the radar in read-only mode?)” … but the thread needs to turn toward a deeper question (“How best can TW meet this need?” How best to reveal different tiddler/template subsets to distinct viewers based on their different iframe URLs?").

Encryption-oriented solutions do count as a change of subject (for this thread’s purposes), but everything about hashes vs query-strings, and how these might best be handled so that end-users (with their iframes) get a consistent tailored experience (including intuitive in-frame refresh handling if possible) is all on target.

[TW_Tones]

In all of the methods discussed here @Scott_Sauyet and @Springer there are dozens of different branches and methods we can deploy. For each approach a tweak or mechanism can be found, whenever an objection can be raised. I could contest some of the implications in both your replies, but we are now so “deep in the weeds” I doubt it is of too much value responding.

• If you want to discuss it in more detail or seek new ideas I suggest a fresh thread with your own specific requirements laid out so we can eliminate unnecessary branches.