Random musings from a Southern California geek. I started WICK and IBDOM. There are some pics (rss). current project.
Thursday, March 31, 2005
Yahoo 360.
I've got yahoo 360 invites, gmail me at frenchy ... family, friends, coworkers, enemies first :)
Sunday, March 27, 2005
GMail offers Phishing Alerts
I'm interrupting my short blogging hiatus to point out that GMail offers, i don't know as of when, Phishing Alerts. Good stuff :) Thanks Googledudes :D
I'd written about phishing a while back too.
I'd written about phishing a while back too.
Monday, March 21, 2005
Theme Songs in Movies
As "Never Say Never" is playing on channel 528 right now, three movies that start the opening credits with theme songs come to my XSLT-infested, semi-lucid mind at this most auspicious hour:
- All James Bond movies
- South Park, The Movie
- Harold & Kumar Go to Whitecastle
Mad Love to Lindy-Pie
Friday, March 18, 2005
Wednesday, March 16, 2005
GMail Invites Out my Ears
Like most other GMail users, I've got what appears to be a never-ending stream of GMail invites to hand out. If you send me an email to frenchy@gmail.com, you're almost guaranteed to get an invitation.
Thursday, March 10, 2005
Wednesday, March 09, 2005
iPod Killer, Reloaded
Sony: "hey look! we too have a flash-based mp3 player! with AAA batteries! watch out iPod"
Monday, March 07, 2005
EarthLink Broadband Over PowerLine Free Trial?
Hrmmm. I saw this site posted somewhere. I don't think I'm part of those lucky homes just yet.
R.I.P. Chris Portman
In over 6 years working here, I'd only interacted with him over our internal IRC a handful of times. One of our company's youngest and brightest minds, he was widely respected as a Guru in his field.
Sunday, March 06, 2005
XSLT Mac OS X Cocoa App
TestXSLT is what I was looking for to do XSLT transformations in Mac OS X. Thanks n' $20 to Marc Liyanage for putting it together :)
Thursday, March 03, 2005
Wednesday, March 02, 2005
Sites and Systems with Public APIs
The following are sites with public, documented APIs.
yahoo.com - Happy 10th! :) Jeremy's Introduction at ETech
google.com
technorati.com
del.icio.us
Feedster
flickr.com
blogger.com
typepad.com
amazon.com
ebay.com (REST)
Buzznet
do YOU have an API? let me know.
yahoo.com - Happy 10th! :) Jeremy's Introduction at ETech
google.com
technorati.com
del.icio.us
Feedster
flickr.com
blogger.com
typepad.com
amazon.com
ebay.com (REST)
Buzznet
do YOU have an API? let me know.
Tuesday, March 01, 2005
ContextAgnosticXmlHttpRequest: an Informal RFC
update: 08/22/2007: Per anonymous commenter, Mozilla is about to release cross-domain support for XmlHttpRequest.
update 3/17/2006: See also the JSONRequest proposal by Douglas Crockford.
update 10/3/2005: Microsoft is asking similar questions. Please read the full discussions we had on ContextAgnosticXmlHttpRequest on the what-wg mailing list. The thread goes-on for quite a while, with good thoughts from many developers.Some key points i've extracted:
- There was a pretty decent consensus for requiring an HTTP service to send one extra HTTP Header that we might call X-Allow-Foreign-Hosts. A ContextAgnosticXmlHttpRequest would fail to expose any data from a service not sending this header. This ought to protect intranets.
- A couple of us firmly believe we truly don't want to be sending any cached/saved Cookies and/or Basic Auth credentials.
XmlHttpRequest is 2004-2005's big buzz. This post is intended for people who are familiar with this technology. If you wish to familiarize yourself with it, you might consider Apple's fine introduction to XmlHttpRequest.
The current security model of XmlHttpRequest prevents a document from initiating an HTTP Request to a host different from the one that served it. There are very very good, useful, critically important reasons for this: Your browser sends cookies along with the request. For similar reasons, a Flash application may only talk back to the same host that served it. This model already allows developers to build a host of insanely great things, and I'm very happy with it.
This informal RFC is attempting to explore the Pros and Cons of an additional type of request: a ContextAgnosticXmlHttpRequest Object. It would not replace the current implementation of XmlHttpRequest. It would be another object we could leverage for other types of requirements:
Here's a basic use case:
A document served by somehost.myFIRSTdomain.com would retrieve XML data over HTTP from somehost.mySECONDdomain.com.
And, by extension:
A document served by host1.mydomain.com would retrieve XML data over HTTP from host2.mydomain.com.
This request would:
update 3/17/2006: See also the JSONRequest proposal by Douglas Crockford.
update 10/3/2005: Microsoft is asking similar questions. Please read the full discussions we had on ContextAgnosticXmlHttpRequest on the what-wg mailing list. The thread goes-on for quite a while, with good thoughts from many developers.Some key points i've extracted:
- There was a pretty decent consensus for requiring an HTTP service to send one extra HTTP Header that we might call X-Allow-Foreign-Hosts. A ContextAgnosticXmlHttpRequest would fail to expose any data from a service not sending this header. This ought to protect intranets.
- A couple of us firmly believe we truly don't want to be sending any cached/saved Cookies and/or Basic Auth credentials.
XmlHttpRequest is 2004-2005's big buzz. This post is intended for people who are familiar with this technology. If you wish to familiarize yourself with it, you might consider Apple's fine introduction to XmlHttpRequest.
The current security model of XmlHttpRequest prevents a document from initiating an HTTP Request to a host different from the one that served it. There are very very good, useful, critically important reasons for this: Your browser sends cookies along with the request. For similar reasons, a Flash application may only talk back to the same host that served it. This model already allows developers to build a host of insanely great things, and I'm very happy with it.
This informal RFC is attempting to explore the Pros and Cons of an additional type of request: a ContextAgnosticXmlHttpRequest Object. It would not replace the current implementation of XmlHttpRequest. It would be another object we could leverage for other types of requirements:
Here's a basic use case:
A document served by somehost.myFIRSTdomain.com would retrieve XML data over HTTP from somehost.mySECONDdomain.com.
And, by extension:
A document served by host1.mydomain.com would retrieve XML data over HTTP from host2.mydomain.com.
This request would:
- allow a document to perform an HTTP request to a foreign host
- without sending any cookies in the request that would otherwise be in effect for that host: no Cookie: Header in request
- Discard Set-Cookie: directives in HTTP responses from the target host.
- Ignore any cached HTTP Basic Auth credentials, and only send those that'd somehow be explicitly set (URI http://username:password@host or setter methods?)
- Always send an accurate HTTP Referer: request header whose value is the URI of the document executing the request. See more below.
- update 11/09/2005: see the above X-Allow-Foreign-Hosts header suggestion which ought to nicely alleviate this problem. In other words, your XML service can only be used by foreign documents if and only if you explicitly allow it by sending this extra HTTP header. - The issue: Everyone and their Moms could now paste some silly HTML code in their web pages to retrieve XML data from web-services-providing web sites. I could now paste the Google Suggest code into my own web page, and show results from Google's servers on my own web page, without going through the trouble of proxying them first. In turn, Google would have to start locking their application down. "Hijacking" HTTP XML services isn't new though, plenty of people have leveraged GMAIL's API in standalone applications without exactly asking Google for their permission. But the learning-and-adoption curve for abuse is far steeper today: You've gotta know a little more about software development than pasting a piece of HTML code into your blog template. "If you're going to leverage someone else's HTTP/XML API in your web documents, be a sport, share-in the bandwidth cost and at least proxy them". I'd most definitely file this under "not unreasonable!".
- This would make "the game" interesting for web sites that are RSS aggregators. They would now have the ability to let their end-users load their favorite sites' RSS XML data directly into the web browser without, technically ,"having to" offer a server-side aggregating/caching/proxying layer. If poorly coded, such aggregator site could drive-up bandwidth costs of most subscribed to blogs.
- There is one HTTP header i would really like a ContextAgnosticXmlHttpRequest to always send out with absolute integrity: The Referer: (sic) HTTP header. For those who are not already aware of this, the misspelling of the word "Referrer" as "Referer" is part of the official HTTP specification. This header would basically identify the URL of the document originating the request. The entity managing the service receiving the request should be able to easily build white lists and black lists to effectively restrict browser-based access to their service: "If you're not coming from www.google.com, i ain't serving you sh!t."
- Beyond the Cookie: HTTP Header, are there any other HTTP headers that should not be included?
- Could phishers abuse this to further obfuscate what goes-on in their web documents? They've already got plenty of tools in their shed. I've often seen phishers set-up multiple domains as "landing-pages" to pose as banking sites, while thoroughly obfuscating their HTML code to hide which host/CGI they're actually submitting the data to: disparate landing pages might submit to a same host/CGI. Even with obfuscated HTML, it's relatively easy to sniff out the form submission target by crawling the DOM via a browser plugin or javascript:document.forms. I'd hate to add yet another Remote-Scripting hack to their tool-shed.
- Should restrictions be imposed on HTTP methods? Say, only HTTP GET is allowed. At which point, we might rename the object to reflect this restriction. The idea is that HTTP POST is more likely to be used for transactional purposes, which is unlikely to happen at a cross-host/domain level, and I'm leaning toward not allowing the HTTP POSTing of large amounts of data to a completely different domain. See also phishers above.
- What about HTTPS? Currently, an HTTP document can't initiate an HTTPS XmlHttpRequest. Should we retain the same restrictions for this object?
- Should HTTP Basic Auth even be supported?
Thursday, February 24, 2005
California Storms Slideshow
The nice thing about living in Southern California is that we always get nice weather. But when we do get bad weather, it doesn't come at us in a girlie-man kinda way.
It was bright and sunny this morning in Hermosa Beach. I shall now resume my daily jogging as soon as I buy myself a new pair of New Balance 716. My 1-year old pair lost its structural integrity on last saturday's 45-min run.
It was bright and sunny this morning in Hermosa Beach. I shall now resume my daily jogging as soon as I buy myself a new pair of New Balance 716. My 1-year old pair lost its structural integrity on last saturday's 45-min run.
Wednesday, February 23, 2005
Google Movies: Showtimes, Reviews and More?
Those crazy google guys are doing it again:
This one.
Just in time for the Oscars, we've created a new "movie:" operator that enables you to find movie-related information faster and more easily, whether you're looking for titles or actors, director or genre, famous lines or obscure plot details.If you're looking for the finest pieces of motion picture ever made throughout the entire history of mankind, movies which relegate the likes of Muybridge, Kurosawa, Truffaut, Fellini, Wim Wenders to the deepest pits of irrelevance, there is one, and only one movie: Google Search you'll ever need to check on a regular basis:
This one.
Communicate, Collaborate, Securely, Cross-Platform
Joi Ito is telling us about a really cool new cross-platform tool, Shinkuro:
For now, you can obtain an unlimited license for free. I bet this offer won't last.
It's basically a very cryptographically robust, cross-platform collaboration tool. It allows you to create groups and share folders of files, has a shared chat space (like IRC) and allows you to share your desktop screen with other members of the group (yes, across platforms). The shared files are transfered in the background and edits to files are sent as diffs which can be accepted into the original by the recipient. There is also standard IM with your buddy list. The great thing is that all of the traffic is encrypted. 256 bit AES and 2048 bit RSA keys. Each message is encrypted with a unique key, and the key is transmitted under the RSA key. This is very important since I know for a fact that people sniff IM and other traffic at many of the conferences and public places.I'm chrisholland!shinkuro.com
For now, you can obtain an unlimited license for free. I bet this offer won't last.
The User-Owned Phone System
David Beckemeyer just posted a review of this really cool embedded linux PBX firmware solution: SIPatHome:
The rebels are at it again. This time they've built a free, open-source VoIP platform for embedded devices. It's a VoIP PBX in box, a cheap affordable box. The box, in fact, is a common Linksys router. It's called SIPatH (hey nobody said geeks know how to name products)
Tuesday, February 22, 2005
Two Iranian Bloggers Jailed
From Jeff Jarvis:
If you're reading this, please read and link to the effort to free Arash Sigarchi and Mojtaba Saminejad.
The Committee to Protect Bloggers is urging support from all bloggers on Feb. 22 -- today -- to bring international attention to the plight of two bloggers, Arash Sigarchi and Mojtaba Saminejad, jailed in Iran. Here's a BBC story.
I first discovered the Iranian blog culture when its Johnny Appleseed, Hossein Derakhshan, reported on the arrest of blogger Sina Motallebi. We blogged about that and brought international attention to the story and Sina credits that with helping to get him out of jail and out of the country.
These people are in jail for doing exactly what we have the privilege of doing: Speaking. We must stand with them.
So please link to the Committee to Protect Bloggers and please bring attention to what his happening to our colleagues in Iran.
If you're reading this, please read and link to the effort to free Arash Sigarchi and Mojtaba Saminejad.
Friday, February 18, 2005
Momentous Weekend!
Josh and Amy just gave birth to their first baby son, Donovan Josiah at 6:50pm on this Friday February 18th, 2005.
Tomorrow, Joe is turning 30.
Sunday, Tom and Laura are getting married.
Tomorrow, Joe is turning 30.
Sunday, Tom and Laura are getting married.
Thursday, February 17, 2005
MSN to Mac Users: We Don't Like You
Embedded Windows Media streams have worked fine in Safari for quite some time now. There's also Windows Media for Mac. What's the rationale here? Try to get me to switch back?
Wednesday, February 16, 2005
ricerpod vs podricer
[11:16pm] _adam_gfx: i am waiting for a ricerPod from ptorrone
[11:17pm] _adam_gfx: with a fin and Vtech stickers
[11:19pm] valmont: holy shit. google returns no result for ricerpod
[11:19pm] valmont: updates his blog
[11:19pm] rojisan: of course not. everyone knows it's a podricer
[11:20pm] valmont: lol. no hit either! hahaha
[11:20pm] rojisan: podricer is gold
[11:21pm] PicoloPoo: i'd play with a podricer
Tuesday, February 15, 2005
Best From Apple: Protecting the Computer
It's no secret to most Administrators of any sizable pool of desktop computers, that users of those machines tend to find ever creative ways to tamper with their systems and render them unusable, resulting in costly losses of productivity. Whether they fall prey to the Microsoft Windows Security Flaw "du jour", click "Yes" to ActiveX prompts triggered by some ad banner, or still find a way to run some spyware-carrying file-swapping program, opportunities to compromise the integrity of a machine abound.
In very specific cases, it might be worth an Administrator's time and regained sanity to investigate migrating a portion of their user base to the Mac OS X platform, upon evaluating the tamper-limiting features it offers.
In very specific cases, it might be worth an Administrator's time and regained sanity to investigate migrating a portion of their user base to the Mac OS X platform, upon evaluating the tamper-limiting features it offers.
Subscribe to:
Posts (Atom)