Re: Problem with stopModalWithCode on a different thread
Re: Problem with stopModalWithCode on a different thread
- Subject: Re: Problem with stopModalWithCode on a different thread
- From: Bill Appleton <email@hidden>
- Date: Wed, 23 Jun 2010 07:16:14 -0700
> Plugins don’t impose themselves, nor are they invoked by a user; they’re
always invoked by content on a web page. The user might go to that web page
specifically to use the plugin, or it might be a side effect, but the
mechanism is the same regardless.
there is a big difference between navigating through an enterprise class
single sign-on gateway to invoke a subscription application and going to CNN
and seeing the dancing mortgage guy. did you really want to "invoke" the
dancing mortgage guy?
> Note that web plugins are more susceptible to attack than regular apps
because, once installed, they can be invoked and run _automatically_ by web
content, with absolutely no warning and no permission needed by the user.
not with the DreamFactory Player. the users sees the app come down, who
wrote it, where its coming from, and they can cancel it. any questions? just
go check the security log maintained by the player that tells everything the
developers app has been doing. this ruins the attack vector. QuickTime is
almost like this as it is used today.
> This makes web plugins probably the most potentially-dangerous type of
software you can install
this comment also sounds like the pot calling the kettle black. consider all
the different flavors of web browsers X all their different versions over
time X all the different operating systems X all the hardware differences.
That is petrabytes of source code running on the client written by dudes
from all over the world that you don't even know. its all software.
On Wed, Jun 23, 2010 at 12:19 AM, Jens Alfke <email@hidden> wrote:
>
> On Jun 22, 2010, at 7:49 PM, Bill Appleton wrote:
>
> > i am pointing out that there is a giant, giant, giant difference between
> plugins that impose themselves on the user and those that are invoked
> because the user wants them.
>
> Plugins don’t impose themselves, nor are they invoked by a user; they’re
> always invoked by content on a web page. The user might go to that web page
> specifically to use the plugin, or it might be a side effect, but the
> mechanism is the same regardless.
>
> > all of the security stuff you are talking about is appropriate for the
> former. all of this security stuff just makes users of the latter pissed
> off.
>
> No, the ‘security stuff’ is appropriate regardless. If a bunch of people
> install your plugin, and if someone were to find a security hole in it that
> lets them do something nasty to your computer, then websites would
> inevitably pop up that invoked your plugin and exploited the bug.
>
> Note that web plugins are more susceptible to attack than regular apps
> because, once installed, they can be invoked and run _automatically_ by web
> content, with absolutely no warning and no permission needed by the user.
> The user might not even know that it’s running. This makes web plugins
> probably the most potentially-dangerous type of software you can install.
>
> > this is absolutely key. we have 10 K companies that desperately need a
> simple way to install and use our player. this is mission critical for them.
>
> Simplicity and convenience don’t usually go along with security,
> unfortunately. For example, ActiveX was a very simple and convenient way to
> extend the web experience (in MSIE on Windows at least), and it became a big
> part of why Windows had so many security problems.
>
> —Jens
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden