Lucas Adamski wrote: > I'm not sure we have any disagreement then. Per > https://wiki.mozilla.org/WebAPI/Security/SMS showing a user > confirmation is a recommended mitigation, so *if* we could implement > something like: > explicit permission for SMS access + OS confirmation on send > - would that work?
I expect that <a href='sms:+1234567890?body=hello%20there'>Send SMS</a> should open up a pre-filled SMS message, even in untrusted web content. And, I guess that must be what the intent mechanism does. Would calling send() with "OS confirmation on send" be different, UX-wise? If it would be the same UX, I think it would be better to simply avoid exposing send() to non-certified apps, to encourage developers to use the same mechanisms that are more likely to work cross-browser (sms:) and/or that work without being "privileged" and which we could potentially implement easier in a cross-platform way (intents). This way, send() would not operate differently depending on the privilege level of the app. Also, I just now understand that there's not a separate permission for reading/deleting existing SMS vs. sending new SMS. While I think there are not many apps that want to read/delete messages but do not want to send them, I think there are quite a few use cases for being able to send an SMS but never needing to read/delete them. And, there are significant risks to allowing an app to read SMS (e.g. the two-factor authentication and password reset cases already mentioned on the wiki, and general privacy risks). So, I recommend separating the permission for sending from the permission from reading/deleting. Cheers, Brian _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
