On Mon, Aug 6, 2012 at 3:30 PM, Brian Smith <[email protected]> wrote: > 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 don't know, but I agree it's something we should support. > 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.) I think you forgot to include the [1] reference. > 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. Very good point. / Jonas _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
