extreme geekboy

cookies by many different names

2010-01-29T17:07:00.003-05:00

Cookies are great, and everyone loves them (chocolate chip are my favorite) but if we leave the Internet to its own device it could potentially drive itself into a state of udder deception where other technologies are secretly used in place of cookies for tracking and identification purposes.

Spending the past two days submerged in various privacy discussions, I've started again deeply thinking about cookies and tracking. The fundamental privacy concerns about HTTP cookies (and other varieties like Flash LSOs) come from the fact that such a technology gives a web server too much power to connect my browsing dots. Third-party cookies exacerbate this problem -- as do features like DOM storage, google gears, etc.

Come to think of it, cookies aren't unique in their utility as dot-connectors: browsing history can also be used. A clever site can make guesses at a user's browsing history to learn things such as which online bank was recently visited. This is not an intended feature of browsing history, but it came about because such a history exists.

But wait, cookies, Flash LSOs, DOM storage, and browsing history aren't uniquely useful here either! Your browser's data cache can be used like cookies too! Cleverly crafted documents can be injected into your cache and then re-used from the cache to identify you.

In fact, all state data created or manipulated in a web browser by web sites has the potential to be a signal for tracking or other dot-connecting purposes. Even if the state change seems to be write-only there could be other features that open up the other direction (e.g., the CSS history snooping trick mentioned above -- or timing attacks).

Stepping Back and thinking about these dot-connecting "features" in the context of the last couple days' privacy discussions has got me wondering if there's not a way we can better understand client-side state changes in order to holistically address the arbitrary spewing of identifying information. I think the first step towards empowering users to protect themselves better online is to understand what types of data is generated by or transmitted by the browser, and what can be used for connecting the dots. After we figure that out, maybe we can find a way to reflect this to users so they can put their profile on a leash.

But while we want to help users maintain the most privacy possible while browsing, we can't forget that many of these dot-connecting features are incredibly useful and removing them might make the Web much less awesome. I like the Web, I don't want it to suck, but I want my privacy too. Is there a happy equilibrium?

How Useful is the web with cookies, browsing history and plug-ins turned off? Can we find a way to make it work? There are too many questions and not enough answers...

sluggish xorg

2009-12-14T16:04:00.002-05:00

I have been fighting with what I thought was a really slow window manager, and so I changed to a lighter weight one and it still took forever to draw things. After fiddling with stuff on and off for a few months, it turns out to be pretty simple: the radeon driver decided to use the CPU for too much of its own job.

I set a couple of flags (thanks to linportal), and everything is speedy again. So if you're fighting with a radeon driver that seems to be worthless (especially with multiple displays) try setting the "MigrationHeuristic" option to "greedy" in your xorg.conf's device section.

Option "MigrationHeuristic" "greedy"

update on HTTPS security

2009-11-20T17:11:00.006-05:00

Version 2.0 of my Force-TLS add-on for Firefox was released by the AMO editors on Tuesday, and in incorporates a few important changes: It supports the Strict-Transport-Security header introduced by PayPal, and also has an improved UI that lets you add/remove sites from the forced list. For more information see my Force-TLS web site.

On a similar topic, I've been working to actually implement Strict-Transport-Security in Firefox. The core functionality is in there, and if you want to play with some demo builds, grab a custom built Firefox and play. These builds don't yet enforce certificate integrity as the spec requires, but aside from that, they implement STS properly.

The built-in version performs an internal redirect to upgrade channels -- before any request hits the wire. This is an improvement over the way the HTTP protocol handler was hacked up by version 1 of Force-TLS, and doesn't suffer from any subtle bugs that may pop up due to mutating a channel's URI through an nsIContentPolicy. I'm not sure that add-ons can completely trigger the proper internal redirect, since not all of the HTTP channel code is exposed to scripts, and add-ons would need to replicate some of the functions compiled into the nsHttpChannel, opening up a possibility of obscure side-effects if the add-on gets out of sync with the binary's version of those functions.

