Tag: privacy

(ISC)2 Security Congress 2018 Presentation

Here are slides for my presentation, “DevOps Is Automation, DevSecOps Is People.” It’s about exercising communication skills, establishing empathy, and considering threat models that consider people.

Communication skills are a part of inserting security into the DevOps process. Empathy is about understanding not only the engineering constraints that DevOps teams face, but also the population of users who will be using an application. We have references for technical flaws and weaknesses like the OWASP Top 10 and the related ASVS. We don’t have as many easy references for the people aspect of security.

Apps are built through collaboration and they’re built for people to use. Security should work as an enabler for DevOps teams to create more secure apps. Part of that security comes from acknowledging that the people who use apps aren’t a monolithic population with static threat models. Threat models should still reference the OWASP Top 10 and STRIDE. Those provide good ways to reason through technical issues in order to build technical controls. But those threat models also need to consider social dimensions of security, such as privacy, abuse, and whether the user experience influences good security behaviors or addresses threats facing those who use the app.

Part of the presentation shows how role-playing games are frameworks for groups to build shared stories, which is relevant to building secure apps. That sense of collaboration, which still involves conflict, is a great way to exercise the skills necessary to work with DevOps teams and has metaphors for understanding how different users face different threats. In an RPG, everyone gets to roll dice. In appsec, everyone should have security that addresses their needs. Collaborative approaches avoid the unproductive attempts to blame devs or users and instead focus on meaningful solutions.

OURSA Recap

Last week I attended the OURSA conference. I tweeted during the conference and wrote up some reasons why I enjoyed the content so much. Briefly, the format (~15 minute presentations followed by panel discussion) kept the themes well-focused. It was also impressive that the conference stayed so well on schedule. But these are more superficial  observations about the execution of the conference. The content and quality of presentations was what really kept my attention throughout the day.

Read some more at https://blog.cobalt.io/oursa-their-presentations-and-your-follow-up-2ba6240f4559.

Check out the recording of the event at https://youtu.be/pcUDzHb4Gdo.

 

Now One Week All Year

The annual summer conference constellation of the week of Black Hat, BSides, and DEF CON usually brings out a certain vocal concern about personal device security. Some of the concern is grounded in wry humor, using mirth to illustrate a point. Some of it floats on ignorance tainted with misapplied knowledge. That’s fine. Perform the rituals and incantations that make you feel better. Enjoy the conferences, have fun, share some knowledge, learn some skills.

But after you select a level of extra precaution. Ask why such a choice is necessary for one week of the year. It’s a question without a single answer. As a leading question, it’s intended to elicit reasons based on a coherent threat model that addresses the week’s anticipated behaviors and environments. As an antagonistic question, it’s intended to explore why “default secure” is insufficient or why, after more than two decades of one-week-a-year concern, system and device security is so poor that none of it can be trusted outside your home network.

As you ponder an answer, take a moment to help someone else improve their baseline security profile.

  • For a mobile device, set a passcode longer than four characters.
  • For a mobile device, enable Touch ID or similar biometric feature.
  • Turn on automatic updates.
  • Enable multi-factor authentication (MFA, 2FA, Security Key, App Authenticator, or whatever synonym it supports) for their email, social media, and financial accounts.
  • Record and save recovery codes associated with enabling MFA. Help them choose an effective storage, such as printed and placed somewhere safe or in a password-protected keychain.

As a follow-up to enabling MFA, help them update and make unique each of their passwords.

  • Install a password manager.
  • Starting with their most-used sites, go through the password change process and allow the password manager to assign a new, unique password. If they wish to have a memorable password, ensure that it’s only used for that account.
  • Review any OAuth or Social Logins used for the account, e.g. if they use Facebook, Twitter, LinkedIn, or similar to authenticate to the site or to allow access to their social account.

Now consider that there are people whose security precautions require attention 52 weeks of the year. People who have expressed an opinion. People who are women. People in abusive relationships. People without political representation, let alone power. These are different situations that need different approaches to securing devices and data.

These are people who can’t buy a “burner phone” for one week, then return to normal. Their normal isn’t the vague threat of a hostile network. It’s the direct threat from hostile actors — those with physical access to their devices, or maybe just knowledge of their passwords, or possibly just knowledge of their existence. But in each case an actor or actors who desire to obtain access to their identity, data, and accounts.

