|
|
|
Jon Crowcroft,UCL & |
|
Ian Brown, Hidden Footprints |
|
http://www.hiddenfootprints.com |
|
|
|
|
|
|
Provide Digital Wrongs Management |
|
Relates to Content Distribution and online
rights management/licensing/copyright protection |
|
Looking at Broadband Internet of Future with
film and game content as well as mp3/napster… |
|
|
|
|
|
|
|
|
Tracking the trail of the wiley copy-wrongdoer –
requires thinking about evidence |
|
Critical problem is not to prevent disclosure, since
this is impossible |
|
Rights management is a red-herring and is more
about fee collection. |
|
|
|
|
LSBs, compression parameters etc. changed to
imperceptibly mark image |
|
|
|
|
Pure watermarking is now fairly common –
problems abound |
|
Scaling |
|
Scrubbing |
|
Collusion |
|
Upgrade… |
|
SDMI…..not too clueful J |
|
|
|
|
NOT trying to do the impossible ie replace all
current audio players with SDMI-compliant "trusted" clients. |
|
NOT
trying to target the consumer: they are too many of them, with too few
resources, who would get too pissed off at the content providers – bills
are already being proposed in Congress that would help Napster and MP3.com
because the voters like them... |
|
* being realistic about where content can be
controlled -- yes with a small number of users for a limited period of time
who can be forced to accept high liability for pirated content (eg
cinemas), no with consumers. |
|
|
|
|
|
Real, etc have scaling problems |
|
Viz cnn.com |
|
Viz evolution of napster to gnutella |
|
New emergence of intermediaries: |
|
Akamai, Inktomi, and middleware business for
them – e.g. |
|
Ffnet, ensim, bandwiz, digital fountain… |
|
Strengths – good at scale and heterogeneity |
|
Weaknesses – still don’t track content |
|
|
|
|
Based on combination of distribution network,
and source marking |
|
Source adds more than enough watermarks –
similar technique to layered FEC multicast (rlc/digital fountain), with
meta data on packets |
|
Distribution network removes different subset of
marks for different receivers` |
|
|
|
|
|
HTTP: |
|
access mechanism |
|
TCP |
|
Client-server: |
|
proxy arrangement possible |
|
Client-side cache: |
|
speeds up multiple access to same page |
|
Proxy cache: |
|
multiple hosts on same network |
|
|
|
|
Extension of HTTP |
|
To peer-to-peer |
|
Synchronise between proxies/replicas |
|
Load balance etc etc |
|
Can apply out tech., there too. |
|
|
|
|
|
Many-to-many: |
|
many senders and receivers |
|
host group or multicast group |
|
One transmission, many receivers |
|
Optimise transmissions: |
|
e.g. reduce duplication |
|
Class D IP address: |
|
224.0.0.0 - 239.255.255.255 |
|
not a single host interface |
|
some addresses reserved |
|
Applications: |
|
conferencing |
|
software update/distribution |
|
news distribution |
|
mutli-player games |
|
distributed simulations |
|
Network support: |
|
LAN |
|
WAN (Internet routers) |
|
scoped transmission: IP TTL header field |
|
|
|
|
|
Features of IP multicast: |
|
group of hosts |
|
Class D address |
|
leaf nodes (hosts) and intermediate nodes
(routers) |
|
dynamic membership, leaf-initiated join |
|
non-group member can send to group |
|
multicast capable routers |
|
local delivery mechanism |
|
IGMP: group membership control |
|
|
|
|
|
Need to translate to MAC address |
|
Algorithmic resolution: |
|
quick, easy, distributed |
|
MAC address format: |
|
IANA MAC address allocation |
|
last 23-bits of Class D |
|
not 1-1 mapping |
|
Host filtering required at IP layer |
|
|
|
|
|
|
|
Distance vector: |
|
need next hop information |
|
(or use poisoned reverse) |
|
Link state: |
|
construction of all SP trees for all nodes
possible |
|
“tie-break” rules required |
|
|
|
|
|
Networks with no group members pruned from tree |
|
Must somehow allow tree to re-grow |
|
Soft-state: |
|
timeout – re-flood |
|
downstream nodes prune again |
|
Explicit graft: |
|
downstream nodes join tree |
|
|
|
|
|
State assumptions about resources allocated to
this project |
|
People |
|
Equipment |
|
Locations |
|
Support & outside services |
|
Manufacturing |
|
Sales |
|
|
|
|
|
|
|
|
|
|
Highlight any procedural differences from
regular projects of this type |
|
Discuss requirements, benefits, and issues of
using new procedures |
|
|
|
|
Sending differently marked data streams to each
client rules out multicast. |
|
Even if bandwidth was available, marking
algorithms don’t scale. |
|
|
|
|
Server watermarks and multicasts n versions of
each packet, where n ³ tree depth |
|
Routers drop one packet version based on next
hop’s IP address |
|
Last-hop router passes on only one packet
version based on receiver and router identification key |
|
|
|
|
Source creates 5 versions of each packet |
|
Each router drops one version |
|
Last-hop router passes on one version to client |
|
|
|
|
PGM application-layer filters could be used at
routers, but have extra security requirements |
|
Reverse SPMs require special support |
|
Client only needs way to obtain security
parameters from server - no media tool alteration is necessary |
|
|
|
|
Provide each client with media decryption keys
after receiving valid reverse SPM |
|
Store original media, client details and tree
topology for as long as content needs to be traced |
|
|
|
|
|
|
Classify recovered clip’s packets - ACCEDBADABCD |
|
Simulate network behaviour during that period |
|
Calculate users and routers who individually or
in collusion are most likely to have produced clip |
|
|
|
|
Review high-level schedule milestones here |
|
|
|
|
|
High-level overview of progress against schedule |
|
On-track in what areas |
|
Behind in what areas |
|
Ahead in what areas |
|
Unexpected delays or issues |
|
|
|
|
|
Marketing plan |
|
Location or contact name/phone |
|
Budget |
|
Location or contact name/phone |
|
Post mortem |
|
Location or contact name/phone |
|
Submit questions |
|
Location or contact name/phone |
|
Notes
