Article

|

So after the preamble, which should give you a frame of reference to what I’m aiming to do in this mini-series of posts about improving my online privacy and security, this short post will talk about the first steps I’m taking to tighten everything up. As this is all at the very beginning of my learning journey, all of these might change in the future. If they do, I will update the post and add a comment below.

In this post I look at two of the fundamentals of privacy on the web: the web browser and search engine. I’m mainly looking at the desktop for now, rather than mobile, mainly because it’s simpler to focus on one thing while I wrap my head around this stuff!

A Change of Browser

I’ve been using Chrome for years, after it usurped Firefox as the “fast, alternative” browser for Windows. These days, Chrome has become seriously bloated – it’s routinely consuming multiple gigabytes of RAM on my desktop. It may be (usually) fast despite of that, but it slows the rest of the computer. What’s more, it’s so deeply wired into Google’s ecosystem that it’s arguably as much a data hoover for Google as it is a browser.

So I was in the market for a new browser to begin with, and I was looking into alternatives like Chromium or Opera. But once I started diving into things a bit more, pretty much every recommendation for privacy-minded software recommended good-old Firefox, so that’s what I’ve gone with. I followed the configuration guide at PrivacyTools.io, as well as:

  • Turn on Do Not Track
  • Set Firefox to never remember my browsing/download/search/form history
  • Never accept third-party cookies
  • Only keep cookies until I close the browser
  • Never remember logins for sites
  • Turned off Firefox Health Report, Telemetry, and Crash Reporter

Extensions

Most of the extensions I had installed in Chrome were privacy-minded anyway, so were equally applicable to Firefox. Some additions came recommended. At the moment I am using the following:

Mobile

The situation on mobile (in my case, iOS) is a bit less clear. For now I’m not using the Chrome iOS app, reverting to Safari with the addition of a content blocker.

Downsides

The biggest issue with the above setup is it removes a few conveniences: remembering pinned tabs between browser sessions; having to login to websites every time you visit; having to retrace your steps to find a page in the future, if you don’t bookmark it at the time… that sort of thing. I might do a little tuning on this, relaxing the settings a little, but overall I think this might be one of those things that I need to live with.

A Change of Search Engine

Apart from a brief flirtation with DuckDuckGo a few years back, I’ve always used Google as my search engine. It’s constantly been the most reliable, fastest, and all-round best at what it does.

Even so, I’ve never been 100% happy with the fact that Google collects just about every data point they can, that it’s all wrapped up in your Google account, linked to everything you do in their other services, and made available for advertisement targetting (amongst who knows how many other things). As someone who’s had a Gmail account since they were invite only, I know Google has a fucktonne of data on me already; the genie is well and truly out of the bottle in that regard.

That doesn’t mean I can’t stop giving them more data. Sure, they’ll get the odd bit here and there when I use YouTube, or the odd email that hits my old, pretty much unused Gmail account, but that’s really it – if I change my search engine to somewhere else.

The obvious thing to do would be to revert back to DuckDuckGo, as I already have experience of it, and it’s accurate enough… but I wanted to try something different for the moment, while I’m still in the learning phase of this little project.

I tried all the recommendations at PrivacyTools.io. Searx generally gave me terrible results, but is an interesting idea; Qwant gave me some decent web results, but the included News results were mostly irrelevant, and I couldn’t find a way to turn these off. StartPage had been recommended in other places too, and overall was the best performing of the bunch – possibly not surprising, as it’s effectively a proxy for Google search, so seems like a win-win in this case. For now, I’ve set it as the default search engine in Firefox.

Mobile

For searches on my iPhone, I’ve set the default search engine to DuckDuckGo, as it’s the best of those available.

Article

|

I know, I know, in theory we should be developing sites that work in every browser and not just targeting specific applications. However, the reality isn’t quite there yet. Support for the different web standards varies massively from vendor to vendor.

Usually we make the decision on how much effort we put into making a site work in a particular browser down to the visitor statistics of that site. If your site only receives a handful of visits from a certain browser, why spend hours – or even days – trying to work around its faults?

