Silverglass Technical

Future plans for Silverglass

2011-10-19T09:06:00.000-07:00

I've got two general plans. One is to move a chunk of the site over to Google Sites as a short-term measure. XMission's done a good job of hosting the web site and e-mail, but I'm wanting to do things I can't do on their service. I want to run my own e-mail server, for instance, so I can provide service to a few friends. I want an external shell server, and I want a Web server I can set up to host other domains if I want to. I need my own host under my control for all that. The problem is I can't set all of that up overnight, so I need a temporary place to hold the web site while I sort out all the rest.

Long-term I want to set up CMS and website-editing software that'll let me do a lot more with the site without having to mess with editing HTML directly, and move the site completely onto my own server. Google Sites is nice for content, but I can't run custom back-end applications on it. I've got a few webapps I want to play with, and I need a server I can run them on. I may start by keeping the text portion on Google Sites and using my own server only for the webapps, but long term I want to be self-sufficient. The trick will be to find software that lets me create page templates and fill in just the content without limiting me to only doing that. Oh, and a model that lets me create/edit everything locally and publish to the site only when it's all correct is a must. Live editing of the site is a no-no.

PC vs. post-PC

2011-08-22T23:03:00.001-07:00

To me the whole argument doesn't make sense. The world simply isn't going to dump what we consider the PC, it's just too useful. To me the argument boils down to one of form factor vs. usage:

Desktop. A standard large-case PC with a separate keyboard, mouse and monitor. It's advantage is, to quote Tim Allen, "MORE POWER!". It can run pretty much the most powerful CPUs around full-bore constantly without overheating. It doesn't worry about draining a battery. It can have a lot of screen real-estate with multiple large monitors. It can have a full-sized keyboard and mouse. It's got lots of relatively fast local storage, and continuous network access. It's nailed down to a single location and tethered to the network via a wire, which makes securing it easy. And while that's also it's biggest downside, the spot it's at is also where most of an office worker's work is anyway. It's most useful when you've got a lot of text to type, data to enter, output to view. It's, quite bluntly, the full-sized pickup truck or van of the computer world.

Notebook. Not the ultra-light, the totable one you carry around in a bag. You plop it down on a table, plug it in to power and maybe a network jack, and you're good to go. It's got a smaller keyboard, mouse and display than a desktop, and not as much horsepower under the hood, but it's ideal when you need something you can plop down anywhere but not something you have to constantly carry around. Think a businessman at a hotel, or someone out at a customer site for the afternoon. It's literally a portable substitute for the desktop, not a mobile device.

Netbook. This is the ultra-light. It's small, low-powered and easy to carry. Ideal for when you need to do some stuff that involves a keyboard but need something you can carry around all the time. It's what you might take to the coffee shop when you expected to be doing some IMing or light typing, but didn't expect to be typing page after page. Typically has a wireless network interface, and connectivity is assumed to be intermittent.

Tablet. Something from about the size of a paperback book up to a clipboard. No keyboard, no mouse, it's based around a touchscreen interface. You aren't going to be doing a lot of typing of text on this, the interface just isn't suited to it. But you can browse the Web easily, and deal handily with applications that involve selecting things from what's displayed on the screen. It's network interface is wireless, and it can't assume a constant network connection. Great for a lot of floor work like taking inventory, and times when you need to view the Web but not enter a lot of data.

Smartphone. Sizes up to about the size of a paperback book. It's mostly a scaled-down version of a tablet, the much smaller screen size being the big distinguishing feature. Where a tablet might be able to get away with the same sort of presentation you'd see on a notebook or desktop system, there's no way that works here. The other big difference is that, since it's expected to be connected to a cel phone network, it assumes a more constant network connection. It may take advantage of a wireless network if one's available, but if no it's still got a data connection through the cel network. Where a tablet's used to a greater degree for processing data and doing things, the smartphone form factor's used more for communication. Voice, video, IM, it's a pocket-sized device for talking to other people that oh, by the way, can also display data. A tablet, OTOH, is a device that displays and lets you manipulate data and oh, by the way, can also probably be used as a phone.

You can see how different the various categories are in terms of what people do with them. I think people don't want a replacement for the standard desktop PC, unless it's to replace it with a laptop that can accept attaching a larger monitor and a better keyboard and mouse for desktop use. And even then a lot of people would wonder why bother, since they don't want to take their desktop home with them. They either want something else instead of the desktop, because they don't do the things a desktop is good at and spend all their time doing things the netbook, tablet or smartphone form factors are good at, or they want those other form factors as an adjunct to the desktop with data shared between the various units. In large part what they want is the way Google services work: I can tie my Google address book and calendar into my e-mail program and when I update a contact there or through the Web interface the changes automatically show up on my phone, and vice-versa. If I change a document on the tablet, I want to see the changed version on my desktop system. I may want to make up my grocery list using a tablet as I check the cupboards and freezer for what we're out of, and then be able to call up that shopping list on the pocket-sized smartphone while I'm shopping and all I'm doing is scrolling through the list and marking things off as I get them (I could carry the tablet along, but it's a little big to fit in a pocket conveniently).

But in the end, I don't expect people will give up their big desktop systems for things like gaming or typing long documents or working with large spreadsheets or all the other stuff you do at the office. And I sure don't see PC gamers giving up their systems, there's just too much stuff you can do with a full keyboard and mouse that console games don't have the input devices to match. We'll be in a post-PC world in the same way IT is in a post-mainframe or post-COBOL world, or the way computers have led us into a post-paper world, or the way nuclear reactors and solar power have led us into a post-steam-boiler world. Oh, that's right, nuclear reactors and most large-scale solar farms just... boil water using a new heat source. Mainframes and COBOL are still firmly entrenched. And paper, well, "It's the 21st century. Where's my paperless office?". I don't expect "post-PC" to be any different. We'll add new devices and new capabilities, and the PC will adapt to work with them without ever disappearing (or even becoming less of a central player).

Google+ (and other social-media sites) privacy issues

2011-08-12T19:20:00.000-07:00

A lot's been said about the privacy issues of Google+. I'd note that there's a flip side, too. Robert Heinlein pointed out that one of the best ways to lie is to tell the truth, but not all of it. Sites like Facebook and Google+ can be turned around and used to lay down the trail you want other people to find. It doesn't have to be a complete trail, just convincing. When someone goes looking, they'll find the trail you want them to find. And since they have found a trail, often they won't go looking for other trails. And if they do and you catch them at it, you have a good case for harassment against them. After all, they'll have to admit that they did find the data on you, and that it all pointed to completely uninteresting places and results, and exactly what evidence do they have that there's anything more? None.

It's a piece of advice for the Evil Overlord's Accountant: keep 4 sets of books. The first set contains records that are completely and utterly clean and prove that the Evil Overlord is a saint and completely and utterly above suspicion of even littering. The second set, which you reluctantly let investigators find if they aren't buying the first set, contains records that match up with the totals for the first set but have some transactions that, while they appear illegal at first glance, turn out upon further investigation to be merely shady and embarrassing but completely legal. Any investigators will probably have stirred up some trouble with their efforts to uncover this second set, and after getting all excited about their initial findings will likely have egg on their faces after it all turned into duds on them, and their superiors will be more than happy to just drop the investigation before they're embarrassed any further.

Apply this tactic with social networks. If you have things to hide, set things up so you're easy to find and lay down a nice innocuous trail using those profiles. Then quietly do anything you don't want people finding out about under alternate identities that don't have any connection to your public profile. After all, it's easy on even Google+ to set up a profile under a fictitious name, as long as the name itself doesn't draw attention and you're discrete about what information you fill in. Just remember that these sites record IP addresses, so use some form of proxy to avoid linking profiles by "they're accessed from the same computer".

Google+ real-name issue

2011-07-27T14:12:00.000-07:00

I can see the arguments on both sides, and they aren't mutually incompatible.

People want to be anonymous. They want to eg. criticize corporations and governments without necessarily opening themselves up to having government agents showing up at their workplace, or corporate lawyers contacting their employer. More innocuously, they want to have a private side of their life that isn't mixed up with their work and professional life.

Other people want continuity of identity. They want to know that when a given name speaks it's the same person, and that a single person can't trivially have a multitude of identities and turn themselves into a virtual crowd that can drown everyone else out or create the illusion of popular support for a position that lacks such support.

Google wants things tied to a single identity, so they can link activities to individual users in a coherent manner. They want to know what your search history is so they can correctly determine what's popular and what's not.

This can in large part be done by disconnecting your profile from your account. Your account gets verified, making it possible but non-trivial to create multiple accounts. Only Google gets to see your account. You can then create one or more profiles linked to that account. The profile can have any name you want, any other information you want, and the information doesn't need to match from profile to profile. They all tie back to the account so Google can audit and track things, but that link's invisible to the public. If someone thinks you're creating sock-puppet profiles, they can file a complaint and Google can verify whether the profiles are all linked to the same account or not without needing to let the world see the link. People can be assured that a given profile belongs to the same person over time, and a name can build up a reputation without people needing to know the exact person behind the name. The profile's identified by a unique identifier like a profile ID, not by the name, so you can see if a different profile's trying to masquerade as an established name. Most everybody's requirements are met.

The problem comes with anonymity. That depends entirely on Google's willingness (and legal ability) to say to someone showing up demanding the account information behind a profile "Do you have a court order? No? Then come back when you have one.". And that in turn depends on a more basic legal/political issue: requiring someone to show that the person behind the identity has in fact done something actionable before being allowed to demand their identity so legal action can commence. To me that sounds reasonable, and in fact the law technically requires charges to be supported before they can even be filed, but in practice the courts seem reluctant to tell a plaintiff or prosecutor "You haven't supported your charges. Go away until you can.". That's a political problem, one that needs addressed by pressuring the politicians to state explicitly that plaintiffs and prosecutors aren't allowed to file charges or commence legal action without solid evidence to support the claims already being on the table. Until that happens there's no way to both allow anonymity and be able to hold bad actors responsible for their actions, and you can't have a civilized environment without both of those.

Microsoft dumping .Net for HTML5/Javascript

2011-06-12T14:26:00.001-07:00

Mike James wrote a blog entry about this. My immediate thought: what did you expect? Microsoft sets their roadmap based on their business needs and what'll benefit them, not what'll benefit their developers. And Microsoft is focused on one thing: insuring that Microsoft controls everything. When they think "cross-platform", they mean "across all Microsoft platforms". They want it to be easy to have apps run on all their platforms, from desktops to phones, and to be as hard as possible to make those things run on any other platform. If things do run on other platforms, they want to insure that Microsoft is a required part of the infrastructure anyway.

C# and .Net and Silverlight are problematic for Microsoft because they can run on other platforms, and when they do other Microsoft products and platforms aren't required. It's not easy but the Mono project has demonstrated that you can create a C# compiler and .Net runtime for Linux, and once it exists for Linux it's a lot easier to port it to any other Unix variant. Silverlight will likely fall into the same category. But HTML5/JS has one big advantage: it's limited enough that you can't create an entire complex application in it. You can do the UI part, but you're going to need a back-end to handle things that just can't be done in Javascript. Microsoft's hope is to use the standardized nature of HTML5/JS to sell management by making sure the "standards-compliant" checkbox is checked, while doing some things under the hood and in the client/server communication with the back-end to insure that you'll need a Windows system in the mix to successfully run one of their new apps. Think back to ASP and how it got tied into IE-specific bits of Javascript and HTML to the point where it was hard to make ASP webapps work right anywhere but in IE. How successful Microsoft will be with this is up in the air, but I think their goal is what it's always been: to make sure it's Microsoft and Windows everywhere, for everything, to the exclusion of everything and everyone else.

