Hey -- this is all good stuff! I'm definitely a bit less cynical about this topic now.
Thanks for the virtual turn-around! On Wed, Mar 5, 2014 at 5:41 PM, Kyle Sluder <k...@ksluder.com> wrote: > On Wed, Mar 5, 2014, at 02:57 PM, Quincey Morris wrote: > > I agree with the earlier post which said (more or less) that if it's your > > job to demo stuff, then it's also your (your company's) responsibility to > > provide a non-secure demo platform, or a non-secure account. > > Take Luther's app out of the equation. > > Due to plenty of circumstances beyond the control of the user (timeouts, > etc.), it may be necessary to reauthorize to some service during the > course of presenting data via AirPlay. There is *no way* to securely use > passwords in combination with AirPlay. > > This is a design problem that falls under the same umbrella as "bad > defaults". The user can optionally cancel whatever password prompt has > appeared (and keep canceling if the software in question persists in its > demand), disconnect from AirPlay, enter the password, reconnect to > AirPlay, and return to the place they left off. > > But that's cumbersome. Instead, the software encourages the user to > enter their password live and on the air. > > As I opined in an earlier thread, when AirPlay is engaged > UISecureTextField should disable echo of the last character. Thanks > Quincey for reminding me that the balloon keycaps should also be > disabled. > > --Kyle Sluder > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
