Persona.org is shutting down

Sebastian Kippe ·

Unfortunately, persona.org is finally being shut down this Thursday. We were big fans of both the BrowserID protocol and Mozilla’s Persona service. And so were our users. Around 30% of new accounts were created using Persona, until Mozilla announced its shutdown in January this year.

Personally, I still think it was a great idea, which unfortunately wasn’t met with enough enthusiasm on the side of the big email providers. But no point in wallowing in the past, so here’s what you can do, in case you signed up on 5apps.com via Persona and haven’t enabled another login option yet.

Connect GitHub, Bitbucket, or GitLab.com

In addition to our existing GitHub login, we also just added support for Bitbucket and GitLab.com. All of these options will also import your SSH public keys to 5apps Deploy, in case you’re signed up for it.

You can enable these options on the Connections page in your account settings, after logging in with Persona (before Thursday) or via username/password.

Enable username/password login

In order to enable password login, just go to your account settings and enter a new password. In case you can’t log in via any other method anymore, just request a password reset, and we’ll send you an email with a reset link right away.

Questions?

If you have any questions or feedback, just leave a comment below. You can also ping us on Twitter, drop us an email, or visit our support site.

Just launched: Free and instant HTTPS for custom domains

Sebastian Kippe ·

Good news, everyone! As of this week, we’re offering free, automatic, instant HTTPS for your custom domains on 5apps Deploy!

There’s no need for any manual steps in the whole process. As soon as you add a custom domain and point it to our servers, your app will automatically receive a certificate upon the first time it is visited via that domain.

Certificates are issued by Let’s Encrypt, a free, automated, and open Certificate Authority (CA). They are renewed automatically every few weeks by our configuration management systems.

In short: lean back and rest assured that your apps are delivered securely by an always-up-to-date infrastructure without you having to lift a finger, ever! Read on for some more details on the benefits of HTTPS (specifically for client-side web apps), and how to upgrade your existing apps on Deploy.

Let’s encrypt the whole Web

The reasons for going HTTPS all the way by default are many:

Security

The most obvious benefit is security and safety for your users. With a plain HTTP connection, it’s not possible for their browser or device to validate that your app’s JavaScript and other resources were actually delivered from the correct server. That leaves a wide-open space for man-in-the-middle attacks and stealing your user’s data. 1

Privacy & Censorship

Another problem with bad actors in the middle being able to read user connections in plain text is that it’s easy to log hostnames and URLs being requested. That makes it possible for ISPs (and in turn authoritarian governments) to both store detailed profiles of users’ browsing activity, as well as block specific content by its domain name or URL (without having to block everything hosted under the same IP address).

Performance

Deploy supports HTTP/2 for modern clients (and SPDY for older ones). However, browsers only enable HTTP/2 when TLS/HTTPS is used. That means in order to enjoy the significant performance benefits of multiplexing requests, your site needs to be delivered via HTTPS.2

Access to Web Platform APIs

With most of the Web community being in consensus about wanting to encrypt the whole Web using HTTPS for the above-mentioned reasons3, browser vendors recently began restricting access to certain Web APIs for sites on insecure origins in their browsers (e.g. Geolocation and getUserMedia in Chrome). Likewise, new APIs will require HTTPS from the start, if they are sensitive to users’ security or privacy. The best way to ensure the uninterrupted functionality of apps using these features is to upgrade them to HTTPS as soon as possible.

Upgrading your existing apps to HTTPS

  • Existing apps on Deploy without a custom domain (using yoursubdomain.5apps.com) have been HTTPS by default for over 3 years now. If you previously considered using a custom domain, but didn’t want to pay extra for a certificate, now you can set it up for free.

  • Apps with a custom domain, for which you subscribed to our previous HTTPS add-on service, have been switched to the new, free certificates. The paid add-on will automatically expire and you will not be charged for renewal.

  • If you were running an app with a custom domain but no SSL certificate on Deploy, we have set up all of your apps for HTTPS already. However, in case you are relying on Web Storage, calls to HTTP APIs, or unencrypted WebSocket endpoints, we disabled automatic redirects to the HTTPS version of your app. Please check your email, as we have notified you in case your app is among those.

Questions? Feedback?

As always, we’d love to hear your feedback and answer any questions you might have! Use the comments below, shoot us a tweet, drop us an email, or visit our support site.

Part 2: AppCache, Web Storage, and upgrading to HTTPS origins

We’ll soon publish a follow-up post about how we dealt with updating your cached offline apps using AppCache from HTTP to HTTPS. It will also include information on how to deal with migrating Web Storage data between HTTP and HTTPS origins. Subscribe to this blog or follow us on Twitter if you’re interested.

Footnotes

  1. While it is possible to attack HTTPS connections as well, it requires a lot of effort and usually specific targeting of single users, whereas attacks on HTTP can be done on a large scale in addition to being easy to attempt for anyone.
  2. We saw up to 35% load time decrease over HTTP 1.1 for apps delivered over SPDY and HTTP/2. Especially mobile clients with high-latency connections benefit considerably, when they can use a single TCP connection to load all resources.
  3. Also see the W3C Secure Contexts spec draft

