Posted by Bob Jonkman on 13th October 2011

Don't Panic, They're Only Vogons by Patrick Hoesly
After dissing Google Plus I was persuaded to try it out for a while before rendering a verdict. So now it’s been over two months, and my verdict is: Mostly Harmless.
When I get home after a hard day of working with a computer, I sit down for a pleasant evening of relaxation with a computer. I read my e-mail, read the news, and read the microblogs. I subscribe to 55 people on Identi.ca, and I follow 84 people on Twitter. Those 139 people generate sufficient 140 character messages to keep me reading until bedtime and beyond.
But on my Google Plus account, I have 27 people in my circles. Those 27 people create a lot of large messages. In fact, they generate a lot more content than my 139 Identicats and Tweeple, since Google Plus puts no limit on the size of messages.
22 of the 27 people are in my Tech Circle. But instead of receiving only technical content from these people, they’re posting messages about vacations, favourite bands, philosophy, and yes, pictures of cats. Now, this happens on the microblogs too, but on a microblog it’s limited to 140 characters, and I can ignore them. On Google Plus the posts are much longer, have pictures attached, comments from other people, and those ubiquitous “John Q. Public originally shared this post” and “Click to +1 this post”. Google Plus does not have the tools to filter messages by content, or even a method to collapse a conversation thread.
There’s no Atom/RSS feed, so I can’t use my preferred feed reader to analyze, sort and organize my Google Plus message stream. And I don’t know of any third-party applications to read, write and manage content on Google Plus. Google Plus does allow the export of all its content, under Account Settings, Data Liberation. Contact info is in the standard vCard format, suitable for importing into addressbooks.
Kudos to Google for giving users useful control of their data. Still, Google also has access to that data, and continues to collect ever more. In the past I’ve recommended Google Mail as a preferred no-cost e-mail host. Recently Google has taken to verifying new users by requiring them to supply a phone number. Google then sends a text message for the user to enter into the registration form. This is a level of data collection that I find creepy, and so I no longer recommend Google Mail.
Finally, to top it all off are the Google Nymwars. Much has been written about why Google’s policy of requiring real names is wrong-headed. Some people whom I might follow have stopped using Google Plus because of the nymwar controversy. I think I’ll be joining them in disdaining Google Plus.
- Google Minus: Banality of user content (not Google’s fault)
- Google Minus: Lack of management tools
- Google Plus: User control over data
- Google Minus: Google control over data
- Google Minus: Nymwars
I think that Google Plus is not the Facebook Killer the folks in Mountain View want it to be.
The image 740 – Towel Day – Pattern by Patrick Hoesly is used under a Creative Commons Attribution 2.0 Generic (CC BY 2.0) license.
Tags: Atom/RSS, cats, considered harmful, content, feed reader, Google, Google Plus, identi.ca, mail, microblog, nymwar, phone number, privacy, registration, review, twitter, user content, vCard
Posted in considered harmful, Google, Microblogging, Social Media | No Comments »
Posted by Bob Jonkman on 29th June 2011

Google Plus Screenshot
Google Plus is available.
I won’t be using it. Google has too much of my data already.
For gushing, sycophantic reviews see Mashable and Techcrunch.
Update 8 July 2011: Someone pointed out that I should probably investigate Google Plus before dissing it, so I’m licking the Google salt block. There will another blog post with the results of this investigation… In the meantime, Circle Me!
Update: 13 October 2011: The Verdict on Google Plus: Mostly Harmless
Tags: considered harmful, Google, Google Plus, Mashable, privacy, review, Techcrunch
Posted in considered harmful, Google, privacy | No Comments »
Posted by Bob on 19th November 2009