Edit: The newest version of NoScript does channel redirecting through setting up a replacement channel in a really clever way -- pretty much the same as my patch. It replicates some of the internal-only code in nsHttpChannel, though, and it would need to get updated in NoScript if for some reason we change it in Firefox.

OWASP AppSec DC '09

2009-11-12T10:59:00.003-05:00

I'm at OWASP AppSec DC '09 this week. If you're there too, come find me and say hi!

csp @ stanford security seminar

2009-10-12T14:20:00.001-04:00

I'll be giving a talk at the October 13 Stanford Security Seminar. 4:30pm in Gates 4B. Show up if you're interested in CSP or want to heckle!

CSP Preview!

2009-10-02T14:44:00.006-04:00

Brandon Sterne and I released a preview of Firefox with Content Security Policy features built in. There are still little bits of the specification that aren't yet ready (like HTTP redirection handling), but most of the core functionality should be there.

If you'd like to play around with this pre-release version of Firefox (very alpha, future release) that has CSP built in, download it here! You can test it out at Brandon's demo page.

In case you're not familiar with CSP, it's a content-restriction system that allows web sites to specify what other types of stuff can be embedded on their pages and where it can be loaded from. It's very similar to something called HTTP Immigration Control that I was working on in grad school, so I'm very exited to be part of the design, specification and implementation -- hopefully a big step towards securing the web.

Previously: Shutting Down XSS with Content Security Policy and CSP: With or Without Meta?

Update: The old download link expired. New one should have a much longer lifetime (here).

notawesome

2009-09-17T14:32:00.008-04:00

While discussing privacy and Firefox 3.5 with Chris a couple weeks ago, we stumbled upon the thought that people might want to be able to select which bookmarks show up when they're given automatic suggestions in Firefox 3's Awesome Bar. This discussion really started with a bit of public metrics and discussion in the blogosphere.

In mid August, Ken Kovash wrote about reasons users gave for not upgrading from Firefox 2 to Firefox 3.0. The number one reason was, surprisingly, the Awesome Bar. Without going into detail, the gist was that people didn't really want certain bookmarks to show up when they start typing URLs.

Perhaps the settings weren't obvious enough, but users can set the awesome bar to search only bookmarks, only history, both, or neither (Alex Faaborg discussed it in June, in fact).

Here's the use case: Bob bookmarks a couple porn sites, then during a public presentation, he starts typing "www" in the URL bar. His porn sites show up in the suggestion list, and everyone in the audience gasps.

The work-arounds for this I see are:

