I upgraded to the latest version of Gimp yesterday, and started playing with some of the artistic filters.  Here are the results of some messing around with Cubistic, GIMPressionist and edge detection filters:





Blogged with the Flock Browser
Advertisements

Until today, doing online banking or using your credit card to make purchases online was generally safe as long as you made sure that the website was using https (rather than just http) and you knew and trusted the company you were doing business with.

However, that has now changed as this blogger has discovered.  (Slashdot discussion here.)  I confirmed that the mozilla.com cert that blogger set up does in fact work — and that is most definitely a serious problem.

In short, one of the SSL certificate authorities run by a company called Comodo has been handing out SSL certificates that it shouldn’t have been, meaning that malicious parties could now have fully legitimate certs for paypal.com, royalbank.com, amazon.com, or anything for all we know.  This makes it considerably easier for hackers to spoof those websites and trick you into giving them your credit card number or other sensitive/valuable information.  You may go to your online banking site, and it might look just like you would expect from past experience, and there would be no errors or warning messages, but in fact when you enter your password number it’s going to a hacker or crime ring.

This is really a crippling blow to internet security.  It will get fixed, but until it does the best course of action is to NOT TRUST any websites with information that you wouldn’t want to be abused.  Virtually any formerly secure website could be compromised as a result of this.  For myself, I won’t make any online purchases or use online banking until there is a proper fix or at least an independent way to confirm the validity of the specific SSL certs that I would be depending on to trust those websites.

Update 1:21pm: Good discussion of this on the mozilla.dev.tech.crypto list, with Comodo participating.

Update 2008-12-31: Comodo has identified and revoked the offending certificates, so the immediate threat of this issue has passed.

Blogged with the Flock Browser

Blogged with the Flock Browser

Blogged with the Flock Browser

Blogged with the Flock Browser

One advantage of our shortened winter days in the Great White North, I get to be awake for some spectacular sunrises…

Blogged with the Flock Browser

Blogged with the Flock Browser

One of my first tasks upon starting at Flock was to design/clean up the XPCOM interfaces we use to represent web service components (Flickr, Facebook, etc.), accounts on those services, and specific APIs implemented by those services. We made great strides in that regard at the end of 2006 and beginning of 2007. Then some cleanup happened over the last two months or so. We now have a pretty workable model as described here.

We’re continuing to refine it, however. What follows are some changes we plan to make on trunk, probably over the course of the next month or so.

Web Service Interfaces
The major changes here are the introduction of flockILoginWebService, a slight reorganization of the inheritance hierarchy, and the elimination of flockIManageableWebService.

  • flockIWebService – Any web service that Flock integrates with. Does not necessarily have to support accounts. All account-related functions would be moved to flockILoginWebService.
    • flockIMediaWebService – A web service that supports the concept of media streams and/or queries.
      • flockIMediaEmbedWebService – A media service for which we support embeddable media (ala the Flock Magic overlay).
    • flockIPeopleWebService – A service that has a concept of “people”, but not necessarily of friends or a social graph. This would replace the current flockIMediaWebService#supportsUsers flag.
    • flockILoginWebService *NEW* – Any service that supports the concept of user accounts. (This would include every service except for Truveo in the current roster.) All account-related methods from the current flockIWebService interface would move to here. This interface would also subsume everything currently in flockIManageableWebService.
      • flockIBlogWebService – A service that supports blogging.
        • flockICustomBlogWebService – Used to support self-hosted blogs.
      • flockIMailWebService – Webmail services.
      • flockIBookmarkWebService – Online bookmarking services.
      • flockISocialWebService – A service with a social graph, wherein users can have friends in the People sidebar, etc. These services will also implement flockIPeopleWebService. (If XPIDL let us do multiple-inheritance then this interface would inherit from flockIPeopleWebService as well. It doesn’t, sadly.)
      • flockIMediaUploadWebService – A service to which users can upload media using Flock’s Uploader. (This interface would also inherit from flockIMediaWebService if possible.)

Account Interfaces
These are basically just being renamed to make them more readable.

  • flockIWebServiceAccount – Can be associated with any flockILoginWebService.
    • flockIBlogAccount – renamed from flockIBlogWebServiceAccount.
    • flockIBookmarkAccount – renamed from flockIBookmarkWebServiceAccount.
    • flockIWebmailAccount – renamed from flockIMailWebServiceAccount.
    • flockIMediaAccount – renamed from flockIMediaWebServiceAccount.
      • flockIMediaUploadAccount – stays the same.
    • flockISocialAccount – renamed from flockISocialWebServiceAccount.

API Interfaces
Web service API implementations should be XPCOM components, but not XPCOM services. This is because we may want multiple instances of them. For instance, both Delicious and Magnolia use the Delicious API. Therefore we should have an instance of flockIDeliciousAPI for each service, so that the API states can be maintained separately.

  • flockIWebServiceAPI *NEW* – defines generic authenticate(), deauthenticate() and call() methods, and an isAuthenticated property.
    • flockIFacebookAPI
    • flockIMovableTypeAPI
    • flockIWordpressAPI
    • flockIDeliciousAPI
    • etc…

Blogged with Flock

Flock is a browser with some unique capabilities, but that also means it has some unique problems to solve as far as browsers go. Core to the Flock experience is the tight integration we provide with various online services — including social, media, blog and bookmarking services.

Many of these services have APIs that we call in order to perform certain tasks, but there are some things we must do without API support… some tasks that require us to examine the actual HTML content of the pages the user is loading up and look for certain patterns. We need to be able to detect when a user logs in to (or out of) a supported service, for example, since some integration features will only work when the user is logged-in. We also need to detect when there are “media streams” available from a given page so that we can allow the user to open them in the media bar.

How do we know if a user is logged in to Service X? Well generally speaking, if you’re logged in to a service then there’s a button or link on the page to allow you to log out. Spotting that button or link is a great clue for the browser to know you’re logged in. If we’re lucky, the button has an id that makes it especially easy to spot, for instance: id=”logoutButton”.

But the thing about web services is that they’re likely to change their HTML at some point. Since that “logoutButton” isn’t part of a published API, there’s nothing to stop Service X from changing it to a link, and perhaps dropping the id attribute. This is a problem for Flock, since it would break our integration. We would no longer be able to detect that the user had logged in to the service, and some Flock functionality would be broken or disabled as a result.

To combat this problem, we have developed a technology called Web Detective. Web Detective lets us specify detection “rules” in an updateable XML file for each service. So if ServiceX ever changes their HTML and breaks Flock’s integration, we can just update the serviceX.xml file and within a few hours Flock users will be running with the new rules and all will be good with the world again.

Here’s documentation on Web Detective and how to understand and write the rules files:
http://developer.flock.com/wiki/Web_Detective

Ideally, the services we support would never change the IDs of key HTML elements (like the example “logoutButton” above), so that Flock’s integration would never break. It’s not really reasonable to expect services to keep the same HTML forever, however. The best case scenario would be if all supported services provided META tags in their HTML HEAD sections on every document. For example:

<meta name=”session-loggedin” content=”y” />
<meta name=”session-userid” content=”JoeUser23″ />

The first tag, “session-loggedin”, would simply have a content of “y” if the user was currently logged in and “n” otherwise. The second tag need only be present if the user is logged in, and would have as content the unique user ID of the logged-in user. For some services this is the same as the username or email addy used to log in, but other services use a separate unique identifier.

If all services supported something along those lines, it would be easy for us to detect and it wouldn’t have to be in danger of breaking when they changed the visual HTML markup on their pages.

Blogged with Flock

Being built upon Mozilla’s Firefox platform means that Flock benefits from all the great work that Mozilla and its contributors have done, and continue to improve. It also means that we have inherited an enormous codebase. Firefox has somewhere in excess of 2 million lines of active code, with over a thousand individual interfaces defined. Flock only adds to that.

Seasoned Flock developers have learned their way around the parts of the code relevant to the components they have worked on, but for a novice the cumulative immensity is overwhelming.

The following diagram highlights some key components and pieces of UI that Flock adds.

[FULL SIZE]

This is not comprehensive, but it pretty closely represents the major components and their relationships as of Flock 0.9, the most recent major release. Of course, the imminent release of 1.0 means that this diagram will soon need to be updated to reflect the new 1.0 features.

Ever-improving documentation for Flock-specific interfaces can be found here:
http://lxr.flock.com/doxygen/flock/trunk/

Blogged with Flock