Tag: livejournal

Posted on

Don’t trust Livejournal? Delete your account.

In December 2016, LiveJournal moved their servers to Russia and in April 2017 they updated their terms of use in a way many users find unacceptable.

In January 2017, as people considered the implications of the server move to Russia, I saw a number of people hesitant to delete their accounts as they were hoping to overwrite their data on Livejournal before deleting, by, eg, replacing their entries with Shakespeare’s plays, or with random nonsense, so that Livejournal didn’t have the entry any more. This won’t work and you might as well just delete your Livejournal account.

Here’s a loose analogy for the way that data on a site like Livejournal may be stored:

There’s a journalling website. It stores its entries on vast reams of paper in a giant library and new entries are scribed onto paper and filed.

The “overwrite with nonsense” strategy assumes that any journal entry you make is at a fixed location on a fixed bit of paper for all time. When you update the entry, the scribe goes to the existing bits of paper and writes on top of them. While this is technically possible with hard drives and similar, in a way that it isn’t with literal paper, here’s what more likely actually happens:

You update the entry, replacing it a Shakespearean play. The new version is written on entirely random empty paper (maybe blank, maybe where someone else’s deleted entry once was), and an index in a different part of the library is also updated. It used to say that your entry of January 7 was on floor 6, shelf 216, and now it says that your entry of January 7 was on floor 12, shelf 16.

But the contents of floor 6, shelf 216 are likely not overwritten for some time. Perhaps they’re marked as available to be overwritten, to be reused whenever it seems sensible, but you won’t know when that is. On the other hand, perhaps they are deliberately marked in the index as “an old version of the January 7 entry” for the sake of users having an edit history, or to have an audit trail, or because a lawsuit demands it, or because a government demands it. This may or may not be visible to you.

Even if floor 6, shelf 216 is marked available to be overwritten, it may not be actively erased, and if it isn’t actively erased, it’s available to be searched by a sufficiently determined or empowered person. (And searching unindexed digital storage is a lot faster and cheaper than searching paper, so not one thousandth as determined or empowered as you need to be to search a library full of unindexed paper.)

And even if floor 6, shelf 216 is no longer marked as “an old version of the entry of January 7”, on any moderately well-run website, floor 6, shelf 216 was never the only copy of your entry anyway. What if there was an accident with fire or water or whiteout? There are backups of your entry, probably at least two in the same library and at least one in a different library. These backups are usually moments in time, ie, the state of the entire journalling website as of New Years. The state of the entire journalling website as of New Years the previous year.

These backups are almost certainly never wiped of entries that are simply edited, and without adding a system that searches back through backups and selectively deletes backups of deleted accounts, they most likely contain the complete contents of deleted accounts as well.

So what you’ve ended up with is a situation where floor 12, shelf 16 contains a Shakespearean play, floor 6, shelf 216 likely contains your original entry, and there are several backups around that almost certainly contain your original entry and are designed in such a way as to be found and restored relatively quickly. This is not a much more secure situation than before you replaced the entry with a Shakespearean play; probably not worth the work you did.

All that said, it’s important to know that there are trade-offs in adding secure, permanent deletion. People quite often edit or delete their data accidentally, or temporarily — for example it is quite common to disable social media accounts temporarily to enforce a social media break — and it’s also common to be hacked and have your data deleted by the hacker. Enthusiastic data scubbing will actively harm you in all these cases. On top of that, storage systems fail (in my analogy, the library burns down, except hard drives fail more often than paper does), and backups are especially important then. And any system that goes back in time and edit backups has risks; what if it has a bug (all software has bugs) and deletes things it shouldn’t? System design to balance securely deleting data that users want to permanently delete with rarely or never deleting data they expect to keep is not easy.

So Livejournal or another site has your personal data, what should you do? I suggest that when you no longer use an online service, or you no longer trust in its management, that you take a personal backup of the data if possible and if you want it, and then delete your account.

You cannot usefully take any additional steps like overwriting your account with nonsense to ensure that actual data scrubbing took place and you should assume that it wasn’t scrubbed unless you can find some written guarantee otherwise. However, over time, backups will get selectively pruned, outages will happen, the business may eventually fail and your data will most likely become slowly less available and complete. That’s the best you can do.

