Nuclear Monster

  • Elias Roman:

    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.

  • In a post titled “1Password Leaks Your Data”  software engineer, Dale Myers, argues that 1Password’s 1PasswordAnywhere feature is very insecure. Here’s how Myers describes the feature:

    For those of you who don’t know, 1PasswordAnywhere is a feature of 1Password which allows you to access your data without needing their client software. 1Password originally only used the “Agile Keychain” format to store their data (not including when they were OS X keychain only). This format basically stores your data as a series of JavaScript files which are decrypted your data when you supply your master password. Since the files are JavaScript and implementations of various crypto algorithms exist in JavaScript, there was no reason why AgileBits couldn’t come along and make a HTML and JavaScript client for viewing your data, so they did.

    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.