Syd wrote: > Mail.app allows form submissions and users switching from Mail expect > similar behaviour with TB. > I understand the phishing risks but for enterprise apps, its critical > to have form submissions in mail clients. > Simple option is to have form submissions enabled via a preference, > and set it to disabled by default.
If it were up to me, I would avoid rendering <form> and related elements at all, similar to Outlook. This would be a much better UX than displaying the user non-functional forms. "Mail.app does it" isn't a very convincing argument, IMO. "Outlook does it" would be more convincing when considering enterprise use cases. From what I can tell from Googling around, at least Outlook 2007 and Outlook 2010 do not support HTML forms [1]. IMO, it is not reasonable to expect/require email applications--especially webmail applications--to safely and correctly support HTML forms. There are many potential security problems. For example, how would HTML forms with input type=password be correctly supported by webmail applications, given that web browsers would likely auto-fill said password fields with the user's email username/password? Right now they can handle this in a very safe way--simply add <form>, <input>, and related elements to their blacklists. In a world where email clients are expected to support HTML forms, they must implement much more subtle logic. Further, the user should be aware of what credentials will be in use in the submission of the form. This would require Thunderbird to determine which HTTP cookies and/or HTTP auth credentials and/or TLS client auth credentials would be used in the form submission, and it would require Thunderbird to somehow coherently display those credentials to the user before passing the request to the web browser. That is basically impossible to do. It is much safer to have the email contain a link to an HTML document that contains the form, so that the HTML application with the form can display the credentials that will be used. Also, webmail applications wouldn't be able to submit such forms if they use methods other than GET unless the target site supported CORS. And, also, there's no way to pass a non-GET request to an external web browser on the command line. This means that such forms would be limited to GET. But, this limitation would encourage developers that rely on HTML forms in email to mis-use GET to implement forms that have side-effects, which is bad. - Brian [1] http://msdn.microsoft.com/en-us/library/aa338201%28v=office.12%29.aspx _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
