Our project could benefit from support for password-like fields within the flow of a form itself. I believe a couple small enhancements could help improve the experience and avoid saving passwords in cleartext:
Addition of a "password" appearance for text fields to hide the value as it is being typed.
Possibly (unless there's a workaround), the addition of a "no-send" (or similar) appearance that would prevent the value from being sent to the server when the form is finalized. This could be useful for other "intermediate" values that the form designer doesn't need or want to be sent to the server, but that are still useful for logic or other calculations within the context of a form.
What do others think? Would one or both of these features be more generally useful to the ODK community? Thanks in advance for your feedback!
This is only something we could do as an appearance, the underlying value would still be saved to the form.
We try to be really explicit to end users (the folks with the devices in their hands) what protection they are being given. Would replacing typed characters with * possibly give a false sense of security given that the password would still be saved to the form in clear text? On the other hand, the most likely "attack" is someone looking over a shoulder so maybe this would feel reasonable. We could also recommend that form designers using this technique also use encryption and don't allow saving drafts. I'd like to get other opinions on this.
You may also be interested in a strategy like the one in this example. I don't know whether you'll find it clever or hacky but the concept is to blank out the clear-text password after it has been entered. You could also replace it with the digest of the password or even a string of *. I haven't verified this extensively!
What's the primary underlying need? Pruning sensitive values as described above, limiting the amount of data sent, making analysis easier, something else?
Something you could do now is use relevance. Nodes that are not relevant are not included in the submission. You could do something like have a "ready for submission" question at the very end of the form that if set to 'yes' toggles the relevance of all the nodes you want to prune.
Some things to note:
all dependent calculations are re-run with blank values for those newly non-relevant values. You could use trigger and/or once to make sure calculated values are retained.
any kind of removal of fields from the submitted record may make edits difficult.
Aside, there is actually already an XForm element spec'd for this exact purpose: https://www.w3.org/TR/xforms11/#ui-secret, although AFAIK its not currently implemented/supported by Collect or Enketo.
This is a very different topic so let's consider it separately if it is seeming valuable to others.
Unfortunately, there's an attempt at an implementation in JavaRosa/Collect and what it does is replace the submitted value by asterisks instead of changing its display.
Given this existing implementation, that we don't want to overstate the level of protection the feature provides, and that this masking is only a UI concern, I think we should introduce a new appearance for it. That would also make it possible to apply to integer fields which could be helpful for pins.
We propose calling this appearance masked. This name doesn't imply any level of security and describes what the appearance does: it masks the actual input being provided by the user.
If this proposal sounds good, we will implement it in the upcoming release of Collect.