Update 4/29/19: The bug affecting printing in Google Calendar appears to be fixed.
Trying to print your Google Calendar but keep getting a broken print preview window? Try enabling the “Show weekends” option under the Day/Week/Month/Year dropdown menu. If you don’t, you may be unable to print your calendar from any view.
It looks like this is a server-side issue, since a 500 error is logged to the browser console when the print preview window fails to load. Hopefully, Google will release a fix for Calendar in the near future, as the issue has already been reported on the Calendar forums:
As announced in February this year, Google Chrome’s design is being evolved to more clearly indicate to users that websites using plain HTTP are not loaded securely and that HTTPS connections should be expected instead. Today, Chrome is pushing a change that affects all HTTP sites worldwide: starting in version 68, Chrome will display a “Not Secure” warning in the address bar for all sites loaded over HTTP.
This isn’t the first change Chrome has made to clearly indicate that HTTP is not secure. Chrome has been marking HTTP traffic as “Not Secure” in Incognito mode as far back as version 62. The “Not Secure” warning has also been appearing for HTTP sites in Chrome’s normal mode when a page contains a password field or when the user interacts with any input field.
Although Chrome has taken the lead, Mozilla Firefox is also on board with the effort to visually flag HTTP pages as insecure. Firefox currently displays an address bar warning for HTTP sites that contain login forms and displays a visible warning message next to login forms that are served insecurely.
What’s Next
The future will bring more changes for the way Chrome visually handles HTTP and HTTPS connections. As I covered back in May, Chrome is scheduled to remove the “Secure” text from HTTPS connections in September with the release of Chrome 69. One month later, in October 2018, Chrome will color the HTTP “Not Secure” warning red when users enter data into insecure sites in Chrome 70. Ed: A previous version of this post inaccurately reflected the circumstances in which the “Not Secure” warning will be colored red in Chrome 70. The color will only change when users enter data on HTTP pages.
Today, the Google Chrome security team announced the next step in their plan for handling plain HTTP pages in Chrome. Over the past couple years, the Chrome team has been slowly increasing the negative visual feedback users get when they interact with unencrypted HTTP sites, and back in February 2018 the team announced a plan to eventually mark all plain HTTP pages as “Not secure” in the address bar. That visual change is still scheduled to take effect in July 2018, but the team has already announced another big change, this time to the way Chrome visually handles already-secure HTTPS sites.
A Little Less Carrot, and a Little More Stick
Starting in September 2018, Google Chrome will no longer display the word “Secure” in the address bar for sites that support HTTPS. The rationale behind this change is that users should only be warned when a site is not loaded securely. Otherwise, users have to look for the absence of a padlock or the “Secure” text, and an obvious warning about insecure content is generally more noticeable than the lack of a positive visual indicator. As shown in the screenshot below, the padlock icon will still stick around for awhile longer, although it will no longer be colored green.
Later, in October 2018, the forthcoming “Not secure” warning on HTTP pages will turn red when users try to enter data into any form loaded over HTTP. Currently, the “Not secure” warning is only shown on HTTP pages with password forms, and when shown it is colored grey to match the site’s URL.
Still a Controversial Change
Google’s significant push towards universal adoption of HTTPS has not been without controversy. It’s generally accepted (for fairly obvious reasons) that sites handling the submission of sensitive data — like passwords and credit card numbers — should use HTTPS, but advocates of universal HTTPS suggest that even the most insignificant sites can still benefit from encryption.
For one, some sites still only use HTTPS for their login pages and serve the rest of their content over HTTP, which can open users up to very real attacks like session hijacking. Also, since all HTTP traffic is sent over the Internet completely unencrypted, it can be modified in transit, censored, scraped for tracking purposes, or have advertisements injected into it. While rare, ad injection by ISPs is very real, and the fact remains that HTTP traffic can be snooped on by anyone from local Wi-Fi hijackers to national governments.
On the other hand, opponents of universal HTTPS raise several complaints. Some claim that HTTPS is simply not needed for sites that do not handle sensitive data and do not care what happens to their content in transit. Others suggest that deprecating HTTP will kill off old, unmaintained websites from the 90’s and early 2000’s that contain valuable information and will likely never be migrated to HTTPS.
Mainly, opponents claim that Google is exercising an unreasonable amount of monopolistic authority over the future of the Web. Google has already been using HTTPS as a positive ranking signal in its search results since 2014, and as a company it does have a significant amount of influence over the Web.
An Ideological Dispute
At some level, the pro-vs-anti-HTTPS debate boils down to an ideological dispute over who should control the future of the web. Proponents claim that universal HTTPS is genuinely in everyone’s best interest, while opponents rankle at the thought of the Web being influenced by Internet companies rather than being the free-to-enter, open-to-everyone system that they feel it began as. Realistically, Google isn’t the only major company backing universal HTTPS, and with the amount of support behind the movement it’s unlikely to show any signs of slowing down.
In this post, I’m going to go over some background information about the web server logs I’ll be posting, and then I’ll go over a basic example of what traffic from Googlebot should look like.
Log Format
The logs I’ll be posting will be in the default combined format for Nginx, which looks like this:
Let’s break that down. Each section that’s prefaced by a dollar sign indicates one piece of information that will be logged. Nginx will collect this information and then concatenate it so that it is easy to scan. If any of the requested pieces of information are not provided, Nginx will replace it with a hyphen. Here is what each bit of information we’ll be collecting means:
$remote_addr: The IP address of the client. - (The hyphen here is just a placeholder for readability) $remote_user: The authenticated user, if one exists. $time_local: The time the request was processed, based on the server’s time zone settings. $request: The requested resource. This will include the HTTP method used. $status: The status code that the web server returned. $bytes_sent: The number of bytes the server sent to the client. $http_referer: The referrer URL, or the webpage that sent the visitor to your server using a link. $http_user_agent: Information regarding what browser or operating system was used to make the request.
Fun fact: You may have noticed that “referer” is spelled incorrectly. This is a misspelling in the actual HTTP specification and you can learn more about that here.
Googlebot Traffic
Now let’s break down a real log, taken from one of my servers. I’m going show how each piece of information in the log matches up to the reference above.
$remote_addr is 66.249.65.115. This is a real Googlebot IP address, so we can be fairly certain this is a legitimate request. $remote_user: Googlebot was not logged into the server, so this field is blank. $time_local: The request came in at 8:36 AM on June 18th, 2016. $request: Googlebot requested the /about-us page using a GET request. $status: The server responded with an HTTP 200 OK status code, indicating that it was able to successfully complete the request. $bytes_sent: The server sent back 2,233 bytes. $http_referer: Googlebot did not list a referrer URL. $http_user_agent: This custom user agent listing tells us that the request was made by Googlebot and not by a typical web browser.
Join us next week for an explanation of some less benign requests.
Pop quiz: do you use the cloud? Even if you don’t know it, it’s highly likely that your answer is “yes”. Cloud computing has become a ubiquitous part of modern day computer usage. However, many people don’t know that much about it.
Google defines “cloud computing” as the practice of using a network of remote servers hosted on the Internet to store, manage, and process data, rather than a local server or a personal computer. That definition is still fairly technical, so let’s break it down.
When you edit a file locally, the file is stored and processed on your computer. This works fairly well, assuming you only have one computer and don’t need to access your file from anywhere else or share it with collaborators. However, if your computer is turned off, you can’t use the file without making a copy of it and placing it on another computer. In today’s world of smartphones and mobile devices, it’s crucial to have access to the same data from multiple locations without having to create redundant copies of files and deal with the hassle of moving them back and forth. The solution is to store the files in a separate, universal location and access those files across the Internet. This separate location takes the form of large, powerful computers run by companies such as Google, Microsoft, Apple, and Amazon, and is commonly referred to as the cloud.
A good example of the cloud in everyday life is modern email. If you use email on both your phone and your computer, and your inbox contains the same emails no matter what device you’re on, you’re most likely using the cloud. The standard configuration for Gmail, Yahoo! Mail, or other email accounts is to store all your emails on your email provider’s servers and to have your devices download temporary copies of them to view. In this example, all your email is stored in the cloud.
Another commonly used cloud service is Google Drive. Google Drive is a service that allows users to upload, edit, and share documents, pictures, and videos. When you use Google Drive, all your files are stored on Google’s cloud servers and are accessible when you sign in to Google Drive with your password.
iCloud on your iPhone or iPad is also a cloud service. iCloud allows you to store photos, backups, and other settings in the cloud so that they are accessible on all your Apple devices. If you use iCloud, you’re using Apple’s cloud servers to store your data.
Other examples include Pandora, Google Play Music, Dropbox, Microsoft Office 365, YouTube, and almost any other service that involves streaming, downloading, or storing content on the Internet.
The name “cloud computing” has nothing to do with the weather, as the term stems from the abstract depiction of remote servers or the Internet in general as a large, ambiguous cloud. However, that doesn’t mean that weather has no effect on the cloud. Since the cloud relies on massive physical computers to store data, a large storm or natural disaster could physically affect these servers. In 2012, Hurricane Sandy partially flooded the server farm of a company called Datagram, Inc. Datagram’s servers ran a number of popular websites, such as Lifehacker, Gizmodo, and Huffington Post, and these websites temporarily went offline as a result of the storm.
Google’s Chromecast hit the market two years ago, and has sold well because of its promising features and its compellingly low pricing. Here’s how it works and what might make it a good purchase for you.
How it Works
Chromecast is essentially a tiny computer that pipes media content into an HDMI port on your TV. That’s about all it does. You can’t interact with the device’s software aside from attaching it to your WiFi network and changing the background image it displays when it’s idle. All of the device’s settings must be changed through the mobile app or from a small desktop app for your computer. It doesn’t make your TV into a separate computer; instead, it acts much more like an HDMI cable.
The primary purpose of Chromecast is to help you display your mobile device’s video or audio stream on your TV. Chromecast uses Google’s new Cast technology to function, which many apps now support. In an app that supports Google Cast, all you have to do is tap the Chromecast icon and you can cast your screen and audio output to your TV.
The cool part about casting media from your mobile device is that in a Cast-enabled app, the media stream is handed off from your device to the Chromecast entirely. That means that you can start playing a YouTube video on your tablet, tap the Chromecast icon, and then lock or turn off your tablet. In apps like Netflix, Hulu, or YouTube, your Chromecast will stream the requested media straight from the Internet without having to go through your mobile device. This is where Chromecast starts to sound a lot more appealing than an HDMI cable.
Chromecast also offers a feature for desktops that’s still in beta mode: the Google Cast browser extension for the Chrome browser. Using this extension, you can cast Chrome tabs or even your entire Windows or Mac desktop to your Chromecast. However, this is not the most reliable Chromecast feature, at least for now.
The utility of Chromecast also depends on the features your TV provides. Chromecast can’t draw power from the HDMI port alone, so it requires a USB power supply as well. On newer TVs with built-in USB ports, you can simply hook up your Chromecast to one of the TVs USB ports. On older TVs that only have “service” USB ports, you’ll have to use the bundled external power adapter. Also, if your TV is new enough to have HDMI ports that support the Consumer Electronics Control feature, starting a cast will cause your TV to automatically switch inputs to display what you’re playing on the Chromecast.
Why You’d Want It
If you want to enable internet streaming for an old TV, Chromecast is perfect. It’s cheap and easy to set up and works with Android and iOS tablets and phones. If you regularly use mobile devices and want some way of easily streaming music or video to your TV, Chromecast is for you. The ability to cast media while your device is locked or turned off is impressive and useful.
However, if you’re looking for some way of connecting your desktop or laptop to your TV, Chromecast may not be as useful. The Google Cast browser extension for Chrome works well on sites that are optimized for Chromecast, but otherwise casting tabs can be laggy or unreliable. The connection quality, being wireless, is easily bested by a direct HDMI connection.
Also, if you’re looking at Chromecast as a way to play DVDs or other offline media on your TV, you’ll be disappointed to hear that you can’t. Google Cast for desktop only supports casting media that can be played in the Chrome browser. You can open offline music files of certain types in Chrome, but as of now there is no way to play DVDs or CDs.
Bottom line: if you use mobile devices often and need some way to play music or video on your TV while still being able to use your tablet or phone, Chromecast is for you.
Setting it Up
Google has done a good job making Chromecast easy and fun to set up. The pictures below are of the unboxing, and the last two show Google’s simple in-box instructions on how to set up the Chromecast. Essentially, you plug your Chromecast into your TV and into the power adapter, and then download the app on your mobile device or on your computer.
