Delivering Software, Electronically? 220
zpengo asks: "I'm trying to find the best way to implement a large-scale Electronic Software Delivery (ESD) service for my software company. I've been able to find very little information online (after weeks of research) so I must take it to America's best and brightest. Have you ever worked with ESD on a higher than plain-vanilla FTP level, and if so, what did you learn from it? When do you consider the product 'delivered'? Was it worth it? (I'm planning to put together a public domain whitepaper on the subject with the information I gather, to help fill in the gaps I found while researching online)."
Delivering software electronicaly (Score:1, Interesting)
Anyone remember this?
Comment removed (Score:3, Interesting)
what are you deliver matters - java app - dll - ? (Score:3, Interesting)
I built a app that for win32 sat in the systray and then looked at a internal FTP and checked the manifest against its own on the machine if anything was new download and ask the user for interaction
on the java side their was webstart which is really nice and is default on MacOS X.x
this automatcally does what my app did and is a hell of a lot nice and secure
apps like windows update are pretty silly as you have to ask the user to look every day and how many lusers do that ? let alone people who know better
its what crontabs where ment for (-;
of course you can build it into the app
and if you just want to deliver software to customers use sftp
its nice and you can even get it on a java applet so that you can point people to a web page and get them to enter username and password and then its server side chrooting them to the right dir
have fun
regards
John Jones
Confirmation (Score:5, Interesting)
I am currently adding ESD capability to my eCommerce software, so that I can deliver electronic goods to customers.
The approach I am looking at is one where after payment has been accepted, the user gets a secure account where they can download the files they have a valid licence for, and the file is passed through a script which checks that the user has authenticated properly. This means they cannot simply post a URL to allow everyone access to the file.
In order to authenticate, and so that they can download this file again at a later date (maybe their hard disk blew up or whatever), they must enter a random 4 digits of the credit card used to purchase the file. This means they would not simply post a username/password and allow everyone access to their account.
When they receive the file it will be archived. When they unarchive the file, the custom unarchiver will request authorisation from my server, informing me they have the file, and what the md5 hash is. This confirms to me they have a valid file and helps against credit card refunds.
Inside the archive, I will look for ways to have unique ID's hidden inside various files, so I can then track the file's owner should it appear on any file sharing sites/networks. This doesnt have to be done in realtime, you can prepare 1000 files in advance and assign them to customers. I will look to write into the EULA a clause that states it is their sole responsibility to keep the file and contents secure, and that any lost sales will be charged to them if it could be proven they were neglegent in securing their computer/network.
I think that the above will be a good set of measures to take. Of course, it all depends on how important/valuable your software is.
Remember, if someone is really persistant, they will find away to share your files without detection. So things like great customer service, and value add will be your biggest help in keeping your customers loyal to you.
What about the rest of the world? (Score:1, Interesting)
First idea, stop thinking that the best and the brightest are all American.
Second, do a spider diagram of all the possobilities.
Third, remove the ideas from the diagram that are not feasible.
Presto, a solution.
why not partner with digital river? (Score:1, Interesting)
Re:I do! (Score:4, Interesting)
Either use a symbolic link (most Unix filesystems), or even a bit of mod_rewrite (Apache). The user will never see the true filename, and if you're smart the actual file is not within a web- or ftp-accessible location anyway.
Eg:
on the filesystem.
Or use a script that authenticates (using the unique ID) and sends the file data; this can be done with PHP, Perl, ASP, or just about any language that can read the QUERY_STRING environment and open/read files. You can store the user's ID and expiration time in a database, flat file, whatever. No browser issues as long as you send the appropriate headers.
I could think of many other ways do accomplish this; copying the file for each user is just nuts... you might as well email it to them.
Anyone (Score:3, Interesting)
Warez groups used it a LOT to remove copy protection from games/apps/etc, so the first think they did whith it after they downloaded it was to alter the SoftIce binaries to get rid of the expiration date...using SoftIce itself to find the places where the checks were being made.
If you build it... they will break it. (Score:2, Interesting)
Developing a secure distribution channel has always fallen down, for me at least, at the point the user gets the raw bytes. Crypto schemes, authorisation keys and checks, and even personalised code is useless once one person manages the crack.
My perspective nowdays is to try and delay breakages until after the main marketing period. With the upgrade cycle, you can generally keep at least the current version fairly secure.
Sorry to sound pessimistic - but I am a great believer in "If it can be built, it can be broken". It's just the time taken that varies.
Q.
P.S. An unmodified crypto routine is brute force ready... Much as I hate to say it, security by obscurity is your best first line of defence. Mod that crypto routine, just don't fsck it up...