it is a security break regardless, and you can do much more than play rogue audio. For example send data in the url ....
On Fri, Feb 1, 2013 at 12:27 PM, Shazron <shaz...@gmail.com> wrote: > Seems like a harmless thing for now for us to fix and re-tag, since the > most this does is allow people to play rogue audio files I guess? I'll file > an issue. > > > On Fri, Feb 1, 2013 at 11:11 AM, Andrew Grieve <agri...@chromium.org> > wrote: > > > CDVSound.m doesn't set the User-Agent, which I think means it's not being > > restricted to the white-list. > > > > > > On Fri, Feb 1, 2013 at 1:45 PM, Shazron <shaz...@gmail.com> wrote: > > > > > Not that I am aware of. There might be something related to the > > user-agent > > > changes. Let me verify your results. > > > > > > > > > On Fri, Feb 1, 2013 at 9:03 AM, Becky Gibson <gibson.be...@gmail.com> > > > wrote: > > > > > > > Did I miss a change in our whitelist implementation on iOS? > > > > > > > > It used to be that I had to make sure audio.ibeat.org was in the > > > whitelist > > > > before running the mobile-spec media tests. When testing with > 2.4rc2 > > I > > > > noticed this is no longer the case. My whitelist is: > > > > > > > > <access origin="http://www.google.com"; /> > > > > > > > > <access origin="*.apache.org*"/> > > > > > > > > <access origin="cordova-filetransfer.jitsu.com" /> > > > > > > > > <access origin="whatheaders.com" /> > > > > > > > > Yet the media plays just fine. I suspect this change has been in > there > > > for > > > > awhile. Previously I just assumed media was working because my > > whitelist > > > > was <access origin="*" /> > > > > > > > > When testing with a changed whitelist via config.xml completely > removed > > > my > > > > test app from the device and did a build clean before running again. > > > > > > > > It looks like whitelist checking doesn't even occur for the media > url. > > > > > > > > just curious! > > > > > > > > > > -- @purplecabbage risingj.com
