we are using the native BlackBerry camera in our app, using the Invoke class to start the camera. We listen for an image being written to the filesystem, and when the user is finished with the camera, we call
Application.getApplication().requestForeground();
inside fileJournalChanged() to get back to our app.
This caused a problem with the camera lingering on the image taking on some devices, some of the time. If you want gory details you can see my post on the BB forums from a while back.
http://supportforums.blackberry.com/t5/Java-Development/restore-invoked-camera-after-deleting-an-image-from-the/m-p/511332
Suffice to say, I am still trying to fix this. Using EventInjector to inject an ESC key press works, however in this question
Getting Event Injector Permission
it is described as a security threat. However this is widely suggested as the way to close the camera and work around other issues. Has anyone had problems using this method to close the camera or to do anything else? Is there a better "best practices" method for closing the camera, as there apparently is in Android (I don't actually know, a senior developer here mentioned it)?
By "problems" I guess I really mean business rules types of problems... app getting blacklisted by an organization, slammed in the app store, etc?
Thanks in advance, this has been troubling me for a while.
I think the biggest problem you'll face is that using event injection requires special application permissions - ApplicationPermissions.PERMISSION_INPUT_SIMULATION to be exact. Since granting an application this permission basically allows it to simulate input events into ANY application at any time, it is considered quite dangerous because a badly-written or intentionally malicious application could do a lot of damage. Therefore many end-users and business do not allow applications that require this permission.
Related
I am working on an educational e-commercial website .. In which the user need to authenticate and then the videos on particular topics will be available.. so how can I prevent my video to be screen-recorded...
Different OS's and applications support different mechanisms to try to tackle this - for example:
Microsoft Edge on Windows 10 uses integrated 'Protected Media Path' for encrypted content which will stop simple screenshots working
Website and web app developers may use a number of CCS 'tricks' to achieve a similar affect, although these can usually be workaround with standard web developer and debug tools.
Mobile video typically uses protected memory for encrypted content which will usually give a black screen on capture.
As mentioned in comments and other answers these are all 'barriers' but they don't make it impossible to copy the content - the best example being pointing a camera at the screen a copying that way.
The idea is generally to make it hard enough compared to the value of the content so that people are not prepared to invest the time to work around your barriers.
It is not possible, for a variety of reasons:
There is no Web API for that.
Even if there was, it would be possible to reverse engineer the browser/OS to allow for screen recording.
Even if, for some reason, you couldn't access and modify the software running on the computer, you could connect the computer to a capture card instead of your monitor.
And if you also couldn't do that, you could just point a camera at the screen and start recording.
To give a brief backstory to bring things up to my current position / reason for my question:
I originally wanted to use sendkeys to send keyboard presses to a Citrix Xenapp Remote Terminal Application (VT320 Emulator).
This does not work.
After some investigation it became apparent that this has been a reasonably common issue.
I eventually found a work-around that involved opening the windows 'On-Screen Keyboard' application and sending mouseclicks using VBA to the OSK app itself. The key transmissions would be successfully received in the remote terminal application.
This solution is a rather awkward and not very practical solution as it relies on many factors e.g. screen resolution, co-ordinates / current position of the OSK etc.
With the above in mind, I am looking to achieve a more full proof method and here's my thoughts:
Rather than using simulated mouseclicks I would ideally like to be able to either 'embed' the OSK app into the excel instance and reference each key
or hide the app and find a way to make the application receive the VBA keys requested.
I'm aware that Sendkeys has its limitations so I have also tried using SendInput via a Keyb_Event and this also didn't work.
To any half experienced expert, I'm clearly a beginner so I'm suffering from a lack of knowledge here perhaps.
If anyone can point me in the right direction for solving this issue, I'd really appreciate it!
Many thanks.
EDIT
I've looked into this a little more and found this post:
Finding the class name of the On-Screen Keyboard?
Which would suggest that if I know the class of the on screen keyboard, I could use its commands within excel VBA?
I did try to use the code within the question but couldn't get it to work.
So hopefully my question is a little easier to answer?
Can I use the class name of the on-screen keyboard app / declare an API function that will allow me to send simulated key functions as if it's the OSK app being clicked by the mouse?
Hopefully someone can help!!
Trying to automate apps locally can be quite fiddly. Doing it through a Citrix HDX connection is just painful.
Do you have any say over the Citrix environment? If so I'd try writing an automation app that actually runs on the Citrix server in the same session as the published app you're trying to automate. This has the advantage that you're effectively automating a local app which would make life easier.
Depending on how your automation works you may need to communicate between your automation app running in the Citrix session and your client. You could use WCF to bridge the two together.
So that's how I would try and do, as regarding your specific question I've provided some thoughts below...
OSK automation thoughts
I've done some limited automation of the OSK. There are actually two OSKs if you're using Win8. Osk.exe is the old one which has been around a while. TabTip.exe is the new Win8 specific OSK.
One problem to keep in mind is that both of these processes run as high integrity processes which means normal (medium) integrity processes have very limited abilities to automate them. So while I could automate some stuff, many messages would just get ignored. So this maybe why you are finding the OSK is not responding like you expect.
You can work around this by running your automation app as a high integrity process, but this generally means you need local admin (or local system) privilege to start the high integrity process. I never looked into the specifics of how you create high integrity processes. I know there's a command line tool you can use to force a process to run at a certain level (icacls.exe), e.g.
https://msdn.microsoft.com/en-us/library/bb625960.aspx
I imagine there would be APIs to do this as well.
I am building a client-side program that connects to a server. This client-side program needs to have the source code available to the users as part of the licencing (not an option). However, I need to ensure that when a user connects to the server with that client-side program, it's running with the original code and hasn't been altered and re-compiled.
Is there any way to check during connection to the server that they're using an unaltered version of the program?
No, there's really no way to do that.
You're basically encountering the "Trusted Client" problem. The client code runs on the user's PC, and the user has full control over that PC. He can change the bytes of the program on disk, or even in memory. If you were to try to perform a hash or checksum against the code, he could simply change the code that did that verification and make it return "unmodified".
You could try to make things a little harder on a malicious user but there's no practical way to achieve what you're hoping.
What you have described is a issue that the video game industry has been fighting for the last decade and a half. In short, how to prevent the user from modifying the client (in their case, generally to prevent cheating, though also for copyright reasons). If that effort has taught us anything, it's that preventing modifications to the client is a constant arms race that you will never decisively win. In light of that, don't even try.
Follow the standard client-server assumption that the client is in the hands of the enemy and cannot be trusted. Build your server side defensively based on that assumption and you'll be alright.
It's very very difficult and probably not worth it. But if you are interested in pursuing it you'd have to develop something that has been code signed and monitored by the Windows kernal.
A couple topics that will orient you to the scope of the problem:
Protected media path
Driver signing
Both media devices and device drivers are digitally signed by the manufacturer and continuously monitored by Windows. If anything goes out of whack, it gets shut down (that'ts the technical term). Seems very daunting. And I don't know if the technology is available for desktop software that isn't a device driver and isn't related to DRM.
Good luck!
I recently had an argument with someone regarding the ability of a website to take screenshots on the user's machine. He argued that using a GUI-program to simulate clicking a mouse really fast to win a simple flash game could theoretically be detected (if the site cared enough) by logging abnormally high scores and taking a screenshot of those players' desktops for moderator review. I argued that since all website code runs within the browser, it cannot step outside the system to take such a screenshot.
This segued into a more general discussion of the capabilities of websites, through Javascript, Flash, or whatever other method (acceptable or nefarious), to make that step outside of the system. We agreed that at minimum some things were grabbable: the OS, the size of the user's full desktop. But we definitely couldn't agree on how sandboxed in-browser code was. All in all he gave website code way more credit than I did.
So, who's right? Can websites take desktop screenshots? Can they enumerate all your open windows? What else can (or can't) they do? Clearly any such code would have to be OS-specific, but imagine an ambitious site willing to write the code to target multiple OSes and systems.
Googling this led me to many red herrings with relatively little good information, so I decided to ask here
Generally speaking, the security model of browsers is supposed to keep javascript code completely contained within its sandbox. Anything about the local machine that isn't reflected in the properties of the window object and its children is inaccessible.
Plugins, on the other hand, have free reign. They're installed by the user, and can access anything the user can access. That's why they're able to access your webcam, upload files, do virus scans, etc. They're also able to expose APIs to javascript code, which pokes a hole in the javascript sandbox and gives javascript code some external access. That's how tools like Phonegap give javascript code in web apps access to phone hardware (gps, orientation, camera, etc.)
Supposing I was developing a fairly graphically intensive application (C++ or C#, graphics API undecided) for which most of the usage will be by remote users over RDP (either terminal server sessions or remote access to a single-user machine). It's obvious that non-essential "eye-candy" effects and animations should be avoided. My questions are:
What should I be careful to do/avoid doing to make most efficient use of the RDP protocol ? (e.g I have an idea RDP can remote some graphics drawing primitives straight to the client... but is that only for GDI ? Does using double-buffering break such remoting and force a bitmap mode ? Does the client-side bitmap cache "just work" or does it only cache certain things like fonts and icons ?)
Is there any sort of RDP protocol analyser available which will give some insight into what an RDP stream is actually transporting (in particular, bitmaps vs drawing primitives) ? (I can imagine adding some instrumentation to the rdesktop source to do this, but maybe something exists already).
In my experience I'd be careful when it comes to animations - especially fade up/down controls that can seriously kill performance over RDP.
Double-buffering might also cause some problems, however I personally haven't had to do too much in the way of workarounds for this - the article by Raymond Chen explains the possible pitfalls quite well.
Essentially, it's a good idea to check in code whether it's running in a remote sessions (RDP, Citrix, etc). Take a look at: GetSystemMetrics( SM_REMOTESESSION ) - you can then decide at runtime whether to enable or disable certain features.
My idea is that the optimization work made on RDP already cover 90% of the problem you're describing, so I would not worry about optimizing for RDP, you're already removed the eye-candy stuff, you know that the application will be used via RDP so I suppose you'll avoid operations that involves continuous redrawing of form, I believe that sould be enough.
Our application was never designed with RDP in mind, we had the same worries you have when a customer told us that all its client will be used via RDP (Citrix, in that specific case) from remote locations but also if we didn't change a single line of code the customer never called with slowlyness problems due to RDP.
Remember... Premature optimization is evil.