Le 2 août 09 à 17:24, Colin Holgate a écrit :

I don't think that the plugin should insist on asking the user for permission to load content from the web

My personal tought :

Yes, as long as this web contents can only interact with the user without any local-filesystem access, but only as inside the plugin runnable code and medias.
No, in any other cases.

The way that Flash works with writing local content works well. Flash can, by default, write up to 100k of local data without asking for permission. The user can increase or decrease that at any time.

But in terms of real ability to fill very unfriendly code to the client-side computer, 100 k is enought to kill anything of the local file-system and even the hard-disk it-self by speeding it up until it definitivelly crash via a 6ko sniplet. So, if 100 k is enought to kill and hack anything, both, the Java or Flash security models are only non-sense in anything else out of marketing considerations.

In my humble advice, as a real honest team, management and company, RunRev know and does exactly what need to be done to protect the client-side computer and i think for my own that they are just doing the best of what need to be done.

On the other hand, i would appreciate to be able to avoid the display of any local-file system access autorisation demand, each time i purpose a plugin-app witch don't interact in any way with the local file system (updating it-self via post, get, realtime video-streaming, video-conferencing, etc...) even if to stay fluent in terms of user's experience, this need for me, to be able to save its personal plugin's preferences to my own server, instead of in writing them to its local file-system.

"Mes deux centimes d'Euro" ;-)

Pierre

--
Pierre Sahores
mobile : 06 03 95 77 70
www.sahores-conseil.com




_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to