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.

Fonts of Dis-Knowledge

The oracles of ancient Greece claimed to have the power of precognition, derived from the gods themselves. In the 17th century, John Locke wrote of more experiential sources for ideas, where sensation and reflection were two fountains of knowledge.

But none of these philosophical considerations are necessary to predict the effect of plugins on browser security. In the course of putting a presentation together, I’ve annotated two particular items.

Java. The Comic Sans of browser plugins. Inexplicably, some people think it’s a clever design choice. But it really conveys an uninformed decision, is ultimately useless (especially for modern browsers), and is a sign of incompetence.

Flash. Wingdings. At first it looks pretty. But its overuse quickly leads to annoyance. There’s no reason for a Flash plugin other than to look at legacy cat videos and suffer agitating ad banners.

They are nothing more than fonts of malware. When was the last time you installed a non-critical update for either one? If you haven’t disabled these plugins, do so now.

I’ll have new content soon. And, with my own knowledge of the future, here’s a peek at what those topics might be:

– Ruminations on privacy.
– Identity, passwords, personas.
– More examples of HTML injection.

And that doesn’t include putting up content for the newly released Anti-Hacker Tool Kit. Alas, my fountain of writing is a mere trickle!

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.
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.


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.

BlackHat US 2013: Dissecting CSRF…

Here are the slides for my presentation at this year’s BlackHat US conference, Dissecting CSRF Attacks & Countermeasures. Thanks to everyone who came and to those who hung around afterwards to ask questions and discuss the content.

The major goal of this presentation was to propose a new way to leverage the concepts of Content Security Policy and Cross-Origin Resource Sharing to counter CSRF attacks. Essentially, we proposed a header that web apps could set to inform browsers when to include that app’s cookies during cross-origin requests. As always, slides alone don’t convey the nuances of the presentation. Stay tuned for a more thorough explanation of the concept.

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.


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.

Secure Your Browser

As web users, we have little influence over the security of the sites we visit. However, we can ensure our browsers, and browsing experience, remain secure by following a few easy steps. Why not start off the year with the knowledge that your browser is better off than it was last year?

Update your browser

Chrome | Firefox | Internet Explorer | Opera | Safari
If your browser doesn’t support HTML5 content, you’re living in a technological past.
If your browser version is more than three months old, you’re living in an insecure past.
If your browser version is more than a year old, you’re infected with malware.

Consider verifying your environment with an online version check like Qualys BrowserCheck or Mozilla Plugin Check.

Enable HTTPS Always

Sites like Facebook, Google, and Twitter now use HTTPS by default. LinkedIn has an opt-in setting to force HTTPS. Demand this from others. The best protection comes from sites that implement HTTP Strict Transport Security (HSTS) and support DNSSEC. Sadly, these are scarce.
Update your bookmarks for each of these sites so you visit the https: version by default.
Encryption improves your privacy and defenses against sniffing or interception attacks when using Wi-Fi networks like those found in cafes, airports, or other public spaces.
Note that a public network that provides encrypted Wi-Fi using WEP or WPA/WPA2 with a pre-shared key doesn’t improve your privacy; anyone with the shared WEP or WPA key will be able to sniff your traffic. Shared secrets have less secrecy than you desire and more sharing than you expect.
HTTPS only works if your browser (and you!) pay attention to the certificate’s validity in the first place. Lots of mobile Apps rely on HTTPS connections, but not all of them bother to verify certificates — missing the entire point of this protocol.

Uninstall Flash

When was the last time you installed a non-critical update for Flash?
Removing Flash from your system removes a significant attack vector for malware and browser exploits. It also removes one vector for “evercookies“. (You’ll still be tracked by ad networks using other techniques.)
With Flash gone you might not be able to view some videos, but there are plenty others that use HTML5’s <video> tag.

Chrome bundles its own version of Flash, which is unaffected by the stand-alone installer (and uninstaller). You must disable it within Chrome’s settings.Chrome disable Flash

Disable Java

When was the last time you found a useful site that needed to run Java?
Disabling Java removes a significant attack vector for malware and browser exploits.
Don’t uninstall it completely, though. You’ll want it around to run Zed Attack Proxy.

Internet Explorer 10, 11IE10 Disable Java

FirefoxFirefox disable Java

OperaOpera disable Java

SafariSafari disable Java