For online services you actively use and where you do trust the management enough to keep your account, ask for written descriptions of their data scrubbing practices to be developed for deleted data and deleted accounts, including deletion from backups and handling of disused hard drives.

Elsewhere:

Tim Chevalier, PSA: Switching to Dreamwidth? (January 2017).

Disclosure: I am an employee of Google. This post does not describe Google’s data deletion practices, in which I’m not an expert in any case; it’s a general description of easy, sometimes harmful, defaults that systems designers could fall into. For Google-specific information, you can view privacy.google.com and Google Infrastructure Security Design Overview.

Creative Commons License
Don’t trust Livejournal? Delete your account. by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Posted on

If you’re still maintaining a LiveJournal, your journal’s now in Russia

Signal-boosting this news as I know a few people still maintaining a LiveJournal who might choose to delete it, or change their use of LiveJournal after learning about this.

LiveJournal is now hosted in Russia

As of late December 2016, the LiveJournal servers (computers) are now hosted in Russia. While LiveJournal has been owned by Russian company SUP since 2007, the servers had until now been hosted in the US and access to them somewhat controlled by Californian law.

SUP has, to the best of my knowledge, not announced or commented on this themselves, but there’s more information at rahirah’s Dreamwidth journal with links to different evidence of the new location of the servers.

A Russian-language LiveJournaller appears to report that Russian law then allows that all the confidential information of [LiveJournal] users is available for [Russian] domestic security services in real time [note though that that’s a automated translation].

A BBC report on Russian law regarding social media in 2014 seems to confirm this:

A new law imposing restrictions on users of social media has come into effect in Russia.

It means bloggers with more than 3,000 daily readers must register with the mass media regulator, Roskomnadzor, and conform to the regulations that govern the country’s larger media outlets.

Internet companies will also be required to allow Russian authorities access to users’ information.

Thanks to my original source of information about this (found via @anatsuno on Twitter).

siderea expresses several important concerns with this:

  1. if you’re in Russia or vulnerable to Russia, and a political opponent, you could now be more easily identified by Russian security
  2. regardless of where you are, your LiveJournal could be possibly be deleted without notice for expressing opposition to Russia or its interests or for other content censored in Russia (eg LGBT-related content)
  3. the flight of LiveJournal users from LiveJournal following this news could simply kill the business and cause everyone’s journals to disappear without notice (Archive Team is storing public entries, regarding it as an at-risk site)

Readers’ connections to LiveJournal aren’t private

LiveJournal redirects secure https links back to insecure http. For example, if you visit https://ohnotheydidnt.livejournal.com/ your browser will connect, but it will be instructed to head to http://ohnotheydidnt.livejournal.com/ before loading the page. (Info from this Dreamwidth comment by mme_hardy, confirming my personal experiences with LiveJournal RSS feeds over the last several months.)

What this means is that the content of any entries you read, including locked ones by both you and other people, are trivially visible to anyone who can eavesdrop on your net connection, including (often) other people on your local network, and anyone on the path between you and LiveJournal such as your ISP and anyone with access to the data flowing across international cables or access to the data as it enters the Russian hosting facility, whereas https connections are encrypted in a way such that those people can see that data is flowing but can’t read it absent considerably more niche and intensive technical measures. (Even if HTTPS were turned on by LiveJournal, you wouldn’t be safe from the Russian law, since they can ask LiveJournal itself to turn over your data in addition to whatever nation-state attacker level techniques they can employ.)

Given my experience with LiveJournal RSS feeds, I’m fairly sure this has been true for some time, predating the move of the servers to Russia. (Here’s one other report that this was already true as of September 2016.) Regardless of timing, this speaks of, at best, disregard for the privacy of their users’ explicitly private (because friends-locked!) information. It’s 2017, mandatory HTTPS for transmission of any data that is sensitive or might, conceivably, somehow, maybe, be sensitive is an absolute minimum standard for user safety. LiveJournal doesn’t even have optional “if you have HTTPS Everywhere installed” or “if you remember to stick the s into the URL yourself” HTTPS (which would still be insufficient as you cannot control whether your readers use HTTPS when reading your journal).