After helping someone with the basic security hygiene of setting strong passwords and turning on automatic updates, gather resources for how to deal with different threat models and different levels of concern. Help them translate those concerns into ways of protecting accounts and data.

One resource to start with could be https://onlinesafety.feministfrequency.com/.

There’s a trope in infosec that this week has “the most hostile network” ever. A network may indeed be hostile, but a hostile playground network is far different from the threats against a network people use on a daily basis.

It can be fun as well as a great educational experience to attack a playground network. On the other hand, networks that no one can use or be expected to use aren’t reflective of security engineering. If you think a network can never be secured or a device never be safe, then you’ve possibly skipped over the exercise of threat modeling and making choices based on risk.

Why You Should Always Use HTTPS

Two keys, crossedThis first appeared on Mashable in May 2011. Five years later, the SSL Pulse notes only 76% of the top 200K web sites fully support TLS 1.2, with a quarter of them still supporting the egregiously insecure SSLv3. While Let’s Encrypt makes TLS certs more attainable, administrators must also maintain their sites’ TLS configuration to use the best protocols and ciphers available. Check out www.ssllabs.com to test your site.

The next time you visit a cafe to sip coffee and surf on some free Wi-Fi, try an experiment: Log in to some of your usual sites. Then, with a smile, hand the keyboard over to a stranger. Now walk away for 20 minutes. Remember to pick up your laptop before you leave.

While the scenario may seem silly, it essentially happens each time you visit a website that doesn’t bother to encrypt the traffic to your browser — in other words, sites using HTTP instead of HTTPS.

The encryption within HTTPS is intended to provide benefits like confidentiality, integrity and identity. Your information remains confidential from prying eyes because only your browser and the server can decrypt the traffic. Integrity protects the data from being modified without your knowledge. We’ll address identity in a bit.

There’s an important distinction between tweeting to the world or sharing thoughts on Facebook and having your browsing activity going over unencrypted HTTP. You intentionally share tweets, likes, pics and thoughts. The lack of encryption means you’re unintentionally exposing the controls necessary to share such things. It’s the difference between someone viewing your profile and taking control of your keyboard.

The Spy Who Sniffed Me

We most often hear about hackers attacking websites, but it’s just as easy and lucrative to attack your browser. One method is to deliver malware or lull someone into visiting a spoofed site (phishing). Those techniques don’t require targeting a specific victim. They can be launched scattershot from anywhere on the web, regardless of the attacker’s geographic or network relationship to the victim. Another kind of attack, sniffing, requires proximity to the victim but is no less potent or worrisome.

Sniffing attacks watch the traffic to and from the victim’s web browser. (In fact, all of the computer’s traffic is visible, but we’re only worried about websites for now.) The only catch is that the attacker needs to be able to see the communication channel. The easiest way for an attacker to do this is to sit next to one of the end points, either the web server or the web browser. Unencrypted wireless networks — think of cafes, libraries, and airports — make it easy to find the browser’s end point because the traffic is visible to anyone who can obtain that network’s signal.

Encryption defeats sniffing attacks by concealing the traffic’s meaning from all except those who know the secret to decrypting it. The traffic remains visible to the sniffer, but it appears as streams of random bytes rather than HTML, links, cookies and passwords. The trick is understanding where to apply encryption in order to protect your data. For example, wireless networks can be encrypted, but the history of wireless security is laden with egregious mistakes. And it’s not necessarily the correct solution.

The first wireless encryption scheme was called WEP. It was the security equivalent of pig latin. It seems secret at first. Then the novelty wears off once you realize everyone knows what ixnay on the ottenray means, even if they don’t know the movie reference. WEP required a password to join the network, but the protocol’s poor encryption exposed enough hints about the password that someone with a wireless sniffer could reverse engineer. This was a fatal flaw, because the time required to crack the password was a fraction of that needed to blindly guess the password with a brute force attack: a matter of hours (or less) instead of weeks.

Security improvements were attempted for Wi-Fi, but many turned out to be failures since they just metaphorically replaced pig latin with an obfuscation more along the lines of Klingon (or Quenya, depending on your fandom leanings). The problem was finding an encryption scheme that protected the password well enough that attackers would be forced to fall back to the inefficient brute force attack. The security goal is a Tower of Babel, with languages that only your computer and the wireless access point could understand — and which don’t drop hints for attackers. Protocols like WPA2 accomplish this far better than WEP ever did.

Whereas you’ll find it easy to set up WPA2 on your home network, you’ll find it sadly missing on the ubiquitous public Wi-Fi services of cafes and airplanes. They usually avoid encryption altogether. Even still, encrypted networks that use a single password for access merely reduce the pool of attackers from everyone to everyone who knows the password (which may be a larger number than you expect).

We’ve been paying attention to public spaces, but the problem spans all kinds of networks. In fact, sniffing attacks are just as feasible in corporate environments. They only differ in terms of the type of threat, and who might be carrying out the sniffing attack. Fundamentally, HTTPS is required to protect your data.

S For Secure

Sites that don’t use HTTPS judiciously are crippling the privacy controls you thought were protecting your data. Websites’ adoption of opt-in sharing and straightforward privacy settings are laudable. Those measures restrict the amount of information about you that leaks from websites (at least they’re supposed to). Yet they have no bearing on sniffing attacks if the site doesn’t encrypt traffic. This is why sites like Facebook and Twitter recently made HTTPS always available to users who care to turn it on — it’s off by default.

If my linguistic metaphors have left you with no understanding of the technical steps to execute sniffing attacks, you can quite easily execute these attacks with readily-available tools. A recent one is a plugin you can add to your Firefox browser. The plugin, called Firesheep, enables mouse-click hacking for sites like Amazon, Facebook, Twitter and others. The creation of the plugin demonstrates that technical attacks can be put into the hands of anyone who wishes to be mischievous, unethical, or malicious.

To be clear, sniffing attacks don’t need to grab your password in order to impersonate you. Web apps that use HTTPS for authentication protect your password. If they use regular HTTP after you log in, they’re not protecting your privacy or your temporary identity.

We need to take an existential diversion here to distinguish between “you” as the person visiting a website and the “you” that the website knows. Websites speak to browsers. They don’t (yet?) reach beyond the screen to know that you are in fact who you say you are. The username and password you supply for the login page are supposed to prove your identity because you are ostensibly the only one who knows them. So that you only need authenticate once, the website assigns a cookie to your browser. From then on, that cookie is your identity: a handful of bits.

These identifying cookies need to be a shared secret — a value known to no one but your browser and the website. Otherwise, someone else could use your cookie value to impersonate you.

Mobile apps are ignoring the improvements that web browsers have made in protecting our privacy and security. Some of the fault lies with the HTML and HTTP that underlies the web. HTTP becomes creaky once you try to implement strong authentication mechanisms on top of it, mostly because of our friend the cookie. Some fault lies with app developers. For example, Twitter provides a setting to ensure you always access the web site with HTTPS. However, third-party apps that use Twitter’s APIs might not be so diligent. While your password might still be protected with HTTPS, the app might fall back to HTTP for all other traffic — including the cookie that identifies you.

Google suffered embarrassment recently when 99% of its Android-based phones were shown to be vulnerable to impersonation attacks. The problem is compounded by the sheer number of phones and the difficulty of patching them. Furthermore, the identifying cookies (authTokens) were used for syncing, which means they’d traverse the network automatically regardless of the user’s activity. This is exactly the problem that comes with lack of encryption, cookies, and users who want to be connected anywhere they go.

Notice that there’s been no mention of money or credit cards being sniffed. Who cares about those when you can compromise someone’s email account? Email is almost universally used as a password reset mechanism. If you can read someone’s email, then you can obtain the password for just about any website they use, from gaming to banking to corporate environments. Most of this information has value.

S For Sometimes

Sadly, it seems that money and corporate embarrassment motivates protective measures far more often than privacy concerns. Some websites have started to implement a more rigorous enforcement of HTTPS connections called HTTP Strict Transport Security (HSTS). Paypal, whose users have long been victims of money-draining phishing attacks, was one of the first sites to use HSTS to prevent malicious sites from fooling browsers into switching to HTTP or spoofing pages. Like any good security measure, HSTS is transparent to the user. All you need is a browser that supports it (most do) and a website to require it (most don’t).

Improvements like HSTS should be encouraged. HTTPS is inarguably an important protection. However, the protocol has its share of weaknesses and determined attackers. Plus, HTTPS only protects against certain types of attacks; it has no bearing on cross-site scripting, SQL injection, or a myriad of other vulnerabilities. The security community is neither ignorant of these problems nor lacking in solutions. Yet the roll out of better protocols like DNSSEC has been glacial. Never the less, HTTPS helps as much today as it will tomorrow. The lock icon on your browser that indicates a site uses HTTPS may be minuscule, but the protection it affords is significant.

Many of the attacks and privacy references noted in the article may seem dated, but they are no less relevant.

DNSSEC has indeed been glacial. It took Google until January 2013 to support it. Cloudflare reported in October 2014 that wide adoption remained “in its infancy.”

And perhaps a final irony? At the time this article first appeared, WordPress didn’t support HTTPS for custom domain names, e.g. deadliestwebattacks.com. To this day, Mashable still won’t serve the article over HTTPS without a hostname mismatch error.

RSA APJ 2014, CDS-W07 Slides

Here are the slides for my presentation, Building and Breaking Privacy Barriers, at this year’s RSA Asia Pacific and Japan conference in Singapore.

The slides convey more theory than practical examples, but the ideas should come across without too much confusion. I expect to revisit the idea of a Rot network (a play on Tor) and toy with an implementation. Instead of blocking tracking bugs, the concept is to reduce their utility by sharing them across unrelated browsers — essentially polluting the data.

In any case, with this presentation over and out of the way, it’s time to start working on more articles!

RSA USA 2014, DSP-R04A Slides

Here are the slides for my presentation, DSP-R04A Is Your Browser a User Agent or a Double Agent?, at this year’s RSA USA conference in San Francisco.

This departed from a security focus into the realm of privacy, noting how browsers struggle (or not) against tracking mechanisms and how various organizations build views of web site visitors.

The Rank Decay Contingency

The idea: Penalize a site’s ranking in search engine results if the site suffers a security breach.

Now, for some background and details…

In December 2013 Target revealed that it had suffered a significant breach that exposed over 40 million credit card numbers. A month later it upped the count to 70 million and noted the stolen information included customers’ names, mailing addresses, phone numbers, and email addresses.

Does anybody care?

Or rather, what do they care about? Sure, the media likes stories about hacking, especially ones that affect millions of their readers. The security community marks it as another failure to point to. Banks will have to reissue cards and their fraud departments be more vigilant. Target will bear some costs. But will customers really avoid it to any degree?

Years ago, in 2007, a different company disclosed its discovery of a significant breach that affected at least 40 million credit cards. Check out the following graph of the stock price of the company (TJX Holdings) from 2006 to the end of 2013.

TJX Price 2006-2014
TJX Price 2006-2014

Notice the dip in 2009 and the nice angle of recovery. The company’s stock didn’t take a hit until 2009 when TJX announced terms of its settlement. The price nose-dived, only to steadily recover as consumers stopped caring and spent money (amongst any number of arbitrary reasons, markets not being as rational or objective as one might wish).

Consider who bears the cost of breaches like these. Ultimately, merchants pay higher fees to accept credit cards, consumers pay higher fees to have cards. And, yes, TJX paid in lost valuation over a rather long period (roughly a year), but only when the settlement was announced — not when the breach occurred. The settlement suggests that lax security has consequences, but a breach in and of itself might not.

Truth of Consequences

But what if a company weighs the costs of a breach as more favorable than the costs of increasing security efforts? What if a company doesn’t even deal with financial information and therefore has no exposure to losses related to fraud? What about companies that deal in personal information or data, like Snapchat?

Now check out another chart. The following data from Quantcast shows daily visitors to a lyrics site. The number is steady until one day — boom! — visits drop by over 60% when the site is relegated to the backwaters of search results.

RapGenius Quantcast Measure

Google caught the site (Rap Genius) undertaking sociopathic search optimization techniques like spreading link spam. Not only does spammy, vapid content annoy users, but Google ostensibly suffers by losing users who flee poor quality results for alternate engines. (How much impact it has on advertising revenue is a different matter.) Google loses revenue if advertisers care about where the users are or they perceive the value of users to be low.

The two previous charts have different time scales and measure different dimensions. But there’s an underlying sense that they reflect values that companies care about.

Rank Decay

Think back to the Target breach. (Or TJX, or any one of many breaches reported over the years, whether they affected passwords or credit cards.)

What if a penalty affected a site’s ranking in search results? For example, it could be a threshold for the “best” page in which it could appear, e.g. no greater than the fourth page (where pages are defined as blocks of N results, say 10). Or an absolute rank, e.g. no higher than the 40th entry in a list.

The penalty would decay over time at a rate, linear or exponential, based on any number of mathematical details. For example, a page-based penalty might decay by one page per month. A list-based penalty might decay by one on a weekly basis.

The decay rate could be influenced by steps the site takes to remediate the underlying problem that led to the breach, improvements to a privacy policy, fines, or covering costs related to fraud as a result of the breach.

If the search engines drives a significant portion of traffic — that results in revenue or influences valuation — then this creates an incentive for the site to maintain strong security. It’s like PCI with different teeth. It might incentivize the site to react promptly to breaches. At least one hopes.

But such a proposal could have insidious consequences.

Rank Implications

Suppose a site were able to merely buy advertising to artificially offset the rank penalty? After a breach you could have a search engine that’d love to penalize the “natural” ranking of a site only to rake in money as the site buys advertising to overcome the penalty. It’s not a smart idea to pay an executioner per head, let alone combine the role with judge and jury.

A penalty that a company fears might be one for which it suppresses the penalty’s triggers. Keeping a breach secret is a disservice to consumers. And companies subject to the S.E.C. may be required to disclose such events. But rules (and penalties) need to be clear in order to minimize legal maneuvering through loopholes.

The proposal also implies that a search engine has a near monopoly on directing traffic. Yes, I’m talking about Google. The hand waving about “search engines” is supposed to include sites like Yahoo! and Bing, even DuckDuckGo. But if you’re worried about one measure, it’s likely the Google PageRank. This is a lot of power for a company that may wish to direct traffic to its own services (like email, shopping, travel, news, etc.) in preference to competing ones.

It could also be that the Emperor wears no clothes. Google search and advertisements may not be the ultimate arbiter of traffic that turns into purchases. Strong, well-established sites may find that the traffic that drives engagement and money comes just as well from alternate sources like social media. Then again, losing any traffic source may be something no site wants to suffer.

Target is just the most recent example of breaches that will not end. Even so, Target demonstrated several positive actions before and after the breach:

– Transparency — periodic updates on breach details, remediation steps, complaint process.

– A clear privacy policy — written in accessible language (i.e. avoids a legal style that, however accurate, may be too dense, misleading, or ambiguous), including a summary of changes.

Thankfully, there were no denials, diminishing comments, or signs of incompetence on the part of Target. Breaches are inevitable for complex, distributed systems. Beyond prevention, goals should be minimizing their time to discovery and maximizing their containment.

And whether this rank idea decays from indifference or infeasibility, its sentiment should persist.

Audit Accounts, Partition Passwords, Stay Secure

It’s a new year, so it’s time to start counting days until we hear about the first database breach of 2014 to reveal a few million passwords. Before that inevitable compromise happens, take the time to clean up your web accounts and passwords. Don’t be a prisoner of bad habits.

It’s good Operations Security (OpSec) to avoid password reuse across your accounts. Partition your password choices so that each account on each web site uses a distinct value. This prevents an attacker who compromises one password (hashed or otherwise) from jumping to another account that uses the same credentials.
Penny-Farthing
At the very least, your email, Facebook, and Twitter accounts should have different passwords. Protecting email is especially important because so many sites rely on it for password resets.

And if you’re still using the password kar120c I salute your sci-fi dedication, but pity your password creation skills.

Start with a list of all the sites for which you have an account. In order to make this easier to review in the future, create a specific bookmarks folder for these in your browser.

Each account should have a unique password. The latest Safari, for example, can suggest these for you.

Next, consider improving account security through the following steps.

Consider Using OAuth — Passwords vs. Privacy

Many sites now support OAuth for managing authentication. Essentially, OAuth is a protocol in which a site asks a provider (like Facebook or Twitter) to verify a user’s identity without having to reveal that user’s password to the inquiring site. This way, the site can create user accounts without having to store passwords. Instead, the site ties your identity to a token that the provider verifies. You prove your identify to Facebook (with a password) and Facebook proves to the site that you are who you claim to be.

If a site allows you to migrate an existing account from a password-based authentication scheme to an OAuth-based one, make the switch. Otherwise, keep this option in mind whenever you create an account in the future.

But there’s a catch. A few, actually. OAuth shifts a site’s security burden from password management to token management and correct protocol implementation. It also introduces privacy considerations related to centralizing auth to a provider as well as how much providers share data.

Be wary about how sites mix authentication and authorization. Too many sites ask for access to your data in exchange for using something like Facebook Connect. Under OAuth, the site can assume your identity to the degree you’ve authorized, from reading your list of friends to posting status updates on your behalf.

Grant the minimum permissions whenever a site requests access (i.e. authorization) to your data. Weigh this decision against your desired level of privacy and security. For example, a site or mobile app might insist on access to your full contacts list or the ability to send Tweets. If this is too much for you, then forego OAuth and set up a password-based account.

(The complexity of OAuth has many implications for users and site developers. We’ll return to this topic in future articles.)

Two-Factor Auth — One Equation in Two Unknowns

Many sites now support two-factor auth for supplementing your password with a temporary passcode. Use it. This means that access to your account is contingent on both knowing a shared secret (the password you’ve given the site) and being able to generate a temporary code.

Your password should be known only to you because that’s how you prove your identity. Anyone who knows that password — whether it’s been shared or stolen — can use it to assume your identity within that account.

A second factor is intended to be a stronger proof of your identity by tying it to something more unique to you, such as a smartphone. For example, a site may send a temporary passcode via text message or rely on a dedicated app to generate one. (Such an app must already have been synchronized with the site; it’s another example of a shared secret.) In either case, you’re proving that you have access to the smartphone tied to the account. Ideally, no one else is able to receive those text messages or generate the same sequence of passcodes.

The limited lifespan of a passcode is intended to reduce the window of opportunity for brute force attacks. Imagine an attacker knows the account’s static password. There’s nothing to prevent them from guessing a six-digit passcode. However, they only have a few minutes to guess one correct value out of a million. When the passcode changes, the attacker has to throw away all previous guesses and start the brute force anew.

The two factor auth concept is typically summarized as the combination of “something you know” with “something you possess”. It really boils down to combining “something easy to share” with “something hard to share”.

Beware Password Recovery — It’s Like Shouting Secret in a Crowded Theater

If you’ve forgotten your password, use the site’s password reset mechanism. And cross your fingers that the account recovery process is secure. If an attacker can successfully exploit this mechanism, then it doesn’t matter how well-chosen your password was (or possibly even if you’re relying on two-factor auth).

If the site emails you your original password, then the site is insecure and its developers are incompetent. It implies the password has not even been hashed.

If the site relies on security questions, consider creating unique answers for each site. This means you’ll have to remember dozens of question/response pairs. Make sure to encrypt this list with something like the OS X Keychain.

Review Your OAuth Grants

For sites you use as OAuth providers (like Facebook, Twitter, Linkedin, Google+, etc.), review the third-party apps to which you’ve granted access. You should recognize the sites that you’ve just gone through a password refresh for. Delete all the others.

Where possible, reduce permissions to a minimum. You’re relying on this for authentication, not information leakage.

Use HTTPS

Universal adoption of HTTPS remains elusive. Fortunately, sites like Facebook and Twitter have set this by default. If the site has an option to force HTTPS, use it. After all, if you’re going to rely on these sites for OAuth, then the security of these accounts becomes paramount.

Maintain Constant Vigilance

Watch out for fake OAuth prompts, such as windows that spoof Facebook and Twitter.
Keep your browser secure.
Keep your system up to date.
Set a reminder to go through this all over again a year from now — if not earlier.

Otherwise, you risk losing more than one account should your password be exposed among the millions. You are not a number, you’re a human being.

Soylent Grün ist Menschenfleisch

Silicon Valley green is made of people. This is succinctly captured in the phrase: When you don’t pay for the product, the product is you. It explains how companies attain multi-billion dollar valuations despite offering their services for free. They promise revenue through the glorification of advertising.

Investors argue that high valuations reflect a company’s potential for growth. That growth comes from attracting new users. Those users in turn become targets for advertising. And sites, once bastions of clean design, become concoctions of user-generated content, ad banners, and sponsored features.

Population Growth

Sites measure their popularity by a single serving size: the user. Therefore, one way to interpret a company’s valuation is in its price per user. That is, how many calories can a site gain from a single serving? How many servings must it consume to become a hulking giant of the web?
Dystopian Books
You know where this is going.

