Tag: web

Posted on

Flickr features I’ve known and loved

As the planning for the sale of Yahoo!/Altaba to Verizon continues, I’m not the only person worried about the fate of Flickr, which has been owned by Yahoo since 2005:

I’ve got a tediously backed-up local copy of my photos and won’t have to kiss them goodbye, but as a happy Pro user of Flickr I’m really worried about its future and beginning an active search for replacements. I’m going to start evaluating possible replacements on the basis of these specific features, roughly in order of importance:

My favourite Flickr features

Embedding my foremost use of Flickr is as a photo host for my parenting blog and, increasingly, to show off my best photos. The ability to embed photographs in third-party websites is essential to me.

Locking at the photo level and guest access. It’s not easy to find non-recent photographs of my children on my Flickr account. That’s because I have a script that marks photos as private once they’re a certain age. Some other types of photos (for example, photos of other children) I often mark as private immediately.

Much of my web life runs this way: just because you can find my recent stuff doesn’t mean you get to casually browse everything I’ve done on the Internet since the beginning of time (circa 1999). I’ve taken full advantage of websites with individual locking every time I’ve used one, including WordPress sites, LiveJournal&Dreamwidth, Pinboard, and, yes, Flickr, and strongly prefer it.

At the same time, the chance of people who care about me obtaining a login to Flickr, or to social-photos-site-of-the-month in order to view pictures of a party we were at is basically nil, so the ability to share links to photos via Flickr’s guest pass system has made it useful to me for semi-private events and photos.

API access. I’m not locking all this stuff on all these sites down by hand! It’s all scripted and done via APIs.

Multiple albums for a single photo I look at my photos through several different types of, uh, “lenses”. There’s events, there’s individuals in the photos (mostly my children), and there’s my show-off albums for my favourite photos or ones most I’m likely to want to share with other people if only they’d ask to see more of my photos. I use albums for all three ways of looking at photos, and thus many of my photos are in both a “my kid at age 3” album and a “visit to the beach in November” album.

I also use tags and I might be able to modify my workflow to use tags to replace some of these features, although the result of a tag search would need to be viewable as a first class album, rarely true in my experience so far.

Creative Commons licencing. I like easily dropping my photos into a big pool of photos that might someday find good uses elsewhere and licence a lot of my non-portraits CC BY for (nearly) maximum re-usability. I fear that even sites that support CC licencing won’t end up being searched by anyone in practice, and if I note a CC licence myself in the description, it’s never going to happen.

Features I’d reluctantly sacrifice

Chromecast support. It’s been really enchanting having our TVs display great photos of our kids throughout their lives, travel we’ve done, and a lot of clouds, all via Chromecast’s support for using Flickr photos for background images, but I’m willing to give it up for my core set of features.

An app. Don’t get me wrong, I do like being able to peruse my photos on my phone, but I’d give it up if I had to. Because I do about half my photography with a DSLR, and edit essentially all my photographs, I don’t upload photos via apps in any case.

Less important

The social ecosystem. I started using Flickr regularly after a lot of people stopped, and I’m indifferent to the social features, eg favourites, comments, following other folks, putting my photos in group albums. I do use some of these, but I won’t be looking for them in a replacement.

Locking to different sets of people. I do use Flickr’s “friends” and “family” distinction a little, but in giving up social, I’m also happy to give up locking other than “locked” and “not locked”.

And now, I’m afraid, it’s well and truly time to go shopping for a new photo host. My favourite. Only not.

Posted on

Make your Dreamhost site HTTPS-only

Encrypt all the traffic!

Some of the archival Ada Initiative web content is hosted on Dreamhost, and today I re-enabled HTTPS for it now that Let’s Encrypt certificates are available both on Dreamhost and WordPress.com.

Update October 2017: official Dreamhost documentation on adding an SSL certificate and forcing your site to load securely with an .htaccess file is available.

Here’s how to enable, and insist on, HTTPS connections to sites hosted on Dreamhost:

  1. Log into the panel
  2. Go to Secure Hosting
  3. Click ‘Add Secure Hosting’
  4. Select the domain you want from the dropdown, check the box next to ‘By checking this option you agree to the Let’s Encrypt Terms of Service.’, leave ‘Unique IP’ unchecked, and press ‘Add now’.
  5. Important: wait for an email from Dreamhost telling you the certificate is ready. This seems to take about fifteen minutes or so. The email contains a copy of the certificate but you don’t need to do anything with it, they configure the webserver automatically at about the same time as they send the email.
  6. Once you have received the email, check that your site is available at https://YOUR-URL and that your browswer does not report errors. (If it does, wait around 15 minutes, try again, and if you’re still seeing errors, screenshot them and contact Dreamhost support.)

Now that HTTPS is working on your site, you can then force all HTTP requests to redirect to HTTPS by placing this in the ~/YOUR-URL/.htaccess file:


<IfModule mod_rewrite.c>
# Redirect all insecure requests
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R=301,L]
</IfModule>

# tell web browsers not to even try HTTP on this domain for the next year
# uncomment this only after you've confirmed your site is working on HTTPS, since it commits you to providing it over HTTPS
# Header set Strict-Transport-Security "max-age=31536000" env=HTTPS

Check that visiting http://YOUR-URL now redirects to https://YOUR-URL, and the same should be true of pages underneath http://YOUR-URL.

Feature request for Dreamhost: make a “force HTTPS” option in your standard config.

