- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Mon, 09 Jul 2012 17:11:29 -0400
- To: public-ldp-wg@w3.org
- Message-ID: <4FFB4901.7000105@openlinksw.com>
On 7/9/12 4:56 PM, Erik.Wilde@emc.com wrote: > possible adversarial scenarios that come to mind are triple injection > where clients submit data that will be good for them in some context, such > as ratings or quality metrics or prices or whatever else are QoS-related > parameters in a given setting. possible badly implemented clients include > scenarios where clients submit inconsistent data that will at least make > the data they submit worthless, and in bad cases will conflict with other > data in the platform and then renders other data worthless as well. > possible DOS scenarios are where clients intentionally submit data that is > know or they hope will make reasoning very slow, without any justification > as to why this data should be submitted in the first place. does this > illustrate things sufficiently? i guess i could produce a longer list of > potential problems, if that's required. Valid concerns, but WebID based ACLs bury all of that :-) Note, I comment as a person deeply paranoid about such matters re. deploying Linked Data, ODBC, JDBC, ADO.NET, OLE-DB, and XMLA solutions. Socially enhanced data access policies are the solution to this real challenge. They were even a challenge 20 years ago as client-server access to databases started exploding. A a deliberate or inadvertent Cartesian Product is a sure way afflict an RDBMS with DOS. Related: 1. http://bit.ly/MVc15h -- a simple post about some simple scenarios, Linked Data enables these policies to be much more sophisticated. -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Monday, 9 July 2012 21:11:52 UTC