5 ms·

There's a WebGL talk at WWDC 2014

117 points by daredevildave 12y ago

0x0 12y ago
Wild speculation: iOS 8 will bring an out-of-process, heavily sandboxed webview, which was the missing piece for enabling webgl for everyone. The greatly increased attack surface (with almost direct gpu access via shaders etc) was too risky to host in in-process web views - explains why webgl was only enabled for iAds (since those would be vetted by a review team)
- pirateking 12y ago
  Going along with your plausible speculation, and assuming XPC is used to communicate with the WebGL view (using UIRemoteView maybe), hopefully that means opening up the XPCKit framework as well in iOS 8.
  - masklinn 12y ago
    Finally having XPC would be really great for application and tools developers.
- twoodfin 12y ago
  Would be nice to get something similar for in-app JavaScript JIT'ing.
  - Flow 12y ago
    Or a standard way to use sandboxes from within your apps. So you can do on-the-fly code generation.
  - rsynnott 12y ago
    Arguably, such a solution would make Javascript JITing safe, too.
- higherpurpose 12y ago
  I wonder if Firefox will remain the only browser out there without a process sandbox. It's still the most vulnerable browser because of that: http://www.extremetech.com/computing/178587-firefox-is-still-the-least-secure-web-browser-falls-to-four-zero-day-exploits-at-pwn2own http://www.extremetech.com/computing/178587-firefox-is-still...
  - erickt 12y ago
    It is coming soon. Firefox Nightly has it as an option, and according to this it's supposed to be an option in Firefox 30. I'm not sure when it will be turned on by default though: https://wiki.mozilla.org/Electrolysis https://wiki.mozilla.org/Electrolysis
    - bgirard 12y ago
      Electrolysis is NOT sandboxing, full stop.
      - cowchase 12y ago
        To cite the wiki: "sandboxing the content processes is a separate project from Electrolysis". So Electrolysis lays the foundation for sandboxing.
        bgirard 12y ago
        It's true. It wont provide anything on its own so I'm trying to be blunt to kill this misconception that keeps spreading.
  - bgirard 12y ago
    We were talking about this yesterday. I asked how many of the previous issues we classified a security problem would of been mitigated by a sandbox and the conclusion would be that it would not even cover the majority. Most of the security issues we encounter are with bugs in the driver. A common bug for example with the Intel mac driver is when sending allocating a valid large texture the texture will sometimes instead be filled with old gpu memory[1]. Then you can glReadPixel the data and reconstruct parts of the desktop windows or tabs. A sandbox isn't going to stop you from exploiting this kind of buggy driver if it incorrectly starts returning other people's data when you asking for unrelated valid commands. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=631258 https://bugzilla.mozilla.org/show_bug.cgi?id=631258
- shadowmint 12y ago
  > The greatly increased attack surface (with almost direct gpu access via shaders etc) was too risky to host in in-process web views What really? Were they seriously even pretending to use that excuse? Everyone I've ever talked to was 100% certain it was simply because they didn't want anyone by-passing the app store for games and other immersive content they would then have no control over. I'm not denying that webgl is an attack surface; it totally is; but surely it's a bit rich to say that the webgl implementation in webkit has been switched off for the last 3 years because of security concerns. If that was the only reason to not having feature parity with other OS's, they'd have some something about it.. oh, you know. 2-3 years ago.
  - coldtea 12y ago
    >Were they seriously even pretending to use that excuse? Everyone I've ever talked to was 100% certain it was simply because they didn't want anyone by-passing the app store for games and other immersive content they would then have no control over. Well, "everyone you ever talked to" was wrong. Apple could not care less about web apps by-passing the app store in this regard. For one, they initially offered web apps in place of a native API, and developers (and users) hated it. Second, they had for the longest time (still do IIRC), the fastest and more complete web browser experience on mobile. Including extra JS hooks for things like the accelerometer and such. Strange coming from a company concerned about the web apps by-passing the app store. Third, most iOS developers don't pericularly want web apps. The App Store has half a billion of credit cards on the ready, and gives billions of dollars to developers each year. It will be extremely difficult to try to monetize some web based game for iOS users. Plus it offers far better performance (and possibilities for integration) than some Javascript/WebGL game. Fourth, WebGL is not that great a deal on the desktop web yet (even most casual games prefer the canvas API or Flash still), so why would it be on the mobile web? >If that was the only reason to not having feature parity with other OS's, they'd have some something about it.. oh, you know. 2-3 years ago. Well, those other OSes, namely Android, just enabled WebGL in their Chrome browser 9 months ago. And, oh you know, that in the beta version of the broswer. In fact, "Can I Use It", still shows only partial support for WebGL, and for the first time available just in the latest Android Chrome version: http://caniuse.com/webgl http://caniuse.com/webgl
  - 12y ago
