How to tell at a glance if a website is fake

Hackers and cyber criminals are constantly looking for new ways to trick internet users into exposing their personal and private data. These attacks are easier to execute than trying to infect an entire computer or local network, but the results can be just as damaging.

The term phishing applies to any instance where a message or website pretends to be part of a legitimate organization but in fact has malicious intent. Most begin with an email distribution, urging readers to click on a link and enter their passwords, social security numbers, or other identifying information.

When a person falls victim to a phishing scam, they may not realize the extent of the impact. Nowadays, stolen personal data is commonly sold on the dark web, a trend which will encourage more attacks in the future.

Even computer experts can sometimes be fooled by a phishing attempt, so it’s important to know what to watch for when opening your email and browsing the web. This article will describe the top five methods for quickly determining whether a website is real or fake.

1. Examine the URL Closely

Screen capture of illegitimate website with descriptions of potential problems (and why they are problems).

All websites on the public internet must use the hypertext transfer protocol (HTTP) with a registered domain name, which is the part of a web address that includes .com or .net. So when you first browse to a new website or click on an unfamiliar link, be sure to take a few extra seconds to review the URL in the address bar. If the address does not start with HTTP or HTTPS, close your browser right away as the site is unsafe.

Hackers will often buy domains that look like they are connected to a reputable company but actually redirect to a nefarious site. These addresses typically have misspellings in their name or use a different suffix.

Another trick that cyber criminals use is the disguising of a URL within a phishing email message. They may have a hyperlink that shows a familiar .com address, but when you click on it, the link will point to an entirely different location. When it comes to URLs, don’t trust anything except for what you see in the address bar at the top of your browser.

2. Check For the SSL Certificate

Overview of SSL encryption.

Websites with a secure sockets layer (SSL) certificate are equipped to handle requests over an encrypted connection. This means that all data sent between your browser and the website’s back-end servers cannot be decoded by any outside entities or hackers.

One of the first indications of a suspicious website is a missing or out of date SSL certificate. You can quickly check for this by looking at the left side of the address bar in your browser to see if a padlock icon is displayed. A simple padlock indicates a standard SSL certificate, while a green bar means that the website is using an extended validation SSL certificate, which offers some additional levels of security.

Modern browsers like Google Chrome and Mozilla Firefox will automatically warn you when you try to load a website that has a missing or expired SSL certificate. To be extra careful, you can click on the padlock icon to view the status of the certificate and the entity who registered it. Never submit any credit card transactions or other personal data through websites that lack an SSL certificate.

3. Scan Developer Tools

When you load a website’s contents into your browser, the HTML displayed in the window does not always tell the full story. In fact, the most dangerous part of phishing websites is often hidden in JavaScript and other code that is invisible to the untrained eye.

Fortunately, you can use the Developer Tools option in Google Chrome to scan for suspicious threats. To launch it, open the Chrome menu, go to the “More tools” submenu, and choose the “Developer Tools” option. A new panel will open with various tabs of information.

Perform a full refresh of the webpage and first check the “Sources” tab to see what external content is being loaded by your browser. Then do the same in the “Network” tab. If you see an unfamiliar domain listed in the logs, consider closing your browser and manually navigating to the website with a typed URL. You can even examine the webpage’s HTML and JavaScript code through the “Elements” tab.

4. Look for Contact Information

Reputable websites will either include their contact information in a dedicated page or else within the footer at the bottom of the HTML content. If you are unsure whether to trust the company with your sensitive data, consider checking these locations to validate the website owner’s identity. If you can’t find any contact information at all, chances the site is dangerous or poorly maintained.

Website footers also typically include a link to a privacy policy, which is a critical piece of information for internet users concerned about how their data is stored and who prefer that it not end up being hawked for a few bucks on the Dark Web. The policy will explain what kind of information is tracked by the website, how long it is kept, and what a user needs to do to delete it.

5. Query the Website Registration

Overview of Whois query