The movie Soylent Green presented a future where a corporation provided seemingly beneficent services to a hungry world. It wasn’t the only story with themes of overpopulation and environmental catastrophe to emerge from the late ’60s and early ’70s. The movie was based on the novel Make Room! Make Room!, by Harry Harrison. And it had peers in John Brunner’s Stand on Zanzibar (and The Sheep Look Up) and Ursula K. Le Guin’s The Lathe of Heaven. These imagined worlds contained people powerful and poor. And they all had to feed.

A Furniture Arrangement

To sell is to feed. To feed is to buy.

In Soylent Green, Detective Thorn (Charlton Heston) visits an apartment to investigate the murder of a corporation’s board member, i.e. someone rich. He is unsurprised to encounter a woman there and, already knowing the answer, asks if she’s “the furniture.” It’s trivial to decipher this insinuation about a woman’s role in a world afflicted by overpopulation, famine, and disparate wealth. That an observation made in a movie forty years ago about a future ten years hence rings true today is distressing.

We are becoming products of web sites as we become targets for ads. But we are also becoming parts of those ads. Becoming furnishings for fancy apartments in a dystopian New York.

Women have been components of advertising for ages, selected as images relevant to manipulating a buyer no matter the irrelevance of their image to the product. That’s not changing. What is changing is some sites’ desire to turn all users into billboards. They want to create endorsements by you that target your friends. Your friends are as much a commodity as your information.

In this quest to build advertising revenue, sites also distill millions of users’ activity into individual recommendations of what they might want to buy or predictions of what they might be searching for.

And what a sludge that distillation produces.

There may be the occasional welcome discovery from a targeted ad, but there is also an unwelcome consequence of placing too much faith in algorithms. A few suggestions can become dominant viewpoints based more on others’ voices than personal preferences. More data does not always mean more accurate data.

We should not excuse an algorithm as an impartial oracle to society. They are tuned, after all. And those adjustments may reflect the bias and beliefs of the adjusters. For example, an ad campaign created for UN Women employed a simple premise: superimpose upon pictures of women a search engine’s autocomplete suggestions for phrases related to women. The result exposes biases reinforced by the louder voices of technology. More generally, a site can grow or die based on a search engine’s ranking. An algorithm collects data through a lens. It’s as important to know where the lens is not focused as much as where it is.

There is a point where information for services is no longer a fair trade. Where apps collect the maximum information to offer the minimum functionality. There should be more of a push for apps that work on an Information-to-Functionality relationship of minimum requested for the maximum required.

Going Home

In the movie, Sol (Edward G. Robinson) talks about going Home after a long life. Throughout the movie, Home is alluded to as the ultimate, welcoming destination. It’s a place of peace and respect. Home is where Sol reveals to Detective Thorn the infamous ingredient of Soylent Green.

Web sites want to be your home on the web. You’ll find them exhorting you to make their URL your browser’s homepage.
Home Page
Web sites want your attention. They trade free services for personal information. At the very least, they want to sell your eyeballs. We’ve seen aggressive escalation of this in various privacy grabs, contact list pilfering, and weak apologies that “mistakes were made.”

More web sites and mobile apps are releasing features outright described as “creepy but cool” in the hope that the latter outweighs the former in a user’s mind. Services need not be expected to be free without some form of compensation; the Web doesn’t have to be uniformly altruistic. But there’s growing suspicion that personal information and privacy are being undervalued and under-protected by sites offering those services. There should be a balance between what a site offers to users and how much information it collects about users (and how long it keeps that information).

The Do Not Track effort fizzled, hobbled by indecision of a default setting. Browser makers have long encouraged default settings that favor stronger security, they seem to have less consensus about what default privacy settings should be.

Third-party cookies will be devoured by progress; they are losing traction within the browser and mobile apps. Safari has long blocked them by default. Chrome has not. Mozilla has considered it. Their descendants may be cookie-less tracking mechanisms, which the web titans are already investigating. This isn’t necessarily a bad thing. Done well, a tracking mechanism can be limited to an app’s sandboxed perspective as opposed to full view of a device. Such a restriction can limit the correlation of a user’s activity, thereby tipping the balance back towards privacy.

If you rely on advertising to feed your company and you do not control the browser, you risk going hungry. For example, only Chrome embeds the Flash plugin. A plugin that eternally produces vulnerabilities while coincidentally playing videos for a revenue-generating site.

