On this point, it's my turn to sound like a broken record: On 10/28/13 7:30 PM, [email protected] wrote: > And even if it a completely decentralized model was practical, in a > peer-to-peer world the metadata that would accrue from watching the > connections themselves would be a fair substitute.
This is another really important point. I'm sure many of us had the first reaction that all this stuff should be decentralized, which of course leads to "let's all get to IPv6". To the extent that consumers are able to have a choice about this, it's quite possible that a decentralized model using our existing protocol suite could *harm* privacy as Ned mentioned above. Beyond that, one has to ponder what externalities are introduced by having yet more consumer code accessible to the great wild world. Ironically, this Saturday, November 2nd, will be the 25th anniversary of the Morris Worm.[1] <#1> The world has improved since that time. A few things to highlight along these lines. One of my favorite studies to cite is that of Stephan Frei who looked at update rates and compared business models.[2] <#2> It seems that now even WordPress is doing this[3] <#3>, but we are certainly not there yet with certain systems. I'm thinking of code used in SCADA systems and automobiles in particular. There are sometimes tradeoffs between privacy and cybersecurity. Many are specifically*not* protocol tradeoffs, but operational tradeoffs. Aggregation of services probably is a good thing for cybersecurity – that's probably a worthy research topic, by the way. There is plenty of room for investigation and review of all of this, but coming back to Paul's earlier warning[4] <#4> that he forwarded, let's be thorough before jumping to recommendations for broad IETF changes. And let's please understand what tradeoffs there are. Eliot [1] http://en.wikipedia.org/wiki/Morris_worm [2] http://www.techzoom.net/publications/silent-updates/index.en [3] http://wordpress.org/news/2013/10/basie/ [4] http://www.ietf.org/mail-archive/web/perpass/current/msg00654.html
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
