Yes I agree. I'm saying that validating the entity goes a long way toward assurance. People are much less likely to dupe a user if everyone knows who they are.
Nothing is perfect, but it can be improved. - Brill Pappin Sent from my Samsung Captivate(tm) on Rogers Dianne Hackborn <[email protected]> wrote: >As far as I know, Verisign and other cert authorities are primarily >validating that the entity holding the certificate is who they say they are. > That is not what you seem to be looking for. You seem to be asking for >someone to independently assure users that code signed by the authority will >not be malicious, however one wants to define malicious (and defining >"malicious" is just the start of the problem). This is a much larger can of >worms. > >On Mon, Jan 17, 2011 at 12:17 PM, Brill Pappin <[email protected]> wrote: > >> Oh i don't know... not that I like the SSL certificate system, but it does >> seem to work and i think they do stand by their issued certificates. >> In that case its a bit easier because they don't verify that the server >> running the ssl cert is not malicious but they do verify the entity that >> requested the cert so that in the even that something was hinky, the >> responsible party would be known and valid. >> >> Come to think of it, one of the existing cert providers (Thawte, Verisign >> for example) could jump into this business with such a service, but Google >> would need to play nice with them. >> >> The goal being to smooth the customers experience so they have a good one >> and not make them feel that they may have just been ripped off when they >> can't figure out how to enable the thing, so any method of doing that is a >> good one as long as it can't be readily abused. >> >> Right or wrong, people trust companies like Google not to screw them over. >> Most people are not like we are; skeptical, savvy and watchful. >> >> I think I like the idea of being able to rate the entity producing the >> software as well as the app itself, that way people like us would discover >> poor or malicious code fairly quickly and flag it. Maybe something like >> eBay style of entity rating would be enough (which would also identify >> companies known to be poor at supporting their software). >> >> The long and short is that I have two IME's in the market and I would >> really like to be able to give my users some assurance that I'm not stealing >> their personal data besides my word on it. >> >> - Brill Pappin >> >> >> >> On 2011-01-17, at 2:42 PM, Dianne Hackborn wrote: >> >> It would be entirely possible for other people to do that kind of >> application verification, if they want. I wouldn't want to do this as a >> certificate, indicating the app gets some special trust relationship with >> the platform -- that puts "the good stuff" in the hands of whatever party is >> controlling access to that certificate. I don't think you should want >> Google or anyone else to be that kind of gate-keeper. >> >> (I also have an intrinsic dislike of such things, because in fact the >> amount of verification that anyone is actually going to be able to perform >> on an app is quite small. There are so many ways for someone who is truly >> malicious to get around such verification, by timed enabling of the activity >> and other things. I think these things give users a much greater sense of >> trust than they should actually feel. Unless the entity is going to stand >> by their verification with a guarantee that they will recompense for any >> damages caused by apps they have verified... and how likely is that? That >> tells you how worthwhile they are.) >> >> On Mon, Jan 17, 2011 at 11:22 AM, Brill Pappin <[email protected]> wrote: >> >>> Thats a good point :) >>> However launching the settings would actually be helpful and exactly what >>> I've been meaning to look into. Combine it with adding a convenient text >>> field they can long-click in should help. >>> >>> I do get a lot of people rating-down or complaining because they didn't >>> read the warning and think that it's telling them I *am* stealing their >>> credit card info! >>> Usually when people write in asking why I capture their data, i have to go >>> on a long explanation which essentially boils down to "It doesn't, but there >>> is absolutely no way i can prove it to you". >>> >>> As a developer and one who will sell more and more in the Market, I really >>> wish there was some sort of "Verified" certificate I could purchase that >>> would indicate to the user that a 3rd party has checked the app for >>> nefarious code. >>> As a user of Android, I'd really feel better with that as well, because >>> some of the apps I've downloaded make me wonder sometimes. >>> >>> In order to put something like that in place, Google would need to support >>> it, the likelihood of which most of us would not hold our breath for. >>> Maybe what would work is some sort of reputation rating for the publisher >>> rather than just the app. Or maybe some sort of rating like we used to have >>> to use for our mail servers when we were getting a lot of spam from a >>> certain IP block. >>> >>> - Brill Pappin >>> >>> >>> On 2011-01-17, at 12:40 PM, Dianne Hackborn wrote: >>> >>> On Mon, Jan 17, 2011 at 7:44 AM, Brill Pappin <[email protected]> wrote: >>> >>>> Yah, I've had a tone of trouble with my users not understanding how to >>>> enable to my IME's. >>>> I don't want to do it for them however. What would be good is a way to >>>> allow them to click buttons in my app to enable it. >>>> >>> >>> Um. Buttons in *your* app is very much doing it for them. :} >>> >>> You can use this to launch the settings app where they can enable/disable >>> IMEs: >>> http://developer.android.com/reference/android/provider/Settings.html#ACTION_INPUT_METHOD_SETTINGS >>> >>> To be honest, there is good reason to *not* make this super easy, because >>> if a user can't figure out how to select an IME to enable, there is a good >>> chance they also aren't going to get the deep security implications and >>> trust they need to have in whatever IME they are using. >>> >>> -- >>> Dianne Hackborn >>> Android framework engineer >>> [email protected] >>> >>> Note: please don't send private questions to me, as I don't have time to >>> provide private support, and so won't reply to such e-mails. All such >>> questions should be posted on public forums, where I and others can see and >>> answer them. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Android Developers" group. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> For more options, visit this group at >>> http://groups.google.com/group/android-developers?hl=en >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Android Developers" group. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected]<android-developers%[email protected]> >>> For more options, visit this group at >>> http://groups.google.com/group/android-developers?hl=en >>> >> >> >> >> -- >> Dianne Hackborn >> Android framework engineer >> [email protected] >> >> Note: please don't send private questions to me, as I don't have time to >> provide private support, and so won't reply to such e-mails. All such >> questions should be posted on public forums, where I and others can see and >> answer them. >> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Android Developers" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/android-developers?hl=en >> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Android Developers" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected]<android-developers%[email protected]> >> For more options, visit this group at >> http://groups.google.com/group/android-developers?hl=en >> > > > >-- >Dianne Hackborn >Android framework engineer >[email protected] > >Note: please don't send private questions to me, as I don't have time to >provide private support, and so won't reply to such e-mails. All such >questions should be posted on public forums, where I and others can see and >answer them. > >-- >You received this message because you are subscribed to the Google >Groups "Android Developers" group. >To post to this group, send email to [email protected] >To unsubscribe from this group, send email to >[email protected] >For more options, visit this group at >http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
