5 ms·

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 increa

by 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
  - 12y ago
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-...

by 0x0 12y ago

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
- 12y ago

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-...