|>>OK first off re keeping the layers separate, very good point. Before we put
|>>security enhancements or rather enhancements for security into HTML we
|>>have to put them into the transport layer. Both Dave Ragget and myself
|>>are working on the security side as well as the HTML+ side so we are
|>>aware of the issues, state of play etc.
|>>
|>>The issues of authentification etc should be the subject of some RFC proposals
|>>in the near future. For a preview of Shen see :-
|>>
|>>http://alephinfo.cern.ch/AL2F01$DKA100/hallam/INFOGEN/SECURITY/REF/security_spe
|> c.html
|>
|>Can't seem to get to this...
:-( Sever down :-(
They might be putting up a new one :-)
|>>There will be support for prohibit copy, prohibit cache etc.
|>
|>I assume that when you say "prohibit" you mean "request that it not be
|>done"?
Errm a little more. In order to fudge the thing you have to have access
to the private key. This can be prevented in the large site set up (eg
CERN) where the key that the vendor responds to is not accesible by the
employees. On a home site it is party time of course. There is no way I
can prevent home users being naughty but I can make it a little harder...
|> This brings up the whole interesting issue of whether it is
|>irresponsible to create something that provides the appearance of
|>security without actually providing it.
We are making the levels of security quite clear. The security is limited to
that of the private key. As it is J random hacker at CERN or MIT will not be
able to read confidential documents and then export them off site. But
this will not prevent the likes of the members of the crypto-lab.
|> If publishers send
|>information out onto the wire, people will be able to copy it and give
|>it away. If they are under the illusion that they can do anything
|>more than make it inconvenient to do so, well...
Hmm VERY inconvenient is the way I would put it...
|>I think this problem pretty much goes away if you price your
|>information appropriately and in small chunks. How much time would
|>you waste searching for a old pirated copy of the Britanica entry on
|>Uganda if you could get the authoritative, up-to-date entry from the
|>source for only $1?
Hmm I prefer the season ticket model myself. Buy into Encyclopaedia Britanica
for $20 pa... Subscription to WiReD $25 pa... etc..
|>>The issue of support for proxying etc is being thought of but we are
|>>not there yet. The big question is about the level of trust you place
|>>in the client. In any copyright protection system you have to put some
|>>faith in the user and client.
|>
|>Designing clients to they are trustworthy necessarily means designing
|>clients so they are not powerful and extensible.
No. Its merely a matter of very clean design.
|> There's a real
|>trade-off involved in how much we're willing to cripple client
|>software in order to provide a false sense of security to existing
|>publishing entities clinging to old ways.
Nope, the idea of the prohibit channels is not really for the likes of
WiReD. By the time second hand copies are passed round it will be
avaliable for free from the archive site, archive is free, current you
pay is what we want to encourage.
The prohibit channels are more for security clearance systems and very
high levels of security. They are not primarily intended for the magazine
market.
Remember this is a revenue maximising operation, not a copy prevention one.
On the home market there will be people breaking copyright just as they do
with cassettes, CDs and videos. What I can guarantee though is that a good
system manager will be able to guarantee that Medical records etc are not
copied when they should not.
-- Phillip M. Hallam-BakerNot Speaking for anyone else.