6 ms·

WebGL support in iOS 5 only available to iAd developers

64 points by nephics 15y ago

sudont 15y ago
I assume there's probably a risk of arbitrary code execution, which is mostly mitigated by vetting each ad. Too bad though, would be nice to see what could be built for iOS web apps.
- rvkennedy 15y ago
  I'd love to know what the imagined risk would be - as far as I can see the only additional capability from WebGL against regular JavaScript is to send commands and data to and from the GPU. What harm can that do?
  - etherealG 15y ago
    the GPU isn't a safe place to execute code. code running on it can be written to hijack the system, thereby providing an entry point for viruses etc. even on chrome the webgl support is limited to specific gpus that have been vetted by the devs.
    - nkassis 15y ago
      It's not really the GPUs that are the issue (once it's on the GPU I don't as far as I know see a way to hijack the system) it's the drivers that are the problem. Before your shaders can run on the GPU they have to be compiled and it's that that funny stuff can occur I believe. I guess you could maybe find a way to interfere with the other applications using the GPU for rendering. Hopefully someone here as a good understanding of this stuff and can tell me if I understand the risk wrong.
      - Someone 15y ago
        once it's on the GPU I don't as far as I know see a way to hijack the system I think GPUs can do DMA => If you can break into a GPU, you may be able to write into kernel space, just like you could (can?) break into a Mac over it's FireWire port (and, possibly, the Thunderbolt port in new MacBooks)
  - maximilianburke 15y ago
    GPUs don't respect CPU memory protection -- they can write to any region of mapped memory. If you happen to have some of your program code living there you can "draw" over it with replacement code.
    - recoiledsnake 15y ago
      What you wrote doesn't make any sense whatsoever, you seem to imply that there is an inherent problem by design with this, but there is no such thing. There are possible bugs etc. that could lead to arbitrary code execution by exploiting as-yet-not-found holes in current drivers. But saying that you can draw over program code would allow even browser content to overwrite program code, especially in these days of GPU accelerated browsers.
      - daeken 15y ago
        To be fair, it's possible for the GPU to write to arbitrary memory, but it wouldn't happen as a matter of standard usage by any means.
      - maximilianburke 15y ago
        It's only a problem if the bits of memory you want to enforce special protection rights on (ie: no execute, read only, etc.) is also mapped into the GPU's address space. It's not something that "just happens" normally, it most often requires clear intent to do so, but it can be done.
  - daeken 15y ago
    There are a few issues here. One is that bugs in the GPU itself can enable memory corruption (and thus code execution), and the other is that GPU drivers are notoriously buggy and huge, making a large attack surface. I can't blame them for being concerned in this case -- opening the GPU to web developers at large opens up a huge can of worms.
    - nkassis 15y ago
      I hope that Apple has enough clout with their GPU providers to get them to fix their driver bugs and implement ARB_Robustness. Seriously if someone can get a good and safe implementation of WebGL it's apple. They own the hardware and the software.
  - AllenKids 15y ago
    Microsoft considers WebGL potentially harmful: http://blogs.technet.com/b/srd/archive/2011/06/16/webgl-considered-harmful.aspx http://blogs.technet.com/b/srd/archive/2011/06/16/webgl-cons... It goes without saying MS has its own agenda regarding web technologies, but the risks are there.
- illumin8 15y ago
  It all depends on the implementation though, right? If Safari just does a simple check to see if the source URL is something like http://adserver.apple.com http://adserver.apple.com then it would be trivial to hack DNS and send WebGL to your iOS device. I can definitely see this being an attack vector used by jailbreakers to jailbreak iOS 5. I think the only way they could prevent these type of DNS jacking attacks is to use a trusted SSL certificate on their iAd servers. I'm not sure what type of performance penalty that would add, forcing all advertising traffic to use SSL.
joelackner 15y ago
at least it's one step forward to bring webgl to tablets...
MatthewPhillips 15y ago
Did they fix the bug from 4.3 where home screen web apps don't use Nitro?
- Xuzz 15y ago
  This is probably breaking my NDA to say this, but yes, they did. Web.app now has the "dynamic-codesigning" entitlement, which enables Nitro.
  - lukifer 15y ago
    What about UIWebViews? I believe I've read that they do not yet gain the Nitro benefits.
    - Xuzz 15y ago
      They don't, but that's a security restriction. They can't give dynamic-codesigning to all apps, or their security (which that disables, as a requirement to enable the JIT) would then be useless.
