- From: Brad Porter <brad@tellme.com>
- Date: Tue, 14 Nov 2006 12:34:33 -0800
- To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Cc: public-wsc-wg@w3.org
My personal feeling is that if the implementation sandbox is tight and users have good control of their personal data, turning on and off browser capabilities should not be required. Active or passive content should not matter so long as the access granted to that content is properly restricted (even potentially restricted to the number of CPU cycles a page can steal). If we can assume that, then we can operate at the sandbox layer instead of the feature layer. In my opinion, the need to turn off browser capabilities is due to poor sandbox implementations. Poor sandbox implementations are due lack of clear sandbox requirements. In my opinion, this incremental approach to the security sandbox has lead to both the security problems, and the user interface problems we have today. --Brad Stephen Farrell wrote: > > > Folks, > > What I was trying to explain earlier. I realise that this > is at least borderline, but wanted to ask the question in > any case. I believe this corresponds to ACTION-3 from > today's meeting. > > XPath and similar languages are effectively almost programming > languages and can therefore potentially badly affect the end > user. In contrast with Java/Javascript these are less likely > to have separate content types or browser settings/controls > that the user can set and understand. > > I don't claim to know the answer, but the question relates to > these examples of sort-of-active content - should WSC consider > these in the same way as Java/Javascript or not? And either way, > what's the boundary between passive and active content? (I > assume we'll need some description of "active" content that > users have to be more careful about.) > > These technologies may also be worth considering if we think > of the user's machine a a DDoS attack vector. (Attack web > server, modify content to include dodgy XPath expressions that > attack someone. Innocent browsers rip away.) > > Stephen. > > > > > >
Received on Tuesday, 14 November 2006 20:34:55 UTC