Use a separate browser for "private" sites.
Use a separate Firefox profile for browsing "private" sites.
Use Private Browsing when browsing "private" sites (but then you can't bookmark the sites).
Turn off bookmarks and/or history searching for awesome bar.

But maybe this isn't good enough for everyone. Some folks might want to just hide a couple of bookmarks from the awesome bar. We need a way to make certain bookmarks "not awesome" so they won't show up.

Enter bookmark tags... you can add tags to bookmarks to find them easily. Why not tag bookmarks with "notawesome", then somehow hide those from the awesome bar search?

On a whim, I hacked together a quick addon to do this: notawesome!

lifehacker picked up on this (dunno how they found it buried in AMO), and apparently some folks find it useful.

To those 800 people using it already: thanks for trying it out, and your comments! I'll see if I can find some time to make it better. If anyone else wants to hack on it, let me know...

force tls

2009-08-10T14:29:00.000-04:00

A while back, Collin Jackson and Adam Barth presented this idea called ForceHTTPS. The main idea was simple, yet powerful: allow sites a way to say "in the future, ALWAYS load me via HTTPS". Why?

"Computers are increasingly mobile and, to serve them, more and more public spaces (cafes, airports, libraries, etc.) offer their customers WiFi access. When a web browser on such a network requests a resource, it is implicitly trusting the hotspot not to interfere with the communication. A malicious computer hooked up to the network could alter the traffic, however, and this can have some unpleasant consequences." [Mozilla Security Blog]

I like this force-security feature, and by suggestion from a few other interested parties, I took to implementing a slightly different version from what Jackson and Barth had done in the past. For now, I'm calling it ForceTLS, and the indicator to "always load via HTTPS" is an HTTP response header.

There's more details on my Force-TLS web site, but that's the gist of what it does. Some folks are working on a more detailed specification that hopefully will be published soon. For now, check out the add-on for Firefox, and let me know what you think!

inheriting XPCOM across languages

2009-08-06T13:59:00.007-04:00

I've been working on an Add-On for Firefox 3.* recently, and came across a situation where I wanted to do a little XPCOM component inheritance. Basically, there's an HTTPProtocolHandler in Firefox that is used in a variety of places, mainly in the creation of URIs and connections through HTTP. I wanted to modify the HTTP Protocol Handler so that it would get to "filter" each HTTP URI before a connection is created, and then maybe upgrade it to HTTPS if necessary (ForceTLS: see the AMO listing, my site, and the blog entry).

Anyhow, since there can be only one HTTP protocol handler, I have to somehow modify it, and since it's written in C++, I basically have to write my own from scratch to deploy it in an add-on.

But wait, there's got to be an easy way. Here's a thought: create a really basic component, capture a reference to the existing HTTP protocol handler, register the new one as the HTTP protocol handler, and for all method calls and property accesses on my handler, delegate back to the original protocol handler. In js-pseudocode:


myHandler.aPropertyAccessed = function(propName, context) {
  if(typeof this[propName] === 'undefined')
    return oldHandler[propName];
  return this[propName];
};

myHandler.aFunctionCalled = function(fname, args) {
  if(typeof this[fname] === 'function')
    return this[fname].apply(fname, args);
  return gOldHandler.functionCalled(fname, args, gOldHandler);
}

But of course it's not that easy because there is no propertyGetter or functionCalled general methods (like in python). So instead, I had to take to playing with prototypes, aided of course by my JS guru Ben:


// "@mozilla.org/network/protocol;1?name=http"
var kCID = "{4f47e42e-4d23-4dd3-bfda-eb29255e9ea3}";
var gOldHandler = Components.classesByID[kCID] 
                   .getService(Ci.nsIHttpProtocolHandler);

function MyHandler() {}
MyHandler.prototype = {
  //custom methods and overridden stuff here
}
MyHandler.prototype.__proto__ = gOldHandler;

But this didn't work because of XPCOM and QueryInterface: the JS object oldHandler may have other interfaces it supports, but the appropriate methods aren't in the JS instance. So I have to do something a bit more elaborate:


// Given two instances, copy in all properties from "super"
// and create forwarding methods for all functions.
function inheritCurrentInterface(self, super) {
  for(let prop in super) {
    if(typeof self[prop] === 'undefined')
      if(typeof super[prop] === 'function') {
        (function(prop) {
          self[prop] = function() { 
            return super[prop].apply(super,arguments); 
          };
        })(prop);
      }
      else
        self[prop] = super[prop];
  }
}

function MyHandler() {
  //grab initial methods (nsIHttpProtocolhandler)
  inheritCurrentInterface(this, gOldHandler);
}

MyHandler.prototype = {
  QueryInterface:
  function(aIID) {
    gOldHandler.QueryInterface(aIID);
    inheritCurrentInterface(this, gOldHandler);
    return this;
  },

  newURI:
  function(spec, originCharset, baseURI) {
    var uri = gOldHandler.newURI.apply(gOldHandler, arguments);
    //... do my stuff here ...
    return uri;
  }
};

Essentially, I have to import the functions and variables from the old HTTP protocol handler, and every time my instance (which is replacing the old protocol handler) is QI'ed, I have to QI the old one and re-import all its properties. This is because the old handler was also an nsIObserver and who knows what else.

I implemented my own newURI method by wrapping the one in the old handler and manipulating the URI that comes out of it. Because this is manually defined, it won't be shadowed by functions imported by the inheritCurrentInterface() calls.

The only lingering XPCOM question I've got is what to do with getInterface(). I think because of the inheritCurrentInterface() implementation, getInterface will get imported with the appropriate functionality when it's needed, but I'm not sure.

So I guess the next step is to try and figure out how to provide a JS library that makes this all a lot easier. I'd like some syntax like:


Components.utils.import("resource://gre/modules/XPCOMUtils.jsm");

var MyService = XPCOMUtils.extendService(kCOMPONENT_CLASS_ID);
MyService.constructor = function(foo) {
  //do something with foo
};
MyService.prototype = {
  //override methods here
  componentMethod: function(a, b, c) {
    super.componentMethod(a, b, c);
  },  
};

// then the rest of XPCOMUtils init stuff...

That syntax may not be workable, but something like it would be nice.

CSP: with or without meta?

2009-06-29T18:24:00.004-04:00

We're working up a storm on Content Security Policy (CSP) here at Mozilla, and I've been spending a lot of time hacking out an implementation and talking with people about how CSP works. I keep coming back to sharp edges caused by allowing policies in <meta> tags. Not only does meta-tag support make implementation of CSP more difficult, but it actually also provides an additional attack surface.

What is CSP?
Quick summary of Content Security Policy: CSP lets web site authors specify a policy that locks down where the site may obtain resources as well as what types of resources may be requested. This policy is specified in an HTTP Request header or may also be specified in a meta tag. There's a great blog post by Brandon that talks about this stuff more in depth.

Enter the http-equivalent META tag.
Originally, the point of allowing policy definitions in meta tags was to gain greater flexibility and give an option to folks who can't modify HTTP headers due to web hosting restrictions. Later on, we started thinking that meta-tag-CSP would be a useful way to allow "tightening" or intersection of policies for specific segments of a web site.

The only use case that comes to my mind is a shared web hosting service. Imagine the controllers of a hosting service want to forbid embedding of Flash content from EvilFlashHacker.com; at the same time their customers may want a more restrictive policy, but only one policy can be specified in HTTP. As a result the hosting company has three options:

Let their customers override the policy (possibly removing the no-EvilFlashHacker.com rule)

Disallow the ability for their customers to tighten the CSP

Provide some way to allow policy tightening without the possibility of loosening.

An ability to specify policies in meta tags gives way for situation 3: policy tightening. Unfortunately there are side-effects to allowing policy specification in both HTTP headers and meta tags.

Side Effects.
Implementing CSP becomes quite a bit more complex with meta tags. First, the user agent has to figure out to do when there are two conflicting policies, one in HTTP and one in meta. We solved this with an intersection algorithm that can only tighten an effective policy. Aside from conflicts, there's also the issue of parsing the meta tag out of the document appropriately before any resources subject to CSP are requested.

Allowing policy specification in a meta tag also opens up another use for successful content injection attacks: injection of an unauthorized policy. Additionally, such a policy could be used for a limited CSRF attack on the site itself through a policy-uri or report-uri directive. Of course an unauthorized "allow none" policy can effectively DoS a site, too.

Content Separation.
In the haze of thinking about meta-tag-CSP uses, I lost track of the reason CSP was HTTP header-based in the first place: to separate the content from the transmission channel and underlying policies that controls what it is for and what it can do. There's a clear advantage to this separation: it is harder to attack. Adversaries now must be able to break into the protocol level, not just the application/content. HTTP headers are way more easily hardened on the server-side than an HTML tag.

I want to eradicate meta-tag support for CSP, and all of the thorns that come with it -- policy intersection, document parsing complexity, HTML injection threats, etc -- because I don't think the relatively small gain from implementing it is worth the potential cost and risk. Is there a use (other than the hosting service use case above) that requires a meta tag CSP... and is worth the security risk and code complexity?

roll your own EV

2009-04-21T19:31:00.005-04:00

In working on a project recently, I found myself wanting to become an EV-SSL certificate authority (EV means Extended Validation). Lofty goals, yes, but really I just wanted to play with EV certificates and see if a couple of things were feasible. I'll post what happens as I figure it out.

Anyway, I needed to find a way to get a browser to accept a root CA that I created, and then get the browser to trust that root CA to issue EV certificates. This is harder than it sounds; regular SSL root certificates can be added easily to any browser, but the EV root certs can't. This is to protect users from accidental or malicious installation of EV root certs -- but unfortunately also protected me from easily doing it too.

Turns out, Firefox will let you "test" some CA certs as EV authorities, but you have to get your hands on a debugging build. Not only that, but unless you want to maintain a fresh CRL or OCSP server, you'll have to modify the source code. Sounds daunting, but it really isn't too bad. I've documented the whole process here, and I'll summarize in this blog post.

1. Create an EV-SSL Certificate Authority, and make an EV cert. This sounds fancy, but basically means: create a certificate authority, then issue a cert with a specific policy OID. The differences between regular CAs and EV CAs are minimal except in how the browser decides to classify them. In short, this should do the trick:

./CA.pl -newca

openssl req -config ./openssl.cnf -new -keyout newkey.pem \
            -out newreq.pem -days 30

openssl ca -config ./openssl.cnf -policy policy_anything \
           -out newcert.pem -infiles newreq.pem

Details here.

2. Tame Firefox. This involves patching the Firefox source code to perform lazy freshness checks on certificates (and there's a patch for that here), and set it up to accept externally defined EV root authorities (you will list them in a text file). Then you must compile the source in debug mode to enable it. Details here.

3. Install your CA and go. You have to extract the base-64 encoded subject and serial number out of your CA certificate by installing this patch, compiling the NSS tools, and running the pp tool on your root certificate. Once you've got that data, put it, the EV policy OID of your choice, and the CA cert fingerprint in a file called "test_ev_roots.txt". That text file goes in your Firefox profile directory. Once that's set up, you run Firefox, install the root CA as a regular SSL trusted authority, and you're ready to go. Details here.

Summary. It's not impossible to install a root certificate and get Firefox to consider it an EV root, but it is surely difficult (and this is good). The instructions presented in this post are simply summary, and not indended to be details, which can be found here.

Edit: I guess I should explain that EV means Extended validation; basically a more thorough check is performed by a certificate authority before issuing an EV certificate [EV on wikipedia]

ev certs are not so ev

2009-03-25T16:16:00.003-04:00

Last week at CanSecWest, Alex Sotirov and Mike Zusman showed how extended validity (EV) certificates don't really provide much additional help to securing a site with SSL. To sum-up a couple of their conclusions:

1. It's not hard to get a regular cert for an interesting domain.
2. An EV-certified site can load data from any other SSL-encrypted locations, regardless of the cert.
3. Rogue cert + MITM + EV-site = arbitrary attack code execution on EV-site.

It seems to me that the problem is rooted in a slight but pervasive misunderstanding of what EV certs do: they provide a more rigorous check to ensure that the entity serving data through the EV certified channel is actually who they claim to be. They don't currently give proof to a site's visitor that the site has not been compromised.

Having said that, if an attacker can prey on the way the site serves content, it doesn't matter whether or not the EV entity is actually who they claim to be; an attacker can just piggyback on their session, serving some cleverly crafted data with a rogue cert. This can be done by playing man in the middle with third-party content embedded on the EV site, or by playing tricks with the browser's cache.

Easy fix: In order to display the green bar (EV badging) require all the stuff on a web page to be served with the same EV cert. This is not attractive for many reasons, including ad syndication and distributed content serving -- both highly desirable uses may cross the fully-qualified domain border and thus require non-EV certs or multiple different EV certs. (EV certs are not allowed to have wildcard domain matching, so any difference in domain name will cause the cert to be invalid).

A more desirable fix, in my opinion, will take a look at the problem from a base level and figure out why EV breaks in these mixed-content or mixed-cert scenarios--then fix EV. The EV cert says "trust my subject at domain.com." What we really need is a way to say "trust this site."

More to come.

Cheers to Sotirov and Zusman for this excellent discovery and PoC man-in-the-middle script.

where should web policies be enforced?

2009-03-10T13:52:00.000-04:00

I've been spending a lot of time thinking about context-based security decisions lately. These are decisions made on behalf of a website (or its users) in order to maintain data integrity and secrecy. Take for instance the issues of CSRF and Clickjacking; both of these attacks involve some sort of contextual manipulation. CSRF is a HTTP request generated by an untrustworthy source and Clickjacking is data theft by overlaying forms (etc).

There are many approaches to stop these things... but on whose shoulders should the policy enforcement lie? Should a web browser be in charge of making sites safe, or should it just be an enabler that provides enough information to a server so it can make appropriate decisions?

CSRF can be stopped by the browser, but in a fairly convoluted way. It's tough for a web browser to discern which requests will cause a significant transaction on the web server. For example, the simple request

GET /profile/deleteme.do

could be enough to trash someone's account on a server. Even some POST requests don't cause internal state changes (imagine a currency conversion calculator or a POST-based language translator form). It seems a bit easier to stop CSRF on the server where the application itself can decide whether or not to trust each request. This requires the browser, however, to provide some information about the request such as where it came from (but HTTP-Referrer is not reliable) or how it came (such as whether it was from an image tag, etc).

Clickjacking is more easily approached on the client side. One approach is to make an impenetrable fence around certain special frames where any outer/parent frames can't layer stuff on top of their children. This frame-firewall approach is not always attractive, so maybe there should be some mechanism that allows the server to say "hey, this is sensitive, don't overlay this content I'm serving." Then again, maybe it would be ideal to just tell the server a bit about where the content will be rendered, and let the server decide whether or not to serve data.

But what both Clickjacking and CSRF have in common is that they leverage contextual blindness that many web applications have -- they're not aware of where requests come from or where there responses end up.

It seems clear that we can't rely on just a browser-side or server-side fix for these types of things, and instead we need to have some sort of cooperation. The question remains, however, who should do the bulk of the enforcement. I'm currently leaning towards using the browser as a context-revealing tool and leaving enforcement and policy decisions up to the server, but there's many times when that's not enough to stop client-side attacks.

career move

2009-02-25T13:17:00.004-05:00

I have been trying to keep this blog fairly technical, but since I haven't posted anything in a while and I've more or less changed my main focus, I figure it is relevant to post an update.

Recently I completed my Ph.D. and took a position at Mozilla Corporation. I'm going to be working on the security team there to protect the internets. Eventually I'll get back into the groove of posting relevant information to this blog (since I'll keep my focus in the security/computing realm) but it might take me a while to ramp up. In the meantime, thanks to all those nice folks at Mozilla who have been helpful with my move.

lappy goes down

2008-10-02T10:08:00.003-04:00

Yesterday my laptop's hard drive made some funny noises, so I shut the sucker down, and guess what? It wouldn't come back up.

I replaced the drive with a 250GB one (bigger and cheaper than an exact "Death Star" replacement from an Apple dealer), then restored from TimeMachine backup (pretty slick, actually), and am now trying to figure out what is broken.

Fink stopped working, but probably due to me being stupid (found an error in a config file, and easily fixed Fink)

Had to reinstall developer tools.

Needed to perform software update twice before mail worked

Other than that, time machine saved my butt. Now to recreate the last week's worth of work, and to convince myself to do daily backups instead of weekly ones.

tax phish

2008-03-22T17:09:00.003-04:00

Tax Phishing season is open. Go catch yourself a good one!

iphone's ambiguous http-auth

2008-03-10T10:40:00.005-04:00

I'm a little disappointed at Apple. While I think the iPhone is a pretty nice piece of work and their browser is pretty nice too, I don't like the way it handles HTTP-AUTH. (There are other gripes I have, like no "find" feature in safari or the mail app, but we'll stick with a security problem for now). Most browsers are kind enough to display on the "safe" pop-up login box which which website requested the authentication. This is not so with iPhone Safari.

Not only does the pop-up "enter your password" box fill the whole screen (a rather necessary evil), but it doesn't display the domain, URL or any information about the website where you're sending your credentials. If I had some free time, I would hack together a quick demo to show how, using iframes (suitably) or images, I can make you think you're logging into one site but you are actually sending your password to another one entirely. It does indicate whether you are sending your password in the clear or if the connection is secured with TLS/SSL, but in a subtle gray font under the login boxes.

I want to know where my password goes!

Drive-by pharming (really) exists!

2008-01-22T16:42:00.000-05:00

According to my colleague at Symantec, Drive-By Pharming has been spotted in the wild.

Maybe this indicates that attackers read academic papers?

I presented our paper (finally) in China last December. It was pretty fun...

battery woes

2007-12-12T07:33:00.001-05:00

I'm traveling right now and I am taking along my teeny little 12" PowerBook which has been good to me for many years. Only, this time, I upgraded it to Leopard and I think it messed up my battery stuff. (Also, upgrading may not have been a good idea since Leopard heavily uses CoreImage, and this computer doesn't support it. The 12-incher is also the minimum specs for the OS: 867MHz, 640MB RAM, 32MB GeForce 4MX video).

I noticed that it goes to sleep quickly -- say when the battery was drained less than half -- and it charges quickly. This lead me to believe it might be a power management issue, so I rebooted the machine and reset the PMU and PRAM. No luck. Still problems. I decided to "condition" the battery, or drain it all the way and charge it again, but I planned to monitor the battery status with pmset (a mac os x command line utility). Here's it's output:


sid-stamms-powerbook-g4-12:~ sidstamm$ pmset -g pslog
pmset is in logging mode now. Hit ctrl-c to exit.
12/12/07 4:57:20 AM GMT-05:00 
Currently drawing from 'Battery Power'
 -InternalBattery-0 98%; discharging; 10:00 remaining
12/12/07 4:57:24 AM GMT-05:00 
 -InternalBattery-0 97%; discharging; 10:00 remaining
12/12/07 5:05:05 AM GMT-05:00 
 -InternalBattery-0 96%; discharging; 10:00 remaining
12/12/07 5:14:44 AM GMT-05:00 
 -InternalBattery-0 95%; discharging; 10:00 remaining
12/12/07 5:25:30 AM GMT-05:00 
 -InternalBattery-0 94%; discharging; 10:00 remaining
12/12/07 5:34:33 AM GMT-05:00 
 -InternalBattery-0 93%; discharging; 10:00 remaining
12/12/07 5:45:17 AM GMT-05:00 
 -InternalBattery-0 92%; discharging; 10:00 remaining
12/12/07 5:54:55 AM GMT-05:00 
 -InternalBattery-0 91%; discharging; 10:00 remaining
12/12/07 6:03:09 AM GMT-05:00 
 -InternalBattery-0 90%; discharging; 10:00 remaining
12/12/07 6:11:24 AM GMT-05:00 
 -InternalBattery-0 89%; discharging; 10:00 remaining
12/12/07 6:19:20 AM GMT-05:00 
 -InternalBattery-0 88%; discharging; 10:00 remaining
12/12/07 6:20:08 AM GMT-05:00 Sleeping...
12/12/07 6:20:08 AM GMT-05:00 
 -InternalBattery-0 0%; discharging; 0:00 remaining

Notice how it drops into sleep at 88%, and the perceived status drops to zero... I think either this battery is toast, or Leopard destroyed it. (I verified the full/empty statuses by pushing the meter button on the battery itself, watching the LEDs tell me how full it is.)

Anyhow, I'm going to let it try to charge all night, even though it will surely give up. Maybe the Internets will tell me what's going on, or maybe I'll just use it as a portable desktop computer. I'll follow this post up with results from pmset while charging to see what it tells me.

Here's some info from system profiler about the battery as it begins charging:


Battery Information:

  Charge Information:
  Charge remaining (mAh): 177
  Charging: Yes
  Full charge capacity (mAh): 20494
  Health Information:
  Cycle count: 294
  Battery Installed: Yes
  Amperage (mA): 2079
  Voltage (mV): 12250

drive-by pharming (kind-of) exists!

2007-11-01T17:03:00.000-04:00

TidBITS is reporting a Mac OS X Trojan that masquerades as a QuickTime codec; the idea is that people are told to install this codec to view a sketchy video on the web, then when they do, the "codec" actually manipulates their computer's DNS settings. Very reminiscent of drive-by pharming, but more obvious than a simple CSRF.

Link to more drive-by pharming info.

expensive ice

2007-09-28T17:27:00.000-04:00

I have a math problem:

Assume both 1) and 2) are 16 ounce beverages.

1) hot coffee = $1.80
2) iced coffee = $2.30

