Quite Possibly

Quite possibly the world’s worst-labeled option on a WordPress plugin:

Force SSL Exclusively - Any page that is not secured via Force SSL or URL Filters will be redirected to HTTP.

What you might assume, as I did, is that setting this option would enable HTTPS to be used on the entire WordPress installation and that it would make the site exclusively HTTPS-based. And you’d be wrong, too.

Instead the option really means: “If you set this, you have to explicitly mark each and every post you want to be secured by HTTPS. Your entire site will now remain completely HTTP-only.” And somewhat snidely, it might add: “Thanks for defeating the purpose of this plugin!”

Now, I can’t imagine who would actually want to do that, and/or what their site configuration would look like. But HTTPS always seems to me to be an all-or-nothing proposition and this mis-labeled option only led to time wasted looking for a culprit in the .htaccess file, in the mod_rewrite rules, the wp-config file, and elsewhere.

Abort trap: 6

If you see OS X generating some error like this at runtime:

App(7990,0×101294000) malloc: *** error for object 0x7f8f5c801038: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6

You could be attempting to free something that wasn’t malloc’d by the C library. It’s a pretty-weird bug I just ran across while attempting to free the contents of a syscall-returned linked-list individually (not always the best idea, but in this case it would have made a particular problem easier to solve).

Note, this is definitely not a nullptr dereference or free(), it was a valid pointer in the linked-list chain, but I still hit an abort() call in the malloc library.

Stateful vs. Stateless Browsing (Improving Your Privacy Online)

I’ve been thinking about how to reduce the trail of information I leave behind while surfing the web.

When the web was first invented, it was, by definition, a stateless place. There was no read/write web, PHP was still a glimmer in its inventors’ eyes, and dynamically-generated content was still the domain of those hardy Perl hackers who could stand writing code for ~/cgi-bin. Things were far less interactive. You browsed to websites, and those websites recorded some minimal information about you to their log files: your Internet Protocol address, what browser you were using (via the User Agent header), essentially just information that was part of the protocol.

In the mid-1990s, Bell Labs and Netscape introduced the cookie specification for the purpose of enabling web commerce, with the unintended consequence of transforming the entire web into a highly stateful place. (Ok, the RFC states the reverse, but we all know what really happened.) Now all of your previous interactions with a website could be in some way encoded, preserved, and recalled via the magic of a browser cookie, even by unintended websites that you may just have brushed up against like so much poison ivy. The ease with which third parties have been tracking our online behaviors, of course, has never been the same.

To reduce one’s web footprint, common tricks were applied: Using Ad- and Flash-blocker plugins in Google Chrome or Mozilla Firefox was one, using an /etc/hosts file was another.

These were things I’d already tried. But with the newer versions of Chrome, I’d begun to use multiple user profiles to specifically separate the profiles that I presented to online services. I had a profile for Facebook, a profile for Google Docs and Analytics, one for my web development work, and so on. The user credentials, cookies, and tracking data in each profile were kept entirely separate from one another, perhaps giving some websites the impression that I was several different people. It was all a bit tedious and, actually, sub-optimal.

I realized:

The more natural usage-pattern split is between stateful and stateless browsing habits.

In other words:

  • If I must be logged in to interact meaningfully with a website, to ensure that it knows who I am or to maintain a shopping cart full of goods, that’s a stateful transaction.
  • If I don’t need to be logged in to receive information from a website, because it doesn’t need to care about who I am or keep track of an order I’ve placed, that’s a stateless transaction.

Examples:

Stateful browsing (example) Stateless browsing
Webmail (Gmail) Plain old web browsing, even using Google Search, can be a stateless affair.

No more ads showing up on partnering display networks immediately after you've googled something!

Any kind of browsing where your actions on a webserver are read-only can be stateless.
Social Networks (Facebook)
Shopping (Amazon, eBay)
Source repositories (github)
Bugtracking Services (Redmine)

