Posted on

Browser Wars and Privacy

A new round of the perennial browser wars has begun. Google Chrome is the current hands-down victor, but don’t be surprised if that changes. The new battleground is privacy. Google will have to fight hard to retain its majority market share. But will our privacy increase? I doubt it. The reason is a long story.

Current Standings

The main browser contenders are Google Chrome, Mozilla Firefox, and Apple Safari. In May 2019, the worldwide standings on all platforms were Chrome 63%, Safari 16% and Firefox 5%. To a certain extent, those numbers represent the distribution of smartphones. Google Android is the most prevalent and the default browser on Android is Chrome. Safari is the default on Apple iPhones. Firefox trails in part because it is not the default anywhere and users have to take the time and trouble to install it. On desktops and laptops in the US, Chrome still runs laps on Firefox and Safari at 64%. Microsoft Internet Explorer and Edge combined, the defaults on Windows computers, come in around 20%, Firefox and Safari trail at around 8%.

Depending on how much consumers value their privacy, these standings may change in months to come.

Last week, the Washington Post lambasted Google Chrome on privacy. Mozilla Firefox has been touting its security and privacy features regularly for the past few months and they have steadily improved their performance to keep up with Chrome.

History

The war used to be the world vs. Microsoft Internet Explorer (IE). The old battle was fought over performance, features, and standards compatibility. Microsoft in the late 90s and early 2000s was feeling safe in its control of the personal computer market; they took an indifferent stance toward emerging browser standards and chose to go their own way with IE, forcing web site developers to write different codes for IE, while following widely accepted standards for the rest. Most consumers were unaware, but it drove engineers crazy.

Eventually, Chrome, Firefox, and Safari moved ahead of IE. Microsoft, in those days, was complacent on web performance, behind the curve on web security, and fighting anti-monopoly suits. Google, Mozilla, and Apple were striving hard to improve performance, security, and adding features while conforming to standards. As a longtime competitor and partner, I can say that Microsoft engineers are second to none, but they floundered in the browser wars and eventually lost to the contenders. Chrome came off as the big winner by concentrating on performance.

Chrome is still the browser performance champion, but their lead is so small, it’s hard for most users to distinguish between the performance of any of the browsers today. I suspect Microsoft struggles because old IE special features are still required by some important customers, which puts constraints on IE that the other browsers don’t face.

The Privacy Battle

In this battle, Firefox appears to have the high ground. Most of Google’s revenue comes from selling ads that are targeted by the information it collects on the habits of the users of its free services like Google search, Gmail, and Chrome. When Chrome ups its privacy game, Google’s potential corporate revenue goes down. This places Google on a razor edge: abuse privacy and the public will quit using its services; increase privacy and ad-targeting gets fuzzy, which will cause revenues to drop.

Mozilla, as a non-profit, has no direct stake in targeting ads and therefore appears to be free to pursue privacy for its users, but it’s complicated.

Even Non-Profits Need Revenue

Mozilla’s 2017 audit states that a large share of its revenue comes from search engines, which pay Mozilla a small amount for each search directed to the search engine. Mozilla has had contracts with Google, Bing, and Yahoo at various times to default searches to these engines. Their current contract default search engine is Google. The auditors note that cancellation of these default search contracts is a substantial risk to Mozilla. Google pays Mozilla with money made from targeted advertising. Therefore, if browsing gets too private, Mozilla still stands to lose revenue. Not as directly as Google, but they are still at risk.

Google, as a public corporation, must keep their revenues up to satisfy their stockholders. Mozilla is a non-profit, but their engineers and other employees do not work for free. To continue to thrive, Mozilla must compete with public corporations for these employees with adequate facilities and wages.

Caution

What does this mean for the public? The high-tech network world is subtly connected and intertwined. TANSTAAFL. There ain’t no such thing as a free lunch. Most free services today are either loss-leaders for paid services, or they are bankrolled by selling data on the habits of the service users. Even when it appears that they are not. Until that basic fact changes, your privacy is on the market.

No matter which browser you choose, it is up to you to select privacy options that correspond to the level of privacy you want.

Posted on

Be Careful With Remote Access

Connected devices on the Internet of Things are cool. I have a friend who looks in on his cats on Whidbey Island with his phone from our house in Ferndale. I love my Bluetooth mouse and being able to start the oven preheating from my office upstairs with my phone. But I wouldn’t want a stranger to have the same access.