As a developer, make no mistake: Microsoft does not care about you. You are important only insofar as you buying into their roadmap is needed for it to succeed. Once that's no longer needed you're at best unnecessary and at worst competition to be eliminated (every sale of software you write is the loss of a sale of something Microsoft wrote or could write, and you selling your software at the expense of Microsoft doesn't benefit Microsoft).

Sony PSN compromise

2011-04-28T11:45:00.000-07:00

We've all seen the news about Sony's PlayStation Network being compromised. It's bad enough the bad guys got personal information. It's worse that they got credit-card numbers. But it's downright unbelievable that they got passwords!

OK, first off: users are partly to blame. You shouldn't be sharing passwords between services. Whatever password you used for PSN shouldn't be used elsewhere.

But that doesn't excuse Sony. The passwords should never have been stored on the servers. Unix has handled that for years. It doesn't store your password, it stores a one-way cryptographic hash of your password. Remember that it doesn't need to know your password, it only needs to confirm that you know your password. So instead of storing your password it runs it through a cryptographic hash algorithm and stores the result. When you enter your password, it runs what you entered through the same algorithm and compares the result to the stored value. If you entered the right password, the two will match. If they don't, you didn't enter the right password. If you chose a strong algorithm it won't be feasible to take the stored hash value and reverse the process to get the original password, and there's no reason not to choose a strong (SHA-1 or better) algorithm since there's plenty of easy-to-use cryptography libraries out there (many of the best don't even cost money).

And credit-card numbers? In this day and age we should be able to do better verification of credit cards. Check ID for in-store purchases, for instance. But most fraud is on-line, you say? We can still do better. Requiring the CVV2 for all non-recurring purchases, for instance. Or linking your cel phone number to your credit card and using text messages to confirm the purchase. When a non-CVV2 charge is attempted, you get a text from the card issuer with details. You then have to text a charge ID code plus an authorization code (CVV2 or other set value) back to confirm the charge. No confirmation = charge declined. Now to make a fraudulent charge the bad guys not only need to get your card number, they need to clone your cel phone which means they need to know your cel phone number, SIM serial number and IMEI and they have to set up actual hardware. These guys operate wholesale, adding the time to do that work makes an 80-90% dent in the number of transactions they can run which pretty much hoses their business model.

Or better yet, for recurring payments go to a "push" or customer-originated payment system. So for PSN, instead of giving them your credit-card number and letting them initiate charges, PSN gives you a merchant account ID and transaction code. You go to your bank (or more likely to their Web site) and set up a payment to that merchant account for the amount required, using the transaction code as a reference number. Your bank then sends the money to PSN's account. End of most existing types of credit-card fraud, because merchants don't need to know any payment information anymore. The only thing you'd need a normal merchant-initiated charge for is over-the-phone purchases, and even then if you've got a cel phone the verification process above's possible.

So why are we still doing things the old-fashioned, fraud-prone way?

ASP.Net ViewState

2011-04-04T14:48:00.001-07:00

Really really dumb idea: using a complex, high-overhead ViewState mechanism to set field values in the Web page returned from posting a form instead of simply setting the field values in the returned page. I mean, the posted page has the values populated, that's it's whole purpose. So when generating the response page, simply set the value attributes to what the fields' values were in the post request. Simple, no? Apparently not for Microsoft.

California stores can't store your ZIP code

2011-02-11T10:22:00.001-08:00

A ruling came down from the California Supreme Court that's eminently sensible: your ZIP code constitutes personally identifiable information that can be used in conjunction with your name to determine where you live and exactly who you are, and California merchants aren't allowed to keep it on file. To me this is eminently sensible.

Now, the reporting on CNN is a bit hysterical. The reporting says retailers can't ask for your ZIP code. The ruling, OTOH, says explicitly that retailers can ask for it and use it in conjunction with authorizing your credit card, and notes that this is what the law explicitly says and not their interpretation. It's the recording of the ZIP code for uses other than authorizing a credit-card transaction that the law and this ruling prohibit. This ruling doesn't do a thing to compromise transaction security or identify verification. All it does is remind retailers (and the lower courts) that yes the law really does prohibit a retailer from building a database of consumers and their buying habits without the explicit consent of the consumer. I know retailers don't like that, but them's the breaks. Consumers don't like retailers doing it, and there's no particular reason businesses should always get their way regardless of how their customers feel. Businesses always say that if consumers don't like practices they always have the option of not patronizing those businesses. Well, if businesses don't like California's practices they always have the option of not doing business in California, no? Sauce for the goose is sauce for the gander.

PS3 root signing key revealed

2011-01-03T12:13:00.001-08:00

Apparently GeoHot has found and published the root key used by the Playstation 3 to sign and verify games. Not just the public key used for verification, mind you, which is the easy part. They've published the private key used to sign the game executables. With the private key, you can sign your own executables and they'll be accepted by the PS3 without needing any hacks, kludges or bug exploits. This is a big deal because the key's pretty firmly embedded in the hardware itself. A simple new firmware update can't change it. And if new hardware doesn't accept the old key, then all existing games simply won't play on the new hardware.

Frankly I don't see why the console makers are so bent on keeping anything but their approved software from running on the consoles. It makes no sense. Someone who wants to run, say, Linux on the PS3 still has to buy the full-blown PS3 console, there's no way around paying Sony for that. They may not buy any games if all they're interested in is running Linux, but then if they couldn't run Linux they wouldn't be buying those games either, nor would they be buying the PS3. They might use this ability to cheat at single-player games, but what's that hurt? They're still buying the PS3 and still buying the games, and there's nobody else to be affected by their cheating. Multi-player games... hacked games might be an issue, except that those games already have lots of ways of detecting cheating on the server side where it's safe from user intervention. For instance, to prevent target hacks simply don't send the client information about objects it can't see. Not even the best hack can target what doesn't exist.

Browser behavior

2010-12-19T14:28:00.001-08:00

We've already got controls in the browser to do things like reject attempts to set third-party (not belonging to the domain of the Web site you're visiting) cookies. I think we need to extend this idea further to make more behaviors dependent on the first-party vs. third-party distinction:

Allow sending of cookies to the site you're visiting while not sending cookies in requests for third-party content. Eg. Facebook's cookies get sent when you're visiting Facebook itself, but if you're visiting CNN's Web site then when fetching the Facebook Like button on thier page Facebook cookies are not sent.
Allow Javascript to run when it's fetched from the same domain as the site you're visiting, but not allow it to run when it's being fetched from a different domain.
Allow image blocking to block only third-party images.
In all cases where there's a block-list in the browser, allow for three settings: allow always, allow first-person only (block third-person), and block always.

IPv4 address pool draining fast

2010-11-30T17:10:00.001-08:00

We're down to just seven /8 netblocks left. Those are the blocks assigned to the Regional Internet Registries (RIRs) who hand out blocks of addresses to entities needing to connect to the Internet. That means we've got effectively 2 blocks left, since when it hits 5 unallocated blocks each of the 5 RIRs will automatically get one of those 5. That'll exhaust the pool of addresses ICANN can allocate to RIRs.

That won't mean too much immediately. The RIRs have unassigned space they can keep handing out. But they won't be able to go to ICANN to get more blocks. That means that when they assign their last space, that's it. Finished. No more. You want on the Internet? Sorry, no addresses left the RIR can give you. It won't be a big cliff, but gradually there'll be more and more problems. Hosting centers won't be able to add more machines because they don't have addresses to give them and can't get any. Consumer ISPs will have problems signing up subscribers because all the addresses available in that area are in use and the ISP can't get more address space. I figure it'll take about 6 months to a year to really come to a head.

Me, I'm going to finish prepping my LAN and gateway for full IPv6 capability and setting things up to run IPv6 internally in parallel with IPv4. That way I'll be ready for the inevitable switch to IPv6 by Cox. And I'm going to make sure any routers I buy will handle IPv6.

And I really ought to work out how to load custom firmware into Netgear routers and access points. I've things I want to do with them.

Another reason to avoid the Windows Phone 7

2010-11-14T15:21:00.001-08:00

Apparently the OS on Windows Phone 7 permanently modifies SD cards. Now, bear in mind that the card slot involved isn't an externally-accessible one, it's under the battery like the socket for the SIM card and you can't readily swap SD cards in and out of it. I suspect it's meant to offer carriers expanded storage for stuff that the user can't mess with or replace/upgrade themselves (if the carrier does things right). But it does bring up one point: Windows Phone 7 devices won't have an SD card slot users can swap cards in. No more dumping your files onto a card and reading them into another phone. No taking the card with phone files over to the computer and reading them in. No external backup of data. No external swappable storage period. To me that's a good reason to avoid those phones. I'd stick with an Android or other smartphone, where I've got the option of external storage.

URL shortener problem

2010-10-07T11:11:00.001-07:00

If you use Twitter, you're probably familiar with the bit.ly URL shortener service. Even if you don't, you're probably familiar with TinyURL, bit.ly, vb.ly or other URL shortener services. They seem convenient. No more having to type or remember long URLs, just create a short one. No problem.

Until vb.ly went off the air. The domain was siezed by the Libyan registrar that controls the .ly hierarchy, because content at the locations pointed to by vb.ly violated Libyan morality laws.

This is why URL shorteners are a bad idea. They create URLs that are under the control of a third party and which can be disrupted at any time. Since there's no direct mention of where the shortened URL points, once disruption happens it's impossible to locate the original destination. If you use the actual full URL, disruption can only occur if the actual site referred to is taken off-line.

Note also that this is why you should make your own copy of content if you really care about having it available. If you merely link to it, it's vulnerable to the destination taking it down or just changing what it says. Only when you control the copy can you insure that it doesn't change or become unavailable in the future. This may annoy copyright holders, however I feel that if I'm writing commentary on what someone said then making a copy to insure I can prove they did in fact say what I claim they said falls under fair use, and making a complete copy is neccesary to show that I'm not merely cherry-picking and taking bits out of context to misrepresent what was actually said and so also falls under fair use.

DNS root zone is now signed

2010-07-17T01:54:00.001-07:00

The DNS root zone is now signed via DNSSEC. The idea behind DNSSEC is that the owner of a zone (roughly a domain) generates a public key and their DNS servers will digitally sign the records they serve up. Intermediate DNS servers will preserve those signatures, allowing querying machines to determine whether the records have been altered from what the authoritative nameserver sent. This makes it a lot harder to do a man-in-the-middle attack against DNS, hijacking a caching nameserver (say one belonging to an ISP) in order to re-route traffic to an attacker's servers. Not impossible, but it's a lot more involved. That's because the public key needed to verify a signature is returned from the zone above the signed zone and is signed by that zone, eg. the public key for silverglass.org's records is returned from the .org zone's server and the key for the .org zone is returned by the root nameservers. So for an attacker to forge silverglass.org records, he has to subvert the entire chain back to the root. Each verifying machine has the single key for the root zone pre-loaded (and presumably verified out-of-band to make sure it's valid), so it's infeasible to fake signatures on records for the TLDs (eg. .com, .org, .us). If I can control the records returned for .org queries I can substitute my key for silverglass.org's, allowing me to forge signatures on silverglass.org records. But since I can't substitute my key for the root key I can't fake signatures of the .org records containing the silverglass.org key, and any verifying server will detect my forgery.

