- From: Peter Williams <home_pw@msn.com>
- Date: Wed, 23 Jul 2014 16:34:00 +0000
- To: Kingsley Idehen <kidehen@openlinksw.com>, "public-rww@w3.org" <public-rww@w3.org>
- CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <SNT407-EAS1623CE5F6C469B90C5F8E4392FE0@phx.gbl>
I like that this group, despite being highly idealistic, is not too religious, and very engineering centric. Here, REST is not as stateless as one might teach, in a class. With https URIs, its about as unstateless as it gets - by default. First, we should all know that “for efficiencies” “crypto” state persists between http transactions. Secondly, folks ought to have figure by now that since 2001 all major hosters have sent their ssl logs to NSA or equivalent. These tie the ssl sessionid to the ip address (to help sort packets and crypto sessions - to help prioritize cryptanalysis efforts). No they do NOT send their SSL session MIBS (but they might as well, since inference puts the pieces back together); sending only “critical infrastructure protection” logs. So I dont want us to set out on the wrong foot (with a continuation or acceptance of the grand deception that was set in motion or accepted in the TBL era of W3C). We have to think 15 years ahead, and imagine the crypto compromise that will be found THEN (given all the issues). we should only use ciphersuites that offer integrity and authentication. We remove the encryption features that is. This is easy enough to do on the ssl server pools. What did we lose? nothing (except the belief in encryption - that doesnt really work as we were trained to expect, aged 12). What did we gain? a new start, looking for a non-deception based crypto compromise - at the social level lack of connivance, when pretending that tracking tracing and surveillance is other than “built in” distinguishing the mission from e-commerce- when society had to be worried about 16 years see a credit-card number in a packet trace. being logically clear that the “only” thing we have done is deliver the kind of logical framework - at massive scale - that was contemplated by lampson et al We stay away from the web supporting Arab springs, PGP sorting out Russian dourness, and getting mired in the pretence of anonymity via trust modelling built from metadata. Sent from Surface Pro From: Kingsley Idehen Sent: Tuesday, July 22, 2014 6:41 PM To: peter Msn, public-rww@w3.org Cc: public-ldp-wg@w3.org On 7/22/14 8:37 PM, Peter Williams wrote: anytime an SSL session is created (based on a webid authentication event), dont suppose a “private” resource could be created - bearing the sessionid number? Only if some implementation decides to act that way. Likewise, an ACL can be derived from an combination of relations in an identity card (be it the x.509 cert used during the handshake and/or public profile document at some later stage). The point is to showcase, widely, how easy it is to track ssl sessions (as a generalized privacy buster) and identity inferences from them. Since this shouldn't happen by default, I don't think we have the generalized privacy buster. In fact, we have the opposite since actual ACLs don't need to be shared with a human driving a Web browser, as part of the protected resource access workflow. Example: Let's say I have a picture that I only want to share with you. My ACL doesn't have to be based solely on the fact that you present an X.509 cert bearing a WebID that triangulates back to a profile document that mirrors the relations in the x.509 cert. etc.. You (the browser user) has little knowledge over the actual ACLs applied to a protected resource, let alone the sniffers out there, assuming my actual ACLs aren't revealed in a compromising way. SPARQL ASK queries over Linked Data will drive the more sophisticated ACLs, declaratively. with that set of reference points, its also a means, on a massive scale, to let ssl session management - now represented as just another referencible resource - protect metadata-based infrastructure - from systemic metadata-trawling vulnerabilities. Yes, ultimately, but (modulo typos) your suggestion would get the opposite of what you state above, if I am understanding you correctly :-) Cannot say how, in short missive, but assume that layers of security leverage the fixed point of sessions to create complex worlds through which other channels of metadata can be passed. I assume the worst, there's a little more to showcase re. ACLs + Encryption at Rest (EAR) once we get some basic interop going. Ultimately, you will need to not only navigate the ACLs that protect a document, you will also have to be able to decrypt the document's content :-) Kingsley Sent from Surface Pro From: peter Msn Sent: Tuesday, July 22, 2014 11:01 AM To: Kingsley Idehen, public-rww@w3.org Cc: public-ldp-wg@w3.org https://homepw.rww.io/storage/mb/ch1/post1 I think this is your breakthrough moment (though Ive said that BEFORE…) For the first time, that https scheme is more than just a way of making an tls transport happen. Now its a real URI, with true https “semantics” around identity and referencing. Well done. Took 5+ years for webbt processes to do their thing, but then you were collectively undoing 20 years of wrong thinking - probably due to the web being overly controlled by IETF at the protocol level (and its “strange crypto” setup, to cite Vint Cert). Somebody pat Henry on the back to, for teaching even the likes of me the pure logic approach of this stuff. I was taught it all, at school, but never “really got stuff like ‘denotational semantics’”. This makes it obvious - and easy. Sent from Surface Pro From: Kingsley Idehen Sent: Tuesday, July 22, 2014 10:40 AM To: peter Msn, public-rww@w3.org Cc: public-ldp-wg@w3.org On 7/22/14 1:16 PM, Peter Williams wrote: http://yorkporc.wordpress.com/2014/07/22/cimba-co/ worked fine, baring some 25 year old issues that noone wants solved (since it puts W3C in the hot seat on crypto complicity). Easy to work around. Windows 8.1 phone trial not a success (being a communications device, more regulated that an PC for crypto). Windows 8.1 PC did fine. Peter, Please share the URI of your sample post since I see you successfully reached that point. Once you share the URI that denotes your sample post we can simply lookup up the rest, pun intended too :-) Kingsley Sent from Surface Pro From: Kingsley Idehen Sent: Tuesday, July 22, 2014 8:53 AM To: public-rww@w3.org Cc: public-ldp-wg@w3.org, peter Msn On 7/22/14 11:23 AM, Melvin Carvalho wrote: You're almost there! Now you just need to create a channel for your posts. Did you attempt to create a new channel? One other thing Logging in to http://cimba.co I am not on there in an obvious way i.e., not via the WebIDs you know (see comments below). I'll connect back there one this side of interop is done, by that I mean: 1. Support for any WebID re. CIMBA -- as opposed to WebIDs where rww.io as the Idp 2. Loosely coupling the CIMBA app, deployment platform Virtuoso, and actual data storage -- e.g., Dropbox, Google Drive, OneDrive etc.. 3. Having Public mean "Public" as opposed to "Public with a WebID that's verifiable using WebID-TLS" -- by not being really Public the user has to manually make each blog post "Really Public" etc.. I can find 3 profiles for you ( 1 normal, 2 QA) in webizen, but I cannot find any channels in them. When I click your name, I get the spinner which never completes. Yes, because that WebID resolves to document hosted by an instance that didn't initially work with CIMBA. Note the comments in our pull request [1] [1] https://github.com/linkeddata/cimba/pull/19 -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
Received on Wednesday, 23 July 2014 16:50:02 UTC