A few ideas:- one of the dangers is that flavours may be damageable... so the general practice would be that, unless we're in a de-sandboxed region (anything else than file://?) all flavours should be sanitized (e.g. no scripting, no relative reference, no embedding, except for pack- embedded data, no remote calls)
- another danger is that the clipboard should not be read without the user knowing, I would recommend, as Safari does, to only allow the standard gestures within the user-agent to be triggering clipboard operations which in turn, offer access to the clipboard.
To my knowledge, this is enough for a model that can be trusted to the users.
I am not very comfortable with the suggestions of trust-level that João Eiras suggests (having played with them in MSIE always prompts the unknowledgeable user to boost things a bit more in case something doesn't work which I find a catastrophic attitude) although I fully agree that we are here talking of either the central user clipboard and or the content of a drag-and-drop feature (i.e. we are talking of acting with external applications as well).
paulLe 09-mars-09 à 02:36, Web Applications Working Group Issue Tracker a écrit :
ISSUE-85 (clipops security practice): What are common sucrity practices for Clipboard APIs? [Clipboard Operations]http://www.w3.org/2008/webapps/track/issues/85 Raised by: Charles McCathieNevile On product: Clipboard OperationsWhat are the common security restrictions and considerations that should be listed in the clipboard apis spec?
smime.p7s
Description: S/MIME cryptographic signature