There are a handful of websites I use regularly that need cookies to function properly: Tandem Exchange, the issue tracking system for Tandem Exchange, Google AdWords, Google Analytics, Google Docs, Facebook, Twitter, Odnoklassniki, VKontakte, and a range of other social networks I use to test social login capabilities. These sites have a legitimate need for cookies, since without them, I can’t prove my identity and access rights.

For everything else, I go stateless.

It turns out, actually, that you can turn cookies off completely for any kind of web browsing where you’re just reading something or looking something up. Unless it’s behind a paywall, or some other access control mechanism, plain web surfing does not require cookies, and may even be better that way (since the website can’t suggest more crap for you to look at, based upon the things it thinks you like). All of your requests must be interpreted as neutral requests. The sort of tuning, customization, filtering, and presentation of the web to your exact preferences and prejudices, can not happen, since each request has to be treated impartially.

So that’s what I’ve done. I’ve created one user profile, in which all the cookies and nasty bits of tracking can occur; and I’ve created a second user profile, in which I accept absolutely none of it. Another way to think about it is that I have a profile that I explicitly allow everyone to know everything about, and I have a profile that no one knows anything about. Whenever I’m required to log into a web service, I use the first profile. Whenever I just want to look something up and browse anonymously (which is 99% of the time), I use the second profile.

Keep in mind, also, that Incognito Mode on Chrome still accepts cookies from all sources. So you may think you’re not being followed around, but you still will be.

Settings (in Chrome)

Create two user profiles via the Settings page:

Guess which one is which?

Then just set the profile settings as follows, and use the profiles as appropriate.

Stateful Stateless
doofus-cookies ninja-cookies
plugins-stateful plugin-stateless
privacy-settings-stateful privacy-settings-stateless

libevent, gcov, lcov, and OS X

Getting a sense of code coverage for open-source projects is necessary due-diligence for any dependent project. On OS X, it’s also a little more work. While doing some of my own research, I wanted to see how well tested the libevent library was, but wasn’t finding much info online. So here’s a log of what I needed to do, to get this information on a Mac.

First things first (and this should apply for many more open-source projects), after I checked out the latest code from github, I added an option to the configure.ac Autoconf source file to insert the necessary profiling code calls for code coverage:

With that added, I reran the autogen.sh file, which pulls in the configure.ac file, and regenerates the configure script, and then I ran ./configure --enable-coverage.

Then I ran make and specified clang as the C compiler instead of old-school gcc. Besides better code quality and error reports, only clang will generate the coverage code. The Apple version of gcc did not do so, leading to some initial confusion.

Once the build was complete, I ran the regression tests with:

Unfortunately, the following error occurred:

So I tried running tests/regress directly and saw:

Oops.

Turns out that Apple uses the profile_rt library to handle code coverage instead of the former gcov library, which is why the _llvm_gcda_start_file function symbol is missing. So I linked to the libprofile_rt.dylib library by specifying LDFLAGS=-lprofile_rt on the make command line:

Rerunning make verify, the following was output, which indicated which of the event notification subsystems were available and being tested on the system:

Once the regression tests finished, the coverage data became available in the form of *.gcno and *.gcda files in the test/ folder and in the .libs/ folder.

Running lcov generated easier-to-interpret HTML files:

Once lcov finished, all I had to do was open up html/index.html and see how much code the coverage tests executed. (And panic? In this case, 14.5% coverage seems pretty low!)

Here’s what the lcov summary looks like:

lcov-libevent

I reran the test/regress command to see if that would help, and it did push the coverage rate to 20%, but I need more insight into how the coverage tests are laid out, to see what else I can do. It is not clear how well the coverage tools work on multiplatform libraries like libevent, which have configurably-included backend code that may or may not run on the platform under test. In these cases, entire sections of code can be safely ignored. But it is unclear that code coverage tools in general are going to be aware of the preprocessor conditions that were used to build a piece of software (nor would I trust most coverage tools to be able to apply those rules to a piece of source code, especially if that code is written in C++).

In any case, like I said in a previous entry, coverage ultimately is not proof of correct behavior, but it is a good start to see what parts of your code may need more attention for quality assurance tests.