Review Privacy Settings

Review settings for Third-Party Cookies, prefer to reject them outright.

Know how to enable the browser’s mode for “Private Browsing” (Firefox, Safari), a.k.a “Incognito Window” (Chrome), “InPrivate Browsing” (IE), “Private Window” (Opera).

Turn on Do Not Track headers. At the moment, this setting likely adds minimal improvement to your privacy. The background and controversy around this setting requires more than one article; check back for more details.

ChromeChrome Privacy Settings

FirefoxFirefox Privacy Settings

Internet ExplorerIE9 Privacy Settings

Internet Explorer 10, 11IE10 Do Not Track headerIE10 Enable Enhanced Protected Mode
(Understand benefits of Enhanced Protected Mode.)

OperaOpera Do Not TrackOpera Cookies

SafariSafari 7 Do Not Track

Safari iOS 6
Go to Settings > Safari > Accept CookiesiOS Safari Accept Cookies

Safari iOS 7
Go to Settings > Safari. Review the PRIVACY & SECURITY section.iOS Safari 7 Privacy & Security

Mobile Device Settings

iOS 6 (iPad & iPhone)
Go to Settings > General > About > AdvertisingiOS Limit Ad Tracking

iOS 7 (iPad & iPhone)
Go to Settings > Privacy > AdvertisingiOS 7 Limit Ad Tracking

Manage Your Passwords

Your email address is often the primary password recovery method for accounts on other web sites. Choose a unique password for your email account. If the credentials for another of your accounts are compromised, then the attackers will not be able to immediately expand their reach into the “master key” that is your email.

If a web site supports it, enable account recovery and login verification with a mobile device (e.g. text messages). It’s more difficult for an attacker to gain control of a physical device in your possession than an email account on the web.

Updated January 2014 with Safari 7 and iOS 7 recommendations.
Updated January 2013 with IE10 and password recommendations.

The Harry Callahan Postulate

What kind of weight do you put in different browser defenses?

  • Process separation?
  • Plugin isolation and sandboxes?
  • Tab isolation?
  • X-Frame-Options, X-XSS-Protection? Built-in reflected XSS protection? NoScript?
  • Automatic updates?
  • Anti-virus? Safe browsing lists?

Instead of creating a matrix to compare browsers, versions, and operating systems try adopting the Harry Callahan Postulate:

Launch your browser. Open one tab for your web-based email, another for your online bank. Login to both. Then click on one of the shortened links below. Being as this is the world wide web, the most dangerous web in the world, and would blow your data clean apart, you’ve got to ask yourself one question: Do I feel lucky?

Well, do ya punk?


. . .

Clicking on links is how the web works. It’s a default assumption that users are expected to click links, and it’s a disproportionate security burden to expect them to scrutinize the characters, TLS hygiene, or provenance of links.

If the presence or absence of a single lock icon conveys ambiguous meaning about “security”, then attempting to discern multiple characters will be even harder. That lock icon is more about identity, i.e. “this is the app your browser is talking to”, than security in the sense of, “it is safe to give information to this app.”

In an ideal world, we should be able to click on any link without risk of that action impacting the security context or relationship with an app unassociated with the origin in that link.

Think of this like an Other Origin Policy for the persona associated with each app you use. Other origins shouldn’t have an unintended effect on the security context of another. When it does have an intended effect, it should be an interactive one that requires an explicit approval from the user.  It shouldn’t be a silent killer. (Well-informed approval is yet another challenge.)

Even so, CSRF countermeasures can’t protect against social engineering attacks and many effective XSS exploits happily work within the Same Origin Policy.

AlchemistIn this real world, users must keep their browsers up to date, they should remove historically vulnerable and ever-contaminated plugins like Flash and Java. But they must also rely on browser vendors to build software with strong isolation. They must rely on app developers to implement resilient designs like enforcing HTTPS connections, implementing pervasive anti-CSRF tokens, and offering multi-factor authentication.

With such distributed responsibility, it’s not hard to see why errors happen. The Other Origin Policy is an aspirational goal. With effective appsec, clicking on a malicious link should lead to nothing worse than an, “Oops!”.

Eventually, you’ll feel comfortable enough to click on any link. Until then, we’ll have to continue educating users, creating safe default behaviors and safe default decisions within browsers, and improving the security architecture of apps.