So my question is this: just how low should the numbers be before a particular browser gets ‘cut off’? Take, for example, the top 5 browsers in Pixel Meadow’s Mint logs:

  1. Firefox (54%)
  2. Safari (31%)
  3. Internet Explorer (8%)
  4. NetNewsWire, Camino & Opera (2%)
  5. Shrook (1%)

From those numbers it’s clear that I need to support Firefox and Safari (which by extension means support for NetNewsWire and Camino), but what of IE, Opera and Shrook? Do I go out of my way to make sure any future revisions of Pixel Meadow work fully in these browsers, or do I just make sure they’ll degrade gracefully if need be?

Of course, this is assuming an existing site… It stands to reason that a new site with no clear visitor demographics should target as wide as possible until their visitor statistics are known.

note

|

Elastic layouts have been getting a bit of talk over the last few months. John, Roger and Patrick have all talked about them. I use an elastic layout in the new design.

What is an Elastic Layout?

Traditionally, web designers talk about either “fluid” or “fixed” layouts. Fluid layouts change width with the size of the browser window, while fixed layouts are set to a specific width. There are arguments for and against each type. Where elastic layouts fit in, is to try and combine the best of both worlds.

The Theory.

Text sized in em units is scalable in browsers (theoretically). So what if we were to specify the widths of our page elements in ems? Our page elements should scale inline with the size of our text.

The Reality.

Using em units to size page elements does work pretty much as expected. However, there are a few things we need to do to avoid some problems.

Global Reset for Less Hair-Pulling

If you let the browser apply its default font-size, margin, padding and line-height, you’ll be in for a very rough ride. Make things easy – apply the global reset:

*{ font-size: 100%; line-height: 1; margin: 0; padding: 0;} /* Global Reset */

This resizes the text on everything to 100% of the default size (16px by default), sets the height of a line to the size of the text, and removes any default margins or padding. By doing this, we remove a lot of the guess work. I use a percentage value because I’ve found that this makes scaling text a little less error prone in browsers. 1em is now equal to 100% or 16px.

Browsers are Crap at Maths.

All the major browsers suffer from rounding errors to some degree. I must admit that it’s been a while since I checked on this, but both Opera and Safari used to render text sized in ems and percentages wrong – 10px would render as 9px, for example. To get around this, the fix was to size text slightly larger than 100% on the top level element. 100.01% was found to be the magic number. So our global reset becomes:

*{ font-size: 100.01%; line-height: 1; margin: 0; padding: 0;} /* Global Reset */

Make the Maths Easier.

I was never very good at maths (much like the browsers), so working things out in multiples/fractions of 16px wasn’t appealing. It’s also harder to visualise how big 16px is, compared to, say, 10px. So to make things easier to work out and visualise, we reduce our base font size down to 10px (using percentages, this is 62.5%). We can apply this to the html element and it will inherit down the line:

html{ font-size: 62.5%; } /*Resize text to 10px */

1em is now equal to 10px. Much better!

Make Everything an EM.

Well, almost. I’ve found that some browsers (the Gecko ones, mostly), will not render a 0.1em thick border, when 1em = 10px. Any border you want to be equivalent to 1px by default, just make it 1px – it might not scale but it will render. Other than this small caveat, the rest should be sized in em units: margins, paddings, widths, font-sizes… Doing so will make everything proportional to the text size, stopping things looking crowded at larger sizes.

Remember – EM Sizes Compound!

By that, I mean that if you apply a font size of 1.2em to the body tag in our example, then for all elements contained in the body, 1em now equals 12px. So a 3em h1 would be 36px high, not 30px like you might have expected. It’s something you need to be on the lookout for.

A Note About Background Images

Elastic design is geared towards using repeating background images. Unless it’s something like the “Latest Little Thing” icon on the homepage, using non-repeating images will land you with holes in your design where the container is wider than the image. A great example of using repeating background images in elastic layouts is the Elastic Lawn CSS Zen Garden entry.

Give it a Try

With all this talk about maths, compounds, et al, I’ve probably put you off elastic layouts. Don’t be afraid to try them. Once you get in the swing of things, it soon becomes second nature. Practice does make perfect, so all I can say is have a go!