Jonas Sicking wrote: > So I'd prefer to keep things simple in the initial release and simply > not expose SMS, and instead focus finding secure ways of exposing it > in a later release.
Do we support sms:+123456789?body=hello%20there links correctly? (Opening up the SMS application with the message and recipient pre-filled.) I think that many applications that would need to send SMS would be able to make do with sms: links, so to me seems like a good idea to do as Jonas recommends. I don't see any developer or customer considering the lack of an automatic SMS API to be a deal-breaker. I think we're being way too reliant on straight-up permission prompts. Doing what the iOS 4+ does [1], providing a way to reasonably integrate the SMS UI into your app, seems way better to me than exposing an API that brings up an annoying prompt. (Perhaps irrationally, permission prompts always seem more annoying to me than "preview" prompts, which I frequently like as a user as they are re-assuring.) Lucas wrote: > Keep in mind that per the model Privileged apps require review and > approval, plus the user is prompted before the app has any access to > the SMS API (additionally, we expect that any app requesting this > API would also provide an "intended usage", which would in turn be > reviewed and approved). It is too early to say how effective these measures will actually be as a security mechanism as we have no real-world experience with any of these features. Given the privacy and financial risks associated with the feature, I think it is prudent to do iron out the wrinkles in our security mechanisms in a production release first. Cheers, Brian _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