That's great for security, but it poses a problem for some (IMO unethical) ISPs and DNS providers like Network Solutions. That's because they've been playing a game: when someone asks for a domain that doesn't exist, instead of returning NXDOMAIN (non-existent domain) for the query they've returned a valid result for the name pointing at their servers which serve up advertising, search results and the like. Essentially they take ownership of every single invalid domain and slap their advertisements on it. But as soon as downstream DNS servers (eg. the ones in every home router) start verifying DNSSEC signatures, the gravy train ends because those ISPs and DNS providers have no way of forging valid signatures. The only exception is that the registry operator can forge results for completely unowned domains within it's scope, and the most common DNS software around has a flag to stop that (TLD servers are expected to only delegate to 2LD servers, they should never return actual results so any results they try to return must be faked and should be treated as NXDOMAIN).

Cloud storage-as-a-service

2010-07-12T15:10:00.001-07:00

Triggered by an article by Phil Jaenke.

You probably saw the announcement about EMC's Atmos Online shutting down. ArsTechnica had an article about it too. The short and sweet: if you were using Atmos Online directly, they aren't guaranteeing anything (including you being able to get your data back out). If you're an enterprise thinking about cloud storage as an alternative to maintaining expensive disk and/or tape in-house to hold all your archival data, this gives you something to think about.

Now, frankly, you should've been thinking about this anyway from the moment you started thinking about contracting with a vendor to store your data. Putting the magic word "cloud" in the name doesn't change the basic fact: you're putting your data in someone else's hands. When you do that you always, always account for things like "How do I get my data back from them?", "What happens if their facilities suffer damage?" and "What happens if they decide to shut down?". And you don't depend entirely on contract terms and penalties. Knowing that you can take your vendor to court and force them to pay up eventually, maybe, assuming they haven't declared bankruptcy, doesn't get you the archival data you need, and the IRS and the financial auditors and the rest won't really care whose fault it is that you can't get at data you're legally required to have available because it's your responsibility regardless.

There's also another question: how about security and privacy? Yes, against hackers attacking your supplier's network, but not just against them. What happens when your supplier gets served with a court order demanding they turn over your data to the other party in a lawsuit you're involved in? Some of that data might be e-mails between you and your legal department or outside attorneys, and reasonably subject to attorney-client privilege. But your attorneys won't get a chance to review anything before it's turned over, because you won't know it's been turned over until after the fact. How does your supplier handle this kind of situation? What steps are you taking to insure that you can't be bypassed when it comes to getting at your data?

So when IT or management asks about cloud storage, make them answer those sorts of questions first. Or at least make them think about those sorts of questions.

Oh, and the service Phil wrote about? Notice that it uses standard NAS protocols to talk to it's device, and standard formats for the stored data. That makes the question of "How do I get my data back?" a lot easier to answer.

In re Bilski

2010-06-26T16:48:00.001-07:00

Monday is the last day for Supreme Court rulings to issue for this term. So far, no opinion in In re Bilski, the major patent case this term, has come down. Some people are thinking that it'll have to come down Monday, because the Court won't want it to hold over into the next term. PatentlyO makes that argument. They also make the argument that it'd be better for the appellant here to drop the case before the ruling issues, and that the only reason for the appellant to pursue the case is that they want business-method patents to suffer a setback. I think Crouch is wrong, Bilski is appealing only because it's the only way to overcome the setbacks they've suffered thus far (see the documents on the case at Groklaw).

Crouch does make an interesting point, though, and one that gives hope that the Court will uphold the denial of the Bilski patent and, by extension, support the Patent Office's new position that purely abstract things like business methods aren't patentable. That's that Monday is Justice Stevens' last day on the Court. He's also the only Justice who's short on delivered opinions, if he's writing the Bilski opinion it'd bring him right into line with the other Justices. If that's so, Stevens also has a track record in opposition to things like patents on abstract ideas and non-physical things. If he's writing the opinion, it's likely because the opinion was in line with his track record and not favorable to Bilski. This'd be good news for software developers. These days one major problem in software development are patents that are over-broad and vague, with their holders trying to apply them to everything in sight. Or patents on blatantly obvious or long-existing things like a shopping cart (but in a Web browser!). Between Bilski and KSR v. Teleflex, the courts and the USPTO have given opponents of over-broad patentability a lot of ammo. That's also another point in favor of the Court upholding the appeals court in Bilski, that'd be in line with it's thinking in KSR.

The alternative, of course, is that the Court decided to give Stevens a light load because he's retiring and the Bilski opinion will be held over for next term. But we can hope that's not the case.

Tablets, netbooks, laptops and PCs

2010-06-21T11:14:00.001-07:00

Forrester Research is predicting iPad sales will tank. I'm not sure about that. In fact I think Forrester is dead wrong. Here's my predictions:

Tablets will displace netbooks as lightweight mobile platforms. On their own they're lighter and slimmer than netbooks and work well for media playing, Web browsing and the like. Attach a lightweight Bluetooth keyboard and they're OK for light text entry without needing too many accessories hauled along. And mobile devices like tablets will show high sales because they tend to be replaced relatively often (mostly because they're sold through cel-phone services with 2-year contracts and hardware upgrade offers just before the contract expires to tempt you into renewing).
Laptops will keep on being the portable computing solution. You won't take them to the coffee shop, but a single bag's easy enough to haul to a hotel or on a trip where you can set up on a desk. They'll show sales growth but not as much as mobile devices, because the wear and tear on the hardware's greater and you tend to have to replace them every 3-5 years because they're breaking down. And if not, you're seeing big increases in capability (bigger hard drives, larger displayes, lower weights) that make a replacement attractive.
Traditional desktop PCs will continue to be a non-growth sector. Everybody who wants one already has one, and they only replace it when it stops working. CPUs and such are already fast enough for ordinary stuff, so there's no real push to upgrade the hardware. When it comes right down to it, though, desktops offer speed, display quality, keyboard quality, peripherals and security/safety that mobile devices lack. Desktops nailed down to a wired network aren't vulnerable to outsiders sniffing traffic. They can support bigger displays, because those displays are sitting on a nice solid desk and don't have to be carried around, and those bigger displays make for more comfortable reading of what's on them. But you don't buy a new desktop every 2 years, you replace them maybe every 5-8 years when they finally do start to break down.

Names

2010-06-17T23:26:00.001-07:00

Yes, names. And the computer systems that handle them. If you write computer programs that handle people's names, read this blog post. Then read this article. Then go back and check your programs for how many of the assumptions in the article they make. Yes, all of those assumptions are invalid. Yes, you will have someone breaking them. Many someones. You'll have more people than you expect using your system. Think about this: right now if something occurs for one person in a million, you can expect more than 300 of them in the United States alone (307 as of July 2009).

And yes, someone out there undoubtedly has in fact legally changed their name to "Robert'); DROP TABLE users" just to be a prat. Your systems should be able to handle him in a suitably boring manner automatically, without needing special coding for SQL injection.

Inertial mass != gravitational mass

2010-06-14T14:52:00.001-07:00

One principle of modern physics is that inertial and gravitational mass are equivalent: it doesn't matter whether you're standing on the surface of an object with enough mass to provide a gravitational pull of 1g or on a flat surface being accelerated at 32 ft/sec², the effects of both frames on you is the same.

Well, it turns out that isn't really so. The paper's rather technical, but it turns out at the quantum level you can get things that behave as if they had different masses depending on whether you're looking at gravitational or inertial forces acting on them. This should lead to some interesting physics in the next few years.

Title I, Title II

2010-05-05T18:10:00.000-07:00

Well, the broadband Internet providers may have gotten their wish, and it'll be ashes in their mouths. A while back, Comcast won a legal victory when they got a ruling saying that the FCC didn't have any authority under Title I to regulate them (and specifically their throttling and shaping of bandwidth based on content and the destination the user was trying to get to).

Well, that's all well and good, except that there's this other part of the relevant law known as Title II. Title I applies to information services. Title II applies to telecommunications services. And the FCC has specific legal authority to decide which one Internet service providers fall under. So the FCC's going to simply shrug it's shoulders and reclassify Internet service as a telecommunications service (as it was back before the Bush era's reclassification of it) falling under Title II. That gives them plenty of authority to impose all sorts of regulations the ISPs don't like, although the FCC's proposing putting in place some binding rules limiting the amount of regulation actually imposed.

Advice: don't taunt the bull if you don't want to get the horns.

.xxx domain argued for

2010-05-05T09:23:00.001-07:00

ICM Registry, which has submitted the .xxx TLD for approval, is pushing for it's approval and adoption. The argument is that parents can then filter out that domain to block inappropriate content.

Yes, well, I suppose that'll work just as well as RFC 3514 - The Security Flag in the IPv4 Header, better known as the Evil Bit.

Floating-point math

2010-05-02T13:30:00.001-07:00

Most programmers don't get it right. They forget that floating-point numbers aren't precise, and that different numbers are irrational in base 2 than in base 10. End result: math errors and weird results.

So, on the web: a basic guide to floating point math.

And for the true math geeks: David Goldberg's paper on floating-point math, and the original ACM journal article if you have an ACM account with library access.

Signs you're abusing SOAP

2010-04-29T13:31:00.000-07:00

Big red flag that you either don't know how to use SOAP or that you shouldn't be using SOAP for this job:

The only argument your call takes is a string, which contains XML which holds the structured data the server needs.

You should be either creating a SOAP object tree corresponding to the XML structure and passing your data as SOAP structured data, or you should be removing SOAP entirely and using simple HTTP POST.

Quake 2 in HTML5

2010-04-02T13:33:00.000-07:00

OK, this just takes the cake. They've ported Quake 2 into HTML5 using a ton of JavaScript and such. Details on the developer's web site. I am amazed.

SCO v. Novell: stick a fork in them, they're done

2010-03-30T15:51:00.000-07:00

It's official: the jury ruled in SCO v. Novell that Novell owns the copyrights that SCO was trying to claim. That pretty much puts paid to all of SCO's dreams of a litigation-lottery win in the IBM case too. IBM's not inclined to settle, and pretty much all that's left is IBM's counterclaims against SCO. SCO has a few scraps of claim left, but all the evidence they're presented put together doesn't amount to enough to make a porn starlet's bikini.

Here's the actual jury verdict form.

eBooks and book sales

2010-03-05T13:16:00.001-08:00

There's been a long-running argument about whether making eBooks freely available without DRM or anything like that helps or hurts sales of physical copies of the book. The DRM proponents have usually argued that the people saying freely-available eBooks help sales are depending entirely on anecdotes that don't prove anything. Well, end of that argument. A pair of graduate students at the University of Michigan did a detailed study of 41 titles that were released as eBooks, looking at their sales figures pre- and post-eBook release. In most cases, an eBook release meant increased post-release sales of the books. The exception was Tor's release, which dramatically demonstrates the problems with restrictive eBook releases. Tor made the eBook versions available for only one week, required registration before you could download and generally made it annoying to get the eBook version. This group of books suffered a significant drop in sales, while the other 3 groups studied showed significant increases in sales.

Publishers take note.

SCO v. world in a nutshell

2009-10-23T09:18:00.000-07:00

To borrow from Darl's favorite cattle-rustler metaphor:

Darl had some cows on his ranch. He noticed that some of the cows on other people's ranches had the same brand as his, so he decided to get a posse together to go after those cattle rustlers who'd stolen his cows.

Then it was discovered that the brand wasn't Darl's, it was the brand of a completely different ranch that'd sold cows to just about everybody in the valley. And worse, as it turns out Darl hadn't even bought those cows, some of his own hands had found them wandering on his land and put them in with the rest of the herd. So now not only are the other ranchers mad at Darl for accusing them of stealing cattle when they hadn't, but some of them are accusing Darl of being the cattle thief.

But poor Darl's still positive that somebody somewhere had to have stolen some cows that should've belonged to Darl if he could've afforded to buy them.

Sidekick data lossage

2009-10-19T08:43:00.000-07:00

You know that big T-Mobile Sidekick data loss incident last week? Well, it seems a source is pointing at the potential cause. Long and short: the service did in fact have a backup, and did in fact start to do a backup before the migration. But they only have space on the SAN for 1 backup copy, and the backup process takes 6 days to run. So part-way through the backup the Microsoft manager in charge ordered them to abort the backup and start the migration, since the storage vendor had assured them a backup wouldn't be needed. Naturally Murphy stuck his nose in mid-way through the migration.

With Microsoft's track record for bad management decisions, this sounds plausible. And in a case like this you can't blame the technology. No tech will save you from this sort of deliberate stupidity.

I'd also note that the whole incident should be a warning to everyone: you need your own backups of your data. It doesn't matter what the contract says, failures can still happen and you need to be able to recover from them.

Delay: unclear on the concept

2009-10-09T11:26:00.000-07:00

Conversation just finished:

"Your simulator delay variable isn't working."
"I tested it and it delays correctly. What's happening?"
"Every time I set it, I get a CURL 28 timeout error. If I take it out, everything works. You need to fix it."
"... Sounds to me like it's working, the response gets delayed like it's supposed to. You did remember to bump up the timeout setting in AD's config file to something greater than the delay you're setting, right?"
"..."
"If you don't, it'll always time out like that because you're making the simulator delay longer than AD's willing to wait."

nVidia exits the motherboard chipset market

2009-10-09T09:57:00.000-07:00

nVidia's known for making graphics chipsets and cards, but they also make another indispensible part of a system: the motherboard support chipset. nVidia's offering is the nForce series of chipsets. But nVidia's leaving that market, at least as far as Intel CPUs are concerned. It's planning to cease making motherboard chipsets to concentrate solely on graphics. This'll leave only two major players making motherboard chipsets: Intel (for Intel CPUs) and AMD (for AMD CPUs). This'll also leave nVidia the odd man out in graphics as the only major player who isn't affiliated with a CPU maker (Intel makes their own video chipsets (albiet very low-end ones) and AMD acquired ATI a while back). This may be a bad move for nVidia, it'll leave Intel and AMD/ATI with a major advantage in terms of integrating graphics chipsets with motherboard/CPU components.

Fortunately my planned motherboards were all going to use AMD chipsets, since I was planning on AMD CPUs and neither Intel nor nVidia make motherboard chipsets for them.

Signs your workplace may not be as professional as they claim to be

2009-10-05T14:22:00.000-07:00

First sign: having to explain in small words what "significant digits" are, and why where the decimal point is doesn't matter when dealing with them. The targets of this explanation all have degrees in either computer science or an engineering discipline.

Meanwhile, over in alt.sysadmin.recovery, people with no degrees at all are having intelligent arguments over the differences between the various alephs and whether particular ones are ordinal or cardinal numbers.

Computer case

2009-07-03T18:06:00.000-07:00

I got the case for my new gateway/router machine: an Antec 300 through Newegg. The nice thing about it's that the power supply mounts in the bottom with the motherboard above. That means fewer cables dangling over everything, and fewer problems getting front-panel cables to reach to the back of the motherboard where some of the headers are. It's also got plenty of fans: one on top, one high on the back, one on the side panel and two behind the front panel. Two downsides, though. The first is that it doesn't have any external 3.5" bays, and the 5.25"-3.5" bay adapters are a pain to get. Not a problem for this machine, it won't have much in the way of USB hanging off it, but it may be a problem for desktop/gaming machines if I can't find decent 5.25" panels. The second is that you can't get at the air filter on the front bezel without taking the side panel off. That makes cleaning the filter a bit more of a pain. Again not a problem with this machine since it'll be sitting where the side panel'll be in the clear, but it may be an issue with machines that'll be under desks.

Another option for a desktop/gaming case is the Antec P183 or P193. Both of those have an external 3.5" bay and filters that seem accessible by opening the front door. I may have to see if someone locally carries them so I can get a hands-on look at them.

Oh, why am I building a new router? The answer lies in the CPU of the current one: a 400MHz AMD K6-3. This is an old Pentium-class. Not P3 or P2, Pentium. It's performance is, bluntly, anemic. I've got a leftover Abit KN8 Ultra motherboard and a CPU to go with it, so that's what I'm turning into a replacement router. It's still old hardware, but it'll be an order of magnitude more powerful than what I've got currently and should handle being a router and access gateway OK.

What SCO management knew

2009-06-24T13:53:00.000-07:00

Lewis Mettler comments on RedHat's filing in the SCO bankruptcy. Now, I disagree with him about SCO management. Darl has been through this kind of thing before. I think SCO's management knew exactly how flimsy and baseless their case was. Whatever their lawyers told them, I think they knew the reality. They'd simply decided that the strength of their case didn't matter. They figured IBM would settle because it was cheaper than fighting and winning.

SCO's problem was just that they miscalculated how IBM would figure the costs. If it's cheaper to settle than to win a lawsuit, you settle. SCO calculated the cost of settling as just the dollars IBM would have to pay them. IBM, though, felt that settling would be taken by their customers as an admission that the accusations had some merit. Since the accusations were that IBM had broken contracts just to make more money, they felt that'd negatively affect their business. Their software business runs around $6 billion a year, so even a 1% drop in business from customers getting nervous about IBM not honoring contract terms would be $60 million a year in lost revenue. That makes settling a lot more expensive, and IBM decided it was cheaper to throw a few tens of millions of dollars at defending their good name than to put hundreds of millions of dollars of revenue at risk.

SCO weren't deceived by their lawyers. They didn't believe they ever had a case. They simply figured that IBM would pay Danegeld if it wasn't too much. And they were wrong.

Web fail

2009-06-09T14:47:00.000-07:00

A challenge most Web designers today fail: design a generic Web page. It must display readably on a 24" widescreen LCD monitor at 1920x1200 resolution, and readably on the 320x200 pixel display of a Web-capable cel phone. It must not fail to render because the browser lacks Flash, or Java, or .Net or anything else not present in the basic browser installation. It must not fail to render because the user isn't running any particular browser.

For extra points, it must render readably on a 24" widescreen LCD monitor running in 640x480 16-color mode (user has failed their check vs. INT to set the correct monitor type and Windows has defaulted to a minimal known-good resolution).

System capacity

2009-06-02T09:21:00.000-07:00

Immediate thought: if your system gets overloaded handling 20 requests a minute, something's really hosed. I'm used to thinking in terms of rates 10-100x that, and counting them per second not per minute. The problem of course is that the offending software is a commercial package, so we can't dig into it to find out what the problem is and fix it.

News from SCO

2009-05-06T22:24:00.000-07:00

Two bits of news about SCO. First, in the bankruptcy case the US Trustee has moved to convert SCO to Chapter 7 liquidation. Second, in the appeal of the judgement in the Novell case, the appeals court heard oral arguments and my first impression is that they weren't impressed with SCO's arguments.

In the appeals hearing, it sounded very much like at least two of the three judges were looking at the contracts themselves, and at SCO's arguments, and going "You know, you're arguing that when the contract says "excludes" it really means "includes". We aren't buying that.". I expect the appeals ruling won't be favorable to SCO.

On the bankruptcy front, the next hearing is June 12th. I suspect the appeals ruling will be in in at least a preliminary form before then. If it goes against SCO, that pretty much shreds the last hope SCO had for postponing the inevitable. And SCO really doesn't want to end up in Chapter 7. When that happens the current executives lose their jobs and the US Trustee takes over management of the company. He's got no dog in the fights between SCO and Novell and IBM, his only interest in them will be to settle them at the minimum cost to the bankruptcy estate. And he'll have access to all SCO's corporate and legal records. Attorney-client privilege won't apply because, as of his appointment, he'll be the client. If he finds records showing SCO knew they didn't have a case when they filed it, he'll have no problem whatsoever filing a sworn statement to that effect in a settlement deal and turning over the records to back it up. That could place BSF in a very bad position. Not that they're in a good one now, mind you.

I've said it before: SCO miscalculated the cost to IBM of fighting. SCO assumed IBM would look at the demand for a few million dollars and count it cheaper than the cost of fighting it out in court and winning. IBM looked at a threat to half or more of their annual revenue world-wide (their gross revenue tops $100 billion), multiplied by decades, and decided a few million was cheap. I can imagine the conversation with their lawyers: "You know it's going to cost to fight this." "Yes, we know. Here's a quarter of a billion for the initial deposit, call us when it gets low and we'll add more.". To give you scale, that's half a percent of the first year of the revenue at risk. IBM's looking at 50 years, most likely (which is less than half the time the company's been in business, they've got current product lines that're nearly that old).

The Internet turns 40

2009-04-07T09:47:00.000-07:00

The Internet as we know it is 40 years old today. The very first RFC, RFC 1 - Host Software, was published on April 7, 1969.

Cloud computing

2009-04-06T09:26:00.000-07:00

Cloud computing isn't anything new. WorldNet from "Valentina: Soul in Sapphire" in 1984. "The Adolescence of P-1" in 1977. The idea of a world-wide computer network where programs can run on any processor on the grid isn't new. The hard part, of course, is making it happen. Machine code's specific to a particular processor. You can't run x86 code on a PowerPC CPU without some hairy emulation happening. Ditto for running Windows software on a Linux system, or vice-versa. So the first big technical challenge is making it possible for code to migrate from machine to machine without getting caught in CPU and OS compatibility issues. Things like Java's bytecode solved that, though. From a technical standpoint, there's nothing stopping code from being shifted around between machines as long as the author didn't choose to build hardware-specific executables.

The non-technical problems are bigger, though. The first is obvious: when running on the cloud or the grid or whatever you call it, your programs and data reside on someone else's system. How do you protect your data from being exposed to people who shouldn't see it? How do you force the hardware's owner, someone you may not have a direct contract with, to protect it from theft or damage? How do you insure you can get your data and programs back in the event you want to go elsewhere? They're all intertwined, you know. Amazon, for instance, solves the problems of data exposure and protection by keeping your data only on their systems, where you've got a contract with them. But at the same time, you don't entirely control the data formats. Your data resides on their systems, not yours, and in their formats, not yours. Unless you built special facilities into your software to send you copies of your data, if you decide to move from Amazon to Google you may find Amazon either won't export your data for you or won't export it in a format Google can import. And you may find your programs, written for Amazon's systems and APIs, won't compile for Google's without major rewriting.

The whole idea is a wonderful one, but you need to think about the logistics and remember that there are no silver bullets. There's no magic here. The obvious problems still exist, and still have to be dealt with, and they won't go away just because they're inconvenient to deal with.

Trademark ownership

2009-04-02T09:05:00.000-07:00

An interesting decision about trademark ownership. What's interesting about it is that the judge ruled that trademark use trumped a registered trademark. A lot of companies have been treating trademarks as if registration, however recent, trumped all common use no matter how long-term and well-established. The judge here threw that reasoning out, ruling that the Dallas Cowboys, even though they didn't have a formal registration on the phrase "America's Team", nonetheless owned it by virtue of long use of the phrase and it's association with the team. This overturned the relatively recent registration of that phrase as a trademark by another company.

This is good news for people who've been using names and phrases associated with their products. When someone else comes along, registers that name or phrase as a trademark and tries to usurp your usage on the grounds that a registered trademark trumps an unregistered one, you can point to this decision and say "The courts say otherwise.".

Google and copyright claims

2009-03-03T10:13:00.000-08:00

You know, I'm thinking that Google should be getting a bit more hard-nosed about copyright. When someone sues them claiming that Google can't internally cache anything without permission, Google should simply shrug and immediately blacklist everything by the plaintiff. From that point on, nothing belonging to the plaintiff will appear anywhere in any of Google's services. You don't want Google to maintain even neccesary internal copies of your stuff? Fine, Google won't and you'll live with the consequences.

Note that this is different from distributing copies of your work. Google can't hand out copies of your book. But returning a sentence or two in response to a search query and pointing to where the book can be bought? That's just as fine as a person mentioning something interesting from a book and telling their friend where to buy it. An author doesn't like that, that author gets to live with nobody recommending their books to friends too.

The Kindle 2 and newspapers

2009-02-26T11:50:00.000-08:00

Thinking about the Kindle 2, it may be the salvation of newspapers. A lot of the cost of newspapers is in the printing: the paper, the ink, the presses, the cost of distributing the sheer physical mass of paper. The Kindle 2 provides a secure subscription-based channel for delivering black-and-white printed content that doesn't require moving physical material around. Amazon already has a content distribution network set up. A newspaper could mark up their edition electronically and distribute it to Kindles. As long as nobody involved gets greedy, I think it could be profitable once the costs of physical printing and distribution are shed.

Verizon using mail submission port 587

2009-02-17T16:42:00.000-08:00

Verizon is moving to using port 587 for mail submission, requiring encryption and authentication to send mail. That alone won't stop the spam originating from their networks, but it's a start. My thought is that there should be 3 ports for 3 different purposes:

Port 25, no encryption or authentication required, is for server-to-server mail transfer. Relaying shouldn't be allowed, all e-mail arriving should be addressed to an in-network domain. Anything else should be rejected. This means no relaying. Messages should not be modified except for adding an appropriate Received header.
Port 587, encryption and authentication required, is for end-user mail submission only. Mail submitted to it should have the Sender header stripped and replaced with one based on the authenticated username.
Port 465, encryption required and authentication allowed, is a hybrid. If the session isn't authenticated, it should act per the rules for port 25. Authenticated sessions should be allowed to relay. If relaying, authentication information should be added to the Received header and if no Sender header is present one should be added based on the authentication information. Messages should not be otherwise altered.

One thing many ISPs ignore (often, I suspect, willfully) is customers who do not use their ISP as their mail provider. I'm an example. I get my Internet connection from Cox, but XMission in Utah host my domain and handle my e-mail.

The Pirate Bay trial

2009-02-17T06:58:00.000-08:00

Apparently half the charges against The Pirate Bay have been dropped by the prosecution. This isn't based on a technicality, as I read it, but on such basic things as the screenshots the prosecution was using as evidence the client was connected to the TPB tracker clearly saying it was not connected to the tracker. It's no wonder the prosecution dropped those charges rather than continue. If they'd've continued, the defense would've introduced the prosecution's own screenshots and the prosecutor wouldn't've been able to rebut them.

I don't particularly agree with piracy, but when the prosecutors screw up this badly they deserve to lose.

Code comments

2009-02-12T11:57:00.000-08:00

Motivated by a Daily WTF entry on code comments. I know exactly what creates this: Comp Sci instructors. You know them, the ones who insist that every line of code be commented, no matter how trivial. After a couple of years of this, students get in the habit of including comments just to have a comment for that line of code. Of course the easy way to do this is to just restate what the line of code does.

Now, as a professional programmer doing maintenance on code I don't need to know what the code does. I can read that line of code and see exactly what it does. I need something a bit higher-level. I need to know what the code's intended to do, and I need to know why it's doing it and why that way of doing it was selected. I know it's interating down a list looking for an entry, I need to know what that list is for and why the code's looking for that particular entry. Instead of comments describing how to iterate through a list, I need a block comment saying something like "We've got our list of orders entered this week, we know they're ordered by vendor, and we're trying to find the first order for a particular vendor so we can extract all his orders quickly.". Probably followed by something like "Now that we have this vendor's first order, we'll grab everything until we see the vendor number change. When we see that, we've got all his orders.". Much shorter, wouldn't satisfy that instructor at all since most of the code won't be commented, but much much more useful when I have to change things. It tells me what the code's trying to do, and what assumptions it's making that I have to avoid invalidating.

Too many Comp Sci teachers need some real-life experience maintaining the kind of code they exhort their students to produce.

Powerful and easy to use

2009-02-03T15:14:00.000-08:00

"You'll find this system to be incredibly flexible and powerful. You'll also find it to be incredibly simple and easy to use with minimal training. However, don't ask it to be both at the same time."

Security vulnerabilities and disclosure

2009-01-19T10:54:00.000-08:00

Triggered by this SecurityFocus column. I've always been a proponent of full disclosure: releasing not just a general description of a vulnerability but the details on how it works and how to exploit it. I considered that neccesary because vendors are prone to saying "There's no practical exploit there." and stalling on fixing it, and the only way to prove there is a practical exploit is to actually produce the code to exploit the vulnerability. It also removes any question about whether you're right or wrong about the vulnerability. There's the code, anybody can verify your claims for themselves. But I've also always been a proponent of telling the vendor first, and giving them the opportunity to close the hole themselves before the rest of the world gets the details. General public disclosure was, in my view, the last resort, the stick to wave at the vendor that you'd employ only if they didn't act with reasonable dispatch to actually fix the problem.

But, as this column points out, these days the vendor's most likely to respond not by trying to fix the problem but by hauling you into court to try and silence or even jail you for having the temerity to tell them they've got a problem in thier software. Which is leading me to believe that responsible disclosure, while preferrable, simply isn't viable anymore. The only safe thing to do, the only effective way to get vendors to respond to problems, is to dump all the details including working exploit code out into public view so the vendor can't ignore it, and to do it anonymously (making sure to cover your tracks thoroughly and leave no trail leading back to you) so the vendor doesn't have a target to go after. That's the only way to avoid months if not years of legal hassles and courtroom appearances, all for you having the temerity to try and tell the vendor privately that they had a problem. IMO this is a sad state of affairs, but it also seems to be the way the vendors want it to be.

It's either this, or fight for court rulings saying that vendors have no legal right to hound researchers who try to disclose privately to the vendor. In fact, we need legal rulings saying that a vendor who tries to silence the reporters of a vulnerability instead of fixing the vulnerability make themselves legally liable for the results of that vulnerability. Short of that, researchers have to protect themselves.

Sysadmin advice

2009-01-13T11:58:00.000-08:00

Really good advice:
http://www.bynkii.com/archives/2009/01/for_new_sysadminsit_types.html

Meece

2009-01-13T09:57:00.000-08:00

Grumble. The trusty old Microsoft Trackball Optical I've been using at work is starting to go. The optics work fine, but the ball is starting to stick and not want to roll easily. I've no idea what's causing it or how to correct it. It's done it and then cleared up a couple of times before, but it's happening more often and not clearing up as readily each time. So now I have to go get a replacement. Microsoft doesn't make this model of trackball anymore, the Logitech thumb-operated trackballs are all too narrow for my hand and the finger-operated trackballs I just can't get used to. So I guess it's back to a laser mouse for me.

Mass transit

2009-01-12T11:58:00.000-08:00

The major problem with mass transit is, frankly, that it's inconvenient for the things people commonly need to do. Stuff like shopping, or quick runs to random places. It's hard to bring anything back, let alone large items like a television or a full load of groceries for a family, and usually the busses and trains take twice as long to get there as a car would even after allowing for traffic snarls. I don't see a fix for this as long as mass transit is designed around large-capacity transports running on fixed routes on a fixed schedule. What we need is a completely different design, which will require a street network designed to accomodate it.

First, the basic local unit is a transit pod running in a dedicated guideway. Stops are cut-outs where the pods can get out of the traffic flow. Pods would be in 3 sizes to cut down on the number of varieties needed. 2-seat pods are designed to hold just people, no cargo, to provide a physically small unit for getting individuals from point A to point B when they don't need to carry much more than a backpack or briefcase. Larger pods are 2-row and 4-row versions, with the rear rows designed to fold flat into the floor to convert seating into cargo deck as needed for that particular trip. These don't run on fixed schedules or routes, people call them to a stop as needed based on how many people are in their group and how much cargo they expect to have and pick the destination once they're in. Pods are routed automatically by the shortest, least-congested path. Guideways don't have to run on every single street, but they should run on enough that it's never more than half a block from any house to a pod stop. For instance, in a residential neighborhood the guideways might run on every east-west street so you have to walk no more than half a block north or south to a guideway. The preference, though, would be to have a guideway on every street so pods can stop literally at your driveway. With this kind of routing, you avoid the waits to change lines that're typical of conventional bus and train systems.

Pods would operate in a large area, and in theory you can take a pod for the entirety of a trip anywhere within a sane distance, but for longer-distance travel inter-area trams would be used. These wouldn't run everywhere. They'd connect transit hubs, and be organized into lines much the way trains are currently. There would, however, be more interconnection than is typical of train lines, so you could take a direct route with less going out of your way and changing trains at a central station. I call them trams rather than trains because I'd design them using dedicated guideways like the pods rather than rails, so a tram could at a hub choose between multiple ways out. That way the system can dynamically allocate trams to routes at each hub to accomodate traffic. If you're going further than a few miles, you'd typically take a pod to the nearest hub and grab a tram to a hub near your destination. If you picked up cargo that couldn't be delivered, you'd take a pod the whole way back.

Using guideways also allows another trick: commercial pods could be designed that'd run on both pod and tram guideways. A store could, for instance, load up a delivery pod with loads for several customers in the same area and route it out (on a pod guideway to the nearest tram hub, then over the tram guideways to a hub near it's destination, and finally via pod guideways to a stop near the delivery address) to drop off deliveries for customers.

The major problem I see with implementing this is that you'd need to majorly disrupt the street network to build the guideways. You literally can't do this on top of the existing streets, you'd need to redesign the streets to accomodate the guideways (no more on-street parking, the guideways will be occupying that space) and have a whole new way to handle cars crossing the guideways without interfering with pod traffic (probably requiring traffic-control gates). IMO it'd be worth it once implemented, but the up-front cost of implementing it makes it a hard sell.

Programmers and undefined behavior

2009-01-05T10:17:00.000-08:00

ISAGN for a sadistic C/C++ compiler to school the current generation of programmers in the dangers of relying on undefined behavior. Too many of them do things like assume that dereferencing a null pointer should cause a crash and core dump. The problem is that nothing says that. The C++ standard leaves the behavior in that case undefined, which means the code and possibly the compiler is free to do anything it wants to at that point. It doesn't even have to consistently do the same thing every time.

So, a sadistic compiler. At run time it'd check for various sorts of undefined behavior. When it detected them, eg. an attempt to use the result of dereferencing a null pointer (as by calling a method through a null object pointer), it'd branch to a routine that'd randomly select from a list of dangerous things to do, such as spewing the contents of /dev/random onto the console, kill -9ing a random process on the system, or zeroing all blocks on a random attached storage device. In addition, the compiler would check for any undefined behavior it could feasibly check for, and take similar actions when asked to compiler such code. Thus, trying to compile "x = a++ - a++;" might result in your system disk being wiped.

The goal: to impress upon programmers that you cannot rely on undefined behavior. At all. Not on what it does, not even that it does the same thing all the time. The only guarantee you have is that you won't like what'll happen. So avoid it like the plague, or pay the price.

Zune lock-up bug

2009-01-03T12:35:00.001-08:00

Owners of Microsoft's Zune MP3 player saw their devices lock up hard at the end of 2008. It turns out there's a leap-year bug in Microsoft's code. The clock in the Zune records time as the number of days and seconds since 1/1/1980. To convert that into a normal calendar time, the Zune starts with this code to convert the number of days to years and days:


year = ORIGINYEAR;
while (days > 365)
{
  if (IsLeapYear(year))
  {
    if (days > 366)
    {
      days -= 366;
      year += 1;
    }
  }
  else
  {
    days -= 365;
    year += 1;
  }
}

It's basically looping through incrementing the year and decrementing days by the number of days in that year until it's got less than a full year's worth of days left. The problem comes on the last day of a leap year. In that case, days will be 366 and isLeapYear() will return true. The loop won't terminate because days is still greater than 365. But the leap-year path inside the loop won't decrement the days because days isn't greater than 366. End result: infinite loop on 12/31 of any leap year. This bug should've been caught during standard testing. Leap years are a well-known edge case when dealing with dates, likewise the first and last days of the year and the transition from one year to the next are standard problem points where any errors tend to show up.

Microsoft's proposed solution: wait until sufficiently far into 1/1 of the next year, then force a hard reset of your Zune. Yeah, that'll get your Zune working but it doesn't fix the bug. Bets that Microsoft's fix for this code causes a different kind of failure on 1/1/2013?

JournalSpace mistakes mirroring for backups, dies

2009-01-02T09:30:00.000-08:00

JournalSpace is dead.

Short form: JournalSpace depended on drive mirroring for back-ups. Something proceeded to overwrite the drives with zeros, and the mirroring politely overwrote the mirrors with zeros too. Their entire database is gone, all blogs, everything.

Repeat after me: mirroring is not a back-up. RAID and drive mirroring are for reliability and fault-tolerance. They'll protect you against hardware failure. They won't protect you against software doing something stupid or malicious. If the software says "Write this data to this location on the disk.", mirroring software and RAID drivers won't, I repeat will not, not write the data. If you're depending on your mirrors to contain something other than exactly what the main drive contains, well, you'll end up where JournalSpace is. You need point-in-time backups to external media, something that won't duplicate what's on the main drive unless and until you do the duplication yourself. That's the only way to insure that, if your software writes corrupted data to your main disks, the backups don't have the same corruption written to them as long as you catch the problem before you overwrite the backups with new ones. This is also, BTW, why you have more than one set of backup media: so if you do run your backups before catching a problem, you've got older backups to fall back on.

This should also be a cautionary tale for anybody wanting to host their data, application or whatever "in the cloud". If you do, and it's at all important, make sure you a) can and do make your own local backups of everything and b) have a fall-back plan in the event "the cloud" suddenly becomes unavailable. Unless, of course, you want to end up like the people who had their journals on JournalSpace: everything gone, no way to recover, because of somebody else's screw-up.

My network layout

2008-12-16T12:38:00.000-08:00

For those interested, this is how I lay out my network.

The center of the network is the gateway/router box. It's got three network interfaces on it. eth0 connects to the wired LAN, network 192.168.171.0/24. Off the gateway is an 8-port switch that handles the computer room, with a run out to the living room and a 5-port switch for the game console and my laptop when I'm out on the couch or I've run a cable outside to sit on the walkway. It's all 100-megabit Ethernet, I'm planning on upgrading to gigabit at some point. Outgoing connections/flows from this network are relatively unrestricted. The only blocks are for DNS, it's only permitted to the gateway box.

eth1 on the gateway connects to a 5-port switch where the wireless access points are attached on network 192.168.217.0/24. This network is considered untrusted, forwarding from it to other networks isn't permitted at the router so machines on it can only talk to each other or the router. In addition the router blocks incoming traffic on that interface except for DHCP and IPSec. This limits what a rogue machine on that network can do. The access points don't have WEP/WPA enabled, but they do do MAC filtering. When I upgrade to a faster AP I may enable WPA using authentication just to annoy the kiddies. The primary use for this network is to carry the IPSec VPN traffic on the 192.168.33.0/24 network. This network is considered trusted, and has the same outbound restrictions as the wired LAN segment. Forwarding between the wired LAN and VPN segments is unrestricted and un-NATed.

eth2 on the gateway is connected to the cable modem and gets it's address via DHCP from Cox. Traffic from the wired LAN and VPN going out this interface is NATed. Incoming new connections are generally blocked, with specific holes opened for connection to services on the gateway machine (ssh, Apache on a high port, the DHCP client). The outside world is considered untrusted. Outgoing traffic has a few restrictions to prevent un-NATed addresses from escaping.

Most security is based on limited physical access to the hard-wired network. The wireless network that can be reached from outside the apartment is treated the same as any network I don't control. Laptops on it should be firewalled as if operating on a hostile network, and use IPSec to make a VPN connection to the rest of my network. This avoids my having to rely on hardware I don't completely control for security.

DNSChanger malware

2008-12-09T12:45:00.001-08:00

The Washington Post's security blog is reporting on the DNSChanger malware. This stuff isn't new. It does two things: changes your computer's DNS resolver settings so it uses DNS servers belonging to the bad guys instead of the servers your ISP provides, and activates a DHCP server so that other computers (say ones attaching to your wireless network) will take addresses and settings (including DNS server settings) from the malware instead of the legitimate server. The result is that everything you do, and everything those machines do, gets funneled through the bad guys' systems along the way. It's hard for security software to detect this, there's no mismatches and no spoofing to spot as a clue there's something wrong.

On my network, this won't work. The DHCP server part might, within limits. But my wireless access point is on a seperate physical network from the hard-wired machines and the firewall blocks the DHCP protocol between the networks. With the VPN active, that limits the damage the rogue DHCP server can do. And my firewall also blocks the DNS protocol at the edge of my network. While on my network you simply can't use any DNS server except the one I provide. If you try, your query packets will get rejected by the firewall when they try to leave my network. That means if you do get infected by DNSChanger, your DNS will simply stop working completely on my network until the problem's fixed. And my gateway machine, the one machine on my network that gets to do DNS queries to the outside world, doesn't run Windows, isn't used for Web browsing and isn't very susceptible to infection by malware.

BodyParts webapp

2008-12-03T11:19:00.000-08:00

I finished the first pass at the BodyParts webapp that lets me view and maintain the Legends&Lore body parts inventory for my guild in EQ2. Security framework enabled, anonymous viewing and a login for editing, Tomcat set up properly, Apache configured to front for it. Now I can update the inventory from the in-game browser, no more writing things down on paper and windowing out to update text files.

Next things on the list:

Add add/subtract fields and buttons to the editing screen so that instead of having to do the math in my head I can just punch in the number of parts and hit Add or Subtract depending on whether I'm depositing or withdrawing parts.
Move the inventory from an XML data file into a real database table. I'll want to move the user information into a database table in the process and change authentication to match.
Reconfigure things to have all webapps in their own sub-tree so they don't sit directly at the root of the content tree. I'll have to see whether I want Apache to re-write URLs (so the user sees /webapp/BodyParts/ while Tomcat sees just /BodyParts/) or whether I want to make the change within Tomcat.
Change things in Eclipse to not depend on MyEclipse for the Spring framework and supporting libraries. I'm finding that as I get more familiar with things it's easier to edit the XML directly than to depend on MyEclipse's tools.

It's been a useful excercise so far.

MS claims in Vista lawsuit

2008-12-01T12:53:00.000-08:00

Microsoft is currently embroiled in a lawsuit over Windows Vista. The plaintiffs there are claiming that Microsoft falsely advertised machines as Vista Capable when they weren't capable of running the Vista shown in advertisements. One of Microsoft's responses to this is that Vista Basic, which the machines are capable of running, is a real version of Vista and therefore there wasn't any false advertising. This isn't going to fly. The question isn't whether Vista Basic is a real version of Vista, it's whether it's the Vista advertised to everyone. And it isn't. It's missing almost all the elements shown in the advertisements, and nowhere in the ads does it say that what's shown may not be present. In fact all the ads emphasize all those elements shown as the things that make Vista Vista. That's going to kill Microsoft.

This isn't a software trademark or copyright case. This is straight-up consumer law that's been around almost as long as car salesmen have been. If you advertise a car on TV and show the supercharged V8, 6-speed manual transmission, sports suspension, full leather interior, full power everything with sunroof version, and that's all you show, and you end the add with "Starting from $9000.", then courts have held that you need to deliver the car as advertised starting at $9000. If the only model you offer at $9000 is the 4-cylinder, 4-speed automatic, cheap cloth interior, manual everything stripped-down model, the courts will nail you for false advertising. You did the advertisement knowing you couldn't and wouldn't deliver what was shown for the price you quoted, and you don't get to do that. Which is why every car advertisement, when they show the price, always says in readable text underneath the "Starting at" stuff something like "Base price. As shown, $LARGER_NUMBER.". And Microsoft didn't do the equivalent. They showed Vista with the Aero interface, emphasized the Aero interface as a defining characteristic of Vista, and never gave a hint in the ads that Vista might not actually contain the Aero interface. A reasonable person, looking at the ads and the "Vista Capable" sticker, would conclude that that sticker meant the machine was capable of running what Microsoft was advertising as Vista. And it can't. And all those e-mails from Microsoft execs show that Microsoft knew it. Bam. Stick a fork in 'em, they're done. They can wriggle all they want, but when it comes down to it they're going to lose on that point for the same reason car dealers lost and had to start adding that explanatory text.

The Srizbi botnet

2008-11-28T10:03:00.001-08:00

After being taken down when McColo was shut down, then resurrecting itself, the Srizbi botnet has been taken down once again. It won't last, though, the botnet will start searching domain names trying to reestablish contact with it's command-and-control network, and it's operators will probably succeed We need new tactics:

Instead of trying to block the botnet when it searches for a new C&C network, intercept it. Put something up at the next few domains it'll try that will respond correctly and take control of the botnet. Once you've got control, use that control to have the botnet download a new module that'll remove the botnet software from the computer, then shut down the computer until the user reinstalls Windows.
Start sanctioning users who allow their computers to become infected. Right now there's no significant penalty assessed against the people who continue to allow their computers to be used by the botnet month after month after month. Start penalizing them. If they get infected, their Internet access gets suspended until they can provide evidence to their ISP that they've cleaned their machine up. Second offense, they get a 3-month suspension. Third offense, they get permanently disconnected. It's the Information Superhighway, and just like the real road system if you accumulate too many points we take away your driver's license.

Keeping a computer secure takes some effort and thought, especially if you're running Windows which was designed to be vulnerable. If there aren't noticeable penalties for being insecure, users just won't put forth that effort.

Spam volume

2008-11-21T09:50:00.000-08:00

Early last week McColo was shut down. They provided hosting to nearly half the spam-related community. Some people were saying it wouldn't make a difference, the spammers would just move to different hosts and spam would pick up again. Well, according to SpamCop's statistics, spam hasn't even started to return to it's previous levels yet. You can see the near-vertical drop on the 11th when McColo was cut off, and peak levels since then have held pretty steady. I think one of the reasons is that other hosts looked at what happened to McColo and said "We don't want that happening to us.". I mean, it was pretty major: all of McColo's upstream providers simply pulled the plug on them, terminated the contracts and turned off the interconnect ports. When a spammer who got caught in that comes to another hosting provider, that provider's got to look at the potential down-side of accepting the spammer: complete and total loss of all their business. And they can't say "Oh, that'll never happen.", because McColo is staring them in the face saying "Yes, it will.".

This is, frankly, what we need more of: providers who serve the spammers facing a credible threat of being cut off from the Net if they don't do something about the problem on their network. For the provider it's a question of money, and the best way to change their behavior is to change the cost-benefit equation so the cost of hosting a spammer is higher than the benefit from them.

BodyParts webapp

2008-11-05T16:54:00.000-08:00

Slowly but surely I'm getting my head around writing a web app using the Spring framework. It's requiring a fair amount of work, but it's much easier to understand when I'm actually writing code and seeing it work (or, more often, fail miserably). I need to get error handling working, then adding a new species, and then adding the security bits to allow some users to edit and others to only view the data. Once I'm done I'll not only have a handle on Spring, I'll have a way to edit my guild's body-parts database while I'm in-game.

Projects I need to do

2008-10-29T13:26:00.000-07:00

Clean up LJBackup. It's been sitting on the back burner for way too long.
Take the EQ2 body-part inventory system I've got, that's currently based on a hand-maintained CSV file, and convert it into a Spring MVC web app. For low-volume stuff I can run it under Tomcat on an odd port on my gateway machine. That'll let me update the inventory through the in-game browser while I'm actually moving body parts in and out. It'll also be a useful show-off project if I want to move into Java and/or web-app work.
Create a utility to back up Blogger blogs, both entries and comments, locally. This should be easier than LJBackup.
Multiple new computers. I've got the guts for a new gateway box (obsolete AMD dual-core Socket 939), just need a case for it. I can turn the existing machines into two boxes sufficient for the kids. That just leaves main/gaming systems.
I need to scheme some way of getting a hosted server and the time to configure and maintain it correctly. I want to handle e-mail, Web server, DNS and such myself and drop the XMission hosting.

Computer models and the credit crisis

2008-10-24T09:23:00.001-07:00

This is more political than normal, but it touches on tech so I'm putting it here. Basically, in the Congressional hearings, Alan Greenspan blamed computer models in large part for the mortgage and credit crisis. I'm sorry, but that's not so. The fault isn't even with the data fed to the models. The fault lies with the people in the banking industry who looked at the models and said "What do we need to feed these models to get the results we want?". They didn't just feed the models wrong data, they outright manipulated the data they were feeding the models to insure the models gave them a specific answer. That's always a recipe for disaster. They knew the models were telling them those sub-prime loans were bad bets, so they created "stated income" rules so they could feed higher incomes to the models and make the models say the loans weren't as risky. They created credit-default swap instruments that they could factor into the models to make the loans appear less risky, and then decided not to factor in the risk of those credit-default swaps also failing.

The banking industry decided what answers they wanted, then hunted around until they got models and inputs that produced the desired result. You can't do that with any sort of model. And if you do, don't blame the models and the techs for your failure to listen to what the models were telling you when that didn't agree with what you wanted to hear.

But then, we see that in IT from management all the time. The techs say "If we do X, we're going to see these problems.". Management berates the techs for being obstructive and standing in the way of doing X when the rest of the company's agreed on it. Then all the predicted problems occur, and management berates the techs again for allowing those problems to happen. PHBs in action.

a.s.r quote

2008-10-01T10:14:00.000-07:00

"Is there any equipment out there that doesn't suck?"
"Yes. Vacuum cleaners."

Browser process models

2008-09-22T16:56:00.000-07:00

Everyone's praising IE8 for it's new one-process-per-tab model. It's got many advantages over the threaded model used by most browsers, including the fact that a crash of one tab can't take other tabs or the browser down. What most people don't seem to get is that the multiple-process model isn't new with IE8, and in fact the threaded model was one adopted only over the strenuous objections of everybody else. You see, threads exist for one reason and one reason only: on VMS and Windows (which was designed in part by the guy responsible for designing VMS), creating a process is expensive. You need threads in those OSes because you can't create a lot of processes quickly. But Unix had cheap process creation from day one. You needed another thread in Unix, you forked off another process. Threads weren't needed. But everybody in the Windows community kept braying about needing threads and why didn't Unix have them, oblivious to the fact that they already had what threads did in the fork() call. So Unix finally, reluctantly, adopted threads with all their pitfalls. And programmers used them heavily when processes would've been more appropriate. Until the pitfalls finally became too much to live with, when they went from just driving programmers nuts to causing problems for the very users who demanded them in the first place. So now we're back to where Unix was 25 years ago, forking a new process when you need a new thread of execution.

Cooling a data center without AC

2008-09-18T14:49:00.000-07:00

http://weblog.infoworld.com/sustainableit/archives/2008/09/intel_air_side.html

Intel has done a test, cooling a high-load data center model without using air conditioning, just ambient outside air. They did see a higher failure rate on the equipment, but not nearly as much higher as was expected. And the portion that used a simple, cheap cooling system without all the climate control of a true data-center AC unit had a lower server failure rate than full-on data-center-class AC yielded. My feeling is that it's not the cold air that's critical to data-center health, the servers will be entirely happy with 80-90F cooling air. It's mostly the dust and to a lesser degree the order-of-magnitude changes in humidity that cause most of the failures. Scrub the dust from the air (even cheap AC units do this, and simple filter systems can do it too) and keep the humidity in the 5-35% range (no need to control it to +/- 2%) and you'll give the servers 95% of what they want to be happy. And you can do that for a fraction the cost of a full climate-control system that controls everything to within 1%.

Need to update site

2008-09-16T16:01:00.001-07:00

I really need to start updating Silverglass (the Web site) again. It used to have a lot of pages about the nitty-gritty of configuring RedHat Linux. I've long since switched to Debian, and the configuration tools have gotten a lot better since the days when getting e-mail address masquerading working involved manually editing sendmail.mc, but there's still things I'd like to document. Setting up the zone files for a DNS server, for example, and configuring a DNS "blackhole" list (a set of DNS domains you want to make not exist anymore, eg. DoubleClick's domains, so that Web advertisements and such just vanish). And some things haven't changed, setting up a firewall for example, and details of Debian's startup scripts and how to play nice with them when writing your own is still useful information. And of course there's rants I want to write but haven't, the originals would be on my blogs of course but copies can go on the Web site. Then there's code projects like the LJBackup program I can finish up and drop on the site.