To be safe, you must take precautions.

Today, or very soon, most of the electric appliances and many other devices that people interact with will be connected to computer networks. At our house, my wife’s car (not my old truck), our kitchen range and its hood, the dishwasher and the microwave are all set up to connect wirelessly to a computer network (the Internet). We can expect more connected appliances to appear on the market soon. In fact, some claim that it will soon be difficult to acquire any electrical appliances that are not connected to computer networks. Why? Because remote wireless computer control has become a cheap feature for manufacturers to add these days. Unfortunately, connectivity has become less safe in the process.

What has changed

In olden times, say 2010, when a refrigerator manufacturer decided to add remote wireless computer monitoring or control to a new model, they would hire a team of electrical and software engineers to design a chip, circuitry, and control software to embed. The team would come up with a tidy little system that would do exactly what the manufacturer intended. No more, no less.

That’s not how it’s done today. Instead, they buy standard, off-the-shelf components and snap them together. One of those components is likely to be the equivalent of an entire personal computer, complete with a wireless interface and capabilities similar to a typical desktop of a couple decades ago. A complete computer is now cheaper to embed than a custom designed minimal component. Unfortunately, these embedded computers are as easy, sometimes easier, to hack as any desktop, laptop, or phone today.

In my book, Personal Cybersecurity, available at the Ferndale Public Library, I cited the case of an electric teakettle that was easily hacked into by “war drivers” cruising the neighborhood looking for open wireless networks to exploit. That was two years ago. Those kind of exploits are more plentiful and easier today.

Using a cheap little circuit board with an entire PC on board, manufacturers can build the device cheaply and figure out how to use the computing and connectivity later. They can add new features after the device has been manufactured using standard programming. This has a downside. Hacking a refrigerator used to require specialized knowledge of custom controllers and software written in assembler for processors that only a few engineers ever heard of. Now, the code is in high level languages on hardware that is taught in high schools.

For example, Amazon has published simple methods for placing a devices with embedded computers under voice control through their Alexa product. I expect projects like Alexa controlled electric whoozits are showing up at high school science fairs. If Alexa can easily be made to control something, there is a good chance that a hacker can too.

On top of that, a small manufacturer has little or no incentive or expertise to build security into their network-controlled toasters. Companies like Microsoft, Apple, Google, and Facebook have regulators, reputations, and stockholders to hold them accountable to public opinion. A rash of house fires from hacked Apple toasters would send Apple stock into a tailspin, the lights would burn all night in Cupertino, and fixes would be issued in days. You might not even realize that a fix was made. Companies like Apple work that way.

But for a small, no-brand appliance manufacturer, odds are great that nothing would happen. These companies, often located in China or southeast Asia, manufacture a batch of appliances, sell no-brand batches to secondary vendors who label the devices and sell them to the consumer. The department store that sold the hacked toasters and the company that designed and manufactured them may only be loosely and temporarily connected. The manufacturer retains no knowledge of what happened to the vulnerable devices or how to contact the final owners. The seller may be accountable but that’s little comfort after the house burns down.

What can you do to be safe?

•    Read the specifications and manuals for electrical appliances carefully. Be aware of the device’s networking capabilities, especially wireless connections. The FCC requires all radio transmitting and receiving devices to register. An FCC id number is a clue that the device can connect to a computer network, including the Internet.

•    If you don’t have a good use for remote connection of a device, turn the remote connection facility off. If you can’t turn remote access off, consider replacing the item. Chalk the expense up to lessons learned and sleep a little more soundly.

•     You may have a good use for connectivity. Surveillance cameras that you can access from your phone are an example. When properly secured, the risk of being hacked can be managed.

•    Before you buy, research. You can often find security-oriented reviews. Read the documentation on the device. If secure access to the device is not documented, don’t buy it. Find an equivalent device that is secured. Follow the security recommendations.

•    Many of these devices come with a default username like “admin” and a password like “password.” You must change these. The password is most important. Use a strong password. A long random sequence of upper- and lower-case letters, numbers, and symbols is best. The easier a password is to remember, the easier for a determined hacker to crack. Record the password safely. I use a password manager. Writing it down in a safe place is good too. If you lose the password, you may “brick” (permanently disable) the device.

•    Use caution with Bluetooth devices. Most are easy to eavesdrop on. Bluetooth can be secure, but it is often a hassle and manufacturers often skip security over convenience. I’ve written about Bluetooth security here.
Posted on

