Question re Facebook Connect policies

[GlamGirlGeek]

I have been eagerly keeping abreast of all the posts re data
portability and who ownss the user data. I appreciate how complex it
is. This question is related and is imbedded in those discussions,
but I want to tease it out.

Does anyone have a sense as to whether there are any circumstances
under which a site can keep user data for more than the 24 hour
holding period. For example, could the site set up a separate profile
for the user that they edit and augment, and then can opt-in to
allowing the site (ie. "give permission") to keep that data on their
site without calling it every time? I have read all of the Facebook
terms of service and guidelines etc. for applications and Connect,
etc. but of course they don't speak to this. If indeed the user
should be able to determine where, when and how their data is used,
can't they give a website permission to essential "copy and save" data
that she/he has ported over from Website.

This probably sounds naive but it is so inconceivable to me that there
is virtually no way for this to be done.

Will really appreciate your insights.

Stephanie

[Omer Gulzar]

this is war u wrote on my blog , please subscribe if you like it

http://www.socialnetlog.com/2009/02/16/facebook-tos/
http://www.socialnetlog.com/2009/02/17/on-facebook-people-own-and-control-their-information-2/
http://www.socialnetlog.com/2009/02/18/facebook-reverts-back-to-old-tos/

Regards
Omer

[Jonathan Vanasco]

Its my *PERSONAL* opinion that a workaround to Facebook TOS is this:

1- Your app requests data from Facebook , and puts that into an HTML
formfield for the user to verify submit. This could either happen
with the application server requesting it, or some sort of JavaScript
function/bookmarklet that fetches data from their system through the
web browser and then populates a formfield -- so that your server
never actually requests the data.
2- The user then audit & edit data, then press submit

Under this flow of data, your app never caches Facebook data. It just
presents the user with their own data, and the user submits data.

I'm sure Facebook would disagree, and find some various means of
disabling your API access. However I'm fairly sure that the law would
side against Facebook as the data that is stored is coming from the
user -- especially in the javascript example.

[GlamGirlGeek]

thank you but i think i am asking a different question. i am not
asking about if or when facebook will ever let go of their ownership
of a user's data, but whether a user can give another site permission
to use their user data (ported through FB Connect) beyond the 24 hour
hold time.

On Feb 19, 5:21 pm, Omer Gulzar <omer.gul...@gmail.com> wrote:
> this is war u wrote on my blog , please subscribe if you like it
>

> http://www.socialnetlog.com/2009/02/16/facebook-tos/http://www.socialnetlog.com/2009/02/17/on-facebook-people-own-and-con...http://www.socialnetlog.com/2009/02/18/facebook-reverts-back-to-old-tos/
>
> Regards
> Omer

[Christian Scholz / Tao Takashi (SL)]

Well, I always found it somewhat ridiculous that Facebook (or MySpace or ...) owns my name and email address and I can only tell another site to store it for 24 hours.

I personally know maybe better how often that changes and I could then simply ask the site to sync up my profile from source X whenever I think it's necessary.

But so much for the Zuckerberg quote "Our philosophy is that people own their information and control who they share it with" (http://blog.facebook.com/blog.php?post=54434097130).

That might be true inside the platform but not outside. 

-- Christian

--
Christian Scholz
http://mrtopf.de/blog

New Podcast: http://datawithoutborders.net

[GlamGirlGeek]

Interesting, thanks Jonathan - i'm curious what others think about
this approach?

[Elias Bizannes]

Jonathan's proposal is very interesting. It's in line with my view
about the value of personally identifiable information: that for it to
be valuable, it needs validation from the user on the most recent
date. The fact you get the user to resubmit it, means you've just
added a new attribute to the data (that being recently confirmed).

Here is something I posted on the VRM Project's mailing list recently,
on a thread about this same topic.

----
Bah! So what if a corporation 'owns' your data.

A company monetises data if
1) they can sell copies of the data (customer lists)
2) they can sell access to the data (advertising)
3) they can sell perception of perceived value (venture capitalists
thinking data = monetisation)

But the thing about data, is that for it to be useful (and truly
valuable), it needs to be recent. No one wants a customer list that's
got the wrong address.

Try this excercise: Imagine it's the year 1995 (those long gone
chasin' waterfalls years). Reflect privately to the following on your:
- Age
- Employer
- Income
- Education level
- relationship status
- address
- city of abode
- primary e-mail account

Now re-answer those questions in the context of that J-lo 2000 period.
Now try 2005 when Shakira was shaking it.
And now compare it to today.

Are they different? For most, they should be.

A company can pretend they own you, but they literally can't. Their
entire monetisation is based on the fact they have the most up to data
about you: all we need to do is educate acquirers, advertisers, VC's
that the data isn't recent and you've just put a fire in a company's
house. Access to the most up to date data is what companies really
want; snapshots are useful only to historians. Even if people guess
the future state of someone based on past data, verified data
recognised by the person in question will always be more valuable.

[Christian Scholz / Tao Takashi (SL)]

On Sat, Feb 21, 2009 at 7:13 AM, Elias Bizannes <elias.b...@gmail.com> wrote:

Jonathan's proposal is very interesting. It's in line with my view
about the value of personally identifiable information: that for it to
be valuable, it needs validation from the user on the most recent
date. The fact you get the user to resubmit it, means you've just
added a new attribute to the data (that being recently confirmed).

I agree that the more recent the data is the better. And so the limitation of 24h of storing it might actually make sense ;-)
The problem is of course that not you decide that but the service provider does. So you cannot simply automatically move your data elsewhere except maybe to confirm every part of it (if that's legally ok).
And this might not be a problem for profile data but imagine you want to do the same with images and a similar restriction would be imposed on that data. It might not even make sense in this context to confirm that data because you'd probably need to upload it again.

Another question is of course what happens if you change your profile data on service B (which is synced from service A). IMHO in an idea world you should only have one "identity provider" for each of your identities which stores your data and where you can decide where to sync it to (and in which intervals). Every other service then should write changes back to this provider.
And even better of course would be a solution where you don't have to poll every 24 hours but where the "master service" pushes that data to it's subscribers.

-- Christian

[Elias Bizannes]

Good points Christian.

I suppose there are two classes of data here: identity (personally
identifiable information) and media (content). This solution works for
text-based identity stuff only, so let's narrow it in that sense.

Thinking this through a bit more, a company like Facebook should be
incentivised to do something like this.

The reason being they need a way of ensuring their users regularly
validate and update their information (per my argument about only
fresh data having the value). By having various applications do it
with user consent, means Facebook can have that free validation
occurring daily or weekly. Facebook can use their ecosystem to add
more value, as these apps provide a valuble service.

Of course, the challenge for every business is going to always be how
to get the most up to date data about a user. Which is why this
approach isn't a risk but an advantage for Facebook. By encourging
constant data validation, they use their economies of scale to always
stay ahead of the game.

Sent from my iPhone

[Gordon Rae]

Here is another Use Case to add to the list. Consumerist reports the
difficulties Stephanie Bernister encountered when she asked Facebook to
remove the page of her brother, after he died.

Facebook Won't Let You Remove Dead Relative's Page, Per "Policy"
http://consumerist.com/5157481/facebook-wont-let-you-remove-dead-relatives-p
age-per-policy

Update: Facebook Agrees To Take Down Dead Relative's Page
http://consumerist.com/5157835/update-facebook-agrees-to-take-down-dead-rela
tives-page