- From: Nathan <nathan@webr3.org>
- Date: Thu, 10 Feb 2011 13:51:59 +0000
- To: Stéphane Corlosquet <scorlosquet@gmail.com>
- CC: Melvin Carvalho <melvincarvalho@gmail.com>, Henry Story <henry.story@bblfish.net>, WebID XG <public-xg-webid@w3.org>
Stéphane Corlosquet wrote: > On Thu, Feb 10, 2011 at 4:58 AM, Nathan <nathan@webr3.org> wrote: > >> Melvin Carvalho wrote: >> >>> This is my question. Is it a problem that they dont currently use >>> fragments. And can we easily can get around that? >>> >> It's probably the least significant of all the problems tbh, strictly for >> webid all we need to do is prove that somebody had/has write access to the >> "resource", so regardless of whether somebody uses /profile or /profile#me, >> in both cases you'll be looking to see if the persons public key is in >> /profile. >> > > You're making the assumption that each profile document only contains data > about one person, which might be the case for FB, but you can't generalize > this, and the spec cannot contain special casing for FB (how about some URL > regex?). What about pages which contain identity about several people? frags > are there for a reason, I don't think we can just ignore them. If I manage > to leave my public key as a comment on your FB profile page, I can now steal > your identity, right? I agree of course, but it may (or may not) need to be a design trade off that's needed to make WebID usable by the web masses, that's even with the requirement of RDF (or embedded RDF /RDFa). > Profile pages are not necessarily static HTML document > which only the user has access too. In systems like FB, Twitter, or CMS in > general, data is pulled from different places and you have to make sure you > know who authored each snippet of it. That was one of the main concerns > David Recordon and his team raised when I visited them in Palo Alto last > year. The use case we were discussing was about the Web in general wrt > harvesting data for OGP, and the reason why OGP/FB will only consider the > RDFa located in the <head> tag is that it's the only data they can trust to > be authored by the author of the page (or the app), anything else on the > page cannot be trusted and could be a comment left by some random person who > would change the title of the page for example with some well crafted RDFa. > It was not about WebID or how they put their pages together, but I bet they > would raise the same points re. their profile pages. I'm to what you're referring when you say "one of the main concerns of David Recordon and his team" - can you confirm? As for the rest, fully agree, noting that it's common practice not to explicitly set a subject when using meta/link elements in HTML >> Another potential issue, is that sites like facebook don't have "one uri" >> for each person, each person can have several different ones, basically >> whatever is in the address bar when that person is looking at their own >> profile. > > Who cares as long as they advertise a unique profile URI in all these pages, > and as long the canonical profile URI dereferences to the right WebID > information? if the required info is there when you deref, then I certainly don't care (other than caching considerations and having a well defined single URI for ACL uses). >> It could be worse though, look at twitters URIs for users.. >> http://twitter.com/#!/webr3 that would lead to a GET on >> http://twitter.com/ for every user on twitter. >> > > again, no problem, as long as the advertised URI for user profile is > http://twitter.com/webr3. The /#!/ is just some javascript sugar, if you > access http://twitter.com/webr3 as anonymous with js off you will see that > you remain on http://twitter.com/webr3 (which is the behavior that a WebID > Verification agent would experience). I was referring more to people using the wrong URI, saying "my name is x" when they should be saying "y", after looking at what's in the address bar. may or may not be a problem, something I'd be interested in thinking about more though (personally). Best, Nathan
Received on Thursday, 10 February 2011 13:53:08 UTC