[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: ideas to potentially share some effort
From:       Martin =?iso-8859-1?q?Gr=E4=DFlin?= <kde () martin-graesslin ! com>
Date:       2010-12-16 17:41:31
Message-ID: 201012161841.38949.kde () martin-graesslin ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 16 December 2010 01:06:32 you wrote:
> > Very unlikely to happen.
> 
> So let me explain. We're implementing support for a new web technology
> called WebGL. In short, it's OpenGL ES bindings for Javascript. In
> practice, that means that malicious Javascript can execute OpenGL
> calls specially tailored to trigger/exploit a given driver bug. This
> is why:
You are mixing here to things: accelerating rendering and support for WebGL. I 
agree that WebGL can expose security issues, but this is not true to normal 
accelerating of web content. That's what my "very unlikely" refers to. I think 
it is impossible to trigger a crash just by writing the "right" Html/CSS/JS 
combination. Also for this aspect the crash on context creation would not be 
an issue if you are able to detect it.
>  1) the security aspect is much more critical in our case
>  2) potentially every driver bug can be triggered by javascript.
If that is an issue for you in the case of WebGL than you will never be able 
to deliver WebGL as you can never know that each and every driver on each and 
every system will not crash. Here you need IMHO an out-of-process 
architecture.
> 
> That's why we need to be super conservative about enabling this kind
> of features.
For WebGL yes, but not for normal accelerated rendering. Personally with my 
user hat on I prefer faster rendering than paranoid security.

Oh and just to let you don't think I comment on something I don't know about: 
I did my Master thesis at a security oriented computer science institute.

Cheers
Martin

["signature.asc" (application/pgp-signature)]

_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin


[prev in list] [next in list] [prev in thread] [next in thread]