> > > I don't think that Adobe is especially interested in promoting > FlashPaper, > > which is essentially a competitor or substitute for PDF. >
Pity about FP being deprecated. However, this is a use-once-then-throw-away project so I'm not too worried about the technology not being supported in future. You should make it very clear to your client, in writing, that all you can > do is make it more difficult. Otherwise, you may be on the wrong end of a > lawsuit when one of these documents does eventually get emailed around. > Yes, you make a good point. Will definitely make this clear in writing. > How do you know you've successfully used HTTP headers to do this? Since all > the action is on the client, how exactly can you verify that this has been > successful? > What I mean is that we have tested it in various browsers etc. I realise that this is merely induction and that I can't know that it will always work on every client in every context. However, we are not really relying on this. What we need to do is also have some kind of crude scrambling of the document swf that can be unscrambled by a wrapper swf. That way, even if the doc was in the cache it wouldn't be readable by a browser. *However, I'm assuming you can manipulate the bytes of an swf in the Flash player.*(Disclosure: I am not a Flash developer I'm a C# guy - but I'm going to be hacking away at AS as though my life depended on it). There are third-party products that manipulate HTTP request and response > headers as a matter of course. Some of these are common consumer > applications. Some of these are installed by computer manufacturers. > What about the tech-savvy business person who asks his coworker in IT down > the hall to grab a copy? > You're right. Anyone could intercept the requests for the document. However, given the crude scrambling approach it would be only be usable after some determined hacking. And if they did that then they could never claim they did it by accident, which I think that is all we are trying to guard against - We are just trying to make it difficult to do - not impossible. After all, all consumers have signed Non Disclosure Agreements. If you're interested in a more secure solution for this, you might want to > take a look at Adobe LiveCycle ES Rights Management. This will let you > deliver PDFs that can only be used in very specific ways, by authorized > users, using Adobe Acrobat or Adobe Reader only (no third-party PDF > viewers). It's fairly expensive, but will let you make it much more > difficult than any of the solutions you're considering. > Thanks for pointing out LiveCycle, Dave. I looked into it and it seems very comprehensive. There are a couple of reasons why I can't use it though. Most of the users work at institutions with locked-down desktop deployments. They can't install *anything* - even a browser plug-in (hence my choice of the ubiquitous flash plugin). And some of these companies have deployed 3rd party PDF readers, which is pretty much a non-starter for LiveCycle. Additionally, LiveCycle is a mammoth toolset and I'm not sure I could get my head around it, develop the solution, deploy it, and go-live by this Friday (which is my scary deadline!). I will consider LiveCycle for a future project though. Anyway, thanks very much for your input. I'd be very interested to know if you think the swf byte manipulation thing is doable. TIA Stu _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
