Dec. 31st, 2008

jducoeur: (Default)
In a discussion on the Portable Contacts mailing list today, one of the more knowledgeable members pointed out (essentially) this url, which feeds a Twitter entry into Google and asks for other identities of that person.

It's pretty clear from the result that Google is trawling the social graph world, and pulling in all the links. There's no rocket science here, but it was a bit startling to see that it went from my Twitter account to my personal homepage (which isn't linked from Twitter). It clearly went from my Twitter profile to LiveJournal, and then from my LiveJournal profile to the web page. Which isn't much in and of itself, but the example he actually gave shows how many different profiles can be sucked in this way.

This is mostly a good and useful thing, but needs to be treated with care, because none of this stuff is validated. That is, almost all of these data sources allow identity A to claim to be the same person as identity B, without B agreeing to it, so you can't actually trust this data too far. It looks like Google is managing this correctly, as a directed graph of claims (that is, it can implicitly be read as "A claims to be B which claims to be C which claims to be D"), but it *looks* like a simple bundle of identities for the same person.

So I'm waiting for someone to misread this stuff and write an app that simply assumes that A, B, C and D *are* the same person. Which will be subject to some really interesting identity-fraud hacks, because it's quite easy for, say, me to *claim* to be Bill Gates in this mechanism. (Or, more sinisterly, for someone to set up an account that links a target to some anonymous Flickr account that is posting child pornography.)

Pay close attention as this stuff evolves, because online identity is a really tricky problem. And while I believe Google understands what it is doing here, I don't necessarily have as much faith in everyone who will be using these APIs...
jducoeur: (Default)
In a discussion on the Portable Contacts mailing list today, one of the more knowledgeable members pointed out (essentially) this url, which feeds a Twitter entry into Google and asks for other identities of that person.

It's pretty clear from the result that Google is trawling the social graph world, and pulling in all the links. There's no rocket science here, but it was a bit startling to see that it went from my Twitter account to my personal homepage (which isn't linked from Twitter). It clearly went from my Twitter profile to LiveJournal, and then from my LiveJournal profile to the web page. Which isn't much in and of itself, but the example he actually gave shows how many different profiles can be sucked in this way.

This is mostly a good and useful thing, but needs to be treated with care, because none of this stuff is validated. That is, almost all of these data sources allow identity A to claim to be the same person as identity B, without B agreeing to it, so you can't actually trust this data too far. It looks like Google is managing this correctly, as a directed graph of claims (that is, it can implicitly be read as "A claims to be B which claims to be C which claims to be D"), but it *looks* like a simple bundle of identities for the same person.

So I'm waiting for someone to misread this stuff and write an app that simply assumes that A, B, C and D *are* the same person. Which will be subject to some really interesting identity-fraud hacks, because it's quite easy for, say, me to *claim* to be Bill Gates in this mechanism. (Or, more sinisterly, for someone to set up an account that links a target to some anonymous Flickr account that is posting child pornography.)

Pay close attention as this stuff evolves, because online identity is a really tricky problem. And while I believe Google understands what it is doing here, I don't necessarily have as much faith in everyone who will be using these APIs...
jducoeur: (Default)
In honor of New Year's Eve, the most important happy thing in my life: having a lady who puts up with my slightly excessive ambition and restless need to have an interesting career; who is willing to work with me to make dreams large and small happen; who is beautiful and sexy and smart and sane. (None of which are to be taken for granted.)

Love you, dear...
jducoeur: (Default)
In honor of New Year's Eve, the most important happy thing in my life: having a lady who puts up with my slightly excessive ambition and restless need to have an interesting career; who is willing to work with me to make dreams large and small happen; who is beautiful and sexy and smart and sane. (None of which are to be taken for granted.)

Love you, dear...
jducoeur: (Default)
Serious Internet geeks may want to take a look at this article in Ars Technica.

Summary: it's been known for a while that the MD5 hash algorithm is a bit weak. Some researchers have used this weakness to create a *really* horrible hack, allowing them to impersonate a major top-level Certificate Authority for cert-signing purposes. They're not saying exactly how the hack works, but the implication is that hackers (using this and other known techniques) could use this to more or less completely impersonate major secure sites, so that users would have no way of knowing that they're talking to a forgery. Very, very, *very* bad.

Moral of the story is that, if you're using MD5 for anything really important, it may be time to move on to better algorithms. With any luck, this will spur all the CAs to do so -- certainly, I would hope that any financial institution would be putting the thumbscrews on its CAs to do so quickly...
jducoeur: (Default)
Serious Internet geeks may want to take a look at this article in Ars Technica.

Summary: it's been known for a while that the MD5 hash algorithm is a bit weak. Some researchers have used this weakness to create a *really* horrible hack, allowing them to impersonate a major top-level Certificate Authority for cert-signing purposes. They're not saying exactly how the hack works, but the implication is that hackers (using this and other known techniques) could use this to more or less completely impersonate major secure sites, so that users would have no way of knowing that they're talking to a forgery. Very, very, *very* bad.

Moral of the story is that, if you're using MD5 for anything really important, it may be time to move on to better algorithms. With any luck, this will spur all the CAs to do so -- certainly, I would hope that any financial institution would be putting the thumbscrews on its CAs to do so quickly...

Profile

jducoeur: (Default)
jducoeur

June 2025

S M T W T F S
12 34567
891011121314
15161718192021
22232425262728
2930     

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags