MarsEdit 3.3.1 is now available as a free update for registered MarsEdit 3 customers. New customers may purchase via the Mac App Store or directly from the Red Sweater Store.

This is mostly a bug-fixes-and-tweaks kind of release, of course the fixes might not feel so minor if they’ve been nagging at you!

• Media Manager now remembers and restores last-selected folder across launches
• Fix a bug that prevented custom text and background color preferences from working in rich text mode
• Add protections to avoid crashing on some malformed server responses
• Fix a bug where only the first paragraph was styled with e.g. multi-paragraph blockquote
• Fix a bug introduced in 3.3.1 that caused image uploads to Movable Type to produce invalid URLs
• Fix handling of Tumblr downtime to be more reliable and convey message to user
• Various bug-fixes to rich mode undo behavior

Enjoy!

MarsEdit 3.3 is now available as a free update for all registered MarsEdit 3 customers. New customers may purchase via the Mac App Store or directly from the Red Sweater Store.

This release features a brand-new option to switch post editor documents into “Full-Screen” mode for more focused writing. In full-screen mode, the window is expanded to take up the entire space of the screen, and the menu bar is hidden from view.

Other changes include an option to speak the text of the active document, using Mac OS X’s increasingly awesome built-in speech synthesis, a preference for controlling font size in the main window, and a number of other enhancements and bug fixes.

• New full-screen mode option for post editor windows
• Now supports speaking the text in post editor
• Supports Mac OS X text transformation in post editor
• Added server-side text filter selection for Squarespace
• Add Search/Replace functionality to preview template editor
• Preferences changes
  • Add preference to adjust font size of main window UI
  • Change name of “Attribution” section to “Quick Posts”
  • Support preview of Quick Post HTML defaults
• Bug Fixes
  • Restore functionality of printing from rich text mode
  • Fix rare crash when authenticating Blogger blogs
  • Fix MetaWeblog image uploads to avoid putting / character before file name
  • In rich mode, avoid styling the following paragraph when entire target paragraph is selected
  • In rich mode, improve undo to avoid undoing typing done immediately before a paste
  • Disable “smart” copy & paste in HTML code editor

Enjoy the release and have a great weekend!

Black Ink 1.4 is now available on the Mac App Store and direct from the Red Sweater Store.

Black Ink is great for solving puzzles on your Mac, but also a fine tool for printing supported puzzle formats in a professional-looking layout suitable for solving on paper. For Black Ink 1.4, I made major strives towards improving the printing features of the app. The major new printing feature is an option to “squeeze” everything for a puzzle onto a single sheet of paper. For larger puzzles this can create a grid and clue list font size that are quite small, but for many folks it’s a priority to get everything on one sheet for easy solving-on-the-go.

Also notable in this release is the return of user-customizable puzzle sources. I removed these in 1.3 because I thought it was more trouble than it’s worth for most users. But for those who do discover sources and are able to configure the settings in Black Ink, this is a much-missed feature.

Complete change list:

• Printing improvements
  • Support a new “fit on one sheet of paper” print option
  • Support live-updating of print preview as settings are changed
  • Fix issues with printing when clue list printing is disabled
  • Fix a bug where some clues would rarely not get printed
  • Work around a printing issue on a pre-release version of Mac OS X
• Other Fixes
  • Prevent possibility of crashes with some accidental keystrokes in puzzle view
  • Remove Houston Chronicle as it stopped publishing Mar 25, 2011
  • Prevent double-quoting titles of puzzles already in quotes
  • Further fixes for Mac OS X 10.4 functionality
  • Fix to show puzzle document names as “Black Ink Puzzle Document” in Finder
  • Restore ability to add custom puzzle sources to the default list

Today Twitter announced a few distinct policy changes for clients of their API, all wrapped up under the banner of improved security permissions for end-users. The best response I’ve seen yet is from John Gruber, who smells something funny in the deli. I tend to agree. The announcements today comprise some useful security enhancements, but the security gains from some of the decisions that were announced are not so great that they offset the serious disadvantage they impose on 3rd party developers, particular developers of native mobile and desktop apps.

Let me break the announcements today into three policy change assertions, and how I react to them.

1. Access to Twitter direct messages will require a new level of user-granted permission. This is a great thing! I recently tweeted that exactly something like this was necessary, because I’ve grown tired of giving every damn service that I wish to connect to Twitter, access to all my confidential direct messages. The new permission allows developers of client apps to state their desired permissions, and those permissions will be listed prominently on your list of approved applications.

   Verdict: Kudos, Twitter.

2. Developers of Twitter clients will be required to use OAuth in order to gain this new permission. In laymen terms, this means client apps can’t log you in with just your username and password. You will need to be redirected to the web. This requirement is ostensibly because Twitter wants to increase the likelihood that end-users will be made aware of exactly which permissions a client application is requesting. Without this requirement, a native application could claim to seek read-only access, but behind the scenes be using your username and password, by way of Twitter’s xAuth solution, to request a higher level of permission than you intended to allow.

   I concede that this requirement is, on the face of it, an added protection for customers who are wary of providing Twitter credentials to an untrusted app. But here’s the catch with native software: you better trust it, because there is no shortage of ways in which it could screw you. It’s running with some degree of elevated permission on your own device. Twitter putting shackles on native app developers in the name of security is laughable. For example, it would be easy for an untrustworthy native app to provide a custom, compromised browser view that purports to drive a user through the Twitter OAuth permission flow with a given permission, but is actually requesting a different level of permission in a second, undisplayed web flow.

   This is not to say that we shouldn’t bother reining in native software that may be flawed or whose permission we may want to revoke. This is what is so clever about the xAuth workflow, the compromise that allows native apps to authenticate as if by way of an OAuth flow, but using a user’s username and password to facilitate the process. If an end-user or Twitter itself loses confidence in an xAuth based application, they can still revoke access to the application in the same way they would for any other OAuth managed client.

   Verdict: Nice try, but if you don’t trust your native software, Twitter can’t do much to keep you from getting screwed.

3. These requirements apply unilaterally to all native clients. Except Twitter’s. I grant you, it makes sense for a company to exempt itself from security restrictions that are imposed to prevent “bad guys” from taking control of a user’s credentials and doing damage to the user or to Twitter itself. But this story is complicated by the fact that Twitter entered a competitive market of native clients of its own system, where for years it was not a player, and then proceeded to adopt increasingly developer-hostile attitudes. In particular towards developers of software that aims to fill that coveted role of a “general purpose read/write Twitter client.”

   Is it illegal to do what Twitter has done? Absolutely not, nor should it be. But in my opinion these 3rd party developers were a valuable asset that was pivotal in building passion for Twitter in the earliest years of its existence. Many of the features that we take for granted in Twitter itself were prototyped in 3rd party native applications. Hell, even Twitter’s own native Mac app was itself a 3rd party application (Tweetie) until not too long ago.

   Twitter’s attitude towards these developers seems to be: thanks for all the help, but we’re done with you. The fact that Twitter is willing to “whitelist” their own apps further suggests that this may not be a pure security play. Only legitimate developers of trustworthy apps would be interested in seeking an API key to connect to Twitter. If your aim is to write malevolent software that abuses Twitter or its users, you should be content to take an app like Twitter’s own Mac client, extract the portions that communicate “securely” with Twitter, and build your own app that only the savviest user will notice is actually posting to Twitter as “Twitter for Mac.”

   Twitter’s willingness to exempt any apps from the OAuth procedure is a concession that they don’t view xAuth authentication as inherently insecure. But they want to limit which API keys get the privilege of continuing to use it. So, expand that list of API keys. At the very least, add long-time supporters such as Iconfactory’s Twitterrific. Better? Provide some kind of approval process through which any qualified developer can seek first-class status. Best of all? Stick to what OAuth and xAuth are best for: providing the power to revoke access for bad actors after bad intentions are discovered. Forcing applications through OAuth is not going to prevent offensive, buggy, or intentionally malevolent code from being authorized by users, but it is going to degrade the user experience for all native clients except, oh, how about that? Twitter’s own.

   Verdict: Dick move, Twitter.