What Happened to Your Browser When You Weren't Looking

"There's nuthin' to 'em," you may think.

You'd be wrong. 

You were right in the Dark Ages of 1999, but not anymore. The browser you use to read this article is a sophisticated piece of software that automatically and seamlessly interacts with several hundred APIs (Application Programming Interfaces) to get the best possible version of this article onto your screen in the shortest possible time.

That means browsers have access to data and information about your screen. They also know, obviously, the link you want them to display. They run through decision trees to optimize the physical side of your experience.

Some people are saying that also means they can decide what to show you. Nope. That's just an example of, "A little knowledge is a dangerous thing."

Malicious code does exist, but it is not incorporated into browsers. Further, browsers and their related APIs are standards-based. The two primary browsers, Chrome and Firefox follow these standards. Use John Doe's Freeee Souper-Douper Browser and all bets are off. I made that browser up. My apologies to John Doe if it actually exists.

Google spearheads browser development. They're a web company, some may argue that Google is the web. Be that as it may, there is no doubt that Google Chrome is the dominant browser by miles. 

It is in Google's best interests that all traffic flows through a browser, preferably Chrome. Most of it does. Then again, there are those pesky apps that spit out traffic directly.

The Responsive Web and the Progressive Web are Google's answer to mobile apps. A fully responsive, fully progressive website functions so much like a native app that users can't tell the difference. 

Companies can and do tell the difference. 

A single Progressive Web app works seamlessly on anything from an AppleWatch to an 8G Smart TV. No more multiple versions for multiple operating systems. No more updates. No more supporting multiple versions.

One size fits all, and development time is cut dramatically. That means big cost savings. Companies like big cost savings.

The Progressive Web even does stuff with no connectivity. I'm not kidding. If you develop mobile apps for a living, get certified on the Progressive Web. Do it now. Don't wait for Google to kick your teeth in. In a dogfight against Google, you will lose.

The simple stuff: New HTML tags

I talked about this in https://www.bebee.com/producer/@paul-croubalian/is-the-responsive-web-a-mobile-app-killer-pt-1 so I'll just feather-touch it here.

Browsers can't tell how big a file is until they actually download it. By then it's too late to save any time. The obvious solution is to tell the browser which files are available, of which size and let it choose. The new HTML tag, srcset, does just that.

Src (source) is an HTML image tag. Srcset is a set of srcs. It's a lot faster to download a 150K image intended for a phone than a 33Mb image intended for a smart TV. 

Srcset gives the browser the choice of several versions of an image, or even completely different images. It tells the browser how big each file is. The browser is "smart" enough to pick the one that is closest to your device's needs. That is to say, not very smart at all. It just knows to download the image whose size is closest to your device's screen size.

That means pages load as fast as possible for your particular device. That's a good thing.

The not so simple stuff

Everything the browser does in the background is done through some flavor of Javascript. Javascript is a programming language that acts only on the client side, i.e. in the browser. It can also use AJAX methods to access/write to remote databases.

Javascript does not have carte blanche, neither does AJAX. Javascript's limitations make it perfect for secure action. A description of AJAX methods is far beyond the scope of this simple primer. Suffice it to say that AJAX also has built-in limitations, and is not a scouring powder.

Service Workers

You all have workers that work all day, every day. They interact with every customer, every time those customers visit your website. They're never late to work because they never leave. They take no vacations because they don't get tired. They take no sick days because they never get sick. 

They may die on the job, but no one would care if they did. 

IT or Marketing would just replace them. Yes, IT or Marketing would replace them, not Human Resources. These workers aren't H at all so HR doesn't care.

These workers are Service Workers. Service Workers are javascript scripts (yes, I know that sounds funny) that sit between the client (browser) and the web (remote servers). 

The Service Worker checks the browser cache first. If it finds what you asked for, great! It takes it from the cache. Reading from the local cache is way faster than reading from a remote server. 

If whatever you asked for isn't in the cache the Service Worker then looks to the web.

When the web server responds, the Service Worker sends that response along to the browser. A well-written Service Worker will also check for no connectivity or low connectivity (Timeout or what Google calls "lie-fi." That's when your device says it has a connection but doesn't. That's a worse experience than no connectivity at all. You don't even get an error, just a blank screen). When it detects no/low connectivity it can respond from previously stored stuff in the cache.

It's what Google calls "Off-Line First" web app development.

As far as the browser knows, it got what it asked for. It doesn't particularly care where it came from, but you do. Why wait 5 - 15 seconds for a server round trip when you can get the same thing with no discernable lag?

