AO3 News

Post Header

If you have podfic, fanvids, or other works with embedded media, users who currently opt to browse the Archive over HTTPS (e.g. via a browser extension) may be unable to access your work. Before we move the Archive to HTTPS, we'll be making some changes to existing audio and video embeds to prevent more widespread issues, but there are also steps you can take now to ensure your content loads for everyone.

The problem

Many of the media players in AO3 works use HTTP links to embed Flash files for playing back audio or video. For example, here's the code for an audio player that uses an HTTP URL as its src:

<embed type="application/x-shockwave-flash" flashvars="mp3=MP3_FILE_URL" src="http://archiveofourown.org/system/dewplayer/dewplayer.swf" width="200" height="27" allowscriptaccess="never" allownetworking="internal"> </embed>

If someone uses HTTPS to access a work with code like that, their browser will notice a mismatch between the page they're on (HTTPS! secure!) and the content it's being asked to display (HTTP! not secure!). When this happens, many browsers will err on the side of security: they won't load or display the embedded media.

Most browsers do allow users to override this behavior and display insecure content, but how easy that is varies a lot from browser to browser, and the process can change from one browser version to the next. (A web search for "display mixed content" plus the name and version of your browser should provide the information you need.) Whenever possible, it's easier -- and safer -- to tell the browser to load the file over HTTPS.

What you can do

To help the browser out, you can simply add that little "s" to the relevant bit of your embed, which will create a secure connection to the file in question. The vast majority of our whitelisted multimedia players already offer HTTPS support. If you only have a few works with audio, video, or even image content which link to external media, you can edit your works, look for the src part and turn the http bit into an https. That's it!

This will ensure that everyone can access your podfic, fanvid, art, or other media, even if they're browsing the Archive in HTTP mode. (Browsers are cool with that mismatch.)

What we will do

Since we can't expect all our users to edit all their multimedia works by hand, we will ensure that all embeds use the correct linkage by doing one big find-and-replace on our end. Because we only allow embeds from a few sites, we can easily find the affected works by searching our database for specific HTML. Then we can run a few simple commands to update the embed code's src from http to https.

This will not touch the content of your work in any way, or alter anything about your work that isn't neatly bracketed by a pair of very specific quote marks. When it's all done, your content will be accessible to users browsing the Archive in secure mode, if it wasn't before. \o/

We are planning to do this on October 4th, right before we switch to HTTPS mode on the AO3.

To make sure that works posted from now on won't run into this problem, we've updated our code to ensure embeds use https links where available, and edited our documentation for audio player embeds.

Edit 09:24 UTC on 05 October, 2017: The update to embedded media files has been completed, but attempts to move the Archive to HTTPS were unsuccessful. HTTP will remain the default for a little while longer, and we'll update you via our Twitter account when we're ready to try again.

Edit 19:16 UTC on 12 October 2017: We successfully made the switch to HTTPS for a few days; however, the extra strain from encrypting all traffic proved too much for our servers at peak times. Until we have installed additional servers (coming soon!), HTTP will remain the default protocol. (Of course, you can still elect to use a secure connection, e.g. via a browser extension like HTTPS Everywhere.) Please follow @AO3_Status on Twitter for futher updates.

Edit 22:15 UTC on 14 October 2017: We have implemented the caching needed to reduce server strain and are currently back on the secure protocol by default. We believe we'll be able to remain on HTTPS, but if it proves too much, we will switch back until our new frontend servers arrive.

Edit 18:28 UTC on 19 March 2018: We have successfully installed our new frontend servers and are now permanently enforcing HTTPS on the Archive. \o/ We still provide HTTP access via insecure.archiveofourown.org.

Comment

Post Header

If you've been following our release notes, you know that we have been working towards full HTTPS support on the Archive for a while now. Today, we're happy to announce that beginning on October 4th, all connections to the Archive will use HTTPS by default.

