Recent Updates RSS Hide threads | Keyboard Shortcuts

  • Real-Time State of Mind 

    donpark 6:28 am on July 9, 2009 Permalink | Reply
    Tags: realtime, stream, ui

    I need to get back to blogging more often. Having to type more than 140 characters feels wierd. ;-)

    Given that I’ll be attending TechCrunch’s Real-Time Stream CrunchUp this Friday, I thought a blog post on a key real-time stream problem would help me into a real-time state of mind.

    Real-time streams have many technical problems to overcome many of which are thankfully being resolved by advances in technology and infrastructure but the problem that interests me the most is the user experience problems:

    Information, real-time or otherwise, is meaningless if users are drowned within it.

    Typical Twitter users see only a fraction of tweets from people they follow. The notion of Top Friends (related to my social radar diagram from 8 years ago) will help but at the cost of additional chores users have to do separate the greens from weeds.

    The financial industry has used real-time streams for a long time so there is a lot to learn there technically. But, when it comes to user experience, they haven’t cracked the nut either, forcing traders to use bewildering number of charts and numbers on multiple displays and input devices to trade. So the emerging consumer real-time stream developers will have to break new grounds ourselves.

     

    • Mike Wilson 6:44 am on July 9, 2009 Permalink

      Well, people can absorb both far more and far less information than they think. Following about 350 people is a nice sweet spot for me while I’m online.

      Financial data streaming is an interesting case of “if you dump the data at them, they will figure out what to do with it.” (Ok, it’s not “if you build it, they will come” but close.)

      The data overload can be mitigated pretty well with an effective software layer. TweetDeck’s columns, ThinkOrSwim’s analytics, etc. But “the naked stream” I think needs to be classified as a tool rather than an end product for users.

      Hmm… still a half baked thought on my part.

    • A "Karriem" Khan 4:24 pm on July 10, 2009 Permalink

      Can I buy your Party Ticket to the August Capital Party

    • donpark 4:38 pm on July 10, 2009 Permalink

      It’s not transferable and the ‘ticket’ is a wristband which can’t be taken off w/o cutting. Sorry.

  • donpark 6:04 am on May 14, 2009 Permalink | Reply
    Tags: aptana, gem_lib, radrails, wtf

    Fixed Aptana RadRails GEM_LIB issue on mac by linking ‘/Users/{user}/.gem/ruby/1.8/gems’ to ‘/usr/local/lib/ruby/gems/1.8/gems’. I can’t blame Aptana for this since it was me who chose to use a tool built by a company that spread itself too thin. I doubt they have more than a couple of engineers working on RadRails which is not enough to provide the necessary quality across the range of environments Aptana is unfortuantely being asked to support.

     

  • HTML5 Microdata Fantasy 

    donpark 7:30 pm on May 12, 2009 Permalink | Reply
    Tags: fantasy, html5, microdata

    I haven’t been tracking HTML5 design efforts lately but what’s being proposed for microdata (see posts by Sam Ruby and Shelly Powers) yucked me sufficiently to revisit an old fantasy of mine about HTML (man, what a boring life I have). My fantasy was to add general element/structure definition facility to HTML. It should easily extended to support microdata as well.

    The way I envisioned it being used is like this:

    <address>
<street>123 ABC St.</street>
<city>Foobar</city>
<state>CA</state><zip>94065</zip>
</address>

    which sure is preferable to:

    <div item>
<span itemtype="street">123 ABC St.</span>
<span itemtype="city">Foobar</span>
<span itemtype="state">CA</span>
<span itemtype="zip">94065</span>
</div>

    As to how a semantic structures and syntactic sugars can be defined, one very arbitrary way could be:

    <head>
<def name="address" package="http://test.com/1/mapking"
    params="{{street city state zip}}">
  <div>
    <span>{{street}}</span>
    <span>{{city}}</span>
    <span>{{zip}}</span>
    <span>{{zip}}</span>
  </div>
</def>
</head>

    I don’t have any illusions that this fantasy has even a tiny chance of coming true though. Besides, it’s like a beggar asking for caviar when any kind of microdata support will satiate our hunger.

    Boss! Boss! The Plane. The Plane!

    update:

    Here is a more elaborate version of the def element for the bored:

    <def name="name" package="http://ting.ly/name"
  attrs="$$first last$$">
  <span>$$first$$ $$middle$$ $$last$$</span>