Blockchain Made Simple

Blockchain! Blockchain! Blockchain! That ought to get some attention. If anyone hasn’t noticed, blockchain is somewhere near the hysteria phase of the hype cycle. Everyone associates blockchain with digital currency. The apparent bubble around Bitcoin and other digital or crypto currencies adds to the intensity of the discussion. But very few people have a firm grasp of what blockchain is and it’s potential. In this blog, I will differentiate blockchain from digital currency and discuss block chain’s potential for profoundly disrupting commerce and society.

Not a single technology

First, blockchain is not a single technology. Like email, or a packet network, blockchain is a method of communication with certain qualities that many different technologies can be used to implement. The most popular implementations of blockchain (Bitcoin and its ilk) use specific technology that relies on cryptographic signatures for verifying a sequence of transactions. However, tying blockchain to a specific technology is unnecessarily limiting. The term “secure distributed ledger” is more descriptive, but secure distributed ledger is also pedantic and long-winded, so most people will continue to call it blockchain.

Essential blockchain

In essence, blockchain is a definitive statement of the result of a series of transactions that does not rely on a central authority for its validity. Putting it another way, contributions to a block chain may come from many different sources. Although the contributions are authenticated, they are not controlled by a central authority.

Think about real estate and deeds. Possession of real estate relies on courts and official records that validate ownership of physical lumps of earth. A central authority, in the form of a county records office has the official record of transactions that prove the ownership of parcels of physical land. Courts, lawyers, surveyors, title companies and individuals all contribute to the record. If you want to research the ownership of a parcel in another county, state, or country you either travel or hope that the local authority has put the records on-line and keeps them current. If you want to record a survey, deed or a sale, you must present the paperwork to the controlling local authority.

If you want to put together a real estate transaction that depends on interlocking simultaneous ownership by a complex structure of partners in parcels spread over several jurisdictions, the bureaucratic maneuvering and paperwork to complete the transaction is daunting.

Blockchain could be used to build a fully validated and universally accessible land records office that does not rely on a local authority. Instead of interacting with local jurisdictions, the blockchain would validate land information and contracts, simplifying and reducing the cost of land ownership deals.

This type of problem repeats itself in many different realms. Ownership of intellectual property, particularly digital intellectual property that travels from person to person and location to location at the speed of light presents similar problems.

Blockchains and distributed transactional databases

Although blockchain is implemented quite differently from a traditional distributed transactional database, it performs many of the same functions. Distributed transactional databases are nothing new. In preparing to write this blog, I pulled a thirty-year-old reference book from my shelf for a quick review. A distributed database is a database in which data is stored on a several computers. The data may be distinct (disjoint) or it may overlap, but the data on each computer is not a simple replica of the data on other computers in the distribution.

A transactional database is one in which each query or change to the database is a clearly defined transaction whose outcome is totally predictable based on itself and the sequence of prior transactions. For example, the amount of cash in your bank account depends on the sequence of prior deposits and withdrawals. By keeping close control of the order and amounts of transactions, your bank’s account database always accurately shows how much money you have in your account. If some transactions were not recorded, or recorded out of order, at some instance your account balance would be incorrect. You rely on the integrity of your bank for assurance that all transactions are correctly recorded.

The value added when a database is distributed is that individual databases can be smaller and maintained close to the physical origin of the data or by experts familiar with the data in the contributing database. Consequently, distributed data can be of higher quality and quicker to maintain than the enormous data lakes in central databases.

Both transactional and distributed databases are both common and easy to implement, or at least they have been implemented so many times, the techniques are well known. But when databases are supposed to be both distributed and keep transactional discipline, troubles pop up like a flush of weeds after a spring rain.

Distributed transactional databases in practice

The nasty secret is that although distributed transactional databases using something called “two-phase commit” are sound in theory and desirable to the point of sometimes being called a holy grail, in practice, they don’t work that well. If networks were reliable, distributed transactional database systems would work well and likely would have become common twenty years ago, but computer networks are not reliable. They are designed to work very well most of the time, but the inevitable trade-off is that two computers connected to the network cannot be guaranteed to be able to communicate successfully in any designated time interval. A mathematical theorem proves the inevitable trade off.

Look at a scaled up system, for example Amazon’s ordering system; if records were distributed between the distribution centers from which goods are shipped, the sources of the goods, and Amazon’s accounting system, a single order might require thousands of nearly simultaneous connections to start the goods on their way to the customer. These connections might reach over the entire globe. The probability that any one of those connections will be blocked long enough to stall the transaction is intolerably high.