The black hole that sucks up Internet Addresses
BoingBoing points me to a Security Fix article by Brian Krebs called A year later: A look back at McColo on the after-effects of Real-time Blacklists (RBLs) that targeted formerly undesirable IP addresses:
The Internet community typically shuns networks known to harbor spammers and organizations that host malicious software and other nastiness, usually by including their numeric Internet addresses on “blocklists”. Many organizations configure their e-mail servers to reject messages from addresses included on one or more of these blocklists. A heavily blocklisted network quickly becomes unattractive to legitimate businesses, since any e-mail sent out of that network will most likely be refused by the intended recipients.
“The problem is once an address block gets so polluted and absorbed into all these blocklists, it’s difficult to get off all of them because there is no central blocking authority,” said Paul Ferguson, an advanced threat researcher at Trend Micro.
(“Blocklist” is a less pejorative term for “Blacklist”)
The problem is not with the (formerly) malicious site, nor with the keepers of the blacklists, or even the lack of a central blocking authority. The problem is with e-mail server admins or firewall admins who let some unpaid, unaccountable blacklist censor their incoming mail or access to Web pages.
A blacklist should be just one of the criteria used to weight the probability that an incoming e-mail message is spam, or that an http stream contains malware. When I use a blacklist I’ll take into account the blacklist’s opinion of an IP source, but I don’t want a blacklist deciding what I can or can’t receive.
It’s far more reliable to actually examine the content stream for spam or malware instead of relying on a third-party’s opinion of an IP address. Yes, this increases the transaction cost for managing spam and malware, but as these blacklist IP address areas increase there’s an ever greater chance of false positives.
Are you using blacklists? Still think they’re a good idea? Wait until your blacklist gets compromised. An attacker takes control of a blacklist, but doesn’t interfere with its regular operations. Instead, it selectively adds and removes addresses. What better way to impose a DoS attack than maliciously subscribing your target to a well-known blacklist? In fact, for the long con I can see an attacker setting up a blacklist site, and spending a year or two building a reputation. As long as system admins rely completely on that blacklist to block certain IP addresses, those system admins are vulnerable to the whims of the blacklist operator.
I also wrote about the role of blacklists in Blocking Port 25 Considered Harmful, just under a year ago.
–Bob.
(Flickr image “Black Hole” by he who shall used under creative commons license)
Posted in considered harmful, dnsbl | No Comments »
Posted by Bob on 13th November 2009