- rbarooah 15y ago
  Whilst the lack of that feature certainly wasn't good, how can that be described as a 'bug'? Nothing was broken.
  - MatthewPhillips 15y ago
    Surely the same page running on the same browser on the same device but with 2 different javascript engines depending on where the page was launched from can best be described as a bug. A design bug, perhaps, but a bug.
    - rbarooah 15y ago
      Home screen apps are not running in the browser - they run in a separate process. What distinguishes a 'design bug' from 'doesn't work the way I want it to'?
etherealG 15y ago
does this mean these won't be any support for websites that use webgl in the browser natively at all? what if I make a webgl site and someone goes to it on an ipad, will it just refuse to work like IE?
- trotsky 15y ago
  Yes, which is the same answer you'd get for java, flash, silverlight, etc.
chc 15y ago
Although it's easy to look at this in a sinister light, the simpler explanation IMO is just that Apple doesn't feel entirely comfortable with its implementation of WebGL on iOS and wants to be able to screen apps instead of turning it into iOS's Flash.
- pagekalisedown 15y ago
  In light of this: http://techcrunch.com/2011/06/15/facebook-project-spartan/ http://techcrunch.com/2011/06/15/facebook-project-spartan/ I think it's just their way to fight back against Facebook.
  - ddagradi 15y ago
    It's hard to fight back against a project that hasn't been released, nor talked about until yesterday.
sjs 15y ago
Oh boy here we go... queue the comments about how Apple hates your cat or whatever ridiculous theory people will invent to explain this. Apple is testing WebGL. Introducing it in iAds is a pilot and will allow them to shake out bugs and such. This is a good thing as it means that WebGL is coming to iOS soon.
- hahainternet 15y ago
  Apple is testing iOS5. Why would they need another testing period focusing on a specific subset of WebGL applications? Wouldn't WebGL be better tested by putting it in iOS5 now and letting the (tens of? hundreds of?) thousands of beta testers destroy it?
  - trotsky 15y ago
    I think if you're worried about having a large unvetted attack surface, simply releasing it en masse to beta testers won't usually result in a very secure product. Sure, you'll get some bugs closed but plenty others will simply get ignored or worked around or worse reserved by bad actors for when it's live. It only really makes sense to release something like that to a wide audience after you feel like you've made a solid first attempt.
  - sjs 15y ago
    Apple often uses frameworks itself in one generation of the OS (Mac or iOS) and then makes it public in the next release after they've worked out the kinks. This is similar, they are testing out WebGL in something under their thumb that they control tightly, it just happens to be less private than usual as 3rd parties will get to bang on it with iAds.
- recoiledsnake 15y ago
  Are iAds the only and best way to test this out? Imagine ad developers given a free reign on animating ads while distracting users and taking up precious phone resources like CPU/GPU/RAM/Battery which need to be available for the actual game or app that the user wants to run. Haven't we learned anything from the web and flash ads that we are forced to repeat it all over again on mobiles?
podperson 15y ago
Aside from the security concerns, I suspect Apple would prefer game developers to write native apps rather than find itself constantly being benchmarked against last night's custom build of Android or Chrome or Firefox running a WebGL game no-one actually plays.
nextparadigms 15y ago
I wonder if this means WebGL will be in Android ICS. Sony Ericsson has already showed some demo in WebGL on a phone earlier this year, if Apple is starting to implement it in iOS already, then Google could do it, too. I just wonder if they considered it a priority, because when asked about WebGL coming to Android's mobile browser at I/O, the WebGL guys weren't too sure if that will happen anytime soon. But I sure hope so! Upcoming dual core and quad core chips should be able to take advantage of it somewhat.
sdbryan 15y ago
How does this make any sense? Apps from the iOS App Store can use webkit views where webGL could apply but native apps have had direct access to OpenGL ES for years (only the original iPhone, iPhone 3G, and the first iPod touch iOS devices did not have a GPU and hence no OpenGL). I was pretty sure iAds only ran in native apps and hence could use OpenGL directly. So why would iAd developers have any interest in using WebGL. Obviously web site developers and HTML5 app developers care very much for WebGL access in mobile safari. If Apple 'artificially' holds back WebGL they will just be shooting themselves in the foot. Imagine the damage if other pad platforms allow interactive, 3D web browsing and the iPad does not. It would be suicidal.
- mambodog 15y ago
  I was pretty sure iAds only ran in native apps and hence could use OpenGL directly And that would be the flawed assumption that has led to your confusion. iAds are built with HTML/CSS/JS only, not native code.

