Data Sharing Summit unpanel- This Thursday please provide suggestions/feedback and further topics
danielabarbosa
I have been asked to participate on a 'unpanel' this Thursday at the
Data Sharing Summit http://datasharingsummit.com/dsswiki/index.php?title=Main_Page
I just saw the panel topic today- so i am sharing it with you all
because i would love to have some feedback, additional questions,
issues that we should raise to others on the panel and in
audience.etc. from the DataPortability Project. This is a great
opportunity in the context of this panel topic to outline some of the
objectives the project group has, the feedback we received from the
community,vendors and users and what our own personal goals as members
of the DataPortability project.
Data Sharing: What Could Go Wrong?
Bob Blakely from the Burton Group will open the conversation
What data is shared?
Who’s data is it?
Who should be able to move it? and under what conditions should
they be able to do so?
Other Conversant are:
* Daniela Barbosa, DataPortability.org (day job at Dow Jones)
* Marc Canter, Broadband Mechanics
* Jospeh Smarr, Plaxo
* Ken Kovash, Mozilla
feel free to post here or email me directly danielavbarbosa @gmail.com
Many thanks!
marc canter
I'm amazed at the similarity between Google Connect, Facebook Connect and
Data Availability.
I wrote about this today - "The Religion of Bringing Social to Software":
http://blog.broadbandmechanics.com/2008/05/the-religion-of-bringing-social-t
o-software
Also is you haven't already - please take a look at my blog series on "How
to build the Open Mesh":
http://blog.broadbandmechanics.com/2008/05/how-to-build-the-open-mesh
:-)
See you on Thursday.
Jonathan Vanasco
OpenID is a really amazing protocol and 'tool' in the general arsenal
of portability. But its a tool/protocol - not a solution -- and
treating it as a solution is grossly irresponsible.
Unfortunately, many advocates over the past year have been pushing for
OpenID to be the 'be-all end-all' solution to online identity.
Usually this comes from overzealous developers and online advocates
who are so stuck in the mire of the dotcom world and living their
lives online, that they don't realize the common person does not want
their LinkedIn, Facebook, MySpace and Flickr accounts fully connected.
So while DataPortability is great and necessary - Identity Conflation
is something that must be avoided at all costs.
For a while we started tracking some horror stories on our corporate
blog, but then just gave up -- it became to horrific and commonplace
( http://blog.findmeon.com/category/be-careful-what-you-post-online/
).
But if you want to know what can happen when DataPortability goes
wrong, how about this:
You lose your job
You lose your family
You lose your friends
You don't necessarily lose your dog, but you kind-of-feel like you're
trapped in an old country song, and might as well anyways.
I wish I were joking, but this is what happens. Too many employees
have been fired because DataPortability has conflated their work and
personal lives. Too many gay/lesbian youth have been outed to their
families before they were ready.
Call me crazy -- but unless data can be linked with assured levels of
privacy and user control, it should not be linked at all.
I'm absolutely amazed at how completely irresponsible some projects
have been in this regard. I seriously wonder if some developers are
really so shortsighted, or if they know what they're doing is wrong
and are just trying to grab users faster.
At FindMeOn, we opted for a user-unfriendly UI/UX back in 2006 when we
were one of the few players in this space -- because we wanted to
safeguard privacy and avoid the likely scenarios of "What could go
wrong?". We've been bitching about the dangers of portability without
privacy controls back when these dangers were only potentials. Now
that they have been realized, and real human lives have been
compromised, it's just sad to see these irresponsible practices pushed
forward.
Julian Bond
>
>I think the biggest thing that can go wrong is identity conflation.
>
>OpenID is a really amazing protocol and 'tool' in the general arsenal
>of portability. But its a tool/protocol - not a solution -- and
>treating it as a solution is grossly irresponsible.
I have a really hard time seeing the linkage here. But hey, I'm a geek.
But do please tell me how OpenID leads to identity conflation.
On the privacy issue, I seem to have this debate over and over again. On
one side we have people who use the net (and especially all those web2
sites) for personal branding. They revel in the ability to do everything
in public to build their reputation. On the other we have the
justifiably paranoid who either deliberately abstain or take great pains
to participate anonymously. Neither of those are the problem. The
problem is the great mass in the middle who haven't understood yet that
very little on the web is truly private. If you post on a public website
it will eventually become public even if the site claims to restrict
access.
If you want a windmill to tilt at, then it's Facebook for trying to
maintain the illusion of privacy. Not OpenID for providing an open
technology for single signon.
--
Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173
Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433
Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat
Contains Flammable Gas Under Pressure
Ben Werdmuller
I've got to take issue with the general tone of your message,
Jonathan. Data portability on its own is not going to lose anyone
their jobs, families, dogs, or darling Clementines. What you say here
is important:
> Call me crazy -- but unless data can be linked with assured levels of
> privacy and user control, it should not be linked at all.
It's about choice.
Right now, some of the biggest names in social networking are
providing an illustion of privacy, as Julian said, while selling your
data to the highest bidder. I've been offered prices per email
address, mobile number, name, or complete profile (although it was
brought to me cold, and we obviously decided not to touch it with a
bargepole).
Given that this is happening, and is one of the most efficient ways to
get money from a free service, it makes sense to give users control
over their data. Ultimately, I think it makes sense for users to be
able to take their data and walk away to a completely different
service, in much the same way as you can change wordprocessors or
operating systems. It's the same kind of insurance customers have
enjoyed in other industries for years: if you treat me badly, or drop
the ball regarding features or service, I'll leave you. Hence
"portability".
But because it's about choice, the user needs to have the final say
over what data is shared and when. We've had that in Elgg for four
years, and I know other systems have now opted to include it: you get
to say exactly which items of data (profile fields, blog posts, etc)
can be seen by whom. That way you can be assured that nobody will see,
eg, your phone number without your permission, let alone have it
exposed via hCard and crawled by some bot somewhere for inclusion in a
marketing directory.
Identity conflation is fantastic - if the user wants it. ("Personas"
are an important concept, and remember, many peoples' online
identities are already conflated at the email address or username
level.) Data portability is brilliant - if the user wants their data
to be portable. The point is, right now, users don't have the option.
--
Ben Werdmuller
Elgg, the social application engine | http://elgg.com/
Tel: +44 (0) 774 863 4754
Skype: benjaminmorayhouse1
Blog: http://ben.elgg.com/
Jonathan Vanasco
When everyone starts centralizing their online identities into a
single url based resource like OpenID, that 'endpoint' that everything
resolves to becomes a two way hub -- I can quickly jump to your
LinkedIn and Facebook accounts from your MySpace , Bebo and Flickr.
At first it sounds like a great idea -- sharing your information like
that is something that a lot of people want to do, especially if
you're in the .com scene or the web-2.0 world. But many people aren't
-- and many people don't want to be.
Most people like to keep their information isolated - they act
differently and share different information across networks , with
multiple digital personas. They're casual on MySpace with friends,
and more professional on Facebook or LinkedIn with colleagues. They
talk differently based on the context and membership of these
communities , and share different qualities of photos and videos and
personal information.
Far too many technologists who embrace the Web2.0 world have been
rushing to integrate services together with OpenID as a 'solution',
not as a protocol. A single digital endpoint is great from a
management perspective, but its absolutely abhorrent from a privacy
and risk management standpoint. Many people don't want all their
information so easily accessible - and aren't prepared or educated
enough for the ramifications of what can happen. We live in a day and
age where a coworker might see a Facebook/LinkedIn page, and it
becomes associated with an offsite blog entry that jeopardizes a
career; or a Facebook page that links to MySpace content that shows
sexual orientation.
Posting content on a website is indeed saying "this is out there, and
this is not private" -- but in the rush to embrace new technologies
and the novelty of integration, technologists have completely ignored
the responsibilities that come along with these innovations, chiefly
the ramifications of aggregated identity content.
As more companies start to embrace portability and openness , privacy
becomes more and more important -- yet few talk about it.
Julian, OpenID and 'single signon' and a single point for management
is a great concept and I have no problem with that, in fact I love
it. My issue is with OpenID as a single Identifier. I'm not an uber-
paranoid nutjob, but I want my business and personal personas kept
separate. I've focus-grouped that 'middle america' demographic for
two years -- amazingly they're not so dumb and clueless about the
net , and have been consciously and unconsciously monitoring how they
share info. They only share family photos/info publicly on one
network; they talk about work and personal lives separate. They make
a ton of privacy missteps, but generally have good bearings.
That said, conflation does happen a bit at the username and email
address level - but not quite as much as you may think , and that on
its own is not a reason to automatically say "well then, privacy
doesn't matter". When you look at what can be conflated, it's even
scarier. People are sharing family histories on a geneology site,
their pets on a doglover site, kids photos on others, and their
employment/education publicly on yet more. On their own this info is
inocuous -- but pieced together through a mashup due to poor OpenID
implementation/advocacy, it's not hard to find out 'mothers maiden
name', 'first pets name', 'childs name', 'street address' or 'first
highschool' -- the standard verifications used for identity checks in
banking transactions.
To quote Ben
over what data is shared and when. We've had that in Elgg for four
years, and I know other systems have now opted to include it: you get
to say exactly which items of data (profile fields, blog posts, etc)
can be seen by whom. "
genuinely glad you and others are offering it. But as you say "other
systems have NOW opted to include it" - it's a new 'opt in' and
concept for the Technologists , and not the de-facto standard.
I'm not seeing any user warnings from startups and projects when they
embrace portablity saying "We offer these great new features... but
its at a tradeoff; you may want to switch features off". Instead I'm
seeing a brand new system that my profile data and contact lists are
being opted into for external views.
It's great that some people are doing things 'right' -- but many are
doing it wrong... dead wrong.
I'm sorry if you don't like my tone - but I'm angered by this
discussion. Not by either of your comments -- which are great -- but
that the industry as a whole has really just sidestepped user privacy
concerns in favor of 'shiny new toys'. I don't know what could be a
better illustration of this, other than a Data Sharing summit that has
several bulletpoints on a "What could go wrong" panel , NONE of which
seem set to discuss or even touch privacy issues. That is beyond
disconcerting or troubling -- it genuinely angers me.
So you might think that I'm tilting at windmills -- but honestly I
think that view is sad and pandemic of this movement. We're at a
point in technology and portability where we should be making
deliberate steps and continually asking each other "What really could
go wrong?", mandating safeguards and privacy controls/standards
before we move forward. Instead, discussions on "What could go
wrong?" seem more focused on technology constraints and corporate/
personal ownership, while privacy issues are left to be essentially
optional.
I'm with you all on user's owning their data, and choice, and
portability, but this needs to be done right and responsibly -- and
right now, this movement (in general) is acting far from responsibly.
Christian Scholz / Tao Takashi (SL)
On Wed, May 14, 2008 at 10:12 PM, Jonathan Vanasco
<jona...@findmeon.com> wrote:
>
> Julian / Ben
>
> When everyone starts centralizing their online identities into a
> single url based resource like OpenID, that 'endpoint' that everything
> resolves to becomes a two way hub -- I can quickly jump to your
> LinkedIn and Facebook accounts from your MySpace , Bebo and Flickr.
As I am a Second Life resident I am very aware of the issues as most
people in SL try very hard
to keep the SL and RL identity separate. That's why I also was against
a solution where all your service
endpoints are already in the first XRDS file discovered (the openid one).
Using one OpenID for everything is hence not going to work here
anyway. Taking the SL example again
I'd think that people have separate OpenIDs (should SL support it
someday) for these. Maybe even more
for various other services.
> At first it sounds like a great idea -- sharing your information like
> that is something that a lot of people want to do, especially if
> you're in the .com scene or the web-2.0 world. But many people aren't
> -- and many people don't want to be.
Right.
So the idea was that the YADIS XRDS file will eventually point to
another (or even more)
XRDS files which are protected by e.g. OAuth. Those can be hosted
whereever you want.
These XRDS files are then not publically accessible and thus can
contain those profiles etc.
which you don't want to have exposed to everybody.
The issue might be though that you can interpolate which 2 openids
belong together when they
both point to the same protected location (or this needs to be a
generic one with no identifier in it). So
maybe we need to think about this a little more (maybe yet another
redirection so that the second one
can be in the protected file).
Additionally the services listed in those XRDS files can be OAuth
protected as well.
With this setup you should be able to link all your locations privatly
together and choose
which services to expose to which social network.
So to summarize it would be
OpenID URL -> YADIS/XRDS -> OAUTH(XRDS) -> OAUTH(Service)
the OAUTHs are of course optional for the user but we should demand
that those services are protected. Maybe something the policy group should
think about how to frame it into some guidelines.
-- Christian
--
Christian Scholz
Tao Takashi (Second Life name)
taota...@gmail.com
Blog/Podcast: http://mrtopf.de/blog
Planet: http://worldofsl.com
Company: http://comlounge.net
Tech Video Blog: http://comlounge.tv
IRC: MrTopf/Tao_T
wavetheory
The url "endpoint" does not provide links to every resource you use
your openID for. It is simply an authentication page which passes a
token to a requesting site that your login is valid. I suppose there
is nothing to stop an openID provider from doing things like this but
there are plenty of openID providers to choose from. Even if this were
the default behaviour it would just be a matter of setting up two
openID logins-- one for personal sites and another for your
professional persona.
It's good that you have concerns about privacy as it relates to
openID, but I think your post is a bit hyperbolic. The general
sentiment I get from reading this group and other posts in the
dataportability community is a strong concern for privacy and control
of one's data. I think ultimately control, rather than ownership, is
what dataportability boils down to. The folks who came up with the XDI
spec had the foresight to implement granular access. I believe openID
2.0's attributes are also able to be shared on a per-site/user basis.
From what I've read of dataportability's technical documents, it is up
to the user whether the services they use are discoverable. Indeed
there are guidelines in place that limit who can see what from your
service catalogue.
In short, relax. Don't get angry. Focus your privacy concerns into
constructive criticism in the appropriate forums. Above all, don't
assume that the dataportability movement is an unplanned rush to bring
2.0 goodness to the masses. Many of us share your concerns and
building the interconnects to anticipate privacy issues.
-wavetheory
danielabarbosa
I am not a technologist like some of the other panel members- and
since this is an un-panel i suspect we will also get a lot of
participation from the attendees.
Usability, User Rights, User Privacy, User education, Attention,
policy and legal issues, Multiple 'personas' (corp vs consumer),
enterprise issues, executive education and involvement (from
traditional companies as well as online vendors), supportable business
models and unified advocacy for these issues and opportunities we have
around DataPortability is my focus- and what i plan to bring to the
panel- i hope i am successful.
will report back.
Christian Scholz (mrtopf.de)
On May 15, 2:36 am, wavetheory <lavaf...@gmail.com> wrote:
> Perhaps I'm wrong, but I don't think openID works the way you think.
> The url "endpoint" does not provide links to every resource you use
> your openID for. It is simply an authentication page which passes a
> token to a requesting site that your login is valid. I suppose there
> is nothing to stop an openID provider from doing things like this but
> there are plenty of openID providers to choose from. Even if this were
> the default behaviour it would just be a matter of setting up two
> openID logins-- one for personal sites and another for your
> professional persona.
would be to put them in there.
We came to that solution as there was the proposal to use XRDS for all
the services you have.
These might also be services which do not support OpenID (yet) like
your twitter profile etc.
(which can be read as it's hCard formatted and hence useful). The
initial idea was to use
OpenID AX with a new attribute which points to this (optionally OAuth
protected) XRDS file
(which we call the service catalogue although I would now rather call
all the services you
found which whatever means a "service catalogue".)
OpenID AX is still in the play btw. but as we already have an XRDS
file in the authentication
process involved (the YADIS one) there was the idea that public
visible services can already
be put in that one. The problem with AX is actually that you cannot
start to use all this if you
don't have an OpenID provider supporting it. An XRDS file OTOH can
even be created outside
your provider (like I can create one myself and point to my openid
provider but also put other
services inside).
So the dicussion happening right now is about:
- what's the role of AX (it might be useful in some cases e.g. if you
use directed identity like
yahoo.com does)
- what's the best sequence of steps for doing discovery, what to try
first, second and so on and
esp. when to stop (you might follow 100s of links to XRDS files
theoretically so we should at least
recommend how many redirections you should follow (as it all takes
time). Esp. with Jonathan's
points about privacy maybe this should be 3 steps then.
Then of course we need services which store or create this XRDS file
for you and there is also
some discussion on how it's updated. There are some ideas and
proposals around for this (like
HTTP PATCH) but I think we should first write down some use cases/
scenarios on how it could
look for the user.
Jonathan, I am not sure if this helps you with your concerns. Of
course we are open to discuss this
further and open to proposals on how we can make this better. I hope I
made clear that privacy and esp.
the choice for people to decide themselves what they want to publish
in which context is important
to me.
> It's good that you have concerns about privacy as it relates to
> openID, but I think your post is a bit hyperbolic. The general
> sentiment I get from reading this group and other posts in the
> dataportability community is a strong concern for privacy and control
> of one's data. I think ultimately control, rather than ownership, is
> what dataportability boils down to. The folks who came up with the XDI
> spec had the foresight to implement granular access. I believe openID
> 2.0's attributes are also able to be shared on a per-site/user basis.
> From what I've read of dataportability's technical documents, it is up
> to the user whether the services they use are discoverable. Indeed
> there are guidelines in place that limit who can see what from your
> service catalogue.
that easy to solve. For now what is proposed to match contacts this is
probably more a service level control. What we might need in the end
is
a user level control but I ended up with knots in my head when
thinking
about this ;-)
I might post something more in detail about this later to my blog (a
bit
drowned in work at the moment).
If there are any people on here who have thought more about this in
terms
of how to implement it etc. please feel free to chime in in the
Technical Action
Group (http://groups.google.com/group/dataportabilityactiontechnical)
> In short, relax. Don't get angry. Focus your privacy concerns into
> constructive criticism in the appropriate forums. Above all, don't
> assume that the dataportability movement is an unplanned rush to bring
> 2.0 goodness to the masses. Many of us share your concerns and
> building the interconnects to anticipate privacy issues.
have
today on the web. It also might be a chance to get less spam ;-)
(because those social networks all have their own messaging system
it's
on the one hand harder to track all those communications but on the
other
hand they have better controls in place of how can send you a
message.
Also look at twitter. You first need to give permission to get
spammed.
If we can carry that over to some general messaging infrastructure
this
might be a huge win).
cheers,
Christian