Ripe for Deep Packet Inspection
Michael Geist points us to a
Sandvine report analyzing global broadband traffic.
Far more interesting than the data presented by Sandvine is the fact that Sandvine has any data to present at all. How did they get this stuff? Did they buy it from Bell and Rogers? Does their throttling equipment phone home? I don’t recall giving them permission to use my data.
They claim they’re not looking at data content. Maybe that’s true, maybe it’s not. But they’ve inspected deeply enough to know that we use more streaming applications than P2P, and more Bittorrent than Gnutella. As any data analyst knows, traffic analysis of data patterns gives as much information as the data itself. Why are they allowed to gather any of this data at all? None of their business what I use on my computer.
I’m sure Sandvine is making a hefty buck selling this report, or at least using it as evidence to sell more of their DPI equipment. They’re profiting from the the data that I didn’t give them permission to use. I think the Privacy Commissioner may want to look into this.
–Bob.
Posted in considered harmful, Deep Packet Inspection, privacy | No Comments »
Posted by Bob on 13th August 2009
The CRTC approved Bell’s request to charge the customers of third-party ISPs “Usage Based Billing”, to take effect in 90 days (November 2009).
There’s much discussion on DSL Reports. Rocky Gaudrault, the president of Teksavvy ISP, weighs in with some advice: We’ll all need to make a concerted effort to curb our downloading to ensure we don’t give a dime more to Bell than we need to. We all know this is a cash grab and anti-competitive tactic [...]
Teksavvy offers a Premium package for $29.95 with $0.25/GiByte over 200 GiBytes, and an Unlimited package for $39.95, but with the new rates Bell won’t allow Teksavvy to offer an Unlimited package. Customers who use more than 60 GiBytes of bandwidth would be charged an extra $22.50 a month. For Teksavvy’s Premium customers, this is nearly double the current price. Customers who use more than 300 GiBytes in month would be charged an additional $0.75/GiByte. For that extra money you don’t get faster speeds than today. For that extra money you don’t get more downloads than today. For that extra money you don’t get a higher quality Internet. And that extra money goes to Bell, not Teksavvy.
Image from the OpenOffice spreadsheet Teksavvy possible UBB pricing.
Disclaimer: This is presented strictly as a comparison between what Teksavvy offers today and what might be the costs after UBB is implemented. This is sheer speculation; there has been no contact with Teksavvy staff on this.
60 GiBytes isn’t much, today:
- 1 GiByte is about 300 average Flickr photos.
- 1 GiByte is about 3 hours of watching YouTube videos — if you watch an hour a day you’ll use about 10 GiBytes/month.
- Using Bittorrent to download Ubuntu (or a movie) uses about 1.5 GiBytes.
- Downloading one season of a TV show is about 16 GiBytes.
- Downloading one High-Definition movie is about 40 GiBytes.
Remember that this is charged both coming and going, so you’ll be paying for all the spam that arrives in your mailbox, all the ads on websites, all the automatic Windows updates.
Customers who only use e-mail and do a bit of Web surfing probably won’t be affected by the rate increase. But anyone who uses the Internet more than casually will be paying more.
Even worse are the “Chilling Effects” – who’s going to develop new cool Web 2.0 applications if they’re constantly watching the meter to ensure they don’t exceed the 60 GiByte cap? Who’s going to sign up for online video services if the movies exceed the cap?
Canada has certainly fallen behind the technology curve. Usage Based Billing puts Canada in an even worse position than the OECD reported in 2008.
If you want to protest this, submit a complaint to the CRTC.
For the type of application select Tariff, and as a subject, use File Number # 8740-B2-200904989 – Bell Canada – TN 7181. Thanx to Antonio Cangiano for these instructions!
I sent them this complaint:
I was disappointed to learn that the CRTC has approved Bell’s request to charge Usage Based Billing on connections for independent resellers, despite the CRTC’s own admission that most submissions from Canadians are opposed to such a tariff.
Usage Based Billing adds a significant cost to Internet services supplied by independent operators, reducing their ability to differentiate based on bandwidth and price. Worse, Bell’s proposed rates to its own customers appear to be less than what it is charging to independent ISPs. The obvious conclusion is that Bell is trying to eliminate its competition.
Recent reports on global bandwidth have already placed Canada next-to-last in cost per megabyte of bandwidth. This latest tariff will only increase prices for consumers, without providing any increase in service. Canada will surely be in absolute last place globally when the next report is issued.
The CRTC is mandated to provide telecom regulation to benefit Canadians. With this tariff, the only Canadians to benefit are Bell shareholders.
–Bob.
Posted in Bell Canada, considered harmful, CRTC, dslreports, Net Neutrality, teksavvy, usage based billing | 5 Comments »
Posted by Bob on 28th April 2009
Valid HTML is not just useful for browsers. One of the big benefits of having valid HTML is that search engines can properly index your site. If the HTML is invalid, then the search engines may index you incorrectly, or not at all. Google isn’t the only search engine out there, and you want to drive as much traffic to your site as possible.
There appears to be some contention whether valid HTML makes a difference to search engines or not. Some say it doesn’t; or that it depends on the search engine; others have evidence it matters a lot.
Even if you’re not coding by hand, I urge you to have a look at HTML Dog, a set of tutorials on creating valid HTML. When things don’t work as expected you can turn here for examples in XHTML.
http://htmldog.com/
If you’re going to be using an editor for your Web pages, pick an editor that creates proper HTML code. Abandon FrontPage. I suggest using KompoZer, which is based on the same rendering engine as Firefox (Gecko).
http://www.kompozer.net/
You should also be checking your pages in Opera, which is a browser that is even better for standards-compliance than FireFox. The Chief Technology Officer for Opera is the same guy that wrote the Cascading Style Sheets specification, so it has a good pedigree.
http://opera.com
If you’re using Firefox then be sure to check your pages with the HTML Validator addon:
http://users.skynet.be/mgueury/mozilla/
And when you think your site is done, check each page with the full-strength validator:
http://validator.w3.org/
http://jigsaw.w3.org/css-validator/
<heavy sigh… />
–Bob.
Posted in considered harmful, valid html | 5 Comments »
Posted by Bob on 10th December 2008