Upon purchasing any public domain name on the internet, whether it’s by an individual or a large company, the new owner must register it through the Internet Corporation for Assigned Names and Numbers (ICANN). Think of it like a DMV system for website registration.

This can come in handy when you want to check on the validity of a suspicious looking website. You can navigate to a ICANN lookup service and query any domain on the public internet with a WHOIS command.

The result of WHOIS query will indicate the legal name and address of website’s owner. It cannot tell you for sure whether a website is real or fake, but if the information provided does not look genuine or references a suspicious organization, you should avoid visiting the address entirely.

Final Thoughts

While phishers can be sneaky, the real problem lies in a gullible public or one too busy to take the time to learn how to properly vet websites. These tips we’ve just covered aren’t foolproof but can go a long ways towards ensuring you don’t hand over your credit card or other personal information to every hacker who throws a fake website in front of you.

It’s like crossing the road. Stop for a few seconds, look both directions, and make sure you have the lay of the land before proceeding. Good luck and thanks for reading.

Editor’s note: Will Ellis develops the guts beneath beautiful websites and can’t wait to see what the blockchain world will look like once the technology fully emerges. He invests in cryptocurrencies and studies history.

Photo of member Will Ellis

The post How to tell at a glance if a website is fake appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

6 tips to turn your slow loading website into a brisk browsing experience

Internet users want a speedy experience and they’re not getting it, a fact that leaves them frustrated and website owners with less revenue. Don’t believe it? Numbers don’t lie. A full 53 percent of surfers want any site they visit load in three seconds or less. The largest ecommerce sites in the world recognize this necessity – they load incredibly fast. Most of the rest of the internet leaves a time gap that makes for a lot of gritted teeth and nervous toes tapping the floor. The good news is that speeding up a slow website is not difficult or time-consuming. The bad news is you might not choose to do it.

Are You Flirting with the Performance Poverty Line?

The performance poverty line is a term that represents the point at which being slow doesn’t matter because you’ve already lost most of your traffic. That number sits at around 8 seconds. The more pertinent question is, do you know your website’s speed. REALLY know your website’s speed?

No guessing because this is important stuff.

There’s an easy way to find out. Pay a visit to a website called Pingdom — it’ll probably load fast because it’s sort of their business — and enter your URL in the box. Select a location from the dropdown menu and hit “start.” Unless they’re exceptionally busy (it happens sometimes) you should get a performance summary in less than a minute.

Screen capture of Pingdom report

There’s a good chance what you see won’t impress anyone, but that’s okay. Few websites do. We’re here to provide you with a road map to get those numbers headed down, down, down and your visitors to start getting happy, happy, happy. Let’s call this…

A 6-Part Roadmap to Fast Websites and Happy Customers

Part 1: Magically Shrink Your Website

Actually, as far as we know, there’s no way to magically shrink your website but you can get the same effect by applying a sweet little bit of technology called Gzip compression. When implemented, some site owners have seen overall file size reduction of as much as 70 percent. That’s huge. Actually it’s tiny and that’s the point. It works like this. When a request hits the server to view the website, it automatically zips all the files before sending them onto the requester’s browser, where it is unzipped and displayed.

Part 2: Fix Bad Design and Too Many HTTP Requests

Every element on your website — we’re talking about images, videos, scripts, and even text — generates an individual request to the server. The more “stuff” your website has, the more requests there are and the longer it takes to load. If ever there was an argument for using a minimalistic approach when designing your website, this is it. Fewer requests mean a faster website. The tricky part is to not get distracted by all things you could do and stick to only what is needed to accomplish the site’s mission.

Overview of http requests and responses

Part 3: Put Hefty Images on a Diet

Images are huge. Incorrectly (or not at all) optimized, they put a terrible strain on bandwidth and leave the server and browser gasping from the strain. While we could write a book on the topic, there is one thing you can do that will fix a lot of the issues and that is choose the correct format — png, gif, and jpeg are good — and make the things as small as you can stand BEFORE uploading to your website. If you upload a full size image, even if you reduce it later, the server still has the original version and that’s the one that clogs the pipeline.