If you use a modern browser, you won't have to do anything -- we'll just flip a (virtual) switch to enforce a secure connection between your browser and our servers. As a result, all AO3 pages will display a lock symbol and/or a friendly little https:// in the address bar of your browser. Old http:// links to the Archive will automatically redirect to the secure version.

For users who might have trouble accessing secure websites, we will continue to provide HTTP access to the Archive -- via insecure.archiveofourown.org -- for as long as necessary. (You might still run into the odd HTTPS link on the site, for example when downloading a work as a PDF, MOBI, or EPUB file.)

We don't expect any downtime during this transition, and you shouldn't notice any changes. Just to be on the safe side, we will monitor our servers and firewalls and might temporarily revert back to HTTP mode should we notice any problems.

Please keep an eye on the @AO3_Status Twitter account for more updates as we get closer to the switch.

Happy (secure) browsing!

Edit 09:24 UTC on 05 October, 2017: The update to embedded media files has been completed, but attempts to move the Archive to HTTPS were unsuccessful. HTTP will remain the default for a little while longer, and we'll update you via our Twitter account when we're ready to try again.

Edit 19:16 UTC on 12 October, 2017: We successfully made the switch to HTTPS for a few days; however, the extra strain from encrypting all traffic proved too much for our servers at peak times. Until we have installed additional servers (coming soon!), HTTP will remain the default protocol. (Of course, you can still elect to use a secure connection, e.g. via a browser extension like HTTPS Everywhere.) Please follow @AO3_Status on Twitter for futher updates.

Edit 22:15 UTC on 14 October 2017: We have implemented the caching needed to reduce server strain and are currently back on the secure protocol by default. We believe we'll be able to remain on HTTPS, but if it proves too much, we will switch back until our new frontend servers arrive.

Edit 18:28 UTC on 19 March 2018: We have successfully installed our new frontend servers and are now permanently enforcing HTTPS on the Archive. \o/ We still provide HTTP access via insecure.archiveofourown.org.

Comment

Post Header

Published:
2015-04-15 14:58:33 -0400
Tags:

Banner by Diane with the outlines of a man and woman speaking with word bubbles, one of which has the OTW logo and the other which says 'OTW Announcement'

The OTW began receiving reports on Monday, April 13, that a site called Ebooks Tree was hosting downloadable files of works posted to the Archive of Our Own, and that they were charging for access to these files. Since then our Legal team has been investigating the entities involved and our Accessibility, Design, & Technology Committee has been finding out what had been done with AO3 content and how.

Upon further investigation, it became clear that Ebooks Tree is not hosting MOBI files of AO3 works, but linking directly to the versions hosted on the AO3 servers, and we do not currently believe they are hosting PDF files, either. The AO3 team has taken action to prevent anyone from downloading works if they were following the links provided by Ebooks Tree.

In the meantime, we have received many questions from fans through both our news outlets and the AO3 Support form. We would like to compile here some of the responses we have already made, as well as address steps that fans can take. We would like to ask that if you have further questions you make them here as it will be easier for more people to get the same information.

What is AO3 Doing To Prevent Fanworks From Being Taken?

As much as we’d like to prevent a recurrence of this kind of issue, we want to take steps that will not end up interfering with fans' use of the Archive of Our Own and content found there. Here are some things we can do and steps fans can take:

  1. The AO3 discourages bots from accessing downloads in our robots.txt rules. While these rules are usually followed by entities such as search engines, bots can also be set to ignore these rules.
  2. We are limiting how many files can be downloaded (and how fast) and could tweak these settings further.
  3. The only way we can prevent bots from downloading files would be to add a CAPTCHA button to downloads, and this would not meet our first goal of maximum inclusivity. CAPTCHA and reCAPTCHA interfaces only work in a limited set of circumstances and create a number of problems for users who are not fluent in English or who have visual, auditory, or cognitive disabilities.
  4. We could also eliminate downloads entirely, but some users depend on downloads due to limited internet time or because they only have mobile access.
  5. Users can opt to keep fanworks locked away from anyone or anything that isn’t a logged-in AO3 user. In order to do so, edit your work and checkmark the “Only show your work to registered users” option, located in the Privacy box. While very dedicated PDF thieves could theoretically circumvent this by creating an account for their bots, this can help.
  6. If you are not yet a registered user at AO3, request an invite! Other than bots, everyone is welcome to have their own account at any of our projects. To get an AO3 account, click the ‘Get Invited!’ button on the front page, and you'll be able to add your email address to the automated invite queue. The queue is first come, first served, and invite codes are sent out on a regular basis. The wait time is usually less than 48 hours, but be sure to check your spam folders if it's been more than a few days.