- United857 12y ago
  iAds have always run in another process (named AdSheet). So extending this approach to all UIWebViews is quite plausible.
  - masklinn 12y ago
    The capability has been used since iOS6: http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-6/ http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-...
AshleysBrain 12y ago
If Safari gets WebGL, combined with the new FTL JIT it could end up being pretty darn awesome for gaming.
- tantalor 12y ago
  Safari already has WebGL behind a flag as the article notes, but most users do not enable it.
  - jonknee 12y ago
    I think they meant for mobile.
- general_failure 12y ago
  Jit is disabled in uiwebview
  - andrewmunsell 12y ago
    So is WebGL[1], but it is possible that Apple has chosen to open this up beyond the native Safari app by implementing some additional security measures (e.g. https://news.ycombinator.com/item?id=7783137 https://news.ycombinator.com/item?id=7783137). Of course, we won't know until WWDC, but it certainly is a possibility. [1]: WebGL is enabled for iAds.
0ptical 12y ago
Ah the heady days of spring and summer speculations.
VoxPelli 12y ago
And for those already wanting to experiment with WebGL on iOS there's always http://impactjs.com/ejecta http://impactjs.com/ejecta – which will likely still be preferable for packaged games even if embedded webviews will start supporting WebGL as it will still have less overhead than the webview.
deleted 12y ago
[deleted]
bhouston 12y ago
This sounds like convincing to me, well somewhere around 75% convincing. :) This will signal the true start of the WebGL era, because the lack of WebGL on iOS has been a real buzz kill for commercial adoption of WebGL outside of pure enthusiastic circles -- I know this first hand unfortunately in trying to do B2B deals with http://Clara.io's http://Clara.io's interactive embed technology -- it is nearly impossible to sell to major clients once they realize that it doesn't work on iOS: http://exocortex.github.io/audi/ http://exocortex.github.io/audi/ - Car http://exocortex.github.io/klaas/ http://exocortex.github.io/klaas/ - House
- wildpeaks 12y ago
  Perhaps you could use Ejecta when they ask for iOS support ? Sure they'd still be disappointed that it doesn't run directly in Safari Mobile, but alternatives like Unity or AIR don't run in it either. Although you probably don't need it anymore now that you have the remote rendering embeds :)
Demiurge 12y ago
Does this mean jailbreaking will become a lot easier?
deleted 12y ago
[deleted]
CmonDev 12y ago
I hope their screening will remain strict. I foresee a whole wave of... "quality titles" scripted in JS.
- untog 12y ago
  What screening? WebGL is used on... the web. That's the beauty of it.
  - mastazi 12y ago
    I think CmonDev refers to apps made with PhoneGap, Cordova etc., and I agree that using this type of solutions for 3D games might not be the best choice in order to offer a good user experience.
cconroy 12y ago
I really hope WebGl+javascript kills CSS and html and all the other web stuff and we get back to desktop rich applications. And a URL can map to some state/object too. Google can then think about searching for things richer than just textual.
- tantalor 12y ago
  Not sure if you are trolling... HTML and WebGL are mostly orthogonal. For example, you do not want to render text or form controls in WebGL. We can improve HTML rendering with GPU-accelerated compositing, but that's mostly behind the scenes.
  - al2o3cr 12y ago
    "you do not want to render text or form controls in WebGL" You don't. I don't. Our users don't. But trust me, there are plenty of ex-Flash devs out there positively ITCHING for a return to the days of un-navigable custom UI elements.
  - cconroy 12y ago
    Definitely not trolling. But I realize I am quite off topic. I am happy that Apple is starting to embrace it. I am thinking of something like the LivelyKernel[0] or better. [0] - http://en.wikipedia.org/wiki/Lively_Kernel http://en.wikipedia.org/wiki/Lively_Kernel
  - potatolicious 12y ago
    I don't think they're trolling - I have some similar feelings about this too. I think the main point is that outside of document-centric websites (say, Wikipedia), rich webapps are basically grossly abusing HTML to wrangle it into a semi-sane (but not really sane) way to render desktop-style UIs. Think GMail, think Pandora - neither of which parses logically as a document, but are made from HTML: horribly hacky, horribly complex HTML at that. It would seem to me that we're making HTML do something it was never meant to do, and that there are many applications on the web today that really don't need that stack at all, and really just need code and a renderer (like, say, a desktop OS). Of course, this is a double edged sword. Simply tossing a renderer to devs is just going to invite a whole slew of confusing, non-standard UIs. Though, that said, if you look at GMail et al, we're already there.