Let me rephrase:

1) coffee + paper cup = $1.80
2) coffee + plastic cup + ice = $2.30

This means that

plastic cup + ice - paper cup = $2.30 - $1.80 = $0.50

In English, the cost of ice and the cost of using a plastic cup instead of paper is $0.50. But wait, there's more: there is less coffee in the iced coffee since ice replaces roughly 50% of it!

Okay, so this means:

1) 1.0*coffee + paper cup = $1.80
2) 0.5*coffee + plastic cup + ice = $2.30

Thus:

plastic cup + ice = $0.50 + 0.5*coffee

Lets go out on a limb and say that the paper cup costs $0.80, which is probably an extreme upper bound. This makes the equations a bit easier:

1) 1.0*coffee + $0.80 = $1.80 :: 1.0*coffee = $1.00
2) 0.5*coffee + plastic cup + ice = $2.30
:: $0.50 + plastic cup + ice = $2.30
:: plastic cup + ice = $1.80

This is friggin' ridiculous. There's no way that a cup costs more than a dollar, you can get a pack of 1000 of the exact cup I'm drinking from for $120; that's twelve cents each. That means that the ice must cost $1.68!!! There's no way it costs that much to make ice, especially when you use it in frappés all day and make it in bulk.

I hope the owner of Java Haute reads this.