Another use for Service Workers

That red arrow from the server can also start something. For example, a web push notification goes from server to Service Worker. If the notification is to a valid, authorized endpoint (basically just a link that identifies a browser that allowed notifications in the first place), it shows it. It doesn't matter if the sending website is open or not. The Service Worker that controls it is in the browser. 

This type of Service Worker acts more like a listener, waiting for a server to wake it up. That makes them open to misuse. That's why they require express permission from the browser's owner to actually exist. Also, every notification has a "kill switch" built right into it.

Wow, isn't all that stuff dangerous?

Not at all. Well, no more than surfing the web in general anyway. There has been talk that since the Service Worker actually "decides" what you see, it can decide what you "should" see. You would only see what it wants you to see, what it allows you to see.

Nope. It just doesn't work that way. That's more "The Sky is Falling!" than reality. There are safeguards built right in.

The First Line of Defense

The first line of defense is Javascript/AJAX itself. They have limitations on what they can do. Those limitations are intentional. They provide a cushion against unwanted or malicious actions.

The Second Line of Defense

The second line of defense is "scope." That takes some explanation. 

If you are a consultant or a project manager, you are familiar with  Scope of Work documents. Those documents specify what you will do, where you will do it, and when you will do it. Service Workers have their own built-in Scope of Works called, logically enough, "scope."

A (very) brief explanation of Scope

Service Workers can only work in the directory where they are saved or any lower (child) directory. You can override that when the Service Worker is first installed on the browser, but only in the same domain. So, if the Service Worker is in https://www.myTweetPack.com/javascript/serviceWorker.js (not a real link) It will only wake up on any hyperlink that starts with https://www.myTweetPack.com/javascript/. Navigate away and it goes back to sleep.

I can specify that the Service Worker will work on anything that starts with https://www.myTweetPack.com if I want, but nothing else. I can't even specify that it should work on http://www.PaulTheGhost.com, even though that site sits on the same server. PaulTheGhost is a different domain, so the Service Worker will fail to install.

That means I can't have a Service Worker that works on everything, everywhere. The exception to that rule is the web push Service Worker I mentioned. It will work anywhere but it only works on inbound traffic with express user permission that can be easily withdrawn at any time. 

I don't own www.Google.com (no such luck) so I can't install Service Workers there. I can't hijack your requests. No one can.

You may now say, "Yes, but Google does own www.Google.com. They can put whatever they want there!" Okay, that might be an issue if it weren't for the third line of defense.

The Third Line of Defense

The third line of defense is transparency. Service Workers are just Javascript code. They are just text files. The code is visible. 

Anyone with Google developer credentials (free at Google.com) can see which Service Workers are installed in a browser, whether they are actively working or not, and what they do. 

Don't break your head over that. If Google or Firefox tried to play games with their Service Workers they would be outed by the developer community within minutes if not seconds. Nobody wants Big Brother.

The Fourth Line of Defense

The fourth line of defense is another limitation. There's another reason why I can't specify that my Service Worker will work on http://www.PaulTheGhost.com. Only https websites can use Service Workers. 

The process for getting https credentials is more detailed than for a simple http site. It includes verifying ownership before a certificate is granted. That means that those who somehow manage to circumvent Service Workers safeguards can be easily traced and stopped. 

Not all browsers support Service Workers (Yet)

As of December 4th, 2017, only Chrome and Firefox give full support for Service Workers. Mabe "only" shouldn't be used here. Together, Chrome and Firefox cover about 74% of internet users. I was actually surprised that Google Chrome was "only" 58% of the market.

Support is in development for Microsoft Edge. Internet Explorer is on its way out. Microsoft has no plans for IE service worker support. That's strange because IE is actually the third most popular browser with nearly as many users as Firefox. 

Go figure.

Opera and Safari will only offer basic support for Service Workers which may well ring their death knell. True, some people love their Opera and Safari browsers. The two browsers only account for less than 5% of users combined. 

If Chrome and Firefox combine for 74% and Opera plus Safari combine for 5%, what makes up the other 21%? That 21% is mostly antiquated browsers (Ex: Internet Explorer 13.13%) and a few specialty browsers here and there. 

Service Workers make too much sense to ignore. 

My not-so-fearless prediction is that browsers that do not have full support for Service Workers will see their market share dwindle. Eventually, they will face extinction.

Cheers

If this article resonated with you, please share it to Twitter. A share to Twitter triggers a vote for the beBee's Best eZine. 
Thank you