Chrome USB Web Debugging Is Awesome

I’ve been doing a little bit of tuning for mobile devices on some web work that I’d been doing, and wanted to give the Chrome USB Web Debugging a try. For those living under a rock for the past two years, Google added the ability to live-debug websites on mobile devices using the standard Android Debug Bridge and a copy of mobile Chrome. This means you can debug your websites using a real browser, running on real Android tablets and phones. And, because most mobile browsers are based on some form of Webkit (or Blink), this should lead to reasonable market coverage.

In this case, I tested it using my Nexus 7, by activating the option in mobile Chrome:

usb-web-debugging-3-small

After installing the ADB plugin for Google Chrome on the Desktop, the following extension icon shows up in the browser window:

usb-web-debugger-4

Once you’ve started ADB via the plugin menu, you can then “View Inspection Targets” and the following list of inspection targets will open up:

usb-web-debugging-5

Inspecting the Chrome instance on the Nexus 7 device will open up the familiar Developer Tools window, acting on the mobile device target:

usb-web-debugging-1

Inspecting a DOM node on the desktop, highlights it on the mobile device, like you’re used to:

usb-web-debugging-2-small

The great thing is that the debugging session is seamless. You are put in full control of an interactive debugger, all of the CSS inspection and modification is there, you can modify anything you want the Javascript console, set breakpoints, inspect, modify, and continue running stopped code. It all just works, which is pretty much the nicest thing you can say about a piece of software (and incidentally the hardest thing to achieve in software engineering).

In short, it’s a great way to code, debug, and optimize a website using a real mobile web browser.

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