|
That's That
===========
That's nothing to sneeze a real nowhere there's a will there's a wayback machine learning Odyssey and the Iliam Neeson of a guntotin' rootin' tootin' Raspberry Piehole in the World and that's
|
|
|
|
|
I want a document format that: when I distribute copies of the document to others:
0. will only "work" (open, be readable) on the computers of those I have sent it to who have a working password. i.e., if you were able to copy it onto another computer, it would not "work" even if you had the correct password.
Requires people with drafts/copies to have internet access, and, when the document is opened, an "authorization exchange" between their computer and a server I control will determine whether the document. No internet access, no document access.
a. has "atomic elements" (text, images) that are copy-able or un-copy-able, editable, or un-editable.
b. content can annotated by the user in some interesting way: the annotations are, then, automatically posted to an archive on my server ... either as created, or when the document is closed.
c. if my server sends the right whatever down the wire when the user opens the document, the document will essentially "destroy" itself: content and structure rendered unusable.
d. the document can be time-limited, and will self-destruct as in 'c. after a certain date.
e. will embed a digital watermark allowing its source to be traced back to an individual or computer.
f. all of the above must not "feel oppressive" to the end-user.
g. has to work on Win, IOS, and Android.
In spite of the above "stipulations," I recognize what's described here... unless done to military-spec encryption and, perhaps, hardware dongle levels of whatever ... can be defeated by someone dedicated enough. Of course, I also recognize the virtual impossibility of preventing screen-shots which could then be run through OCR software to resurrect viable text, etc.
My thoughts are that the only way most of this could be implemented would involve having an installer that created a "hardware hash" key based on the user's cpu, hard-drive, etc., during installation and then sent that up to the server. The server would then use that to "water-mark" each document, and the reader app would send that hash to the server when the reader was opened ... the server would then send back a message that would control "document state."
Why would I want such a document application/format ? To prevent accidental copying and forwarding of content, for example. To prevent possible plagiarism when sharing original creative work. More seriously, I can see a need for this in certain "intellectual property" scenarios.
I confess complete ignorance of what's possible in this "arena" using tools like Acrobat and MS Word, at this point in time.
Is the seed-idea for your next million dollar$ waiting for you, lurking in this excursion into Orwellian fantasia ?
Will you at least buy me a latte when you cash in ?
cheers, Bill
«I want to stay as close to the edge as I can without going over. Out on the edge you see all kinds of things you can't see from the center» Kurt Vonnegut.
|
|
|
|
|
BillWoodruff wrote: Is that too much to ask?
Yes.
|
|
|
|
|
|
Please take a look to the Harvard study cases for Economics and Management Engineering. They use a client that even block screen captures (which I bypassed anyway, VNC is the way) and the corresponding format. It also charges money for printing.
When I attended courses at my local University (Polytechnic University of Turin) we also had a similar client to freely access books that were otherwise to be bought.
I can't be more specific due to Internet access restrictions of my company (long live the Direction!).
Geek code v 3.12 {
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++*
Weapons extension: ma- k++ F+2 X
}
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
|
|
|
|
|
There is a protection API that all the MS Office applications and Adobe PDF viewer called "Information Rights Management".[^]
It works well enough at preventing emailing/printing/accidental disclosure but, of course, can be circumvented by someone with a camera phone and OCR software.
|
|
|
|
|
PDF?? At least some of your items I would think are handled by this format.
|
|
|
|
|
It already exists; it is called a "compact disc".
..but it ain't too hard to change a few byte and create a new one. So, no, not in the digital world.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
SharePoint? 
|
|
|
|
|
BillWoodruff wrote: the document can be time-limited, and will self-destruct as in 'c. after a certain date.
The problem with self-destruction is: How would you trigger it if there is no access to the server that is in charge of the kill switch? One could steal a document and try to hack it on an network-isolated device. There's also no easy way to prevent an attacker from creating copies or backups of the document (provided that "the document" is a physical file stored in a file system) and restore it if the original has been destructed.
Because of this, I think a better approach would be to get away from the idea to have a physical copy of the document present on the client. I mean, if an internet or local network connection for authentication etc. is required to access it in any event, why store the document on the client in the first place?
IMO a protected document has to live on the server exclusively, and the client (the reader) downloads only the parts it wants to access on demand, storing that information in encrypted form in memory rather than on disk. The private key could be the hardware hash of the client device, although that might not be the safest approach because someone with physical access to the device could steal that information and build a specialized virtual machine that impersonates the client. Any edits are sent back to the server and stored there. No need for self-destruction as the local information will be lost when the reader is closed or after a timeout (zeroing the memory) or when the device is powered off.
|
|
|
|
|
Quote: all of the above must not "feel oppressive" to the end-user.
You should be alright as long as they're dead or in a coma but then I'm not sure what the point of them having the document would be!
|
|
|
|
|
You're basically talking about Digital Rights Management for documents.
And given that people with lots of money spend a lot of it on getting very clever people implementing this for their games, movies, and music - only for even cleverer people with no money to circumvent it the same day and publish it to torrent sites - I can't help thinking we're all on a loser here! 
Except of course for the very clever people who somehow remain employed to try again...and again...
I would agree though. I suspect we need to redesign the internet from scratch, involving individual identity and security systems as its core components, and hopefully dumping HTML for good at the same time. That way, you could start tieing documents of all types to users and get some real protection going.
But...nobody would use it because it would be too secure... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: nobody would use it because it would be too secure...
Not 'too secure', but dangerous.
Imagine I had access to the authentication-server for 'the internet'; we would never run out of IPv4 addresses.
Baking DRM into the internet would also not help; if the document is visible, it can be captured.
Meaning you now have two problems, while starting with one 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
An ebook library that I once used required this[^]. Some of the features you require are supported, like allowing only a particular user to access the document and setting a time limit. I have no idea how the documents themselves are created, though. Probably some Adobe product.
|
|
|
|
|
From my limited experience as a user Amazon eBooks have most of what you want.
|
|
|
|
|
Hi Bill
I read your request with great interest and I have been associated with an application available in Australia which addresses the central issue: locked documents. This application focusses on version control and revision control: locking the Word document at full revision, with Word-functionality markup revealing the changes between revisions.
Since it is improbable that one can break the security (requires world-PCs for 10 x exp 26 seconds), and the content is locked, so self-destruct was not included in the system specification. Management of documents at word-by-word level is central to this application - and is different from Documentum, LiveLink, Hummingbird, etc. in this regard.
Your requirements are broader than this application: brought on by the advance in mobile computing. I have passed your requirements to the developer for his comments.
Should you be further interested, please reply.
|
|
|
|
|
Is that too much to ask ?
TL;DR - Yes
Long version - I have worked extensively with Digital Rights Management systems including Microsoft's own AD-RMS (which is a classic MS software - Overly Complex Architecture but Pretty Neat Features). Parts of what you are asking for is practical at all or impossible to implement. There are lots of factors when it comes down to protecting a document. Offline scenarios are real pain in the neck. Identifying the document/user/device/location is one of the challenges as well. There are many issues you see when you start a feasibility analysis on a requested feature and you have a bunch of them.
In any of the cases, you need to bring your expectations down.
Also, take a look at this : http://www.worldox.com
|
|
|
|
|
You could probably leverage it as a Kindle Book.
Kindle Readers Everywhere, simply make the user buy it 
It is pretty limiting...
Not sure about the timing feature, but you could do it as a lease, and yank it back (no self-destruct, just that they lose the ability to open it)
|
|
|
|
|
Hi all, I'm trying to read an article on here and there's an ad for Azure on the right hand side of the screen which is obscuring what I'm trying to read - is there a way to get rid of it ?
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
You probably want to mention if you are a mobile device and you definitely want to mention which browser (including version) you are using.
If you, by chance, are using mobile, I suggest you select the choice, "deliver desktop site" or whatever that choice is. I know on Android Chrome CP looks all kind of crazy and is all zoomed in.
Good luck.
|
|
|
|
|
I'm on a laptop running Win 7 using Firefox
Thanks
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
Right-click on the ad > Inspect Element.
There will be an highlighted line. Right-click > Delete Node.
Your ad should be gone. If not, repeat those steps for all elements blocking your view.
Cheers.
"It's hard to beat someone who never quits".
|
|
|
|
|
Ta very much I'll give it a go
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
Works thanks
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
No problemo, sir.
"It's hard to beat someone who never quits".
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