For more information on Strict-Transport-Security see HTTP Strict Transport Security for Apache, NGINX and Lighttpd and Stack Overflow: How to set HSTS header from .htaccess only on HTTPS.

Bonus round: update absolute links

If your site is a bunch of static HTML files, and you have done a lot of absolute linking to your own webpages, here’s a possible command you could run, replacing example.com with your own domain. I don’t recommend running it unless you know the UNIX command line, and you have a fairly good idea of what find and sed both do:


DOMAIN=example.com
cp -a ~/$DOMAIN ~/$DOMAIN-backup-before-https-edit
cd ~/$DOMAIN
find -type f -name "*.html" -exec sed -i "s/http:\/\/$DOMAIN/https:\/\/$DOMAIN/g" {} \;

Creative Commons License
Make your Dreamhost site HTTPS-only by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Posted on

US-based websites and COPPA

Alex Sutherland, who is not yet 13 years of age, told Google+ his date of birth and promptly lost access to his Gmail account.

I’m not posting this to join any obnoxious blamestorm aimed at Alex or his parents: it sucks he lost his email archives and I hope that his parents are able to get it back for him. It sucks he had his trust breached and there’s no getting that back for him.

But I’m mostly posting because people are seeing the provisons of the US Children’s Online Privacy Protection Act (COPPA) for the first time and saying “pfft, not that hard to comply, why ban under 13s at all?” There was an illuminating comment on Making Light that is helpful there:

COPPA has a lot of “common sense” provisions which no doubt sounded great from the point of view of legislators and parents, but which are pretty appalling from the point of view of the operator of a Web 2.0 service. They’re burdensome enough, that, to my knowledge, only sites intended specifically and exclusively for children trouble to implement them. That is, no Web2.0 websites operating in the US permit users under the age of 13, except for specialty children’s sites. Not Google, not Facebook, not MySpace, not Livejournal, not Twitter, not Flickr or Picassa or Photobucket, not any web service here in the US.

Why? Well, you know how when you have a problem with your Gmail, you can pick up your phone and call Google’s tech support line? Ah ha ha ha. Right: no such thing. Well, one of the provisions of COPPA is that there has to be a phone number through which parents can call the service, as well as an email address at which they can email the service. Google doesn’t particularly want to have to pay operators to be standing by. No Web2.0 startup wants to be staffing a phone number open to the general public.

Google also doesn’t particularly want to figure out how to fulfill the provision of writing a statement as to what “information it collects” from (minor) users, since it allows users to type absolutely anything they want into those email bodies. Among sites for children, the open-ended TEXTAREA form field, like the one I’m typing this comment into, are seen as threats; highly structured or brief forms of input — pulldown menus and short text fields — are seen as safer. That prohibits most interesting Web2.0 applications.

Now Google is pretty big, it could afford to solve this if it wanted to, but has decided not to. But I think this is an issue worth knowing about in general: this means that children under 13 can’t participate in the Web as we know it today, essentially, because COPPA means that it’s prohibitively expensive to allow them to use websites that allow free-form content. Opinions might vary on whether this is a good thing (I certainly don’t think so, although I’m also not planning to turn my son loose on Google on his sixth birthday either), but it’s a thing.

Posted on

Self-hosted photos, line, end of

It’s quite probably that sometime in the next few days I will hand my public photo hosting entirely over to Flickr or Picasa, quite belatedly compared to most people I know. I wanted to document some self-hosting problems:

  • Self-hosted photos are isolated, because there’s no subscription standard for photos. RSS and so on aren’t ideal because each application decides how to embed the thumbnail and so on in the content, meaning that you can’t cleanly aggregate images from all different software for easy viewing. I really think this is a big deal in uptake of self-hosting: you can’t let people pull your new photos into their own app of choice for viewing. (Same problem for blog comments, by the way, although I realise people would then want a ‘make a comment’ API and the spamming gets even worse.)
  • Gallery 2, which I started using in 2007, has been end-of-lifed in favour of Gallery 3, which is effectively a new project. Gallery 3 is still under-themed (and all of the themes look like a big ad for Gallery 3) and its new upload API isn’t supported by local clients yet. Plus, importing and re-linking everywhere (sure, they support redirects… if you weren’t using clean URLs and never hotlinked the thumbnails anywhere) is enough hassle that I’m not willing to do it every three years, and a project that has had a clean re-write twice is likely to do it again.
  • None of the big free gallery software projects (Gallery 3, Zenphoto, Plogger, probably Coppermine but I haven’t looked) support importing from the others well. You’re supposed to start afresh, or use a Perl script that has the stability status of "worked for me, more or less."
  • If you do switch, there’s terrible support for HTTP redirects of either photo pages or thumbnail hotlinks.
  • The usual web-app sysadmin problems, in which you’re supposed to make everything world-writable, and you upgrade by downloading a ZIP and unpacking it and opening a special file, and just copying a few things, and and and.
  • If photo locking is available at all, it’s way complicated, it requires people subscribe to your (well, my) dinky little photo site, there are no guest passes, etc etc. This is important to me as the parent of a baby.
  • They are feature-chasing, not leaders in features, especially usability.

I stopped enjoying doing this kind of thing for fun many years back. (You know what software thing I’m looking forward to? Learning R. You know what doesn’t resemble learning R? Writing web apps.)

PS: if you email me to suggest that I try self-hosting apps I haven’t tried, I very likely will not try it for lack of time. You would need to put serious work into the sales pitch, up to and including describing a great workflow for my particular needs and offering to migrate my database for me. I could be surprised, I guess.