64 points by nephics 15y ago

I assume there's probably a risk of arbitrary code execution, which is mostly mitigated by vetting each ad. Too bad though, would be nice to see what could be built for iOS web apps.

rvkennedy 15y ago
I'd love to know what the imagined risk would be - as far as I can see the only additional capability from WebGL against regular JavaScript is to send commands and data to and from the GPU. What harm can that do?
- etherealG 15y ago
  the GPU isn't a safe place to execute code. code running on it can be written to hijack the system, thereby providing an entry point for viruses etc. even on chrome the webgl support is limited to specific gpus that have been vetted by the devs.
  - nkassis 15y ago
    It's not really the GPUs that are the issue (once it's on the GPU I don't as far as I know see a way to hijack the system) it's the drivers that are the problem. Before your shaders can run on the GPU they have to be compiled and it's that that funny stuff can occur I believe. I guess you could maybe find a way to interfere with the other applications using the GPU for rendering. Hopefully someone here as a good understanding of this stuff and can tell me if I understand the risk wrong.
    - Someone 15y ago
      once it's on the GPU I don't as far as I know see a way to hijack the system I think GPUs can do DMA => If you can break into a GPU, you may be able to write into kernel space, just like you could (can?) break into a Mac over it's FireWire port (and, possibly, the Thunderbolt port in new MacBooks)
- maximilianburke 15y ago
  GPUs don't respect CPU memory protection -- they can write to any region of mapped memory. If you happen to have some of your program code living there you can "draw" over it with replacement code.
  - recoiledsnake 15y ago
    What you wrote doesn't make any sense whatsoever, you seem to imply that there is an inherent problem by design with this, but there is no such thing. There are possible bugs etc. that could lead to arbitrary code execution by exploiting as-yet-not-found holes in current drivers. But saying that you can draw over program code would allow even browser content to overwrite program code, especially in these days of GPU accelerated browsers.
    - daeken 15y ago
      To be fair, it's possible for the GPU to write to arbitrary memory, but it wouldn't happen as a matter of standard usage by any means.
    - maximilianburke 15y ago
      It's only a problem if the bits of memory you want to enforce special protection rights on (ie: no execute, read only, etc.) is also mapped into the GPU's address space. It's not something that "just happens" normally, it most often requires clear intent to do so, but it can be done.
- daeken 15y ago
  There are a few issues here. One is that bugs in the GPU itself can enable memory corruption (and thus code execution), and the other is that GPU drivers are notoriously buggy and huge, making a large attack surface. I can't blame them for being concerned in this case -- opening the GPU to web developers at large opens up a huge can of worms.
  - nkassis 15y ago
    I hope that Apple has enough clout with their GPU providers to get them to fix their driver bugs and implement ARB_Robustness. Seriously if someone can get a good and safe implementation of WebGL it's apple. They own the hardware and the software.
- AllenKids 15y ago
  Microsoft considers WebGL potentially harmful: http://blogs.technet.com/b/srd/archive/2011/06/16/webgl-considered-harmful.aspx http://blogs.technet.com/b/srd/archive/2011/06/16/webgl-cons... It goes without saying MS has its own agenda regarding web technologies, but the risks are there.
illumin8 15y ago
It all depends on the implementation though, right? If Safari just does a simple check to see if the source URL is something like http://adserver.apple.com http://adserver.apple.com then it would be trivial to hack DNS and send WebGL to your iOS device. I can definitely see this being an attack vector used by jailbreakers to jailbreak iOS 5. I think the only way they could prevent these type of DNS jacking attacks is to use a trusted SSL certificate on their iAd servers. I'm not sure what type of performance penalty that would add, forcing all advertising traffic to use SSL.

joelackner 15y ago

at least it's one step forward to bring webgl to tablets...

MatthewPhillips 15y ago

Did they fix the bug from 4.3 where home screen web apps don't use Nitro?

Xuzz 15y ago
This is probably breaking my NDA to say this, but yes, they did. Web.app now has the "dynamic-codesigning" entitlement, which enables Nitro.
- lukifer 15y ago
  What about UIWebViews? I believe I've read that they do not yet gain the Nitro benefits.
  - Xuzz 15y ago
    They don't, but that's a security restriction. They can't give dynamic-codesigning to all apps, or their security (which that disables, as a requirement to enable the JIT) would then be useless.