Introducing service integrations

Sebastian Kippe ·

Good news, everyone! We just launched a new feature that lets you integrate Deploy with other services on the Internet. You can find it in the settings menu of your app panels:

We’re starting out with a few popular services, most of which we’re using for our own apps. Those are:

  • Slack and Grove.io for group chat
  • Sentry for exception/release tracking
  • Ghost Inspector for automated UI testing
  • A generic webhook for your own custom workflows and integrations

However, these are just a start. Use the link beneath the services list in order to tell us, which services you’d like to see next! We’re already looking forward to your requests.

Questions? Feedback?

As always, we’d love to hear your feedback and answer any questions you might have! Use the comments below, shoot us a tweet, drop us an email, or visit our support site.

A new system status site

Sebastian Kippe ·

About two years ago we first launched our system status dashboard, keeping you up-to-date with the live status of all our infrastructure components.

As an uptime company – hosting both your client-side apps and static websites, as well as people’s precious personal data – we kept an excellent track record of keeping your things online and speedy since day one. But sometimes things just naturally go awry.

DDoS attacks on servers or whole networks, degraded hardware performance, and other problematic situations arise. And when they do, it’s important to us that you’re in the loop about what’s happening exactly.

In order to fulfill that goal even better from now on, we just launched a completely new system status site:

Screenshot

Our new site is based on Cachet, an excellent open source status page system. Compared to our old site, it brings some very useful improvements:

  • Status types are clearer and more exact. They now include “performance issues” (the most common one in day-to-day operations) and “partial outage”, apart from the less common “major outage”.
  • Incidents aren’t tied to one service/component necessarily anymore. An attack on our whole network e.g. will be a single incident with a single update stream (while retaining correct status per service).
  • Better status types for incident updates, ranging from “investigating” to “solved”
  • First-class support for scheduled maintenance announcements and statuses
  • A single RSS (or ATOM) feed to subscribe to instead of one per service

There are even some additional features we’re not using yet, but which we will set up in the near future. Namely email subscriptions, as well as displaying key metrics on the dashboard (like e.g. mean response time).

As was the case before, the status site is hosted outside of our core infrastructure, so that the likelihood of it being slow or unavailable when it matters most is extremely small.

Let us know if you like the new site, and be sure to check out Cachet in case you need something similar for your own organization or project!


P.S. I just realized that we launched this just in time for System Administrator Appreciation Day 2015. So, happy SysAdmin Day to our master of infrastructure, @gregkare, who’s been doing an amazing job at 5apps and beyond! (He’s also very funny on Twitter; you should follow him.)

Introducing SSL for custom domains

Sebastian Kippe ·

Screenshot

Good news, everyone! We’re finally launching one of the most requested features of 5apps Deploy: SSL for custom domains. It’s available immediately on all plans, including the free tier.

How it works

  1. You can order SSL for custom domains for the duration of either 1 or 2 years. We’ll send you a reminder when it’s time to renew, of course.
  2. The SSL certificate purchase, setup, and maintenance is fully managed by us. We’ll even regenerate and exchange your certificates on Heartbleed-type security events. You just order, and we’ll take care of the rest.
  3. For your own domain you’ll get the same excellent SSL setup that we’re using for all 5apps sites and services, as well as for the free *.5apps.com subdomains that you get with every app. Check out this example on SSL Labs for all details.
  4. The SSL setup is not attached to a specific app. You can switch domains on apps as much as you want, and if there’s a certificate available it’ll automatically be used with the app that’s using that domain.

Orders usually take less than 24 hours to complete. In the case of subdomains, you’ll need to add a new CNAME record in order to validate your domain first.

Benefits

Apart from the obvious benefits of vastly increased security and privacy for your users, there’s one advantage you might not know about yet:

5apps Deploy supports the SPDY protocol, making your apps and sites load much faster on high-latency connections, like e.g. on mobile networks. But as SPDY actually requires SSL in order to work, it is only available on either *.5apps.com subdomains or custom domains with SSL enabled.

That means just by enabling SSL, you might be able to give your users significant load time improvements, especially on mobile devices and when you include a lot of separate resources.

Where to order

First, you need to set up your custom domain on an app. As soon as you’ve done that, you’ll see links for enabling SSL for that domain right under the custom domain field in your app settings panel:

Screenshot

You can also see an overview of all your custom domains as well as their SSL status on your developer account page.

Caveat

In order to be able to use multiple SSL certificates on one IP address, we’re using Server Name Indication (SNI). This protocol has been around for a while, so it is supported by all modern browsers and operating systems. However, it’s not supported by Internet Explorer and Safari on Windows XP, as well as the stock browser on Android 2.x. In those cases we’re automatically downgrading to HTTP, so that your users aren’t confronted with invalid-certificate warnings.

Questions? Feedback?

As always, we’d love to hear your feedback and answer any questions you might have! Use the comments below, shoot us a tweet, drop us an email, or visit our support site.

Archive of all entries