Part 4: Upgrade Your Hosting

We love cheap stuff as much as the next person but when it comes to choosing a web hosting plan, you need to understand the different types of plans and know when it’s time to upgrade. Inexpensive shared plans can be as low as a few dollars a month and that’s okay for a hobby or site that doesn’t have much traffic yet. Once you reach a certain level, though, the shared resource approach of this kind of plan will almost certainly mean slow-loading and downtime. While a dedicated server might not be worth the expense, a virtual private server or VPS hosting can be a great compromise.

Schematic depicting VPS

Part 5: Turn on Browser Caching

Browser caching is an easy-to-implement, tactic that most fast-loading websites use. The idea is simple. Rather than force the server to send over all the website files every time someone visits, static files (those that don’t change) are stored in the browser’s temporary memory and only dynamic files have to be retrieved. Obviously, this doesn’t help on a first visit but, with browser caching enabled, subsequent visits will be quicker. For WordPress websites, W3 Total Cache is a free plugin to look for. Others just require a simple code addition.

Part 6: Resolve Plugin Conflicts

This WordPress-specific advice is based on the reality that a lot of site owners install plugins that they never update or even use. Considering the third-party nature of these bits of software, it should be no surprise that they don’t always play nice together — they weren’t intended to. If your WordPress website is slow or buggy, one of the first actions to take is to uninstall any plugins you aren’t using. After that, turn what’s left off one at a time and check site speed. There’s a good chance you’ll find one of the culprits to slow loading.

Final Thoughts

The state of technology today is such that people expect (even if it’s not a reasonable standard) a website to load in three seconds or less. A clean, fast-loading experience will go a long ways towards creating loyal customers and more revenue, which are both good things to shoot for as an online entrepreneur. Keep in mind that the process is iterative. There’s no magic wand that will turn your site into a speed burner. Small actions taken methodically, such as the ones described, should, over time, move you incrementally closer to that three second target. Good luck and thanks for reading.

Photo of Gary Stevens

Member author Gary Stevens is a front end developer. He’s a full time blockchain geek and a volunteer working for the Ethereum foundation as well as an active Github contributor.

The post 6 tips to turn your slow loading website into a brisk browsing experience appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Inspecting Security and Privacy Settings of a Website

Inspecting the Content Security Policy of a Website

Starting in Firefox 41, Mozilla provides a developer tool that allows users to inspect the security settings of a website. Using GCLI (Graphic Command Line Interface) a user can inspect the Content Security Policy (CSP) of a website. CSP is a security concept that allows websites to protect themselves against cross-site scripting (XSS) and related attacks. CSP allows website authors to whitelist approved sources from which content can be loaded safely. Browsers enforce that Content Security Policy header and only allow whitelisted resources to be loaded into that website. The CSP inspection tool » security csp lists all whitelisted sources.

The main intention behind CSP is to protect websites against XSS attacks, but the protection needs to be deployed in a way that allows support for legacy code on these sites. For example, the keyword ‘unsafe-inline’ was originally introduced to support legacy inline scripts while transitioning sites to use CSP. This keyword whitelists all inline scripts for a site, but it also allows attacker-injected scripts to execute, making CSP ineffective against most XSS attacks. Hence, the CSP devtool not only lists all whitelisted sources, but also provides a rating for each whitelisted source, to indicate the level of protection.

Inspecting the referrer policy of a website

Starting in Firefox 43, Mozilla exposes more website privacy settings and also allows users to inspect the Referrer Policy » security referrer. The referrer policy allows websites to exercise more control over the browser’s referrer header. Specifically it allows website authors to instruct the browser to strip the referrer completely, reveal it only when navigating within the same origin, etc. The referrer devtool provides an example of what referrer will be used when visiting different websites, allowing the user and developer to inspect what information is sent when following a link.

Inspecting the Content Security Policy as well as the Referrer Policy is only the starting point to providing end users with more feedback about the security and privacy settings a web page uses. We hope to add more tools in the future to give users more transparency and control over the security and privacy of the websites they visit.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Embedding WebRTC Video Chat Right Into Your Website

