If you owned a retail store, would you let a customer start cursing and yelling at your customers that the products you sell would give them incurable diseases or would you kick that customer out?
Steam’s curator program was implemented a little over a year ago. This program allowed individuals and groups of users to put together a selection of recommendations with a brief text component that appears on everyone’s Steam store page when enough people are following that curator.
Some curators are what you would expect. Publications like Cheap Ass Gamer, PC Gamer, Giant Bomb, Gaming On Linux, and Rock, Paper, Shotgun, have groups and recommendations. It’s nice to see that a publication you like is recommending a game, and it says a lot when none of them are. Then there are community action groups dedicated to specific causes, like one that is a group of made up of non-developers highlighting games that lack features that they feel should be available on every computer game regardless of what era it was developed in or if the lack of such a feature would even be an issue for this type of game.
Finally, there are curators on Steam that are beyond hyperbole. For example, Waifu Hunter. Normally this name would just imply that the group is operated by anime fans who will never know how to speak with actual women. Their disgusting motto is “I will tell you if a videogame has attractive anime ladies in it.” Here’s a sample recommendation from Waifu Hunter:
This game is a matryoshka doll of cancer, furries, and Tumblr. Play this if you hate good writing, loathe functional game design, and want to get AIDS.
Valve allows this to exist in their store, why? This negative recommendation is for a point-and-click adventure that has very positive overall user reviews. 103 positive and 10 negative reviews are shown directly on the store page for the game. Destructoid gave the game an 8 out of 10. This system is intended for positive recommendations, not rants from 8chan users. It is time to kick this customer out of the store.
The short version is: if you are any kind of open-source leader or senior figure who is male, do not be alone with any female, ever, at a technical conference. Try to avoid even being alone, ever, because there is a chance that a “women in tech” advocacy group is going to try to collect your scalp.
ESR’s blog post goes on to back up this conclusion with IRC logs from one anonymized source that nasty women are all around trying to destroy him and other self-aggrandizing free software/open source shitlords through false claims of sexual assault. The comment thread on the post is an amazing cavalcade of other mens rights assholes who followed through links from terrible websites such as Phoronix and Breitbart. Surprisingly, the comment thread is a little bit better on the Phoronix post where people call out Michael Larabel on linking to ESR’s garbage as if it were fact.
ESR calls this an attempt by women to “… smear and de-legitimize the Linux community (and, by extension, the entire open-source community) in order to render it politically pliable.” ESR is the one who has smeared the Linux community. He has threatened harm to other developers, by all accounts is a terrible developer, and a racist who takes credit for coining the term open source when it was actually invented by Christine Peterson.
To that end, today we’re launching a portal for podcasters to start uploading their shows to Google Play Music before we open up the service to listeners.
Translated from Google-speak: The Google Play Music app for Android (and iOS) is going to download podcasts to Google servers and rehost them on their own servers. Podcast publishers will only have access to listener metrics for Google Play Music listeners through Google’s interface. Google will also insert extra ads around the podcasts that aren’t from, and won’t benefit, the podcast publisher:
Google reserves the right to show display (image) ads alongside podcast content. Google will not insert any pre-roll ads before podcast content starts or mid-roll ads during a given podcast episode. Google reserves the right to serve post-roll video or audio ads after podcast content. Google Play Music does not provide direct payment or revenue share for podcast content.
Today, podcast publishers put up an RSS feed that anyone can use. It’s an open standard that any client can download one of these RSS feeds, get a list of episodes, and download them. Publishers interpret the one metric that matters, downloads, and use that in addition to occasional surveys of their listening audience to sell ads to advertisers if they choose to run advertising. If Google Play Music becomes the way that most people listen to podcasts it will destroy the open standard and increase the number of advertisements that people are forced to listen to. This is not good.
Downwell came out recently, it’s a great arcadey-good time on Windows and iOS. Here’s a little bit of it on Windows.
DICE released their Battlefield 4 community map today alongside another large patch to the game. Here’s an hour of it on video. While it is good that they are still releasing free content for almost two years after BF4 was first released, it still feels strange to have a “community map” when they could have released real community map making tools and encouraged hundreds of map creations. It’s not easy to put together a package of tools to make maps for a game, but it is worth it when you’re trying to keep people interested in a series for years between official sequels.
If you browse to your .agilekeychain “file” on disk, you find that it is actually a directory. Inside this directory is a file named “1Password.html”. If you access this file over HTTP (note that using the file protocol won’t work), you will be greeted with a grey page which has a lock image and a password field. Enter your password and your keychain will unlock and you have a read only view of your data.
So what’s the problem? Well, it turns out that your metadata isn’t encrypted. I discovered this after having a sync issue with Dropbox (I use Dropbox to host my keychain). The file that had issues was 1Password.agilekeychain/data/default/contents.js. Being a curious kind of guy I opened the file to see what was in there. The answer is the name and address of every item that I have in 1Password. Every single one. In plain text.
This contents.js file does exist. It describes in plain text every URL that you have a login for in 1Password, Myers also goes on to explain the security issue in greater detail and a post in response by Agilebits (the developer of 1Password) gives their roadmap for phasing out the AgileKeychain format that is still the default in 1Password today in favor of the OPVault format that they’ve been working on for years. Technical descriptions of both formats for storing passwords and metadata aside, the important part is that AgileKeychain has this issue and OPVault doesn’t and Agilebits is working on fixing it and moving everyone to the more secure format. Neither format leaks your passwords and the headline and content of Myers’ post is misleading.
Myers’ description of the security hole gets even worse:
But it gets worse. I decided to have a look and see just how bad things were. Thanks to people having links for easy access to their keychain on their websites, Google has indexed some of these. A simple search brings up results. By looking at one of these it was a simple matter to identify the owner of the keychain and where he lived. I know what his job is. I even know the names of his wife and children. If I was malicious, it would be easy to convince someone that I had compromised their account and had access to all of their credentials. Not to mention the fact that they have revealed their location online which may put their personal safety at risk.
And in describing the newer OPVault format:
…Since the data is stored as JSON, I can’t figure out why, but perhaps AgileBits decided having your keychain accessible on the internet isn’t the best idea?
The conclusion a reader of Myers’ post might reasonably come to if they read nothing else is that 1Password has a security hole where every site you’ve ever logged into has been leaked publicly.
AgileBits was going easy on Myers in their response. The truth is that none of this public sharing happens by default.
Even if you store your 1Password keychain in the current default format of the AgileKeychain and decide to use Dropbox for syncing, it is not automatically pushed out to the public. A 1Password user would have to ignore AgileBits’ instructions for accessing 1PasswordAnywhere via Dropbox’s website and intentionally choose the option to share the files publicly via Dropbox or another method.
If you use 1Password, and have decided to sync it using Dropbox, you can check if you have shared your keychain directory publicly by going to the sharing section of Dropbox’s website and checking the list of directories and files you share on Dropbox. I would be extremely surprised if many people using 1Password have done shared their 1PasswordAnywhere files publicly.
Myers’ article is barely accurate in describing the extent of the contents.js security hole. If your computer’s hard disk isn’t encrypted anyone who has access to your computer, or anyone who can circumvent the encryption on it, could easily access the contents.js file and know what sites you have logins for. If anyone was boneheaded enough to share the file publicly, they may have unknowingly also shared the list of sites that they’ve stored passwords for.
By default, the web browsers Firefox, Safari, and Chrome also leak all of our web browsing history in a sqlite formatted file that is trivially viewable by anyone who has access to an unencrypted computer with a sqlite database browser. Just like 1Password these browsers don’t by default store this information publicly and you would have to go out of your way to make the data more insecure by sharing it publicly on the web.
The majority of Myers’ article is misleading in giving the reader the impression that contents.js is shared publicly by default. It is good that in response AgileBits appears to be accelerating their timeline for moving everyone to the OPVault format for storing passwords and metadata, and it should not have required Myers’ public shaming to do that, but it is ridiculous to scare people off of this password manager when their passwords security was never in doubt as even Myers’ concludes at the end of his article.
The first non-prototype Steam Controller has reached the press and users who pre-ordered it early. PC Gamer has their first impressions. Here’s PC Gamer’s Wes Fenlon describing the touchpads that replace a more traditional set of analog sticks:
I know that learning to use the Steam Controller is going to take time. I’ve been using controllers shaped and designed like the Xbox 360 pad for more than a decade, and that analog form factor and face button layout really dates back further than that. The trackpads are a very different thing. But my early reaction to playing games with the controller is resigned disappointment: the feeling that Valve may have taken on an impossible task. Years of engineering effort went into making something better than a gamepad, something that could fill in for a mouse… and this was what they came up with? There really wasn’t a better way?
Perhaps there wasn’t, but I’m not sure this is the solution I want. In Left 4 Dead 2, aiming with the right trackpad felt labored and inaccurate, like using mouse aim at an extremely low sensitivity. I know that could be improved by adjusting sensitivity and familiarizing myself with the control method more. I can absolutely get better at it, but I don’t think I’ll ever like it as a form of input.
It sounds like the trackpads are just as unusable for most games as on the prototype. I’d really like to try them in something mouse-focused like Cities: Skylines. Meanwhile, Linux users on Ubuntu are stuck having to manually edit text files to get their systems to identify the controller for now.
Archive.org has a special on archived muzak in aisle 89:
In the late 1980’s and early 1990’s, I worked for Kmart behind the service desk and the store played specific pre-recorded cassettes issued by corporate. This was background music, or perhaps you could call it elevator music. Anyways, I saved these tapes from the trash during this period and this video shows you my extensive, odd collection. Until around 1992, the cassettes were rotated monthly. Then, they were replaced weekly. Finally sometime around 1993, satellite programming was intoduced which eliminated the need for these tapes altogether.
The older tapes contain canned elevator music with instrumental renditions of songs. Then, the songs became completely mainstream around 1991. All of them have advertisements every few songs.
The monthly tapes are very, very, worn and rippled. That’s becuase they ran for 14 hours a day, 7 days a week on auto-reverse. If you do the math assuming that each tape is 30 minutes per side, that’s over 800 passes over a tape head each month.
John Carmack is one of those rare people who pretty much everything they write is worth reading. He’s not always right, but it is always entertaining to watch his level of genius on display. In this case, Carmack is writing about overcoming the problems he ran into while developing a custom virtual reality environment where you can watch Netflix films and shows on the Samsung Gear VR device. You should read it.