I am wondering if anyone has any experience with these services - similar to recorded delivery for standard (snail) mail.
The ones I have been reading about are ReadNotify and PGP Digital Timestamping.
A couple of questions:[ol][li]Does it work?[]Is it worth anything? []Particularly in a legal sense - does the fact that you have the “reciept” notice from the service provider prove that the information was delivered? (for legal purposes, I am in the UK)[/ol]Any/all comments welcomed…[/li]
Grim
I have seen this work on a high school network but i’m not sure about the internet
and if the reciept diddn’t prove you had it sent then who ever sent you the reciept is lieing
:dubious:
Well, I had hoped for a somewhat more coherant answer…
Grim
Have you thought of setting up two email accounts with different ISPs and testing them yourself?
Try and set up your accounts where you can read the full email headers. I’m betting if the company inserts additional header lines to track email, anyone could do the same and forge them.
Why I don’t understand is how they can make the claim they can track how long an email has been opened, among other things. If you log on to your ISP, download your email, log off and read it offline, how is this tracked? Is a hidden notification sent from the receiving account without knowledge of the receiver? Is that legal?
If your email account/client are set up to handle delivery and read notices, why pay for it from a third party? Of course, the recipent’s account might not honor delivery/read notices so you would be out of luck.
I have no direct knowledge about either of the systems the OP asks about, but you’ve hit on the gist of the problem that plagues all the similar schemes I’ve seen. They all rely on a trusted client. That is, you have to run an email client which cooperates with their system, handles whatever headers or other tags they apply, and acts in a way they expect. They are trivial to disable or subvert by simply not using the trusted client. Like too many bad security products, they work perfectly well for cooperative users and not at all for malevolent users.
It looks like the digital timestamping process only allows you to include a verifiable timestamp in an outgoing mail. This lets the sender demonstrate that he encrypted/signed the message at a specific time, but it doesn’t enforce any behavior on the recipient. This seems perfectly reasonable and useful, but it doesn’t seem to do what the OP intended.
The ReadNotify system allows you to add their notification and rights management features by forwarding mail through their proxy. However, they claim they proof of delivery, proof of opening, retraction, and rights management on the client. None of these can be accomplished without a trusted client app. They seem to rely on recipient action (e.g. click here to indicate you read this) to enforce some of their policies.
My criticism of ReadNotify is relatively uninformed and I’d welcome being proved wrong because if anyone could make a system like this work in general, it would be very useful. However, until these kinds of features are included at the protocol level and enforced pervasively by clients and servers, I see lots of cracks.
I’ll take a shot at this:
A) Does it work? - yes.
B) Is it worth anything? - yes, although quantifying the value is much more difficult.
C) Is it “proof”? - no, but it can be evidence, legally.
Well, let me elaborate on that last one. I am not a lawyer, and have very little understanding of UK law. However, I have some experience in dealing with these issues as a layperson.
There are a number of legal concepts that become intertwined. You have common law, but common law doesn’t deal with email and electronic “signatures”. It does deal with contracts, evidence, and proof however. You have statutory law, and in the UK, I am unaware of the status of statutory law regarding electronic signatures (and/or related topics). And then you have case law. Folks with legal minds I respect remind me that statutory law shouldn’t really be relied on until case law supports it. And I sincerely doubt there is much case law developed on any statutory law that might exist.
From here on, I’ll talk with the perspective of US law, which I assume to be very similar to UK law. Let’s first review the “real world” analogs. If you were to send a document (a notice, for instance) via the postal service with a return receipt, you first need to understand what that receipt really says. Does it simply imply that the package was delivered? Or that the intended recipient received it? And if they received it, did they open it? Read it? Understand it? Acnknowledge it’s message?
What if it is a contract, and they sign it, and send it back. Does their signature “prove” that they accepted the contract? No…
They can still dispute it, in court. But all of those factors, including lots of other context, is used as evidence. And preponderance of evidence is used to make the case. Someone else (judge or jury) will decide if it is proof enough.
The electronic counterparts are the same. They do not “prove” anything. But they can significantly contribute to the value of the evidence.
The concept I think you are after is non-repudiation, which would prevent someone from denying being party to a specific transaction. A very good (and reasonably brief) discussion of these issues can be found here.
I am not familiar with the specific implementations you linked to. Just looking at the homepage of ReadNotify, I can confirm that they make at least one untrue claim. But that doesn’t mean that they can’t add value. I am familiar with PGP and Timestamping services, but I have no insight into that specific implementation. Think about it - it is easy to see how technology could prove email was delivered to the appropriate server, that the server delivered it to a specific client (although not a specific user), even that it was opened, and stayed opened for some time. But how could technology “prove” that is was read? Did it give a comprehension quiz? Beginning to see the problem?
I’ll avoid a dissertation public key cryptography, but that technology is the only one I am aware of that even tries to offer non-repudiation (at least in a generally accepted manner). The technology issues are extremely complicated, and I won’t go into them here, but suffice it to say, the real underlying problems aren’t with the technology. They are how people interact with the technology.
So here is where I differ (perhaps slightly) with Micco’s statement about inclusion in the protocol layers and client/server enforcement. The challenging problems to overcome aren’t really down in the technology, they are at layer seven of the OSI model - where users (people) interface with the technology.
For public key cryptography to be helpful in this context, one must be very sure that the initial binding of the secret key to a specific individual is done with high assurance. This is a critical step, and usually cannot be effectively performed in any way besides “in person”. This is usually the killer for the sorts of things you are discussing. But even if that step is completed with high assurance, other issues are equally important. Can you prove that only that individual retained access to the secret key?
The bottom line: Business decisions always come down to managing risk. Technology solutions may provide a way to minimize the risk, but you will still have to decide whether you can accept the remaining risk. And because of the “newness” of these electronic solutions (and lack of statutory and supporting case law), quantifying the risk is also very difficult.
I don’t think we differ at all. I agree with everything you said. My point was that right now, it’s a people issue like you say, but we could push it lower. Right now, all these services require a cooperative client (by which I mean the person on the receiving end agrees to participate in the machinations required to make it work). If the recipient chooses not to acknowledge the notifications, opts to filter that outgoing traffic, refuses to sign the receipt with his keys, whatever, then the protocol fails.
These choices could be pushed lower in the stack if the technology is pervasive and hard to subvert. For instance, in a corporate environment where the software used on the client side can be controlled, you can implement a lot of these things like return receipts and rights management. However, it requires the server to be able to authenticate the client software and refuse to communicate with a non-compliant app, and it may still be an arms race situation where users try to spoof compliance and the server must go to more extreme measures to authenticate not just users but software.
In a more open environment, sending to arbitrary recipients, this kind of control is futile (IMO) at this time. Drastic changes in the protocols could change that. For instance, we could implement a new version of SMTP and POP protocols that included low-level support for these kinds of features, make public-key signing and encrypting transparent, etc. In this case, it might be possible to enforce these things in a more general way, but you still have to worry about non-compliant apps tricking the system into accepting their traffic.
As far as the OP goes regarding the legal consequences of these, you need to look at two separate cases. In the first case, you get the return notifications or whatever you expect, and you need adequate authentication processes to make that stand up. In the other case, the recipient chooses not to cooperate and you get nothing in return. In that case, you can’t make any kind of legitimate statement about what the recipient did or did not do.
I still think we may disagree a bit, but I see one problem, the term “client”. When I use client, I’m talking about software running on system that is interacting with a user. And my point is that the technology exists from the client on to do this stuff. It is connecting the user to the client that causes the problems.
BTW, most email systems these days DO support such technology, through S/MIME. Also, of course, any particular implementation of these technologies will have their own vulnerabilities and weaknesses.
The one spot, and perhaps what is most relevent, where we agree, is that right now, these systems will never be useful without the cooperation of the other party. They will have to essentially “opt-in” to the system, and agree to play by the rules. Trying to impose this on an arbitrary third party is fruitless.
I think I agree with you, so if you don’t agree with me it’s because I haven’t clearly articulated what I’m thinking…
I agree that this technology currently exists from the client on, but it is not enforced at the client level. That is, the human using the client can choose to subvert the system by running a non-compliant client application. I think this is what you’re labeling a failure of the user, but I consider it a failure of the technology. There will always be users who don’t want to do things a certain way, and either the software enforces certain standards or it doesn’t. If it doesn’t, then you’re left worse off than you were before because you cannot rely on the consistency of the system. Just having these kinds of options (read notifications, rights management, authentication) available in the client isn’t useful in a legal sense unless they must be used. If the user is free to load up their own email client that doesn’t support these features, the features are pointless.
I agree with your comments about opt-in obviously, and I’m just pointing out that once they opt in, you have to be able to be sure they’re actually playing by the rules. If I say I will participate in your system but then I decide to filter my outgoing packets to remove all the notifications that I’ve read your email (or worse, tinker with the data to make it appear I did things differently) then the technology has failed and the system is useless.
Thank you all - much more what I was hoping for!!
Much food for thought.
Grim