Avoid Possible Phishing Scams

It is possible that the purpose behind offering content from Ebooks Tree was to gather financial information from users. To access their files they require you to sign up via a site called http://www.lazygame.net/ and give your credit card info. It is probably a very bad idea for fans to take this step.

What Can Fans Do if Their Fanworks Actually Are Hosted Elsewhere?

Fans who find their works taken and used elsewhere without their permission may want to consider using this template to tell those sites to take down your content:

  • Your Name and/or Pseudonym as an e-signature (or the name of the person you’ve authorized to submit this request, with a slash before it and after it):
  • Link(s) to the unauthorized works (link to the pdf, the mobi and the page hosting all of it)
  • Link(s) to an authorized version of your work (whether on AO3, tumblr, LJ or somewhere else)
  • An email address of the submitter (include it again even if it’s in the header)
  • This statement: I have good faith belief that use of the material in the manner complained of is not authorized by the copyright owner, its agent, or the law.
  • This statement: The information in the notification is accurate, and under penalty of perjury, that the complaining party is authorized to act on behalf of the owner of an exclusive right that is allegedly infringed.

Legal Options for Fanworks

Here are some questions fans have had about their works, along with replies from our Legal Advocacy team.

  1. “Do I even own any copyright in my fanworks?” Answer: yes, you automatically own copyright in your original expression. You don’t own any rights in the characters, settings, etc. that you’ve based your fanworks on, but you do own rights in what you, yourself, have added to them—which means people can’t copy and sell your fanworks without your permission.
  2. “Can the OTW make a copyright claim on behalf of all people whose works have been taken off the AO3?” Answer: No. We don’t own any rights in your work, and that’s how you’d want it! When you post work on the AO3, you give the AO3 the right to display it, but you don’t give the AO3 any ownership rights at all -- which means the OTW doesn’t have the legal ability to, for example, issue a DMCA takedown notice for all of the AO3-hosted works, as some have suggested.

We will be updating this post should further information become available so please check back or leave questions here.

Comment

Post Header

To combat an influx of spam works, we are temporarily suspending the issuing of invitations from our automated queue. This will prevent spammers from getting invitations to create new accounts and give our all-volunteer teams time to clean up existing spam accounts and works. We will keep you updated about further developments on our Twitter account. Please read on for details.

The problem

We have been dealing with two issues affecting the Archive, both in terms of server health and user experience.

  • Spammers who sign up for accounts only to post thousands of fake "works" (various kinds of advertisements) with the help of automated scripts.
  • People who use bots to download works in bulk, to the point where it affects site speed and server uptime for everyone else.

Measures we've taken so far

We have been trying several things to keep both problems in check:

  • The Abuse team has been manually banning accounts that post spam.
  • We are also keeping an eye on the invitation queue for email addresses that follow discernible patterns and removing them from the queue. This is getting trickier as the spammers adjust.
  • We delete the bulk of spam works from the database directly, as individual work deletion would clearly be an overwhelming task for the Abuse team; however, this requires people with the necessary skills and access to be available.
  • Our volunteer sysadmin has been setting up various server scripts and settings aimed at catching spammers and download bots before they can do too much damage. This requires a lot of tweaking to adjust to new bots and prevent real users from being banned.

