On private discussion with Greg DePriest, I think I understand his
viewpoint, but also that the viewpoint arrises from a misconception.
ALTO will basically operate in one of the following manners (exact
mechanism is subject for debate, but this is the general concept):
1) Client queries "Who should I talk to who's participating in
identifier ID" (Q? ID)
2) Client queries "Who among this list of participants is best to talk
to" (Q? IP-LIST)
3) Client queries "For ID Q, who among this list of participants for
identtifier ID" (Q? ID, IP-LIST)
And there are significant advantages to #1 or #3.
Greg has been operating under the assumption that it is either 1 or
3, and that ID must be stable, meaningful, and reasonably long lived.
Which is the case for IDs (hashes) in P2P protocols.
If that is the case, then his argument is "At least allow us to play
Whak-a-mole by saying 'these hashes are bad'". Which does work to
some degree.
And if ALTO was a distributed caching or distributed search protocol,
I'd agree with him, 100%.
For in those things, ID generally has to relate to the content (its a
hash, and its long-lived), so with an automated system, you can play
automatic DMCA Whak-a-mole and have an effect.
However, I believe (and I think there is a consensus) that IDs are
opaque data to ALTO, simply a blob of bits provided by the P2P
protocol, and are probably best specified as UUIDs. And ALTO's IDs
only need to be for a very short time, sufficient to rebalance the P2P
network.
Thus if ALTO provides a significant performance gain for P2P (as
opposed to an aggregate cost savings, where I believe the benefits
lie), a pirate data source can simply churn IDs very quickly: "For
the next 20 seconds, all peers should reoptimize using this NONCE".
And there are reasons for such reoptimizations on purely legitimate
P2P, (eg, churning ID's allows you to "reoptimize now" and avoid
problems with stale data in ALTO) so you can't block that behavior.
Thus since IDs don't have to be long lived for this use, nor related
to the file content, you can't play whak-a-mole, and building that
facility into Alto's infrastructure doesn't help content providers vs
the pirates but would hugely complicate and compromise the design of
ALTO.
Since an "exclude these" model wouldn't work due to churn, the only
way ALTO could provide content protection is an "include only" rule:
only identifiers which are specifically ADDED by a "trusted" source
are supported, and I believe that would be a huge compromise in ALTO's
usability (why don't these trusted sources just pay for Akamai and not
use P2P?), and even that might not work as pirates could optimize on
"lightly used but allowed" identifiers and just ignore the false
matches.
This is the best reason why "Content protection is not in the ALTO
charter": ALTO, by its limited nature and viewpoint, can't provide
content protection, and attempting to provide such functionality
anyway would significantly compromise alto's design.
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
