Does Silverlight 4's WriteableBitmap *really* cripple legit cross-domain access in the name of DRM?

Your sentiment is shared by many, many devs trying to do this for legit purposes. There are some work-arounds out there, all of them either hacky or bizarro. But this is probably the best one I've seen: Screen Capture in SIlverlight 4.0.

Your sentiment is shared by many, many devs trying to do this for legit purposes. There are some work-arounds out there, all of them either hacky or bizarro. But this is probably the best one I've seen: Screen Capture in SIlverlight 4.0.

Just read again and saw that you're not looking for a crossdomain. Xml solution. This page has some other options (again, no solution out there is "great"): betaforums.silverlight.net/forums/t/1180... Also, not sure if this is an option, but your app as an OOB app will not be restricted to security checks in ClientAccessPolicy.

Xml or CrossDomain.xml. Is Out-of-Browser an option for you? EDIT: Upon further review of the post and comments, I believe (Tom, please confirm this) that the need isn't to get a screenshot of the user's instance of the SL app running on their own box (which something like Customer Support in Silverlight would take care of pretty well).

Rather, it is to take picture of the user's screen (same as PrtSc-ish). In this case, it is a lot tougher, but not impossible. Rui show's how he does it here, but it relies on a component already being on a user's machine.

Jeremy get's even more creative with Silverlight 4 Hack: Use Native/Desktop CLR Without COM Registration, which would effectively allow access.

Being OOB doesn't solve this problem; all it does it relax restrictions relating to sockets and permissions. – Tom Ritter Aug 5 '10 at 15:24 @Tom Ritter: I guess I'm confused - how doesn't that solve the problem? I guess I should have said "elevated permission OOB".

– Otaku Aug 5 '10 at 15:32 Even full Trust OOB doesn't negate WriteableBitmap's DRM Pixel stuff. ClientAccessPolicy/CrossDomain have nothing to do with it - the cross-domain pixel access is independent of them. – Tom Ritter Aug 6 '10 at 19:45 @Tom Ritter: Okay, based on your response I think I may have been mis-reading your need.

Please see edit above. – Otaku Aug 6 '10 at 20:19.

This WritableBitmap behavior have nothing to do with DRM and everything to do with security. If the screenshot you trying to take shows image element with content from different domain then that domain must have crossdomain. Xml file with appropriate permissions.

You can contact domain owner and ask them to place crossromain. Xml in the root of their domain. Alternatively, Full-Trust OOB application should do the trick since it doesn't check for crossdomain.xml.

Ok, If you have in your visual tree and you try to create WriteableBitmap from it, that WriteableBitmap's pixel access will be locked, crossdomain. Xml or not. (Shame on you microsoft).

Good news (sorta) is, you can use following workaround: Load image using WebClient; call SetSource on image with stream from OpenReadCompleted handler. Create your WriteableBitmap and notice how Pixels property doesn't throw security exception anymore. Far from ideal, but manageable.

In the linked thread a Silverlight MVP explicitly says crossdomain. Xml does not override the restriction. Have you tested this and confirmed he is wrong?

– Tom Ritter Aug 4 '10 at 4:31.

As explained in the identical question the only way to get silverlight to allow you to get the content out of a Writeable Bitmap without any of the following: Out-of-browser Service/Code/App/Rooted GAC otherwise installed on the user's Machine Elevated Trust is to proxy the content and trick silverlight into thinking it's all from the same domain.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.