bernatfp 12y ago
I also wonder when is Apple going to update Safari with WebRTC support. It's something many users could really benefit from.
- rsynnott 12y ago
  WebRTC's still in draft and expected to change a fair bit; Apple rarely implements draft standards unless they're draft standards it made (Canvas etc)
judah 12y ago
The title is misleading. It should read, "There's a WebGL talk at WWDC 2014." This blogger spotted a talk at WWDC 2014 on WebGL. He speculates this means there's a forthcoming release of Safari with WebGL enabled by default, thus predicting Apple is embracing WebGL. But we don't actually know that.
- mikeash 12y ago
  Seriously. WWDC starts in a week and a half. If Apple is really embracing WebGL, we'll probably find out on the first day. Is it so hard to wait?
- dang 12y ago
  Thank you. We changed it. The HN guidelines call for changing titles when they're linkbait or misleading.
stcredzero 12y ago
I hope this allows Javascript games to completely displace Flash -- without becoming as big an attack surface as Flash and Java became. Right now implementing an HTML5 or JavaScript multiplayer game is still a considerable exercise in navigating browser differences.
ant_sz 12y ago
I found in current version of Safari, the rendering of webGL still have some issues on Retina display, It also cost too much energy. So I will be satisfied even if Apple can only solve the most of these problems on desktop platform and make it on by default.

117 points by daredevildave 12y ago

0x0 12y ago

Wild speculation: iOS 8 will bring an out-of-process, heavily sandboxed webview, which was the missing piece for enabling webgl for everyone. The greatly increased attack surface (with almost direct gpu access via shaders etc) was too risky to host in in-process web views - explains why webgl was only enabled for iAds (since those would be vetted by a review team)

pirateking 12y ago
Going along with your plausible speculation, and assuming XPC is used to communicate with the WebGL view (using UIRemoteView maybe), hopefully that means opening up the XPCKit framework as well in iOS 8.
- masklinn 12y ago
  Finally having XPC would be really great for application and tools developers.
twoodfin 12y ago
Would be nice to get something similar for in-app JavaScript JIT'ing.
- Flow 12y ago
  Or a standard way to use sandboxes from within your apps. So you can do on-the-fly code generation.
- rsynnott 12y ago
  Arguably, such a solution would make Javascript JITing safe, too.
higherpurpose 12y ago
I wonder if Firefox will remain the only browser out there without a process sandbox. It's still the most vulnerable browser because of that: http://www.extremetech.com/computing/178587-firefox-is-still-the-least-secure-web-browser-falls-to-four-zero-day-exploits-at-pwn2own http://www.extremetech.com/computing/178587-firefox-is-still...
- erickt 12y ago
  It is coming soon. Firefox Nightly has it as an option, and according to this it's supposed to be an option in Firefox 30. I'm not sure when it will be turned on by default though: https://wiki.mozilla.org/Electrolysis https://wiki.mozilla.org/Electrolysis
  - bgirard 12y ago
    Electrolysis is NOT sandboxing, full stop.
    - cowchase 12y ago
      To cite the wiki: "sandboxing the content processes is a separate project from Electrolysis". So Electrolysis lays the foundation for sandboxing.
      - bgirard 12y ago
        It's true. It wont provide anything on its own so I'm trying to be blunt to kill this misconception that keeps spreading.