</def>

    which could be used like this:

    <name first="Don" last="Park"/>

    There are lots of wholes in this sketch which is why it’s a fantasy.

     

    • Douglas Hineline 10:31 pm on May 12, 2009 Permalink

      You can’t stop a stampede my man. The general html semantics has too much momentum to change direction too much, besides we’re just now starting to get browsers that act somewhat similar. In the end it is all just XML nodes, but try telling that to IE.

    • donpark 11:25 pm on May 12, 2009 Permalink

      Yeah, I know. I was there when IE core guys explained how the IE worked during a W3C DOM WG meeting. If I could, I would bury W3C in the sand then build an out house over it.

    • Philip Taylor 12:52 am on May 13, 2009 Permalink

      How would your idea differ from simply defining all the data in a separate machine-readable XML file and then using XSLT (or some other templating language) to construct the HTML from it?

    • donpark 8:55 am on May 13, 2009 Permalink

      If it’s done on client-side, only that I think this is easier to learn than XSLT. If XSLT transform is server-side, this is easier to use as well. I find XSLT learning curve rather steep for average HTML jockey.

    • Simon Gibbs 11:25 am on May 14, 2009 Permalink

      If you were to put city state, zip and street elements in a namespace and use CSS3 selectors then you wouldn’t need any syntax transformation in the page, or anywhere else.

      Once the elements are in a namespace and the markup is valid XML getting to RDF (via GRDLL) or unmarshalling objects (XPath, JAX-B) is easy – everyone is happy. Most intelligent people are able to grok XML namespaces given a few days of exposure to them.

      Given CSS3 rather than a def element there is very little missing from standards and tools, so this is not especially fantastic.

    • lun0 3:12 pm on June 4, 2009 Permalink

      hehehe awesome stuff

  • Smiley Profile Image Set 

    donpark 11:41 pm on May 6, 2009 Permalink | Reply
    Tags: blog,

    I wish I could use a set of profile images instead of just one and have appropriate one displayed based on text content so that if I put a smiley like :-) or ;-) in the text, photo of me smiling or winking will show.

    It doesn’t have to be a face, it could be topic/category images. And I don’t see why tweet-specific images couldn’t be displayed since Twitter already sends out image URL with each tweet (inside ‘user’).

     

    • Linvia 12:00 am on May 31, 2009 Permalink

      Hey this is kind of random, but I stumbled upon your blog when doing a google search.

      I am still very new to this blogging thing and I just installed the P2 theme. I was wondering how you got a display picture up. I don’t know where to even access that.

      If you could help at all that’d be so great :)

      Thanks in advance.

    • donpark 11:07 am on May 31, 2009 Permalink

      Hey Linvia. If you are referring to Flickr Photos, it’s a widget available from WordPress console if you are using WordPress.com service. If you are using your own installation, you’ll probably have to install a WordPress plugin.

  • donpark 10:44 pm on May 6, 2009 Permalink | Reply
    Tags:

    Trying Twitter/Facebook-like P2 theme to see if that’ll get me to post more often.

    I did change default template’s post body font size and added side paddings for easier reading.

     

    • Tim 5:43 am on May 7, 2009 Permalink

      I just heard about this theme on Matt’s site and WordPress.tv and I’m trying it out as a private site for communications for my youth group. I’m hoping it works good for discussing different topics and activity updates in an easy-to-use format similar to Facebook’s and Twitter’s updates.

    • MiscBytes 1:05 pm on June 1, 2009 Permalink

      I like this theme and think it really encourages conversation. What is is like on the back end? The usual WordPress stuff? I assume you can save drafts if you want – and schedule posts, etc.?

  • Why wasn't OAuth Vulnerability found earlier? 

    donpark 3:53 pm on April 28, 2009 Permalink | Reply
    Tags: ,

    According to OAuth about page, it was Blaine Cook who initiated the birth of the the standard while working at Twitter in Nov. 2006. Blaine mobilized the initiative by getting Chris Messina involved which attracted others at CitizenSpace to join the effort (an excellent demonstration of benefits co-working social environments offer). By April 2007, the initiative got to formalize and, by October 2007, OAuth Core 1.0 spec was finalized. The question of interest to me is, why did it take a year and a half to uncover the first vulnerability?

    It’s puzzling because OAuth was well known and popularized, attracted a large body of developers, many of whom I presume read the spec, and implemented by many, some very large companies. I’ve read the spec as well and discussed it with peers and partners in the security and payment industry on several occasions.

    I think the right answer might be that our collective perspective in dealing with the standard was focused on implementation, application, and hype while wrongly assuming that the standard was secure. Recollecting my thoughts when I was reading the spec for the first time, I now realize that it was the safety in numbers and the lure of promising applications that influenced me to focus only on implementation.

    The good news is that I think OAuth will be given the proper shake it needs to get any remaining kinks out. The bad news is that we are likely to repeat the mistake when the next popular grassroots standard emerges in a hurry. Relatively fast pace of community/grassroots standard initiatives is not a concern only if mass appeal can be effectively leveraged to shine intensive searchlight on all aspect of the standard.

     

    • Peter Keane 5:25 pm on April 28, 2009 Permalink

      I recently implemented my first OAuth client and had a slightly uneasy feeling that there was a bit of magic — I couldn’t cleary see how it was truly secure. Fact is, it was pretty darn close — the hole was never exploited (that we know) and steps are being taken to close that hole.

      That said, a simple fix will still leave a bit of “magic:” there is an authentication equivalency that is not being addressed (in OAuth terms, that user@consumer == user@service_provider) by way of a properly out-of-band mechanism. I would prefer to see that hole sewn up more definitively — essntially “whitelisting good guys” rather than “blacklisting bad guys” (which can become a game of whack-a-mole). I should note that many knowledgeable folks on the list feel the proposed fix is adequate. Two-legged OAuth, a less common use than the typical Three-legged flavor, is an excellent protocol (the exploit was discovered only in the Three-legged variety), and I suspect we’ll see more adoption as a stand-in for HTTP Basic & HTTP Digest authentication.

    • Matt Brubeck 7:24 pm on April 28, 2009 Permalink

      I don’t think it’s that complicated. There have been all manner of crypto protocols and security protocols that have been in use for years before critical flaws were discovered. Some were developed by standards bodies or subject to academic peer review. The fact is that any flaws left in a system after it’s been reviewed and revised and published can be quite hard to see, even if they’re obvious after someone points them out.

    • donpark 8:21 pm on April 28, 2009 Permalink

      Matt, while I agree that other protocols had flaws of varying nature, uncovering of fundamental flaws like the OAuth one and DNS one are rare events, often resulting in industry-wide scramble.

      Also, I don’t think we should accept incidental trickles of flaw discoveries as the norm when there are actions we can take to improve the process.

      IMO, it’s the same with open source projects. OS participants are primarily focused on using, extending, or repurposing the project code which means while bugs are uncovered, security vulnerabilities are rarely found until attack incidents occur or by chance.

      So I think some attention should be paid to finding ways or factors to introduce in grassroots initiatives and open source projects that encourages early detection of security vulnerabilities.

  • On Twitter's OAuth Fix 

    donpark 2:58 pm on April 25, 2009 Permalink | Reply
    Tags: , ,

    While the OAuth team is working on addressing the OAuth session fixation vulnerability at the spec level, Twitter made following changes to reduce the exposure window:

    • Shorter Request Token timeout – This is good practice in general. Developers tend to be too generous and, all too often, forget to enforce or verify enforcement.
    • Ignore oauth_callback, in favor of URL set at regration time – this prevents hackers from intercepting callback.

    Double-callback is still possible though which means Twitter OAuth Consumers will have to detect extraneous callbacks and invalidate access to everyone involved because they have no way of telling who is who.

    Remaining exposure to the vulnerability is when hacker’s simulated callback arrives before the user. We are talking temporal exposure of a couple of seconds at most which, given current Twitter use-cases, is not that big a deal. I wouldn’t do banking over Twitter though. ;-)

     

  • On OAuth Vulnerability 

    donpark 2:38 pm on April 23, 2009 Permalink | Reply
    Tags: ,

    Twitter’s OAuth problem turned out to be a general problem affecting other OAuth service providers and well as consumers using ‘3-legged’ OAuth use-case. For details, you should read not only the relevant advisory but Eran Hammer-Lahav’s post Explaining the OAuth Session Fixation Attack.

    First hint of the vulnerability surfaced last November as a CSRF-attack at Clickset Social Blog which was initially diagnosed as an implementation-level issue. Well, it turned out to be a design flaw requiring some changes to the protocol.

    There are actually two flaws.

    The first flaw is that parameters of HTTP redirects used in OAuth can be tempered with or replayed.

    This flaw allows hackers to capture, replay, and mediate conversations between OAuth Consumer and Service Provider flowing over the surface of User’s browser between the User, Consumer, Service Provider.

    I think the easiest general remedy for this flaw is including a hash of the HTTP redirect parameters and some shared secret like consumer secret. A more general solution like evolving tokens could be done as well but inappropriate as a quick remedy.

    This flaw should not affect OAuth service providers that manage and monitor callback URLs rigorously.

    The second and more serious flaw is that the User talking to the Consumer may *not* be the same User talking to the Service Provider.

    This means that a hacker can start a session with TwitsGalore.com then phish someone to authorize at Twitter to gain access to TwitsGalore.com as that someone without stealing password or session-jacking.

    Solving the first flaw simplifies the solution to the second flaw by reducing the possibility of the hacker intercepting callback from Service Provider to Consumer which is not supposed to have any sensitive information but some implementations might include. Wire sniffing is a concern if HTTPS is not used but the relevant concerns for the flaw are integrity and identity, not secrecy which is an application factor.

    Removing the possibility of callback URL tempering leaves double callback, meaning that the hacker start things off, tricks someone into authorizing without intercepting the callback, then simulate a callback to Consumer. Note that the Consumer would have started a HTTP session with the hacker, session associated with the RequestToken in the callback. Even if HTTP session is not created until the callback is received, there is no way for the Consumer to tell who is who.

    I think Service Provider have to send back a verifiable token, like a hash of the RequestToken and consumer secret so the hacker can’t simulate the callback.

    Regardless of which solutions OAuth guys decide on, one thing is clear. It will take time, many weeks at least, if not months. That’s going to put quite a damper on developers in the Consumer side of the OAuth as well as the Service Provider side.

     

  • Value of Journalism 

    donpark 11:05 am on March 11, 2009 Permalink | Reply
    Tags: journalism,

    Will newspapers survive? I think the physical form will survive for another 10 years at least at much lower valuation then eventually break into nich market fragments. The profession of journalism will, however, not only continue on but become more respected than before.

    This is why I think so. When we are short of something we consume, like water in the desert, we put value in availability. As we approach ubiquitous availability of the same, we shift value to quality.

    In a sea filled with unverified and biased news and information, we will rediscover the value of journalism. We will see memes as what they really are, mental viruses, and know the danger of careless consumption. As we have become more health conscious, we will also become more mental health conscious.

    We’ll see products of journalism like bottled water, avoid reading/eating things off the ground, and see eaters of biased or mutated news as inbred rednecks. Those who can afford to pay, that is.

    As usual, I am exaggerating. Not quite hyperbole but enough force to kickstart pointless thinking.

     

  • Leg Fetish 

    donpark 2:46 pm on March 1, 2009 Permalink | Reply
    Tags:

    I’ve been too busy tinkering so, beyond twittering, I haven’t had the mindshare to blog. Sorry.

    I think the stock market is in for another big leg down soon, not like the slide we’ve had lately but a drop of 500 pts or more in a day. One card Obama adminstration can play to stem or prevent the damage is the restoration of the up-tick rule.

    I could be wrong, of course, so use your own judgement.

    update on March 2nd at 10:41AM: Dow is at 6800 now, 200+ pts down but the volume is not there, just average so far, so this is not the massive volumn crash I was expecting. It’s as if hedge funds have changed their trading strategy from a disaster movie to suspense-building horror movie. Eerie. The only real support is still 300 pts away, btw, at 6500. There will be continued drama, of course. I’m just not sure what kind.

    update on close March 2nd: So the market went down orderly in a straight line more or less with Dow closing down 300, S&P barely hanging on at 700 which makes it look bad. NASDAQ didn’t do too badly but volume was nearly 4x where Dow volume was about 1.5x. Spitting into the wind, downward pressure is still overwelming. I am done looking at the market for today. It’s time to look at some business plans and code.

    a reminder to follow me on twitter: my tweets are mostly mindfart but look what I twitted last Thursday. ;-)

     

    • dbt 2:39 am on March 2, 2009 Permalink

      I think the uptick rule is foolish, and I’m generally very pro-regulation-of-finance.

    • donpark 3:57 am on March 2, 2009 Permalink

      Foolish or not, I don’t think the desirable effect is deniable.

      Anyway, just noticed that Asia closed 3-4% down and Europe currently down as much and looking to do worse so what I was afraid of might have already started. Oh, well.

    • Joshua Allen 8:09 am on March 3, 2009 Permalink

      I’m still betting on 5000 or below (http://twitter.com/allenjs/status/1028340694), but it appears that Obama wants it to be slow and volatile. I expect a few big rallies of 100 points or more before it finally drops through 6000.

      I just wish we’d get the damned deleveraging over with.

    • donpark 11:58 am on March 3, 2009 Permalink

      Good call there Joshua. There is growing consensus lately on 5000/500 being the bottom although I frankly doubt it won’t reach that far down. 6000/600 is vulnerable, of course.

      BTW, I am going to ignore today’s bounce which is not convincing enough, not even to qualify as a technical bounce.

Older Posts →

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
esc
cancel