rbarooah 15y ago
Whilst the lack of that feature certainly wasn't good, how can that be described as a 'bug'? Nothing was broken.
- MatthewPhillips 15y ago
  Surely the same page running on the same browser on the same device but with 2 different javascript engines depending on where the page was launched from can best be described as a bug. A design bug, perhaps, but a bug.
  - rbarooah 15y ago
    Home screen apps are not running in the browser - they run in a separate process. What distinguishes a 'design bug' from 'doesn't work the way I want it to'?

etherealG 15y ago

does this mean these won't be any support for websites that use webgl in the browser natively at all? what if I make a webgl site and someone goes to it on an ipad, will it just refuse to work like IE?

trotsky 15y ago
Yes, which is the same answer you'd get for java, flash, silverlight, etc.

chc 15y ago

Although it's easy to look at this in a sinister light, the simpler explanation IMO is just that Apple doesn't feel entirely comfortable with its implementation of WebGL on iOS and wants to be able to screen apps instead of turning it into iOS's Flash.

pagekalisedown 15y ago
In light of this: http://techcrunch.com/2011/06/15/facebook-project-spartan/ http://techcrunch.com/2011/06/15/facebook-project-spartan/ I think it's just their way to fight back against Facebook.
- ddagradi 15y ago
  It's hard to fight back against a project that hasn't been released, nor talked about until yesterday.

sjs 15y ago

Oh boy here we go... queue the comments about how Apple hates your cat or whatever ridiculous theory people will invent to explain this. Apple is testing WebGL. Introducing it in iAds is a pilot and will allow them to shake out bugs and such. This is a good thing as it means that WebGL is coming to iOS soon.

hahainternet 15y ago
Apple is testing iOS5. Why would they need another testing period focusing on a specific subset of WebGL applications? Wouldn't WebGL be better tested by putting it in iOS5 now and letting the (tens of? hundreds of?) thousands of beta testers destroy it?
- trotsky 15y ago
  I think if you're worried about having a large unvetted attack surface, simply releasing it en masse to beta testers won't usually result in a very secure product. Sure, you'll get some bugs closed but plenty others will simply get ignored or worked around or worse reserved by bad actors for when it's live. It only really makes sense to release something like that to a wide audience after you feel like you've made a solid first attempt.
- sjs 15y ago
  Apple often uses frameworks itself in one generation of the OS (Mac or iOS) and then makes it public in the next release after they've worked out the kinks. This is similar, they are testing out WebGL in something under their thumb that they control tightly, it just happens to be less private than usual as 3rd parties will get to bang on it with iAds.
recoiledsnake 15y ago
Are iAds the only and best way to test this out? Imagine ad developers given a free reign on animating ads while distracting users and taking up precious phone resources like CPU/GPU/RAM/Battery which need to be available for the actual game or app that the user wants to run. Haven't we learned anything from the web and flash ads that we are forced to repeat it all over again on mobiles?

podperson 15y ago

Aside from the security concerns, I suspect Apple would prefer game developers to write native apps rather than find itself constantly being benchmarked against last night's custom build of Android or Chrome or Firefox running a WebGL game no-one actually plays.

nextparadigms 15y ago

I wonder if this means WebGL will be in Android ICS. Sony Ericsson has already showed some demo in WebGL on a phone earlier this year, if Apple is starting to implement it in iOS already, then Google could do it, too. I just wonder if they considered it a priority, because when asked about WebGL coming to Android's mobile browser at I/O, the WebGL guys weren't too sure if that will happen anytime soon. But I sure hope so! Upcoming dual core and quad core chips should be able to take advantage of it somewhat.

sdbryan 15y ago

How does this make any sense? Apps from the iOS App Store can use webkit views where webGL could apply but native apps have had direct access to OpenGL ES for years (only the original iPhone, iPhone 3G, and the first iPod touch iOS devices did not have a GPU and hence no OpenGL). I was pretty sure iAds only ran in native apps and hence could use OpenGL directly. So why would iAd developers have any interest in using WebGL. Obviously web site developers and HTML5 app developers care very much for WebGL access in mobile safari. If Apple 'artificially' holds back WebGL they will just be shooting themselves in the foot. Imagine the damage if other pad platforms allow interactive, 3D web browsing and the iPad does not. It would be suicidal.

mambodog 15y ago
I was pretty sure iAds only ran in native apps and hence could use OpenGL directly And that would be the flawed assumption that has led to your confusion. iAds are built with HTML/CSS/JS only, not native code.