- bgirard 12y ago
  We were talking about this yesterday. I asked how many of the previous issues we classified a security problem would of been mitigated by a sandbox and the conclusion would be that it would not even cover the majority. Most of the security issues we encounter are with bugs in the driver. A common bug for example with the Intel mac driver is when sending allocating a valid large texture the texture will sometimes instead be filled with old gpu memory[1]. Then you can glReadPixel the data and reconstruct parts of the desktop windows or tabs. A sandbox isn't going to stop you from exploiting this kind of buggy driver if it incorrectly starts returning other people's data when you asking for unrelated valid commands. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=631258 https://bugzilla.mozilla.org/show_bug.cgi?id=631258
shadowmint 12y ago
> The greatly increased attack surface (with almost direct gpu access via shaders etc) was too risky to host in in-process web views What really? Were they seriously even pretending to use that excuse? Everyone I've ever talked to was 100% certain it was simply because they didn't want anyone by-passing the app store for games and other immersive content they would then have no control over. I'm not denying that webgl is an attack surface; it totally is; but surely it's a bit rich to say that the webgl implementation in webkit has been switched off for the last 3 years because of security concerns. If that was the only reason to not having feature parity with other OS's, they'd have some something about it.. oh, you know. 2-3 years ago.
- coldtea 12y ago
  >Were they seriously even pretending to use that excuse? Everyone I've ever talked to was 100% certain it was simply because they didn't want anyone by-passing the app store for games and other immersive content they would then have no control over. Well, "everyone you ever talked to" was wrong. Apple could not care less about web apps by-passing the app store in this regard. For one, they initially offered web apps in place of a native API, and developers (and users) hated it. Second, they had for the longest time (still do IIRC), the fastest and more complete web browser experience on mobile. Including extra JS hooks for things like the accelerometer and such. Strange coming from a company concerned about the web apps by-passing the app store. Third, most iOS developers don't pericularly want web apps. The App Store has half a billion of credit cards on the ready, and gives billions of dollars to developers each year. It will be extremely difficult to try to monetize some web based game for iOS users. Plus it offers far better performance (and possibilities for integration) than some Javascript/WebGL game. Fourth, WebGL is not that great a deal on the desktop web yet (even most casual games prefer the canvas API or Flash still), so why would it be on the mobile web? >If that was the only reason to not having feature parity with other OS's, they'd have some something about it.. oh, you know. 2-3 years ago. Well, those other OSes, namely Android, just enabled WebGL in their Chrome browser 9 months ago. And, oh you know, that in the beta version of the broswer. In fact, "Can I Use It", still shows only partial support for WebGL, and for the first time available just in the latest Android Chrome version: http://caniuse.com/webgl http://caniuse.com/webgl
- 12y ago
United857 12y ago
iAds have always run in another process (named AdSheet). So extending this approach to all UIWebViews is quite plausible.
- masklinn 12y ago
  The capability has been used since iOS6: http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-6/ http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-...

AshleysBrain 12y ago

If Safari gets WebGL, combined with the new FTL JIT it could end up being pretty darn awesome for gaming.

tantalor 12y ago
Safari already has WebGL behind a flag as the article notes, but most users do not enable it.
- jonknee 12y ago
  I think they meant for mobile.
general_failure 12y ago
Jit is disabled in uiwebview
- andrewmunsell 12y ago
  So is WebGL[1], but it is possible that Apple has chosen to open this up beyond the native Safari app by implementing some additional security measures (e.g. https://news.ycombinator.com/item?id=7783137 https://news.ycombinator.com/item?id=7783137). Of course, we won't know until WWDC, but it certainly is a possibility. [1]: WebGL is enabled for iAds.

0ptical 12y ago

Ah the heady days of spring and summer speculations.

VoxPelli 12y ago

And for those already wanting to experiment with WebGL on iOS there's always http://impactjs.com/ejecta http://impactjs.com/ejecta – which will likely still be preferable for packaged games even if embedded webviews will start supporting WebGL as it will still have less overhead than the webview.

deleted 12y ago

[deleted]

bhouston 12y ago

This sounds like convincing to me, well somewhere around 75% convincing. :) This will signal the true start of the WebGL era, because the lack of WebGL on iOS has been a real buzz kill for commercial adoption of WebGL outside of pure enthusiastic circles -- I know this first hand unfortunately in trying to do B2B deals with http://Clara.io's http://Clara.io's interactive embed technology -- it is nearly impossible to sell to major clients once they realize that it doesn't work on iOS: http://exocortex.github.io/audi/ http://exocortex.github.io/audi/ - Car http://exocortex.github.io/klaas/ http://exocortex.github.io/klaas/ - House

wildpeaks 12y ago
Perhaps you could use Ejecta when they ask for iOS support ? Sure they'd still be disappointed that it doesn't run directly in Safari Mobile, but alternatives like Unity or AIR don't run in it either. Although you probably don't need it anymore now that you have the remote rendering embeds :)

Demiurge 12y ago

Does this mean jailbreaking will become a lot easier?

deleted 12y ago

[deleted]

CmonDev 12y ago

I hope their screening will remain strict. I foresee a whole wave of... "quality titles" scripted in JS.

untog 12y ago
What screening? WebGL is used on... the web. That's the beauty of it.
- mastazi 12y ago
  I think CmonDev refers to apps made with PhoneGap, Cordova etc., and I agree that using this type of solutions for 3D games might not be the best choice in order to offer a good user experience.

cconroy 12y ago

I really hope WebGl+javascript kills CSS and html and all the other web stuff and we get back to desktop rich applications. And a URL can map to some state/object too. Google can then think about searching for things richer than just textual.

tantalor 12y ago
Not sure if you are trolling... HTML and WebGL are mostly orthogonal. For example, you do not want to render text or form controls in WebGL. We can improve HTML rendering with GPU-accelerated compositing, but that's mostly behind the scenes.
- al2o3cr 12y ago
  "you do not want to render text or form controls in WebGL" You don't. I don't. Our users don't. But trust me, there are plenty of ex-Flash devs out there positively ITCHING for a return to the days of un-navigable custom UI elements.
- cconroy 12y ago
  Definitely not trolling. But I realize I am quite off topic. I am happy that Apple is starting to embrace it. I am thinking of something like the LivelyKernel[0] or better. [0] - http://en.wikipedia.org/wiki/Lively_Kernel http://en.wikipedia.org/wiki/Lively_Kernel
- potatolicious 12y ago
  I don't think they're trolling - I have some similar feelings about this too. I think the main point is that outside of document-centric websites (say, Wikipedia), rich webapps are basically grossly abusing HTML to wrangle it into a semi-sane (but not really sane) way to render desktop-style UIs. Think GMail, think Pandora - neither of which parses logically as a document, but are made from HTML: horribly hacky, horribly complex HTML at that. It would seem to me that we're making HTML do something it was never meant to do, and that there are many applications on the web today that really don't need that stack at all, and really just need code and a renderer (like, say, a desktop OS). Of course, this is a double edged sword. Simply tossing a renderer to devs is just going to invite a whole slew of confusing, non-standard UIs. Though, that said, if you look at GMail et al, we're already there.

bernatfp 12y ago

I also wonder when is Apple going to update Safari with WebRTC support. It's something many users could really benefit from.

rsynnott 12y ago
WebRTC's still in draft and expected to change a fair bit; Apple rarely implements draft standards unless they're draft standards it made (Canvas etc)

judah 12y ago

The title is misleading. It should read, "There's a WebGL talk at WWDC 2014." This blogger spotted a talk at WWDC 2014 on WebGL. He speculates this means there's a forthcoming release of Safari with WebGL enabled by default, thus predicting Apple is embracing WebGL. But we don't actually know that.

mikeash 12y ago
Seriously. WWDC starts in a week and a half. If Apple is really embracing WebGL, we'll probably find out on the first day. Is it so hard to wait?
dang 12y ago
Thank you. We changed it. The HN guidelines call for changing titles when they're linkbait or misleading.

stcredzero 12y ago

I hope this allows Javascript games to completely displace Flash -- without becoming as big an attack surface as Flash and Java became. Right now implementing an HTML5 or JavaScript multiplayer game is still a considerable exercise in navigating browser differences.

ant_sz 12y ago

I found in current version of Safari, the rendering of webGL still have some issues on Retina display, It also cost too much energy. So I will be satisfied even if Apple can only solve the most of these problems on desktop platform and make it on by default.