r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Plugin-2] Browser Plugins

Pekr
15-Jun-2006
[1110x2]
it does not imo anything like that ...
plugin dll imo does not do anything, just starts View with some parameter 
.... it is View's get-net-info, which is outdated (look at the source) 
and incorrect. It looks at incorrect Registry setting
BrianH
15-Jun-2006
[1112]
I mean, once the security infrastructure is set up properly in a 
future version of the plugin, anonymous scripts shouldn't get a persistent 
sandbox at all, so there would be no place to put a user.r.
Pekr
15-Jun-2006
[1113x2]
that is why even normal View is not able to get control panel proxy 
setting
Brian's suggestion might work, but not sure Josh will do it, as he 
already suggested we should contact Carl, to fix View code involved 
...
Graham
15-Jun-2006
[1115]
ok, my bad understanding
Pekr
15-Jun-2006
[1116x2]
no persistent sandbox? what do you mean, please? Are you suggesting, 
that our plug-in apps, should not rely on local storage? I am not 
sure I like it ...
Imagine plug-in version of IOS. Currently the sand box is in Temp 
dir, which get's purged by control panel setting. I don't want to 
lose MY local data :-)
BrianH
15-Jun-2006
[1118]
I have gone over this before - the key word is anonymous.
Pekr
15-Jun-2006
[1119]
maybe I don't understand what you mean ....
BrianH
15-Jun-2006
[1120]
Josh's aforementioned secure source code was something I suggested. 
The other part of the suggestion was that every secure script would 
be cryptographically signed by an SDK license key, or some other 
way for RT to trace the author of the script. Only those signed scripts 
would be allowed to store persistent data in a sandbox without the 
attempt to do so prompting the user with a security requestor.
Pekr
15-Jun-2006
[1121]
so in your opinion, plug-in should not be allowed to write even in 
sandbox dir?
BrianH
15-Jun-2006
[1122]
Scripts that aren't cryptographically signed (anonymous scripts) 
would be limited in what they can do on your system.
Pekr
15-Jun-2006
[1123]
my question was a bit different, though. Let's imagine your proposed 
secure way, so I can use it for some app, to sync some data to user. 
The problem for me is the sandbox placement - in system Temp dir, 
which can be purged via control panel. I am not sure I like it, if 
there is possibility I could loose my synced data. Or am I missing 
something?
BrianH
15-Jun-2006
[1124x2]
Your last reaction to when I brought this up:

OK - one thing is clear now - "What would you let your worst enemy 
do with your computer?" should be a saying for Rebol plug-in .... 
now just how to represent it ...
My suggestion was just for anonymous scripts. Signed scripts could 
get a sandbox, probably somewhere under %appdata%.
Pekr
15-Jun-2006
[1126]
Did it take long time for you to dig it up? :-)
BrianH
15-Jun-2006
[1127]
I just had to look for the last point in the history where I posted. 
Security seems to be a recurring theme in my posts. :)
Pekr
15-Jun-2006
[1128]
btw - what do you mean by "should not get a persistent sandbox at 
all" - do you mean it should not be allowed to write to temp at ll, 
just use memory? Or just by anonymous you mean randomly generated 
"anonymous" directory somewhere in Temp directory?
Graham
15-Jun-2006
[1129]
Isnt' this a bit over the top?  What about cookies ?
BrianH
15-Jun-2006
[1130]
No, just use memory. No cookies except browser cookies - there should 
be a way to access them, similar to how do-browser lets you access 
JavaScript. Perhaps a wrapper function around do-browser could work 
for now.
Volker
15-Jun-2006
[1131]
although some storage for graphics-heavy things would be nice.
Pekr
15-Jun-2006
[1132]
Brain - are you suggesting so tight security for us rebollers only, 
or do also other plug-ins use such limited environment? (although 
I am starting to understand, that there should be NO way of how to 
harm your computer, or it will be regarded - unsecure)
BrianH
15-Jun-2006
[1133x2]
I don't want there to be any need for people to make a REBOL-blocker 
like FlashBlock or NoScript.
(both of which I use,  btw)
Volker
15-Jun-2006
[1135]
i would not go oncrypto only but also on "allow website", like noscript
BrianH
15-Jun-2006
[1136]
Yes, we need better security requestors too.
Volker
15-Jun-2006
[1137x2]
yes, and remembering such things. maybe asking on start to allow 
access to last session. if denied sandbox is cleared.
that is one extra click
BrianH
15-Jun-2006
[1139x2]
Volker, I agree that some graphics-heavy scripts could use local 
storage. Those scripts could easily be signed though.
There should also be a way to provide access to the browser's objects. 
The browser already caches those, and that cache is managed by code 
that the user is already trusting.
Volker
15-Jun-2006
[1141x2]
signing needs keys. then we need a free registry if we want all the 
newcomers to have fun.
and allowing access based on url is IMHO the most natural way.
BrianH
15-Jun-2006
[1143]
Actually, there is a lot that you can do even within those restrictions. 
Just look at Flash.
Volker
15-Jun-2006
[1144x3]
but there could be done more :)
speciallly when things start. later onecan optimize, but thefirst 
 protoype-bitmaps can be large.
and if you cancel "reuse last session" and check "forever" you are 
pretty much anonymous.
BrianH
15-Jun-2006
[1147]
Well then, the question you should consider when thinking about newbies 
is this: What would you let your worst enemy do with your computer? 
This is the web. We aren't talking about saints here - we are talking 
about people who use baner ads to install spyware.
Volker
15-Jun-2006
[1148]
I did ask. cant see doors for banner-adds nor spyware.
BrianH
15-Jun-2006
[1149]
Banner ads are on web pages. You can make banner ads with Flash, 
and that is less dangerous than the current plugin.
Volker
15-Jun-2006
[1150x2]
files are a risk to privacy if they cant be blocked. that reuse-question 
does this. and they can be prepared to be run, eg called *.exe and 
hoping the user some day clicks on them. so i suggest a wrapper, 
maybe store everything as rebol[]#{stuff} or in a single zip or something.
i thought we talk about local storage. what has that to do with banner-addds?
Pekr
15-Jun-2006
[1152]
wouldn't e.g. local storage limited to say 20 MB be sufficient "security"? 
Hmm, should read that Flash security doc first probably :-)
BrianH
15-Jun-2006
[1153x2]
As I've mentioned here before, there many nasty things you can do 
with the present plugin and I don't want to make suggestions on a 
web-public group. Go private if you want some ideas - I trust you 
not to misuse them.
I read the Flash security doc, and it has many good ideas. I'm still 
a little iffy about it providing cookies to anonymous scripts without 
providing a management interface - that's why I still use FlashBlock.
Pekr
15-Jun-2006
[1155]
how can cookie harm you?
BrianH
15-Jun-2006
[1156x2]
I mean Flash cookies - browser cookies do have a management interface.
Cookies can be used to track your movements, and can be used as persistent 
distributed storage.
Pekr
15-Jun-2006
[1158]
I trust you gurus for proper security concerns, however let's not 
forget us - the end users, where over complication does not work. 
Even Vista is being reduced in such regard - way too many obtrusive 
security requestors to users. In other words, - don't bother end 
user with questions he knows sh*t about their meaning anyway:-)
BrianH
15-Jun-2006
[1159]
Imagine if Google used the plugin for their ads - they would be able 
to store their whole database distributed amongst the computers of 
everyone on the internet. Would a security requestor be able to explain 
that to a newbie?