Most of you remember the Hello Chrome, it’s Firefox calling! blog post right here in Mozilla Hacks demonstrating WebRTC video chat between Firefox and Chrome. It raised a lot of attention. Since then we here at Fresh Tilled Soil have seen a tremendous amount of startups and companies which have sprung up building products based WebRTC video chat technology. Tsashi Levent-Levi who is a WebRTC evangelist has been interviewing most of these companies on his blog, the list is quite impressive!

WebRTC chat demo

Much like most of early adopters we have been playing around with WebRTC for quite awhile now. We have of course created our own WebRTC video chat demo and have also very recently released WebRTC video chat widgets.

The widgets work very simply, anybody can take the following HTML embed code:

<!-- Begin Fresh Tilled Soil Video Chat Embed Code -->
<div id="freshtilledsoil_embed_widget" class="video-chat-widget"></div>
<script id="fts" src=""></script>
<!-- End Fresh Tilled Soil Video Chat Embed Code -->

and add this code to any website or blog post. You’ll see the following widget on their website:

From here it’s dead simple to start a WebRTC video chat, just make up a name for a room, type it in and click start chat. Tell the other person to do the same and you’re all set.

As always make sure you’re giving this a try in Firefox Nightly or the latest stable build of Google Chrome. If you are on a tablet make sure you are on Google Chrome beta if you are using the Google Chrome browser.

Something else to note is that for this first version our video chat is limited to just two participants per a room. If a room name is occupied by two people the third person who tries to connect to this room simply won’t be able to connect.

How It Works

Without getting too deep into the code behind how WebRTC video chat actually works, let’s briefly go over what is actually happening behind the scenes when you click the start chat button and how WebRTC video chat actually works. Here is a step by step timeline of what actually happens to give you a better idea:

A quick note about this step: “Once remote media starts streaming stop adding ICE candidates” – this is a temporary solution which might result in suboptimal media routing for many network topologies. It should only be used until Chrome’s ICE support is fixed.

A quick and very important tip to remember when you are trying to get this to work. We used a ‘polyfill’ like technique as shown in this article by Remy Sharp. As Remy describes we wrote a piece of code to adapt for the Firefox syntax to get cross-browser functionality.

Issues We Ran Into and How We Solved Them

As you might expect we ran into a number of problems and issues trying to build this. WebRTC is evolving quickly so we are working through a number of issues every day. Below are just some of the problems we ran into and how we solved them.

PeerConnection capability in Google Chrome

While working with the new PeerConnection capability in Chrome we discovered a strict order of operation for it to work; more specifically:

  • Peers must be present with local streaming video before sending SIP (offer/answer SDP)
  • For ‘Answerer’; Do not add ICE candidate until the peer generates the ‘Answer SDP’
  • Once remote media starts streaming stop adding ICE candidates
  • Never create peer connect for answerer until you get the ‘Offer SDP’

We fixed it by handling those issues and handling the connection in the order described above. This was crucial to making the connection work flawlessly. Before we did that it would work only every once in a while.

Added latency due to lag

When streaming to a mobile device there is added latency due to lag and limitations of surfing the net via mobile phone.

We solved this by making the resolution of streamed video reduced via a hash tag at the end of the URL. URL can optionally contain '#res=low' for low resolution stream video & '#res=hd' for HiDefinition streaming video as an optional URL parameter. A quick note here that other configurable properties are now available such as frames per second which you can use for this same purpose.

Recording the WebRTC demo

We’ve been dabbling with recording video WebRTC demo. When recording video we used the new JavaScript type arrays to save the streaming data. We quickly discovered that it is only possible to record the video and audio separately.

We solved this by creating two instances of recording, one for the audio and one for the video, that utilized the new javascript data types and recorded both streams simultaneously.


It’s exciting to dabble in this stuff, we love WebRTC so much that we created an entire page dedicated to our experiments with this technology and others which we believe will transform the web in 2013. If you have any question please give us a shout.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)