celebrity

2007-06-30T22:08:00.000-04:00

This is a random mood construction I wrote after biking along the bay...

The wind tore through the land, causing the million golden, fibers of grass to murmur in gossip. Seagulls hung lazily in the air, craning their necks into the wind, attempting to get ahead of the others. The water rippled, insistently swimming in circles, consuming the algae on the rock-lumped shore.

The hills in the distance slouched in their balcony seats, squinting at the sun as it hung low in the west. The slouching was necessary to avoid the cheese-slice railing of the power lines, long wires segregating the hazy picture into sea and sky.

Alongside the insistent murmurs of the whispering grass stalks, an asphalt carpet rolled out, marking a path for celebrities and holding back the landscape from getting in the way. This swervy pavementrain conducts many elite passengers between venues, allowing a voyeuristic view into the dangerous wild; a view without the bane of submitting to the whispering mass of conspiracy amidst the shores of the bay.

And then: the paparazzi.

small victory for privacy

2007-06-21T14:04:00.000-04:00

"A U.S. appeals court in Ohio has ruled that e-mail messages stored on Internet servers are protected by the Constitution as are telephone conversations and that a federal law permitting warrantless secret searches of e-mail violates the Fourth Amendment."

"ISPs, the ruling states, have 'mere custody' over the e-mail and subpoenaing them 'is insufficient to trump the Fourth Amendment warrant requirement.'"

"[David Rivkin] said that, even given the expectation of privacy, the context of the effort to access the data -- whether it was part of a criminal case or an intelligence-gathering effort, for instance -- had to be considered."

Link

id theif pursuit

2007-06-15T12:03:00.000-04:00

The San Francisco Chronicle published an article about an ID-theft victim chasing her ID's thief. The story reads like a great chase scene in a novel! The victim chases the thief for about forty-five minutes through down-town San Francisco.

She didn't really know what she would do if she caught Nelson. "She was a big girl," Lodrick recalled. She told the 911 operator she felt a little scared. The operator said: "If you in any way feel threatened, do not continue the pursuit."

Lodrick told the operator: "No, I'm OK."

San Francisco Chronicle Article

the internet is a reflection of self

2007-06-05T15:34:00.000-04:00

"The Internet, this place intended for sharing information, has become a place where we go to confirm beliefs we already have."
(on "I read it on the Internet")

"I'm not suggesting we put anonymous bloggers, or anonymous posters in jail..."
(on improving accountability online by jailing originators of anonymous data)

-- Andrew Keen