Re: Question: User Story -- Bootstrapping Facebook

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?

Steph.


>
> 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 14:24:20 UTC