Getting your content out of LiveJournal

If based on this you choose to delete your LiveJournal, here are some options to keep your entries. This list isn’t comprehensive.

If you want to move the content to another website, here’s some blogging platforms that provide imports from LiveJournal:

If you want to download your entries for private use, you can:

  • use LiveJournal’s own export tool but rather painfully (you’ll have to do one download per month), and without comments
  • use ljdump on the command line, which worked for me as of 2015 when I deleted my LiveJournal, but will require that you’re an experienced command line user
  • use BlogBooker to export it to a Word or PDF file (disclosure: I haven’t used this site in quite some time, and would appreciate hearing if it works, but I suggest people at least try it because it exports to a non-programmer friendly format that people could keep as a private archive, and claims to include comments and images)
  • Archive Team lists other backup tools

If your LiveJournal made use of their photo hosting, I am not sure which backup solutions will import your photos or how they will be stored. I am also not aware of any import tool that replaces LiveJournal entries with a “this entry has moved to URL” message or similar. If anyone is working on a competing LiveJournal import/export tool, photo export and redirection text are both features that my friends and I would have found useful at various times.

Creative Commons License
If you’re still maintaining a LiveJournal, your journal’s now in Russia by Mary Gardiner is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Posted on

Social networking requirements

This article originally appeared on Geek Feminism.

I knew that someone posted on this blog discussing what requirements a feminist-informed social network would have. Turns out it was me. A year on, and due to discussions around Google+, I think I have some positive requirements. (I recommend reading the old comments thread too.)

Control over identifying information. Name, gender, age, who you are friends with, what you talk about, what events you are in, and what you look like: this is all varyingly sensitive information and should be able to be hidden.

As few restrictions as possible on identity. Allowing use of pseudonyms, not assuming that everyone has two, or two ‘important’, names, free specification of gender if specified at all. As little structured compulsory information as possible. Unstructured, free-form, and non-compulsory are key things here.

Accessibility. State of the art accessibility design including testing with screen readers, colour palettes suited to as many variants of vision as possible, collaborative transcripting and captioning of images, no flashing ads or autoplaying video.

You own your space and control entry. This means you should be able to moderate things. Being able to ignore people is good but is not enough: you likely don’t want to subject your friends to the conversation of a person who you dislike enough to ignore.

Rigorous site-level attention to spam and harassment. No one (much) wants spam, enough said. But harassment—continued interactions or attempts to interact after being told to stop, including ban evasion—should be a terms of service level violation, as should any threats (whether or not the person has been told to stop). Use of threats or hate speech in user names and default icons or other things that appear in directory listings or search results may also need to be considered. This all requires staffing and a complaints system.

Consistent access control. If you set something private, or it was private by default at the time, it should stay that way, probably to the extent where if it can’t remain private for technical reasons, it should be deleted/hidden by the site rather than made public.

Access to your work and ability to export it. The correct thing to do here is a little tricky (are other people’s comments in your space yours to export and republish, or not? what about co-owned spaces?) The autonomo.us community has had some inconclusive discussions.

Fine-grained access control. I don’t think something along the lines of that which Livejournal and its forks have had for years and which Facebook and Google+ have implemented to varying degrees, is required (public blogs have a strong presence in activist discussions) but it’s useful for more universal participation. Some people need it.

Clear limits on sharing. This is something that Google+ early testers are coming up against again and again: ‘Limited’ posts are or were shareable, a commenter using someone’s name with the + sign (eg ‘+Mary’) does or did actually invite them into private comment threads without the original poster’s input. If you offer access control, the software must make it clear what controls apply to any space, and if you have influence over that or not, so that you can control your own revelations in that space. Substantial user testing to make sure that people understand what your interface is trying to say is required.

No advertising. I guess it might be possible to show people ads in a way that has neither the problem of offensive or upsetting ads (“lose weight for your wedding today!”) nor the problem of the advertisers doing dodgy malware ads to harvest your info or worse. Maybe.

What else? How do your favourite sites do on these?