Much of this has cut into our volunteers' holiday time, and we extend heartfelt thanks to everyone who's been chipping in to keep the Archive going through our busiest days.

What we're doing now

Our Abuse team needs a chance to catch up on all reported spamming accounts and make sure that all spam works are deleted. Currently the spammers are creating new accounts faster than we can ban them. Our sysadmins and coders need some time to come up with a sustainable solution to prevent further bot attacks.

To that end, we're temporarily suspending issuing invites from our automated queue. Existing account holders can still request invite codes and share them with friends. You can use existing invites to sign up for an account; account creation itself will not be affected. (Please note: Requests for invite codes have to be manually approved by a site admin, so there might be a delay of two to three days before you receive them; challenge moderators can contact Support for invites if their project is about to open.)

We are working hard to get these problems under control, so the invite queue should be back in business soon! Thank you for your patience as we work through the issues.

What you can do

There are some things you can do to help:

  • When downloading multiple works, wait a few moments between each download. If you're downloading too many works at once, you will be taken to an error page warning you to slow down or risk being blocked from accessing the Archive for 24 hours.
  • Please don't report spam works. While we appreciate all the reports we've received so far, we now have a system in place that allows us to find spam quickly. Responding to reports of spam takes time away from dealing with it.
  • Keep an eye on our Twitter account, @AO3_Status, for updates!

Known problems with the automated download limit

We have been getting reports of users who run into a message about excessive downloads even if they were downloading only a few works, or none at all. This may happen for several reasons that are unfortunately beyond our control:

  • They pressed the download button once, but their device went on a rampage trying to download the file many times. A possible cause for this might be a download accelerator, so try disabling any relevant browser extensions or software, or try downloading works in another browser or device.
  • They share an IP address with a group of people, one of whom hit the current download limit and got everyone else with the same IP address banned as well. This can be caused by VPNs, Tor software, or an ISP who assigns the same IP address to a group of customers (more likely to happen on phones). Please try using a different device, if you can.

We apologize if you have to deal with any of these and we'll do our best to restore proper access for all users as soon as possible!

Comment

Post Header

We've recently upgraded our password encryption in response to a possible security issue affecting a number of accounts. Your account will be automatically upgraded to use the stronger encryption next time you log in. If you usually stay logged in all the time, please log out and then back in to ensure your account is upgraded.

What was the issue?

We maintain a virtual development environment which coders who want to work on the Archive can download: this is a copy of everything needed to run the Archive so that our coders can easily develop and test. This comes with a partial copy of Archive data, so that coders can see how changes in the code will affect the site, with identifying information such as email addresses stripped out. However, we were alerted to the fact that the way we previously encrypted passwords meant someone with access to this data could theoretically use it to figure out passwords associated with some accounts.

Our new encryption system will make it much harder for anyone who accesses our data in any way to guess passwords. In addition, we will review how we put together the sample data we use for development. Only known coders have accessed the old data (we keep a record of downloads) and we have no reason to think that users' accounts were compromised. However, account security is a priority and we're asking our users to change their passwords as a precautionary measure.

How to change your password

Affected account holders will shortly receive an email with a link to the "Change My Password" page. To change your password without the link:

  1. Log into your account with your current password.
  2. Visit your Profile.
  3. Follow the "Edit My Profile" link at the bottom of the page.
  4. Follow the "Change Password" link at the top.

We strongly recommend you pick at least a combination of letters and numbers, and avoid easily guessable passwords like 'password' or '123456'. You may wish to use a service like How Secure is my Password? to help you create a strong password.

Comment

Post Header

Published:
2014-04-09 04:54:04 -0400
Tags:

As many of you are aware, the Heartbleed Bug is a serious vulnerability in the OpenSSL software library. It is possible for people to gain access to information from vulnerable sites that would allow them to impersonate those sites in order to obtain sensitive data. With some smaller sites, it may be possible to acquire user names and passwords directly.