I just need to get time and energy together and actually do it.

Hubble Space Telescope discovers unidentified object

2008-09-15T11:54:00.001-07:00

The HST has spotted an unidentified object. (Here's a more serious article.) It's not similar to any type of object previously seen, and it's spectrum doesn't match that of any known object or type of object. There wasn't anything in that part of space before it blipped in, and there's nothing obvious there now that it's faded. So what is it? Nobody's got any good ideas yet.

"The most exciting phrase in science, the one most likely to herald a new discovery, is rarely "Eureka!". More often it's "That's funny. It's not supposed to do that, is it?"."

Large Hadron Collider

2008-09-10T10:42:00.000-07:00

They've fired up the LHC today for the first tests. A lot of people have been making noises about the risk of it creating a black hole that'll swallow Earth. I'm sorry, the world won't be ending today.

Yes, the LHC will be colliding particles with higher energies than anything humans have been able to manage to date. But the Universe isn't human, and has been colliding particles with energies orders of magnitude higher than the LHC's capable of for billions of years. Several such collisions happen here on Earth each year as high-energy gamma rays impact the atmosphere. Given the length of time and the number of events per year, if those collisions would create a black hole that'd last any length of time we'd've seen evidence of it happening before now.
Any black hole the LHC might create will have only the mass of the particles involved in the collision. That's only going to be a couple of protons worth. Such low-mass black holes emit a large amount of Hawking radiation relative to their mass. And that emitted radiation comes from their mass. Low-mass black holes simply evaporate very quickly (within fractions of a second) after forming. So even if a black hole does get created, it'll disappear again probably before we even know it existed.
Even if the black hole sticks around, it won't pull in enough to be a problem. Remember, black holes don't have any greater gravitational pull than anything else of the same mass, their only special property is how steep their gravity well is. The danger radius of such a low-mass black hole is going to be a fraction the size of a subatomic particle. It's going to have to hit another subatomic particle almost dead-center to suck in any additional mass. At this scale "solid' matter's 99.999% empty, so it's going to take that black hole a very long time (as in millions of years) to accumulate enough mass to begin to start pulling in matter on a macroscopic scale.
Ignoring the above, the black hole will have the same velocity vector and momentum as the particles that created it. That velocity'll be well above the Earth's escape velocity, and tangent to it's surface. Any black hole will simply continue in a straight line away from Earth, never to return.
And even ignoring the previous points, this is the test phase. They've only turned on one beam to calibrate and align things. With only one beam, there aren't going to be any particles colliding. So even if the LHC could create black holes, it won't be creating them today.

So, I'm sorry, but the crowbar-wielding Gordon Freeman won't be getting any screen time because of the LHC.

Abit leaving the motherboard market

2008-08-28T11:52:00.000-07:00

According to this article, Abit is exiting the motherboard market by the end of this year. Abit's been my preferred motherboard brand for a long time now, with the right mix of interfaces and options for what I want. Now I've got to find another brand that has models with the right mix and a history of reliability. Annoying.

aseigo on new MS/Novell deal

2008-08-23T10:53:00.000-07:00

http://aseigo.blogspot.com/2008/08/microsoft-and-novell-reaffirm-pact.html

aseigo has some comments on MS's new deal with Novell to buy more Linux support coupons. I have to agree with him. One thing that has bothered me with MS's activites is their nebulous claims about their IP that's supposedly infringed upon by Linux. My first reaction is "I'm from Missouri. Show me.". Exactly what intellectual property does Microsoft claim to own that's being infringed upon, and exactly what in a Linux distribution infringes upon it and how? Lay it out and let's get it resolved. And yet Microsoft won't do that. They play coy, dodging around saying exactly what it is they're accusing Linux of. And my immediate reaction to that is to think that they really don't have any claim that'll stand up to public scrutiny, that if they had to actually lay it out all they'd end up with is "We got nuthin'.". And that makes me immediately suspicious of any deal that supports them in this. When someone's running a scam (which is what a false claim to get others to pay you is, a scam), there's only two kinds of people doing business with them: marks, and accomplices. I probably want to avoid both.

DMCA: copyright owners must consider fair use

2008-08-21T07:31:00.000-07:00

Copyright owners must consider fair use before filing a DMCA takedown notice. The full decision is here. The basic upshot of this is that copyright owners are required to consider whether a use of their material would reasonably be considered fair use under copyright law. The DMCA requires that the copyright owner have a good-faith belief that the use is infringing before they can file a takedown notice, and if the use falls under fair use and a reasonable person would have concluded this beforehand then the "good-faith belief" test fails. That, BTW, leaves the copyright liable for damages and penalties if the target of the notice wants to push it. The downside, of course, is that showing bad faith is a difficult thing to do in court, but still it's nice to have the principle upheld.

The judge says he's not sanguine about the defendant's chances of proving bad faith on the part of the plaintiff. I'm not so sure, at least if the judge is unbiased about it. The infringement in question is a song playing in the background of a baby video posted to YouTube. The Supreme Court has set forth 4 factors to consider in determining fair use: the nature of the use (commercial vs. non-commercial), the nature of the infringed work, the amount and substantiality of the portion used and the effect of the infringement on the potential market for the work. It's going to be very hard for a record label to argue that people are going to put up with watching someone's baby video repeatedly just to save the cost of buying the song. They're also going to have a hard time arguing commercial use, YouTube may put ads on the page but the uploader doesn't get any money from them and has no control over them and the entity that does get the money (YouTube) isn't the one the plaintiff's making a claim against. Even the nature of the copyrighted work works against the label. The work is a song, and it's merely incidental background noise in a video whose point is to showcase the uploader's baby. The only factor that works anywhere near in the plaintiff's favor is the amount of the song audible, and that's countered by the fact that the song's purely incidental background. As I said, it's not likely anyone's going to look at this video mainly for the music, any more than anyone watches a football game mainly to see the advertisements pasted around the stadium. Given all that, if the defendant's got a good lawyer I think they can make a very strong case that plaintiffs couldn't reasonably have believed the use wouldn't meet the qualifications for fair use. And proceeding when you know or should know otherwise is the very definition of bad faith.

Google session vulnerability

2008-08-19T10:31:00.000-07:00

At DefCon there was a presentation on a way to hijack a Google Mail session. Google's implemented a new option to counter it, the option to always use SSL. Now, important point: the attack is not the one that sniffs your session cookie if you're using an unencrypted link. That attack can be prevented merely by using SSL all the time. This attack will work even if you use SSL for everything. It works by inserting code on a non-GMail page that'll cause a request to the non-SSL GMail pages, and the browser will send the session cookie in that unencrypted request without you being aware of it. When you use Google's fix, setting your account to always use HTTPS, Google does more than just force you to an "https:" URL. It also wipes your existing session cookie and creates a new one with a flag on it to tell the browser to only send this cookie in secure (HTTPS) requests. This prevents the cookie from being sent in the clear ever.

Law & Life: Silicon Valley: Major Victory for Open Source in Jacobsen Decision

2008-08-13T14:39:00.000-07:00

Law & Life: Silicon Valley: Major Victory for Open Source in Jacobsen Decision

Artistic License is a copyright license after all

2008-08-13T11:53:00.000-07:00

In the Jacobsen v. Katzer case, the trial court had ruled that the Artistic License (the open-source license under which the software involved was distributed) was a contract, not a copyright license. The Appeals Court for the Federal Circuit has overturned that ruling. The case is convoluted, because it originates not out of a copyright dispute but out of a patent issue. The copyright aspect came up out of the patent portion of the case. But it's good news nonetheless for open-source software. One of the standard arguments by open-source detractors is that the GPL and similar licenses are just contracts, subject to the vagaries of contract law, and violations of them have to be pursued as contract breaches. Now it's possible to hold up this ruling and say to them "The US Appeals Court disagrees with you.". Among other things this affects are the ability to recover costs. In a standard breach-of-contract suit the plaintiff, even if they win, is expected to bear their own costs except in unusual circumstances. In copyright-infringement actions, though, the law grants the prevailing party a much greater right to recover their costs and legal fees. This makes it easier for open-source authors to find lawyers willing to help them with copyright enforcement.

Credit-card system

2008-08-11T12:41:00.000-07:00

You know, we need a change to the way credit-card purchases are handled. Card-present transactions, ones where you're physically there with the card to swipe, are OK. But when the card's not present, we need a change. Currently the system works by the merchant pulling money from your account. We need to change it so the card-holder pushes the payment to the merchant. That would eliminate the whole need for the merchant to store credit-card information, and eliminate a bunch of fraud in the process.

How would it work? Well, for a one-shot payment (your standard on-line purchase), check-out would proceed as normal except that when you told it you'd pay by credit card it wouldn't prompt for the card number. When you got to the confirmation page, it'd give you a merchant identity code and a transaction number. You'd then go to your credit-card issuer's Web site, log in and use those two numbers to generate a payment to the merchant. You'd of course verify that the merchant's identity code gave you the expected merchant name. You'd make the payment for exactly the amount the merchant gave as the total, and your card issuer would charge your card and transmit the payment to the merchant. The merchant could match the transaction number they got along with the payment with their order records, and ship your order only once they'd received your payment. The merchant's account would be solely for receiving money, nothing could be pulled out of it, so it'd be impossible to steal from the merchant. Nobody who knew your card number and other information could run a transaction, regardless of how much they knew, unless they also had the password for your account at the issuer and could log in as you to generate the payment. It'd be impossible for merchants to make unexpected charges to your card. And if the merchant claimed you hadn't sent the payment, you'd have your bank/issuer's record of the merchant accepting the payment as proof you had. This could all piggy-back on the bill-payment systems a lot of banks already have in place.

For recurring payments, it'd work two ways. For payments where the amount's known, the merchant could give you a customer identifier to use as the transaction number. Then you could simply set up an automatic recurring payment for that amount with your bank. For payments where the amount wasn't known beforehand (eg. utility bills), a back-channel could be provided where you give the merchant your card number or other bank-provided customer identifier and the merchant can send a payment request to your bank using that identifier and providing the payment amount and a transaction number. That'd go into a payment-request list you could view, and you could generate payments to the merchant directly from that list. These payment requests could even be used for non-recurring charges too, with a checkbox in the payment-information step to indicate whether you wanted the merchant to generate a payment request or not and a way to give the merchant your customer identifier. For full auto-pilot operation, the bank might let you flag requests from certain merchants for auto-approval, preferrably with a limit on the payment amount (eg. if your electric bill was normally $45-55 you might put a limit of $75 on auto-approved payments, with anything above that requiring manual approval) and timeframe (eg. auto-approve the utility bills for the next 2 months while you're possibly on vacation). Of course auto-approval removes a lot of the protection from fraudulent and unauthorized charges.

For people without Web access, it still works. They obviously won't be buying on-line, not when they can't get to Web sites at all, so the impact's mainly to mail-order and telephone purchases. Payment authorization can be added to ATMs easily enough. It can probably be added to telephone banking systems, although it's easier with voice-recognition systems than with ones that depend on the touch-tone keypad to enter information. And of course it could be done by a teller at a bank branch. In the worse case, a simple interface to turn auto-approval on for payment requests from merchants you needed to pay would turn the system back into the traditional pull-payment system.

California IP and non-compete law

2008-08-11T12:28:00.000-07:00

As a follow-up to the last post about non-competes, I thought I'd repost links to the relevant California codes on intellectual-property and non-compete agreements:

California Labor Code 2870-2872 on intellectual-property agreements
California Business and Professions Code 16600-16607 on non-compete agreements

Anyone in the tech field in California should be familiar with these, because tech companies routinely put terms in their employment agreements that exceed what these laws allow. I made sure, when I signed my intellectual-property agreement, to add a notation referencing the limitations in 2870-2872 and making my acceptance limited to only what was allowed by those sections of the law.

Non-compete agreement? Not in California.

2008-08-08T09:31:00.000-07:00

The California Supreme Court has ruled non-compete agreements illegal except in a very few circumstances. The law allows for them explicitly in cases involving the break-up of a corporation or partnership, but beyond those exceptions written into the law the Court ruled that the law simply prohibits an employer from restricting a former employee's right to engage in their profession. The full ruling is here. Given that it's the California Supreme Court ruling on this, Federal courts are likely to follow this ruling when interpreting California employment law. So if you work in California and your company had you sign a non-compete clause, it's out the window now.

Note that this doesn't mean you can do anything you want. If you got training at the company's expense, for instance, the clause that says you must either stay a certain length of time or re-pay the cost of the training (probably pro-rated) is still enforceable. If you do something like take company confidential information (eg. software source code, customer lists, etc.) and give it to your new employer, your former employer has grounds other than non-compete they can sue you on. And if you're a salesman and openly solicit your former company's customers to follow you to your new one, your former company again can sue you for that.

Telnet

2008-08-04T09:51:00.000-07:00

Telnet: a useful program for determining whether a remote system is accepting connections on a given port, and for issuing direct commands to SMTP, HTTP and other similar services. It's use as a terminal emulation program is Not Recommended.

DNS vulnerability

2008-07-29T10:37:00.000-07:00

There's a few things that need to be done to completely fix the DNS cache-poisoning vulnerability Dan Kaminsky discovered.

First, filter additional response data (glue records) aggressively. In delegation responses, the only acceptable glue should be A records for the names given in the responsive NS records. In non-delegation responses only additional records for the exact name being queried should be accepted, records for other names should be discarded. If you're going to cache additional records, only records passing this filter should be cached. Ideally no additional records should be cached.

Second, implement DNSSEC across the board. It shouldn't be that hard, it just requires people to do the work. Signed data makes it impossible for an attacker to successfully get forged responses accepted (barring someone breaking the major public-key encryption algorithms).

Third, network operators near the edge of the network should implement ingress/egress filtering and require it of networks connecting to them. Towards the backbone there's too many netblocks on each interface to filter, but at the edges it's feasible to identify all the netblocks that should be sending packets across a given link. No network should ever permit a packet to go upstream unless it's source address is in a netblock belonging to that network or to a downstream network. No network should accept a packet from a downstream network unless it's sourced from a netblock attached downstream of that interface. That makes forging the source address (needed for the DNS cache-poisoning attack) nearly impossible.