Therefore, practical systems are designed to be as resilient as possible to network interruptions. In general, this means making sure that all the critical connections are within the same datacenter, which is designed with ample redundancy to guarantee that business will not halt when a daydreaming employee trips on a stray cable.

Reliable, performant transactional systems avoid widely distributed transactions. Accounts are kept in central databases and most transactions are between a local machine running a browser and a central system running in a cloud datacenter. The central database may be continuously backed up to one or more remote datacenters and the system may be prepared flip over to an alternative backup system whenever needed, but there is still a definitive central database at all times. When you buy a book on Amazon, you don’t have to wait for computers in different corners of the country and the world to chime in with assent before the transaction will complete.

That is all well and good for Amazon, where sales transactions in an enterprise resource planning database (accounting system to non-enterprise system wonks) makes sense, but not for problems that involve the coordination of many sources of truth, like the jurisdictions in our land records example above. In that case, each records office is the definitive source of truth for its share of the transaction, but there is no central authority that rules them all and we spend days and weeks wading through a snake pit of physical contacts and possibly erroneous paper when we cross jurisdictional boundaries.

Practical blockchain

This is where blockchain comes in. Imagine a land record system where rights, records, and surveys for a parcel of real estate were all recorded and anyone could record information and transfer rights by presenting a credential that proves they hold a given right, then transfer the right to a properly credentialed recipient all within a single computer interface. A chain of transactions stretching back to the beginning of the blockchain verify the participants’ data and rights. The identities of the rights holders could be required to be public or not depending on the needs of the system, but the participants can always present verifiable credentials to prove they are agents holding the rights they assert or are an authority for the data they contribute. And all this authenticated data spread over many different computer systems.

Digital currency

This is basically the way crypto currencies work. When a Bitcoin is acquired, its value is backed by a verifiable record tracing the transfers of the coin back to its moment of origin. Maintaining the record is the work of many computers distributed all over the world. Bitcoin solves the problem of the cost of maintaining the record by offering freelance maintainers, called miners, bitcoins in return for performing the maintenance. The integrity of the record is maintained through elaborate cryptographic protocols and controls. Bitcoin and similar currencies are designed to be untraceable: purchasing or selling Bitcoins require credentials, but not identities of the participants. Anonymity makes Bitcoins attractive for secret or illegal transactions.

A downside of the Bitcoin-type blockchain is the tremendous amount of expensive computing required to maintain the blockchain. In addition, some critics have charged that Bitcoin-type currencies are enormously complex schemes that promise profits based on future investments rather than true increases in value, which amounts to a Ponzi scheme. Whether Bitcoin is a Ponzi scheme is open to argument.

The red herring

Unfortunately, the crypto-currency craze is a red herring that distracts attention from blockchain’s profound disruptive potential. Stock, bond, and commodity exchanges, land record offices, supply chain accounting and ordering, tracking sales of digital assets like eBooks, and many other types of exchange rely on central clearing houses that charge for each transaction. These clearing houses facilitate exchange and collect fees without contributing substantial value. Blockchain has the potential to simplify and speed transactions and eliminate these middlemen, like Uber eliminates taxi fleets and online travel apps eliminate travel agents. Amazon eliminated publishers and literary agents for eBooks and blockchain could eliminate Amazon from eBook sales.

How can this work without a central authority holding the records of the transactions? The underlying concept is that as long as the blockchain is maintained according to rules known to a group of maintainers, no one maintainer need have central control as long as the other maintainers can detect when somebody fudges something. A proper blockchain algorithm is physically impossible to maintain in ways contrary to the rules. There is more than one way to do it. The Bitcoin model is not the only way to implement a blockchain. Paid miners and anonymity are not inherent in blockchains.

For example, an author could register an electronic document with an electronic book block chain registry. Readers could enter into a contract with the author for the right to access to the book. These contracts could be registered in the blockchain. Readers could relinquish their contracts with the author or transfer their contract to another reader and lose the right to access to the book.  The rules depend on the contracts represented in the blockchain, not the technology. Additional technology such as cryptographic keys might be used to enforce contracted book access. Unlike current DRM schemes, no authority like a publisher or an Amazon is involved, only the author, the reader, and the transaction record in the blockchain.

I’ll get more into how it’s done in another blog.