I would like to set up some WMV Video Streaming, using Windows 2003's Streaming Media Server and Silverlight.
Now, unfortunately Silverlight only supports HTTP, which means that people can just download the videos. While that in itself is not a problem, I wonder what options there are to prevent them being playable outside of the network.
Of course, DRM comes into mind. Is there an easy way to get it and set it up? I do not want to have some complicated User-Scheme, it essentially boils down to "If you can reach the server (which is only in the internal network), you get a license, otherwise not".
Any experience with WMV DRM or Content Protection in that area?
What would I need on top of Windows 2003 Server and Silverlight 2?
DRM is a negative sum game. You lose money and time in implementing it that you could have spent on something useful to your users, and your content becomes less valuable to your users. It is also impossible to implement effectively. I'm not going to address any specific DRM scheme, but the core of the argument is that in order to show content to the user, the user's computer must be able to decrypt it. Therefore, the decryption code, and the decryption keys, must be present on the user's computer. Encryption can only protect data from interception and tampering between two secure endpoints. If one of the endpoints is compromised (and you are assuming this in your distrust of the user), then cryptographic techniques are useless.
Michael: you could do a few things. You could use IIS7 and create a web playlist which can be protected by SSL certificates to secure the stream. Additionally Silverlight does support a no-touch (from the end user's perspective) DRM scheme we call PlayReady. It does involve having a server to issue the license so that may violate your desire for a no/low cost solution (but DRM solutions rarely are). These are two options though.
In this session the baseball guy talked about making the URL's usable only once. I assume it's not a 100% solution but it could prevent users from copypasting url's.
An alternative to in house DRM is hosted DRM.
We "EZDRM.com" offer a great low cost solution, and still provide you all the features of DRM.
Related
What is the best practice to pass sensitive information like password/secret from angular to Webapi?
Should we need to hash/encrypt them at the client before sending to webapi?
Having https:// protocol would be enough to pass the sensitive information over the wire without encrypting?
Let me know your thoughts.
using https is encrypting
SSL is secure socket layer and uses various encryption algorithms (configured on the web server) in order to encrypt any communication and it is the best means of protecting information. Any data sent to the client is compromised and so encryption in the browser (JS not native) is typically considered not worth while.
Suggest going to letsencrypt and setting up certbot to get/renew your certificates, it also helps with server configuration. You may also want to look into general "server hardening guides" on linux I also use a program called lynis on the server side to help audit/lock things down. There are also companies that will evaluate the hash algorithms your server is allowing in order to verify it isn't using any algorithms that are known to have exploits (like heartbleed), typically the companies are advertised as "PCI certification" companies but the tests are basically all automated. (PCI is payment card industry or visa/mastercard secruity best practices, if not followed and data is lost you may be considered more liable if you are not following PCI rules/suggestions)
Following general security best practices and writing code that is not subject to SQL injection will put you ahead of most unfortunately but there are no silver bullets to security (same as performance):
https://www.intellectual-tech.com/blog/web-security-ch-1
Does anyone know of any documentation of how to access bank data via some sort of webservice or other method for use in a Silverlight financial / banking application? Is there any sort of standard protocol or terminology used for this that I can look up online. I'm having trouble finding any sort of information on how this is typically done.
"Access bank data"... Not exactly something banks allow from the outside world. They kinda want to keep things secure :)
If you work for a bank you may well have access to various web services internally. There are standards for data transfers, but every bank will likely have it's own systems.
I'm having trouble finding any sort of information on how this is typically done.
That's probably a good thing. This is typically done by either internal bank developers or consultants. For example, take the Bank of America Windows Phone 7 app (which is a Silverlight app): it connects to BofA's servers, but I would be surprised if the way in which it connects is public information. Because you can use it to check your account, I can only presume that there is a web service hosted somewhere that allows these clients to get this data. I'm pretty confident, however, that the connection is secured, and the details of it are kept hidden for good reason.
In short, banks don't usually expose web services to the outside world for public consumption. Unless you've been hired by a bank to specifically do this, I'm not sure you should be able to.
Our clients must pay a monthly Fee... if they don't, what is the best way to block the asp.net software usage?
Note: The application runs on the client own server, its not a SaaS app...
My ideas are:
Idea: Host a Web Service on the internet that the application will use to know if the client can use the software.
Issue 1 - What happen if the client internet fails? Or the data center fails?
Possible Answer: Make each web service access to send a key that is valid for 7 or 15 days, so each web service consult will enable the software to run more 7 or 15 days, this way the application will only be locked after 7 or 15 days without consulting our web service.
Issue 2 - And if the client don't have or don't want to enable internet access to the application?
Idea 2: Send a key monthly to the client.
Issue - How to make a offline key?
Possible Answer: Generate a Hash using the "limit" date, so each login try on software will compare the today hash with the key?
Issue 2 - Where to store the key?
Possible Answer: Database (not good, too easy to change), text file, registry, code file, assembly...
Any opinion will be very appreciated!
Ah, the age old issue of DRM. And that's what you're talking about here. Frankly, the fundamental answer to your question is: you can't. No matter what you do to the system, it can be hacked and modded in such a way that your DRM authentication scheme can be bypassed and/or broken.
This is a fundamental fact of software development: it can and will be pirated.
So, the answer to your question is that you will have to trust the client to pay you the fees you determine to be correct (which is the whole point of contracts in this situation).
Any other actions you take are a hardship and annoyance on your paying customer, and has the potential to erode your customer base.
Now, if you want control of your software in the nature described, then do not provide it to users to run on their own servers. Force them to be SaaS. In that way, you control all of that. But this is the only way.
Something that you don't appear to be thinking about, but I have seen networks which do not allow any type of "dial home" solutions, as a majority of the systems were internally focused and thus these internal servers were NOT allowed to contact the outer internet. At all. It was deemed a security risk to even allow them access. How would you handle those networks?
Frankly, if I was the customer, and I paid my fees to license your software (which I installed on my own device) I would be irate if I had to allow that device access to the internet in order for it to work. Doubly so, if the software in question was any type of financial management, customer management, HR management, quality management, inventory management, sales, or just anything related to my business, customers or employees. I don't trust software developers enough to have their software talk to something else when my business-relevant data is held in their software.
In the end, what you are describing is an antagonistic approach to take with your paying customers. If you don't believe me, look at the comments that UbiSoft is getting for their latest customer-hating DRM scheme.
IMO, you have two good paths here:
Go SaaS
Ensure your contract has a
bite for non-payment
usually you provide an scrambled key that includes a valid authorization token and the expiration date through which service is paid. Then the installer will use this to "activate" your software. Not sure how this would be viewed if you have 1-2 week periods. you'd want to warn them about upcoming expiration. Also not sure how to tell if they've set their own clock back.
In short, nothing will be perfect.
I've dealt with this before and its not possible to make a perfect system. There are risks in anything you do. The best thing is to weigh your options, and determine the method that has the least likelihood of being hacked and the most likelihood of working correctly and easily for the customer.
Like others have said, they could change their clock and invalidate the license checking mechanism. If you didn't trust the user, you could make the license system connect to your servers. You would then need to ensure that they always have a connection to your servers to check the license.
What if there is a valid reason that they cannot access your server?
Their internet connection has a problem.
YOUR internet connection has a problem.
In that case, should you disable the application? Probably not. But then again, what if they shut down the connection on purpose? Then you would WANT to disable the application.
If you give them a monthly key, you're adding a monthly annoyance and you may lose a customer after a while (people tend to do business with those who make it easy).
For example: If you base it on their clock, and the application needs their clock to be accurate for some reason, then its unlikely that the customer will change their clock.
I agree with Stephen but ultimately, I think that your contract is your best ally here.
As been previously mentioned, you don't want to inconvenience customers, especially if you have a large deployment.
As for SaaS, if I were a customer using your product and you said that the model is changing and we need to access the software from your server and ours must be decommissioned, I'd not be happy. I'd probably use the opportunity to switch packages.
In corporate settings, the contract really is the best way to handle these issues. I've worked on licensing issues for desktop and ASP.NET applications and they can cause a number of headaches for both you and your client.
However, if you insist on using something like this I suggest you go with a middle ground. Instead of only unlocking the application for a week or two, provide a license for 6 months or a year. This way, if you run into licensing issues (and you will run into issues) they only occur once a year rather than a couple of times per month. That will be cheaper for you in support and your clients will be less unhappy about dealing with licensing issues. If the company stops paying and you need to terminate the license you can handle that on a one-off basis, using contract enforcement as needed.
On the web service or client license options, I think a good license system would incorporate both. A client license to provide a the application a stable license and a web service to generate and deliver the license key when it is time for the application to be renewed. If the client won't allow the application to call home to get the license key also provide a manual entry method.
If you are going to store a license on the client, do not try to build a component yourself. There are many components available which will be much more robust and reliable than the one you build. There is a .NET .licx-based licensing method and a number of 3rd party methods that you can use. Which one is most appropriate depends on your scenario: how flexible you want the license and what other options you need. Most importantly, find something reliable - any time your customers spend fixing problems caused by licensing is non-productive for them and will reflect poorly on the application.
The important thing to keep in mind is that no system is fool proof. If your application is valuable, someone is going to figure out how to steal it. But at the corporate level and with custom software it's more likely the licensing will be used to remind people to pay rather than stop wholesale piracy.
I've just discovered J2ME and I love the possibilities that it presents. I'm currently working on a simple application and I'd like to maybe release it as an open-source project sometime in the future.
As part of my research into J2ME and mobile devices, I looked into applet signing. It seems that people who want to create applets for free are caught between and rock and an awful shite-place. Applet signing is extremely expensive and extremely convoluted - and the expense can't be justified when coding for free.
There are a huge number of J2ME compatible devices out there - I think it would be a shame to have to ignore them, and just wait patiently for the next wave (e.g. Android).
I was wondering if other people have any ideas about ways to approach this problem?
UPDATE: I found this blog article which summarises the problem for those interested... http://javablog.co.uk/2007/08/09/how-midlet-signing-is-killing-j2me/
I thought about setting up a non-profit umbrella organisation for open-source J2ME developers who want a VeriSign certificate (as a certificate can sign code an unlimited amount of times). I would aim to raise the $500 and then enable group members to share the purchased certificate. Had a quick chat to a VeriSign rep and they thought the idea could work (as long as the organisation was registered as a legal entity).
However, since handset manufacturers now seem to be moving to support only UTI root certificates (which you can only get through the 'Java verified' programme) - this might not be as useful as I thought it could be... if anyone has any ideas would be great to hear them.
I am afraid that you are fighting a battle that you can't win. Using the restricted APIs is getting harder and harder and this is not accidental. As you've read in the blog entry you've mentioned the biggest problem is the network operators. Even if you buy a certificate from Verisign or Thawte (which is by the way cheaper), your application won't run in network operators branded phones, since these have their own CA rules.
At first it was possible for a developer to install his/her own certificate, but even this is now not possible. This strict rule is mandated by the phone manufacturers (Nokia for example) and applies to all phones (even no branded ones). I believe that this too is not accidental and is mainly because of pressure put to device manufacturers by the network operators.
Finally, although MIDP 3.0 has been announced for years, nothing has really come out of it. It seems that even Sun believe that J2ME is only for games.
All of these have been extensively discussed in J2ME forums for a long time. The general consensus is that the network operators do not want to have every phone available in the market operate as a smart phone and be able to run a third-party application. Then it will be very easy for everyone to use a cheaper, web-based alternative instead of SMS messaging for a example. This may sound as a conspiracy theory, if you are new in the J2ME world, but have in mind that network operators sell phones with their own firmware that lock even basic functionalities (e.g. transferring photos via Bluetooth or using MP3s as ringtones) to force the owner to use paid services!
I don't know if this is going to change now that smart phones (iPhone, Android, Windows Mobile) are gaining momentum. Have in mind that restrictions apply also for these platforms (notably Symbian, which is also very unfriendly for open source).
You can create a signing certificate
that you self-sign. Your users have
to be willing to trust you.
You can instruct your users how to
create a cert and self-sign with it.
Then the users have to be able to
trust themselves.
There are more or less open CAs; you
have to be willing to trust them and
convince your users to trust them.
The Java Tutorial has a section on signed applets that will lead you through the steps.
I'm a J2ME application developer and i totally agree your post. The costs for signing a MIDlet are simply unaffordable for open source initiatives and unless your're developing simple games, you'll soon or later end up in using restricted APIs to access sockets or Location API just to name two of them. This is very frustrating and if you consider that the permission policies are not always threated the same on various devices, the thing get worst: on some mobile phone you can tell the OS to trust the entyre MIDlet and never bother you at all, other continue to ask you permission every time you call for a restricted method. It's tragic!
I rellay appreciate your proposal and i think it would be a great achievement for JavaME developers.
I am going to write a database application for the camp I work for. I am thinking about writing it in C# with a Windows GUI interface but using a browser as the application is seeming more and more appelaing for various reasons. What I am wondering is why someone would not choose to write an application as a web application. Ex. The back button can cause you some trouble. Are there other things that ayone can think of?
There are plenty of cons:
Speed and responsiveness tend to be significantly worse
Complicated UI widgets (such as tree controls) are harder to do
Rendering graphics of any kind is pretty tricky, 3D graphics is even harder
You have to mess around with logins
A centralised server means clients always need network access
Security restrictions may cause you trouble
Browser incompatibilities can cause a lot of extra work
UI conventions are less well-defined on the web - users may find it harder to use
Client-side storage is limited
The question is.. do enough of those apply to your project to make web the wrong choice?
One thing that was not mentioned here is the level of complexity and knowledge required to generate a good web application. The problem being unless you are doing something very simple, there is no "Single" knowledge or technology that goes into these applications.
For example if you were to write an application for some client server platform.. you may develop in Java or C++. For a complex web application you may have to have expertise in Java, Java Script, HTML, Flash, CSS, Ajax, SQL, J2EE.. etc. Also the components of a web based application are also more numerous, Web Application Server, HTTP Server, Database, Browser.. are tipical components but there could be more.. a client server app is tipical just what it says.. a client application and a Server application. My experience and personal preference is not web based .. web based is great for many things. But even though I am an IT Architect for a leading company that is completely emersed in Web Apps as the solution for everything... The cons are many still.. I do thing the technology will evolve and the cons will go away over time though.
Essentially the real limitations are only through of the platform, being the browser. If you have to account for all browsers in current use that can be a pain due to varying degrees of standards in each of them.
If have control of the which browser to use, that is everyone is on computers that you control on site, and say you install firefox on all of them, you could then leverage the latest Javascript and CSS standards to their fullest in your content delivery.
[edit] You could also look into options like the adobe integrated runtime or "AIR" as an option allowing you to code the front-end with traditional browser based options like xhtml/css/javascript, flash/flex and have the backend hooked up to your database online, only also providing functionality of a traditional desktop app at the same time.
The biggest difference and drawback I see with web applications is state management. Since the web is, by nature, stateless every thing you want to maintain has to be sent back and forth from the server with every request and response. How to efficiently store and retrieve it in a matter with respect to page size and performance is hard to do at times. Also the fact that there is no real standard (at least not that everyone adheres to) for browsers makes consistency really..........fun.
You need to have a network access to the server that you are going to have the web application on (if there are going to be multiple users for the application - which is typically the case).
Actually, there are more pros than cons - if you can give some details about your application, we could help a little more...
It completely depends on the requirements of your project. For the most part, there isn't much web applications cannot do these days. Admittedly, certain applications do belong on the desktop as browsers (while currently advancing, and rapidly), still are not quite there yet. From the advent of applications such as Google Docs, Gmail
There isn't much you -cannot- do on the web. If you're creating a World of Warcraft competitor however, the web is most certainly not the optimal solution. Again, unfortunately we'd need more insight on the application you're building for the camp. The best part about the web is that anyone with a browser can use your application.
Web applications delegate processing to a remote machine. Depending on the amount of processing, this can be a con. Consider a photo editor that's a web app.
Web applications also can't deal with a whole lot of data going back and forth to and from a client. You can watch video online.. when it's compressed. It will be awhile before we see any web-based video editing software.
Browser compatibility is also a hassle. You can't control the look-and-feel of the application 100%.
Vaibhav has a good point. What's your application?
A major one is down time for migrations... users will not expect the application to be down, ever, but realistically it will have to be down for major upgrades. When doing this with a desktop application, the user (or end-user systems admin) is in control of when upgrades happen; with an online app, they're not.
For applications which have large data, performance can be a major problem as you're storing a large number of users' data centrally, which means the IO performance will not be as good as it would be if you gave them all a laptop.
In general scalability gives problems for a server-based app. Desktop applications scale really well.
You can do an awful lot with a web-based app, but it is a lot easier to do certain things with a thick client:
Performance: You get simple access to the full power of the client's CPU.
Responsiveness: Interactivity is fast and easy.
Graphics: You can easily use graphics libraries such as DirectX and OpenGL to create fast impressive graphics.
Work with local files
Peer-to-peer
Deciding whether a web application is a good approach depends on what you are trying to achieve. However here are some more general cons of web applications:
Real integration with desktop apps (e.g. Outlook) is impossible
Drag and drop between your app and the desktop / other running apps
With a web application, there are more privacy concerns, when you are storing user data on your servers. You have to make sure that you don't loose/disclose it and your users have to be comfortable with the idea of storing that data on your servers.
Apart from that, there are many security problems, like Man-in-the-middle attacks, XSS or SQL injections.
You also need to make sure that you have enough computing power and bandwidth at hand.
"Ex. The back button can cause you some trouble."
You'll have to be specific on this. A lot of people make fundamental mistakes in their web applications and introduce bugs in how they handle transactions. If you do not use "Redirect after Post" (also known as Post-Redirect-Get, PRG design), then you've created a bug which appears as a problem with the back button.
A blanket statement that the back button in trouble is unlikely to be true. A specific example would clarify your specific question on this.
The back button really is not that much of an issue if you design your application correctly. You can use AJAX to manipulate parts of the current page, without adding items into the browser history (since the page itself wont change).
The biggest issue with designing web applications has to do with state, and the challenges that need to be programmed around. With a desktop application, state is easy to handle, you can leave a database connection opened, lock the record and wait for the user to make the changes and commit. With a web application, you could lock the record...but then what if the user closes the browser? These things must be overcome in the design of your application.
When designing a web application, make sure that each trip to the server "stands alone" and provides a complete answer. Always re-initialize your variables before performing any work and never assume anything. One of the challenges I ran into once was pulling "pages" of grid data back to the user. In a real busy system, with record additions/modifications happening in real time, the user navigation from page to page would vary greatly, sometimes even resulting in viewing the same set of a few records as new additions were added in-front of the query.