Coffeine abuse by maciekbor
Over in the
Teksavvy Forum at DSLReports
Rocky Gaudrault, the owner of my ISP,
Teksavvy, started a discussion on blocking port 25 entitled “
Argg…. UCEPROTECT… very frustrating!“. This is
my reply:
Two cents I’d like to contribute:
The UCEPROTECT service isn’t blocking e-mail, it merely provides an opinion on an IP’s reputation as a mail server. Technically, this opinion is expressed with a DNSBL.
When mail doesn’t get delivered, it’s the receiving mail server that blocks it, not UCEPROTECT. The recipient may reject the mail based on the opinion of the DNSBL, but if that DNSBL gives bogus information then the recipient will be blocking legitimate mail. The fault is with the mail recipient for choosing a poor DNSBL. It’s not Teksavvy customers who can’t send e-mail, it’s the recipients who are refusing to accept it.
Even if Teksavvy did block port 25, there’s no guarantee that poor DNSBL services would whitelist Teksavvy’s servers. DNSBLs are run at the whim of their operators, and they can blacklist anything they like. The people who use these services need to understand that they’re letting someone else decide what mail they can receive, completely out of their control.
Port blocking is ineffective as a spam fighting technique — ISPs started port blocking in 2001, but if port blocking is so good, why is there still spam? Most spam still comes from disreputable bulk mailers running large-scale operations. Remember the McColo servers from a few weeks ago? When that one operation was shut down there were reports that spam volumes dropped by 30%. To fight spam, concentrate on the large-scale spammers.
There are lots of spambots running on poorly protected home computers, but that’s a symptom of poor security. Blocking port 25 won’t fix the security problem. To fight poor security it’s far better to identify the compromised computers, and provide them with tech support to fix the problem. Teksavvy is in a better position to do that than any other service provider I know.
There is no benefit to Teksavvy customers in blocking port 25 — It doesn’t protect Teksavvy customers from spam. It might protect other ISP’s customers from Teksavvy spammers, but it also denies Teksavvy customers full access to the Internet. Full, unblocked access is one of the main differentiators that Teksavvy brings to the market. Don’t give that up, Rocky.
Blocking ports also prevents legitimate services. ESMTP extensions like DSN rely on a direct connection to transfer Delivery Status Notifications. If a relay server doesn’t implement DSN then status notifications don’t get through. If port blocking is turned on, the smart host providing the relay service had better implement every ESMTP extension that exists. And that could still block other services that rely on unfettered access to port 25 (iMIP anyone?)
Blocking one port today is the thin edge of the wedge to blocking other services. Already I’ve seen requests for blocking ports 137 and other Netbios ports. If Teksavvy starts port blocking then every time there’s a new vulnerability the Teksavvy execs will need to agonize over whether to block or not. DNS is broken? Block port 53. There’s child porn on Usenet? Block port 119. CRIA threatens to shut down encrypted filesharing? Block port 443. If Teksavvy has a policy of no port blocking, all these decisions are moot.
I left Rogers because of port blocking, and came to Teksavvy because of unfettered access. Please don’t take that away.
–Bob.
Coffeine Abuse by maciekbor is used under a
Creative Commons Attribution license.
Posted in considered harmful, dnsbl, dslreports, port blocking, smtp, teksavvy | 7 Comments »