Two stick figures discuss the data that could be revealed by the Heartbleed vulnerability, including keys, emails, passwords, and erotic fanfiction
Comic courtesy of xkcd

Fortunately, our Systems team has investigated and determined that we have never run a version of OpenSSL on our web servers which is vulnerable to this attack. They have also upgraded OpenSSL and restarted the application on our application servers, even though it should not be possible to exploit any vulnerabilities on those systems.

Login information used only on the Archive should be safe. If you also use the same information on other sites, it would be a good idea to change it. Keep in mind that you shouldn't change your password on a site until after you know that they've fixed the vulnerability. You can check the status of a site with this Heartbleed test.

As always, our volunteers will do their best to keep your information safe and alert you to any vulnerabilities as soon as possible.

Comment

Post Header

Published:
2013-02-07 17:25:55 -0500
Tags:

While developing the Archive of Our Own, site security is one of our top priorities. In the last couple of weeks, we've been reviewing our 'emergency plan', and wanted to give users a bit more information about how we work to protect the site. In particular, we wanted to make users aware that in the event of a security concern, we may opt to shut the site down in order to protect user data.

Background

Last week we were alerted to a critical security issue in Ruby on Rails, the framework the Archive is built on. We (and the rest of the Rails community) had to work quickly to patch this hole: we did an emergency deploy to upgrade Rails and fix the issue.

As the recent security breach at Twitter demonstrated, all web frameworks are vulnerable to security breaches. As technology develops, new security weaknesses are discovered and exploited. This was a major factor in the Rails security issue we just patched, and it means that once a problem is identified, it's important to act fast.

Our security plans

If the potential for a security breach is identified on the site, and we cannot fix it immediately we will perform an emergency shutdown until we are able to address the problem. In some cases, completely shutting down the site is the only way to guarantee that site security can be maintained and user data is protected.

We have also taken steps for 'damage limitation' in the event that the site is compromised. We perform regular offsite backups of site data. These are kept isolated from the main servers and application (where any security breach could take place).

In order to ensure the site remains as secure as possible, we also adhere to the following:

  • Developers are subscribed to the Rails mailing list and stay abreast of security announcements
  • We regularly update Rails and the software we use on our servers, so that we don't fall behind the main development cycle and potentially fall afoul of old security problems
  • All new code is reviewed before being merged into our codebase, to help prevent us introducing security holes ourselves
  • All our servers are behind firewalls
  • All password data is encrypted

What you can do

The main purpose of this post is to let you know that security is a priority, and to give you a heads up that we may take the site down in an emergency situation. Because security problems tend to be discovered in batches, we anticipate that there is an increased risk of us needing to do this over the next month. In this case, we'll keep users informed on our AO3_Status Twitter, the OTW website and our other news outlets.

Overall site security is our responsibility and there is no immediate cause for concern. However, we recommend that you always use a unique username / password combination on each site you use. Using the same login details across many sites increases the chance that a security breach in one will give hackers access to your details on other sites (which may have more sensitive data).

We'd like to thank all the users who contacted us about the latest Rails issue. If you ever have questions or concerns, do contact Support.

Comment

Post Header

Published:
2013-01-04 11:26:49 -0500
Tags:

A number of users have reported receiving malware warnings from Avast when accessing the Archive of Our Own. We haven't been hacked, and there is no cause for concern - the warning was a false positive.

Avast is erroneously flagging a file used by New Relic, which we use to monitor our servers (you can see more details in this thread). New Relic are working with Avast to resolve the issue, and we expect things to be back to normal very shortly (we have had only a small number of reports today).

Thank you to everyone who alerted us to this! If you see something unexpected on the site, we always appreciate hearing about it right away. You can keep track of the latest site status via our Twitter AO3_Status, and contact our Support team via the Support form.

Comment