The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Prevent offline viewing of Internet pages

I have a site where users pay for access one year at a time. Obviously I want users to renew their membership each year. BUT if a user saves my pages to their own harddisk they can continue to use these pages for free as long as they want. Most of my users are schools with servers of their own. If/when my pages end up here, access is now free for all connected to that server.
  I would like to restrict the use of my pages one step further than a normal login with user id and password offer. The best thing, as far as I can see right now, would be to prevent the page to be run outside my site. I’m aware of several programs that offer to “fix” my pages, but these programs also do several other “secret” things to my code that often prevent the page from working at all.
  How can I “tie” a page to my site?
  Does anyone else have similar problems?
Cheers Jorgen
Jorgen Brenting Send private email
Saturday, December 09, 2006
 
 
Good luck ;)

This is similar to the "How do I protect my graphic image?" problem. Once your code and/or pixels (screen image of a page) are on someone else's computer, just what exactly can you do? Not much. All you can do is make it a little harder and so discourage the easily-discouraged. The determined will beat you.

Technically, the only real option is to write your own "viewer" (web browser) such that the viewer is the only client your server will serve, and the viewer will not allow the user to save web pages to the local computer (and no cacheing either), and the viewer prevents PrintScreen. Hardly a solution in the commercial sense. I imagine most of your current and potential customers would simply run away :)
less is more
Saturday, December 09, 2006
 
 
Okay, let me rephrase the question a bit: What is that the programs offering “to prevent offline viewing” actually do?
Jorgen Brenting Send private email
Saturday, December 09, 2006
 
 
If you do something like use Javascript (AJAX) to load the individual paragraphs for display - as opposed to having them in the page - you might be able to do something...  but if they don't have Javascript, it's not going to work.  And printing might be difficult.
KC Send private email
Saturday, December 09, 2006
 
 
Put the information into eBooks with expiration dates.
dev1
Saturday, December 09, 2006
 
 
KC:
All the pages do have JavaScript in them already. It’s in an external file and I was wondering if I could hide that file in another folder from which no one could request it (Microsoft server).

dev1:
e-Books  won’t work because user join on various dates.
Jorgen Brenting Send private email
Saturday, December 09, 2006
 
 
++Obviously I want users to renew their membership each year++

Why don't you create new content so users WANT to renew.

Saturday, December 09, 2006
 
 
++Why don't you create new content so users WANT to renew.++

I do, I do, of course I do. Lots of it! But I also want users to run my interactive pages (e-learning) on my site only.
Jorgen Brenting Send private email
Saturday, December 09, 2006
 
 
Once a user can see a page, there's no way to prevent that user from saving the contents.  I can use PrintScreen and save to a file.  I can do a Select All and Copy to wherever I like.

The best way to keep users subscribed to your site is to keep having new content so they'll see a benefit in continuing to subscribe.
Right to HFre
Saturday, December 09, 2006
 
 
Even if you provide super-protected content with your own reader and all, if I really want or need your page content and anything else fails, I'd take out my digital camera to make screenshots.

There is only one 100 percent sure way to protect digital content: Do not publish it.
Secure
Saturday, December 09, 2006
 
 
Well, the pages in question are interactive e-learning pages so a screenshot would not be of much use, but I'm beginning to get the point :)
Jorgen B.
Saturday, December 09, 2006
 
 
You don't have to protect your page against every clever hack under the sun.
You just need to make it a little too difficult and time-consuming. Having the javascript in another file already makes the thing difficult for almost everyone.
Pakter
Saturday, December 09, 2006
 
 
Thank you Pakter, I quite agree. The JavaScripts are already in separate files. I was thinking whether it is possible to put these files in another folder and in some way restrict access to this folder from the outside, but of course not from the html file calling the JavaScript. My own tests so far have been fruitless. I’m on a Microsoft server and I lack the knowledge to solve this one.
Jorgen B.
Saturday, December 09, 2006
 
 
DRM sucks.  I only buy digital music from eMusic, which sells legal (in the US - not some psuedo-legal ripoff site hosted in Russia) MP3s, sans any form of DRM. 

Sure, that means I can't get my hands on the latest 'top 10' albums ... but that's no great loss.  I'll take the inability to purchase Britney Spears 'music' over the ability to legally media shift any day.