Lightbeam ExampleThere are few means to make the browser an agent that prioritizes a user’s desires over a site’s. The Ghostery plugin is an active counteraction to tracking; it’s available for all the major browsers. Mozilla’s Lightbeam does not block tracking mechanisms by default; it reveals how interconnected tracking has become due to ubiquitous cookies.

Browsers are becoming more secure, but they need a site’s cooperation to protect personal information. At the very least, sites should be using HTTPS to protect traffic as it flows from browser to server. To do so is laudable yet insufficient for protecting data. And even this positive step moves slowly. Privacy on mobile devices moves perhaps even more slowly. The recent iOS 7 finally forbids apps from accessing a device’s unique identifier, while Android struggles to offer comprehensive tools.

The browser is Home. Apps are Home. These are places where processing takes on new connotations. This is where our data becomes their food.

Soylent Green’s year 2022 approaches. Humanity must know.

Plugins Stand Out

A minor theme in my recent B-Sides SF presentation was the stagnancy of innovation since HTML4 was finalized in December 1999. New programming patterns emerged over that time, only to be hobbled by the outmoded spec. To help recall that era I scoured archive.org for ancient curiosities of the last millennium. (Like Geocities’ announcement of 2MB of free hosting space.) One item I came across was a Netscape advisory regarding a Java bytecode vulnerability — in March 1996.

March 1996 Java Bytecode Vulnerability

Almost twenty years later Java still plagues browsers with continuous critical patches released month after month after month, including March 2013.

Java: Write none, uninstall everywhere.

The primary complaint against browser plugins is not their legacy of security problems (the list of which is exhausting to read). Nor that Java is the only plugin to pick on. Flash has its own history of releasing nothing but critical updates. The greater issue is that even a secure plugin lives outside the browser’s Same Origin Policy (SOP).

When plugins exist outside the security and privacy controls enforced by browsers they weaken the browsing experience. It’s true that plugins aren’t completely independent of these controls, their instantiation and usage with regard to the DOM still falls under the purview of SOP. However, the ways that plugins extend a browser (such as network and file access) are rife with security and privacy pitfalls.

For one example, Flash’s Local Storage Object (LSO) was easily abused as an “evercookie” because it was unaffected by clearing browser cookies and even how browsers decided to accept cookies or not. Yes, it’s still possible to abuse HTTP and HTML to establish evercookies. Even the lauded HTML5 Local Storage API could be abused in a similar manner. It’s for reasons like these that we should be as diligent about demanding “privacy patches” as much as we demand security fixes.

Unlike Flash, an HTML5 API like Local Storage is an open standard created by groups who review and balance the usability, security, and privacy implications of features designed to improve the browsing experience. Establishing a feature like Local Storage in the HTML spec and aligning it with similar concepts like cookies and security controls like SOP (or HTML5 features like CORS, CSP, etc.) makes them a superior implementation in terms of integrating with users’ expectations and browser behavior. Instead of one vendor providing a means to extend a browser, browser vendors (the number of which is admittedly dwindling) are competing with each other to implement a uniform standard.

Sure, HTML5 brings new risks and preserves old vulnerabilities in new and interesting ways, but a large responsibility for those weaknesses lies with developers who would misuse an HTML5 feature in the same way they might have misused XHR and JSONP in the past. Maybe we’ll start finding plaintext passwords in Local Storage objects, or more sophisticated XSS exploits using Web Workers and WebSockets to scour data from a compromised browser. Security ignorance takes a long time to fix. And even experienced developers are challenged by maintaining the security of complex web applications.

HTML5 promises to obviate plugins altogether. We’ll have markup to handle video, drawing, sound, more events, and more features to create engaging games and apps. Browsers will compete on the implementation and security of these features rather than be crippled by the presence of plugins out of their control.

Getting rid of plugins makes our browsers more secure, but adopting HTML5 doesn’t imply browsers and web sites become secure. There are still vulnerabilities that we can’t fix by simple application design choices like including X-Frame-Options or adopting Content Security Policy headers.

Exterminate!

It’ll be a long time before everyone’s comfortable with the Dirty Harry test. Would you click on an unknown link — better yet, scan an inscrutable QR code — with your current browser? Would you still do it with multiple tabs open to your email, bank, and social networking accounts?

Who cares if “the network is the computer” or an application lives in the “cloud” or it’s offered via something as a service? It’s your browser that’s the door to web apps and when it’s not secure, an open window to your data.