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