In my experience, DRM just makes it harder for consumers.  Make it hard enough to pirate your content, and you'll make it so hard for legitimate users that they'll go elsewhere. 

Better to focus on usability and great new content, IMO.  If you feel like you have to employ technological lock-in like DRM, there's probably something wrong with your business model.  Just go ask the RIAA :-)
Duncan Bayne Send private email
Saturday, December 09, 2006
 
 
Perhaps the Javascript can get the date (from the browser in which it's running), and fail if the current date is very different from a date that hard-coded inside the javascript file ... then you'd need to update your own javascript files periodically, but old javascript files (archived on users' computers) would stop working in a few days.
Christopher Wells Send private email
Saturday, December 09, 2006
 
 
Any source code stored on the local computer can be modified, so no point in relying on any code trickery.

My original point was that "protecting" content has a low gain/pain ratio and businesswise it's probably better to pursue an entirely different path. A point also made by other posters above.
less is more
Saturday, December 09, 2006
 
 
Duncan:
Of course all DRM that is visible (or audible) to the user is a bad thing. What I’m talking about here is something that in no way would affect honest users – at all.
  DRM is an interesting subject in itself, but as I see it there will always be two problems left no matter what: People generally want to get paid for their work – I bet you are among them - and very few want their intellectual work (i.e. program code) stolen. That is why the programs out there, which offer to ”encrypt” your code and – more interesting to me – tie your pages to your domain, caught my attention.
  So right now, even though I agree with “less is more”, I’m still curious to HOW these programs can prevent offline viewing. What is that they do to your code?
Jorgen Brenting Send private email
Sunday, December 10, 2006
 
 
I have used one of those encryption programs here: http://www.123abc.dk/DepotAdgang/SigLytSkriv/sls1s1a_E.htm
Try to view this page offline.
What I personally don’t like about this is, that more often than not it makes your page useless and it interferes with the server in mysterious ways – session variables disappears for example – and generally I do not want to use a tool, that I do not understand at least partially
Jorgen Brenting Send private email
Sunday, December 10, 2006
 
 
I would personally NOT renew my membership if you succeeded in prohibiting offline viewing. IMHO new content is THE answer to all questions related with subscription-based websites
trandism
Sunday, December 10, 2006
 
 
You could also consider changing the subscription length to monthly, with timed releases for updated content.

Time the releases so that people can only access the content after the monthly access fee is paid, and make sure that a new login is required each month.
*myName
Sunday, December 10, 2006
 
 
Consider what other companies do that have subscription-based content, like Microsoft with MSDN Universal, or Developer Express with its various controls packages.  Nothing prevents a person from subscribing, getting all the latest stuff, then failing to renew...and then, a couple or three years later, subscribing again to get updates.

Nothing except economics.  With Developer Express, for instance, their "Professional" suite of .NET controls costs $800 for an initial subscription, but only $300 to renew.  So over a seven-year period, initial subscription plus renewal would cost $2600.  If you cancel and then get a new subscription every three years, your cost is $200.  You save a mere $200, and you miss the benefit of getting new updates and content all the time.

So consider doing something similar: A higher initial subscription fee, and a cheaper renewal fee to encourage people to keep renewing instead of just re-subscribing every few years.  Plus, of course, enough new content to make it worth renewing.
Kyralessa Send private email
Sunday, December 10, 2006
 
 
"I have used one of those encryption programs here: http://www.123abc.dk/DepotAdgang/SigLytSkriv/sls1s1a_E.htm
Try to view this page offline."

Done ;-)
Roman Werpachowski Send private email
Monday, December 11, 2006
 
 
Hi Roman
Would you mind telling how?
Jorgen Brenting Send private email
Monday, December 11, 2006
 
 
"Perhaps the Javascript can get the date (from the browser in which it's running), and fail if the current date is very different from a date that hard-coded inside the javascript file ... then you'd need to update your own javascript files periodically, but old javascript files (archived on users' computers) would stop working in a few days."

What a pain.  I would stay away from such a system.

I have a few times edited pages and displayed them.  I could do that here if I had to.  It would be time-consuming (at least the first time until I figured out the pattern), and I would think nasty things about the Web site.

One site that I subscribe to stupidly has links in E-mail that link to pages containing merely a JavaScript line that redirects to the real page.  Oddly, the JavaScript link pages are supposedly in HTML since that is part of the URL.  I run with JavaScript disabled, so the link pages show a blank.

I do not know what problem they think they are solving, but they sure look silly.

Sincerely,

Gene Wirchenko
Gene Wirchenko Send private email
Monday, December 11, 2006
 
 
Jorgen: shit... I forgot to clean the browser cache during testing :(
Roman Werpachowski Send private email
Monday, December 11, 2006
 
 
Since this is an interactive learning site, is it possible to restructure the lessons such that various key details need to be reported back to the server and/or fetched from the server each time?

For example, say you recorded which "page" a user is on, as in TheDavid is now viewing page 15 of 30. If the 15 and the 30 are server side variables retrieved via AJAX or plain old Javascript, I will get an error message whenever I'm offline.

I can hack the Javascript to not send in a request (always assume 30 pages) but you can modify your server code to report me as a potential pirate whenever I visit the site and explicitly not request a new page count. I.e., TheDavid requested physicsLesson5.php but did not request the totalPages variable.

Having offered that as a solution, I'd also point out that most schools and universities are too busy to play Javascript games, especially if the subscription cost is reasonable. However, you do have to accept the possibility that determined, individual students can figure a way around it and it may not be worth the time and effort fighting those students.
TheDavid
Monday, December 11, 2006
 
 
By the way, Jorgen, a couple of our local libraries offer eBooks as well as regular books; you sign up for an account and then you can access the eBooks over the Web.

In order to keep you from downloading the whole e-book and keeping it, most of the books are in PDF format (some are in HTML, though) and you can only view one page at a time.  And if you flip pages too rapidly (not easy to do, since you have to wait for each one to load individually), it pops up a captcha that you have to type in to continue.

How well does it work?  Excellently; it's managed to annoy me so much that I can't stand to use it for more than perhaps half an hour at a time, and I haven't logged in to that system for many months now.

The difference between that system and your system is that that one was a one-time buy for the libraries.  I guarantee it wouldn't have held up as a subscription, even if it kept offering new content.
Kyralessa Send private email
Monday, December 11, 2006
 
 
Thank you all. There is nothing to clarify your mind as sincere suggestions and comments from outside. Right now I think Kyralessa sums up what may be the most clever policy to adopt: “
A higher initial subscription fee, and a cheaper renewal fee to encourage people to keep renewing instead of just re-subscribing every few years.  Plus, of course, enough new content to make it worth renewing. “ Others have said the same. LessIsMore hit the target from the start. Thanks again.
  I certainly do not want to make life difficult or even mildly irritating for busy teachers and other good people. On the other hand, if some clever way to make life just a little more frustrating to someone trying to steal instead of buying (cheap I can assure you) a membership, I would gladly adopt it. TheDavid may be on to something.
Jorgen Brenting Send private email
Monday, December 11, 2006
 
 
Jorgen, the Firefox Scrapbook extension seems to capture your page just fine -- for display purposes, anyway. Don't know about the functionality.
Lazlo Send private email
Monday, December 11, 2006
 
 
Here's a simple solution. Take your page, encrypt it, place the encrypted contents into a javascript string. Then you have a page viewier script that asks your server for a decryption key, applies the decryption key to the string variable, then does a document.html.body.innerHTML = 'encrypted string variable';

Anyone doing a view source only sees the page viewer and encrypryted string, all of your javascript still works because your DOM is identical, and the only way someone can get the decrypt key is with a packet analyzer.

And lets face it, if they're willing to use a packet analyzer, they'll have the smarts and the will to get your page no matter what you do.
Noishe Feargus Send private email
Tuesday, December 12, 2006
 
 
Isn't there a limit to the length of a Javascript string?
TheDavid
Tuesday, December 12, 2006
 
 
> What a pain.  I would stay away from such a system.

Alternatively, have the Javascript decrypt the page based on a key stored in a cookie. Would the Javascript have access to the cookie if it were run offline? Also set an expiry date on the cookie.
Christopher Wells Send private email
Wednesday, December 13, 2006
 
 
Christopher, now you're just being silly. Store the entire page and/or decryptor in the cookie(s), that's the last place anyone would look for them :)
less is more
Wednesday, December 13, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz