Re: Question: User Story -- Bootstrapping Facebook

Stéphane Corlosquet wrote:
> On Thu, Feb 10, 2011 at 8:51 AM, Nathan <nathan@webr3.org> wrote:
> 
>> 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?
>>
> 
> The fact that on the Web, you do not know who authored each bit of a page.
> With static pages this used to be very easy since the webmaster is authoring
> the whole page in their text editor, but with rich web apps (typically any
> sites accepting input from other users), you cannot ensure that all the
> information on the page can be trusted as being authored by one single
> person. This is not a WebID specific issue, but one issue that needs to be
> taken into account when talking about dynamic WebID profile document which
> might contain data which has been authored by random users. Is this more
> clear?

Yup, I just read wrong the first time and wasn't sure whether you meant 
the concerns related to "we need multiple webids per profile/doc" or "we 
have these concerns about which bit of a doc you can trust" :)

Cheers for clarifying,

Nathan

Received on Thursday, 10 February 2011 14:26:16 UTC