Ok so I read in help that if you download an image from a url not in your crossdomain file you can no longer read from the screen. This seems odd to me, why would reading colors from the screen pose a security threat, but that is not really my issue here.
I want to read some colors from a render texture and up until now I’ve been converting the render texture to a texture2d by using GetPixels. Is there another way this can be done so it doesn’t get kiboshed by the over zealous security of the sandbox?
This is not odd but documented in the Security Sandbox manual page, including an example why
Loading freeform data from somewhere just is pretty inresponsible, if you want to keep your users secure load data only from where you are willing to give a guarantee on safety (where you would put yourcash into the guarantee if you fail)
Its really not over zealous, its standard. Your own pattern of handling security towards your users is the leaky bucket in the chain
The solution to solve this is write a webservice that fetches the images, potentially caches them and thats ‘safe’ basically so you can ensure that the data forwarded is safe too.
Yeah that’s what I’m considering. But why is that any “safer” surely all that does is bypass the security that Unity puts in place so in fact they may as well not have bothered. The leaky bucket is in fact the internet itself, as soon as you allow people in a company to access it there really is no way to prevent security leaks.
But anyway from the docs
Surely the way to handle this is for Unity not to allow www requests that are not oked by the user?
Or not allow the user to send data out of the player.
Why does reading the color of a pixel break this security?
Reading the pixels doesn’t but if you loaded a texture from the local network, then reading the color means that you can read data from a potentially private document. Reading color = byte[ ] = can be sent through network whereever you want.
As for why having your webservice inbetween is saver: cause your webservice can NOT access these private areas within the local LAN the webplayer is executed in unlike the webplayer can, so the security constraints of the environment are enforced and kept intact
Textures are the only exception of data you can load without a crossdomain file at all and its there for the purpose of allowing to load textures at runtime from remote places like google, flicker, fb etc. Asking for every single access would be a plain simple nightmare but it would be an alternative, thats correct. But neither nor anyone else wants that, bet on it, cause not being able to get the FB users image for the friends listing in the background but having to break the experience for every friend in the list is no option, if unity does that it can just as well stop offering webplayers
Actually you can be happy that unity is selective there, that you can use ReadPixels if you don’t access unsafe textures. Cause normally webtechnology simply does not offer general screen grabbing and alike in general for security reasons
hmmm interesting, still begs the question that if you have a game (something like mine) that requires downloading images from facebook but the moment you do that it breaks the rest of the game you haven’t really gained very much by allowing it at all. It would be nice for the developer to offer the option of “allowing” a url to download from that the user ok’s. Surely wouldn’t need to happen for every call to facebook just the first time I would have thought.
Well it would be easier if you followed basic security rules right from the start instead of building your game around a functionality thats documented to not work and doomed to fail from second 0 onward, even though I know that it can be hard to keep track of all these things the webplayer building process should potentially popup a confirmation dialog that you have read the security sandbox page or force you to do it at least once, there are so many people new to unity that ignore it and run into plentitudes of problems from it (like trying to use system.io, connect to some server without socket policy server, trying to download data from unsafe places, …)
Question is what do you really try to do, do you really need the readpixel or are there easier, more performant, save ways to handle it.
Well that’s the thing, I only need the colour of one single pixel. Basically every object i my “game”, which is more of an app, needs to be user selectable. I initially tried using mesh colliders but that was unbelievably heavy and impractical so I ended using the gpu to do all the work by rendering an index pass and extracting the colour under the mouse into a lookup table. That has been fine for 2 years until I now need to extend the whole thing to allow user inputted images. At which point I run into the issue above.
I believe I have 2 possible solutions
Write my own raycaster (or hope that mesh colliders have improved)
Write a proxy script on the server that spoofs Unity into thinking the images are served up from our server and not a remote one.
You now also have the possibility to offer additional functionality along your own webservice like offering them to share images (given that makes sense for your case) or alike as you now have a ‘layer’ inbetween … it offers you a whole platform for social features to expand if that makes sense in your case
the webplayer building process should potentially popup a confirmation dialog that you have read the security sandbox page or force you to do it at least once, there are so many people new to unity that ignore it and run into plentitudes of problems from it (like trying to use