Sandboxing? No, thanks!

Mac app sandboxing was to become mandatory back in November last year. According to Apple this is a piece of technology destined to protect app users: "Sandboxing your app is a great way to protect systems and users by limiting the resources apps can access and making it more difficult for malicious software to compromise users' systems.".


From my point of view, sandboxing in the Mac is wrong. Sandboxing is going to affect both application developers and users if Apple ever makes it mandatory for Mac App Store applications. It is already making developers simplify their software, making it less attractive and useful to users, frustrating both.

Mac App Store rules have already prevented many good apps, particularly utilities, from being sold through it. This is likely the case of apps like Hazel, Carbon Copy Cloner, AppZapper or iStat menus, and certainly the case for our own Xslimmer and Clusters, among many others. To cope with the rules, some developers have created partially crippled versions of their apps in order to comply with these rules. Some have even adapted their product to those rules, even if it meant reducing its functionality.

Sandboxing restricts apps even more. Applications cannot directly access files, networks or devices outside their own sandbox. While this might help in preventing malicious software from accessing the user's data, it also forbids many good apps from doing what they are designed to, and prevents them from interacting with each other like they currently do. For example, in Snapshot, our photo printing app, we use Karelia's iMedia framework. This library allows Snapshot users to access pictures from apps like iPhoto, Aperture or Lightroom. To do so, iMedia reads the preference files of these apps and determines the location of their photo libraries. Reading other apps preferences or accessing their content is no longer possible using a sandboxed app. Should we have the user search for the pictures through the file system instead of offering them directly like we do now?

Apple is trying to make the Mac sandboxing work. They are implementing new entitlements, APIs and even exceptions to make it a little bit more convenient for developers to adopt the technology. However, except for keeping access to the MAS, developers do not gain anything by doing so. What's more, adapting existing apps to the sandbox is far from easy, and, in many cases, it is impossible to offer their complete current functionality. In addition, it makes the application submission process more complicated, as entitlements and exceptions have to be justified. Apple explains: "If your app requires access to sandboxed system resources you will need to include justification for using those entitlements as part of the submission to the Mac App Store. Apps that are being re-engineered to be sandbox compatible may request additional temporary entitlements. These entitlements are granted on a short-term basis and will be phased out over time."

With the announcement of Mountain Lion, we have been surprised with a new technology called Gatekeeper. This is a different, newer technology to prevent downloading and installing malicious software. It allows the user to select the level of safety they want: run all apps, run MAS apps or run MAS apps and those signed with a developer ID issued by Apple. Users can even temporarily override secure settings by Control-clicking, and use any app at any time. So, the user is in control and developers do not have to make any major changes to their apps.

So far, Apple has had to delay the MAS mandatory sandboxing deadline twice, and the last time, it has even relaxed some of the rules. I hope that when June comes Apple kills the sandbox completely, and when it does, it does so in favor of Mountain Lion's Gatekeeper. For well-behaved developers, it would mean to keep working as before. For users, it would mean to keep enjoying fully functioning, well integrated apps, and yes, this time, in a more secure fashion.

--
Other articles on the same topic:

The App Culture

OS X Lion Sandboxing Is A Killjoy Destined To Ruin Our Mac Experience

Mac App Store Sandboxing Requirement Pushed to March as Uncertainty Looms

Real Security in Mac OS X Requires Apple-Signed Certificates

Sandboxing and Clipstart

Between a rock and a hard place – our decision to abandon the Mac App Store

Why the Mac App Sandbox makes me sad

Sandboxing

Think sandboxing will stop malware? Here's why you're wrong, Apple

Mac OS X 10.7 Lion: the Ars Technica review

Developers React to OS X Mountain Lion

There is Xslimmer in the Air (in the Macbook Air)

Since the Macbook Air was first presented at Macworld '08, we have had several people telling us that we should write about it. In particular, how Xslimmer is an ideal tool for it due to the small hard drive sizes. Faced with this kind of proposal, the question becomes what to exactly point out that it is not totally obvious. Xslimmer is a product to recover disk space from applications. The Macbook Air has a small hard drive. What else? As I do not know, I leave it there and point to you to some other people's articles:

* http://www.isights.org/2008/02/free-disk-space.html

* http://www.macrumors.com/2008/01/31/unboxing-video-of-macbook-air-more-notes/

Enjoy!

Lossless same-drive Mac HD Repartition, part 2

A while ago I explained how I did repartition my iMac hard drive. Then came WWDC, and with it I got the Leopard beta. Being in SF, without access to my iMac, I decided that I had to repartition my MacBook hard disk, so I could install Leopard and follow the sessions correctly.

Using my own post, I followed the different instructions. At repartition time, everytime I executed "diskutil resizeVolume ..." I got an error message about not having enough space. My MacBook's HD had been almost full, but I had freed 26Gb in order to make a new 20Gb partition. Clearly, it was not the disk space. It was also clear that my disk was probably highly fragmented and that diskutil was unable to allocate 20 contiguous gigabytes for my new partition.

I found an app called iDefrag. After some tests, I told it to defrag my drive with the default options. I took like 45 minutes to complete the whole process. I then retried the "diskutil resizeVolume ...". This time it worked perfectly.

LateNiteSoft at WWDC '07

I have started WWDC preparation. I have downloaded some of the headstarts, based on the sessions that interest me. Now, I have to install the latest Leopard preview in my laptop. For that, I need to go back to the repartition the hard drive once again. Lucky I did documented the first time!

I believe there are some very interesting technologies in Leopard. Core Animation being one of them. As I have been always interested in Special FX, game development and movie creation, it seems like a natural choice. So, once I get Leopard installed, along with the latest Xcode 3, I will take the material for Core Animation and try to grasp the basics before getting to San Francisco. I do have some ideas of things that would be nice to implement in Xslimmer, and even some ideas about possible new apps that we could create using Core Animation and other Leopard technologies. If I just had a more time...

Anyhow, I hope next week will be a fun one. I am really looking forward to meeting other Mac developers, whatever exciting news Steve Jobs provides us with, and all the possible learnings I can get.

If you are around, and would like to meet, let us know!

Want to try Xslimmer 1.2.3 Beta ?

Xslimmer 1.2.3 is finished. Quite a few things have changed from the previous version:

• Column headers, sorting. The application list now features column headers, allowing you to sort the applications by the criteria of your preference
  
• Additional application information through drawer. Using the "Info" icon of the toolbar you can get a side drawer that adds information on the application, and offers a couple of actions: exclude and slim.
  
• Single application slim. You can use the drawer or the secondary click on an app to slim that app alone.
  
• App exclusion is now accessible through toolbar, secondary click menu and drawer
• Progress bars and several icons design has been updated
• 3 new localizations have been added: Japanese, Dutch, Swedish (not complete yet)
  
• Delete, Backspace keys now eliminate applications from the list
• History is now resorted after slim has finished, maintaining the selected criteria
• History and backup purging are no longer active by default

So, we want volunteers to test it for a few days before launching it. Please remember, it is beta software. Should you detect any issues, please contact us!

Xslimmer 1.2.3b2 can be downloaded here.

Xslimmer 1.2.2 crack released! So what?

I've just found out that Xslimmer 1.2.2 has been cracked. It's not too bad, this release has been out for a few weeks already, while previous versions had the dubious honor of having been pirated in only a couple of days. Is this because we have strengthened our protection system? No, it is not. We haven't changed a bit (or a comma) of our code in that respect. Are we planning to do so? No, we are not. We have too little time and too many things to do. We prefer to spend our precious sleepless hours working on new features and customer support rather than fighting some infantile dumbheads.

The situation is very simple. We have made a lot of effort, and people seem to like our software. If they keep buying copies, we can continue improving Xslimmer and working on the other ideas we have. Otherwise, we won't. Each individual sale is worth much more than the 12 bucks we charge for a license. Each sale is a recognition that we have made something useful and valuable, a boost of morale, a reason to keep on working to the expense of our free time and our families. We strive to provide our customers the best service we possibly can. You see, it's not only the money, it's not even the prospect to become full-time indie developers one day: it's our pride and reputation that are at stake.

I believe that this is clear not only for ourselves, but for the vast majority of the "Mac community". As you may know, being recent switchers we are relatively new to the Mac family. One of the most notorious aspects of owning a Mac involves the feeling that you are part of a group of nice, discerning people. You don't buy a Mac for nothing: you buy it because you are looking for something special. Mac owners are warm to newcomers, passionate about quality and highly discerning about the difference between a carefully crafted application and a quick, careless hack. The first Xslimmer crack came out in less than 24 hours after release of version 1.0. And some of our well-known competitors are freeware applications. And still, some people buy copies of Xslimmer. It doesn't mean that our competitors are crap, it means that people will recognize the different approach in each application, and will buy Xslimmer if they believe it suits their needs best. And, of course, most don't consider downloading a crack, because they recognize the work that has to be done to put an application together. I had not seen this passion in the Windows or the Linux worlds, and I am proud to have become a member of this community.

Other authors have previously explained that most people that use pirated versions of your software will probably never buy it, even if the crack did not exist. Having lived among Mac users for a while, I'm a convert to this theory now. I'm even inclined to measure it. This post is, in fact, a little experiment to test to what extent piracy affects sales. If you are proud to be a Mac owner, feel free to spread the word: there is a cracked version of Xslimmer going around, but also a legitimate one whose purchase is the way to show your support for its development. Do you think our sales will decrease significantly? I'm willing to bet that they won't. But I'll measure the conversion ratio (sales to downloads) during the following days, and will post any meaningful results here, so we'll see.

A final reason not to use pirated copies of Xslimmer, if you need any, is that we are planning to release version 1.2.3 next week. Version 1.2.4 will come a couple of weeks after that. And so on, until we run out of ideas. Do you want to depend on some random drone to enjoy the upgrades? We'll see in a few days what the results of our little experiment are, but I doubt you will.

Lossless same-drive Mac HD Repartition

Recently I discovered a lossless way to repartition my Mac's main hard drive, without having to boot from an external drive. I have been looking for this for quite a while, as I wanted to install the Mac OS X Leopard preview in order to test the new development tools and maybe try a new feature or two for Xslimmer.



Some people had suggested to use the Bootcamp utility to resize and partition the drive. But I had already installed Windows (basically for gaming) and did not want to lose that partition.

So, I finally read an article on how to do this using the command line command diskutil, and its hidden feature named resizeVolume. If you check the man pages, you will see that there is no information on this matter, but you can obtain some executing "diskutil resizeVolume":

freeport:~ jorge$ diskutil resizeVolume
Disk Utility Tool
Usage: diskutil resizeVolume [Mount Point|Disk Identifier|Device Node] size
...
Non-destructively resize a disk. You may increase or decrease its size.
When decreasing size, you may optionally supply a list of new partitions to create.
Ownership of the affected disk is required.
Valid partition sizes are in the format of .
Valid sizes are B(ytes), K(ilobytes), M(egabytes), G(igabytes), T(erabytes)
Example: 10G (10 gigabytes), 4.23T (4.23 terabytes), 5M (5 megabytes)
resizeVolume is only supported on GPT media with a Journaled HFS+ filesystem.
A size of "limits" will print the range of valid values for the current filesystem.
Example: diskutil resizeVolume disk1s3 10G
JHFS+ HDX1 5G MS-DOS HDX2 5G
Valid filesystems: "Case-sensitive HFS+" "Journaled HFS+" "Case-sensitive Journaled HFS+" "HFS+" "HFS" "MS-DOS FAT32" "MS-DOS FAT16" "MS-DOS" "MS-DOS FAT12" "UFS" "Linux" "Swap"

So, as you can see, to resize a partition you first need to know its name. For that you can use "diskutil list":

freeport:~ jorge$ diskutil list
/dev/disk0
#: type name size identifier
0: GUID_partition_scheme *465.8 GB disk0
1: EFI 200.0 MB disk0s1
2: Apple_HFS Macintosh HD 434.0 GB disk0s2
3: Microsoft Basic Data WINDOWS HD 31.4 GB disk0s3

In my case, the partition was disk0s2. The partition scheme or the EFI partition should be ignored. As I said before, I already had a Mac OS partition and the Bootcamp partition. I wanted to create a new 20 Gb partition out of the main Mac OS partition, disk0s2.

Now, there are some limitations to the resizing. I guess it has to do with how much free space you have in the partition you want to divide. To verify the limitation, you use "diskutil resizeVolume partition_name limits":

freeport:~ jorge$ diskutil resizeVolume disk0s2 limits
For device disk0s2 Macintosh HD:
Current size: 466003951616 bytes
Minimum size: 213448208384 bytes
Maximum size: 466003951616 bytes

Finally, you have to provide the resizing parameters to the "diskutil resizeVolume" command. In my case, I wanted to keep 414Gb for the main partition and create a new Journaled HFS+ with 20Gb:

freeport:~ jorge$ diskutil resizeVolume disk0s2 414G JHFS+ Leopard 20G
Started resizing on disk disk0s2 Macintosh HD
Verifying
Resizing Volume
Adjusting Partitions

Finished resizing on disk disk0s2 Macintosh HD
You will need to manually reformat your new partitions.
WARNING: You must now reboot!

In my case the first step, "Verifying" was what took the longest time. After that it all went very fast.

Once done, you should reboot. After rebooting, you can use diskutil or Disk Utility to prepare that new partition for use.

freeport:~ jorge$ diskutil list
/dev/disk0
#: type name size identifier
0: GUID_partition_scheme *465.8 GB disk0
1: EFI 200.0 MB disk0s1
2: Apple_HFS Macintosh HD 414.0 GB disk0s2
3: Apple_HFS 19.9 GB disk0s3
4: Microsoft Basic Data WINDOWS HD 31.4 GB disk0s4

In my case, I used Disk Utility, selecting the new partition, the Erase tab, then proving a name for the partition, and clicking on the Erase button.

freeport:~ jorge$ diskutil list
/dev/disk0
#: type name size identifier
0: GUID_partition_scheme *465.8 GB disk0
1: EFI 200.0 MB disk0s1
2: Apple_HFS Macintosh HD 414.0 GB disk0s2
3: Apple_HFS Leopard HD 19.9 GB disk0s3
4: Microsoft Basic Data WINDOWS HD 31.4 GB disk0s4

(Update) One more thing needs to be done. This time is for Windows to keep running fine. You should edit boot.ini (I used textmate), so it knows the partition is it located in. Mine looked like this:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(3)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(3)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect

As you see, it says partition(3) for the Windows partition, which is now wrong. I changed it to partition(4) and it worked like a charm. Notice partition(3) appears twice, you should change both.

All set!

Now I have Leopard on my Mac along with Tiger and Windows, thanks to these simple operations. Needless to say, before you attempt to do anything like this, you should have a backup.

[Update: I wrote a second part of this article]

Disclaimer: Visitors do assume all the risk of viewing, reading, using, or relying upon this information. We assume no responsibility for damage to computers or software of the visitor or any person the visitor subsequently communicates this information to.

Have fun!

Back...after the break

As with every major release of an application, not only the days prior to the release are very intensive, but also the days after. With Xslimmer 1.2 it has not been different. Issues, doubts, questions, bugs, feedback. Lots of hours of dedication and little sleep.

The most important bug was what I initially called the "UK English Bug", which at the end also had an important impact on our German customers. After a few hours of being detected, we released 1.2.1 in order to fix it. Incredibly, none of our beta testers were German or UK English people. We apologize to those who suffered this issue.

A few days later, with 1.2.2 we fix some other minor fixes and tweaks were introduced. Then, we took a break. For a few days, we had enough with our day jobs and our families.

Right now we are back, and starting with 1.2.3 and our general Xslimmer roadmap. We shall keep you posted.

MacWorld Ends While We Release

After a week in which all attention was concentrated in San Francisco, things start to get back to normal. Hopefully, next year we will be able to participate. I am really looking forward to that, and, by that time, the iPhone should already be available.

Meanwhile, we did release Xslimmer 1.1.7. It would be great to hear opinions on the GUI changes. We were concerned that making the drop window disappear, making the main window the drop area, would not be something our user would like. We believe this change simplifies usage of the application, while it provides us with the flexibility to include new features in an easier way.

Xslimmer in 2007

First of all, we wanted to wish you a very happy new year. After a few days of rest, we now retake Xslimmer's roadmap.

We are now finishing v1.1.7, which will bring some changes to the GUI, along with some other features. These changes to the GUI are necessary in order to incorporate the anticipated language stripping feature which we are already working on. Also, it will allow us to add other features in a simple way, like using a dialog to add folders or apps, without having to drag them.

Appart from the new features, from my point of view the most important change in 1.1.7 is that we take out the little drop window. Of course, you will be able to drag apps to main app window, as you are today, and we have built

Next is localization. In 2 ways: first, adding language localizations to Xslimmer, and then the previously mentioned language stripping. In 1.1.8 we intend to include at least one localization, along with some requested features like history purging.

It is version 1.2 that will feature the new stripping function.

We have many other features in our roadmap, but we are not going reveal them all yet.

We are, of course, open to new features requests from our customers. Just click here to send as any ideas you would like to see implemented in Xslimmer.

Xslimmer in Pomcast.com

Two days ago we had an interview with Stuff MC, from Pomcast.com, for the Spanish version of the podcast. During the interview, we comment on the creation process of Xslimmer, future possibilities and we talk about the Apple world in general. If you are interesed, you can check it out here.



There will be an English version in the future. Until then, we wish you a very happy new year.

Season Greetings

The last 2 months have been very intensive. We launched the first public beta of Xslimmer on November 1st. Since then until now, we have had several different releases, 10 in beta, 6 non-beta. Beta releases were mostly oriented to issue resolution, while non-beta have been dedicated to adding new features to the product. Today, in addition to what was included in the very first version, Xslimmer includes:

* Dock-drop feature
* History log window
* Restore function
* Report function
* Growl support
* Direct Slim feature
* Revamped Preferences
* Improved Window animations and transitions
* Other UI improvements
* Many performance improvements
* Panther compatibility

We continue with our roadmap, which includes quite a good number of additional features, and some major new functionalities, like the ability to strip languages.

This is not all. During this period, we have executed 3 different marketing actions. We started with the GiftZOT bundle (at MacZOT), then a MacAppADay one-day feature and the AppZapper/Xslimmer Christmas bundle.

Hundreds of emails, many hours dedicated to the website, particularly its backend and much, much more. Seeing the results, it clearly has been worth it. Pedro and myself would like to thank you all for the support and feedback you have provided us.

We hope you enjoy a very happy Christmas and a great new year.

Making History

Making Xslimmer's history functionality took a little bit more than what was initially scheduled. The basic reason was that new ideas kept coming while we were designing its window. From these new ideas, we implemented the possibility to restore a backed up application and the possibility to report issues with applications slimmed.

Additionally, we took a while to design the window. In its initial conception, the history window had only text, and too much information. Little by little we transformed it into something like this:



While this image was pretty close to the final version of the window, there were still many little details to take care of. First, the color buttons. These did not look completely right to the eye. In addition, they did not behave too well while one of the apps was selected. Second, the sorting buttons in the segmented button were not showing correctly. Third, I had made it so that when an application was restoring, its restore button would show a spin progress indicator, so the window did not really need one. Finally, the window was in need of some gradient.

As a result, we kept working, and the window was almost ready a few days later:



Still solving the segmented buttons bug in Cocoa was going to take quite some code. Louie commented: "I know how to solve that bug: get rid of the buttons, and make the table headers the sort buttons". That is what finally went into 1.1.4:



So, tell us what you think!

Marketing

These last few days have been a bit different. Initially, we had plan to work on getting 1.1.3 out by today. In 1.1.3, we intend to include a "Slim History" window that will allow you to review all the applications you have slimmed, your overall savings over time and the possibility to recover an application from its backup, if you did had the backup option turned on during the slim process. In addition, from the Slim History window you will be able to report any problematic application in an easy way to us.

While I worked on the Slim History, Pedro was working on Panther compatibility. We believe that being Panther compatible, will Xslimmer useful for a much wider audience. It is tricky though. First, we are using Intel machines for our development, so we have had to buy a PPC machine in order to work on this. This machine will allow us to ensure that we get to that desired Mac OS X 10.3.9 compatibility, and will also permit to better test our releases in the PPC platform. Second, Panther does not have some of the fine 10.4 methods, so some parts of the code are being rewritten.

During the last week though, we have been busy in getting people to know that Xslimmer exists. We contacted Brian Ball some time ago to promote Xslimmer via MacZOT. When he got back to us, he suggested to include Xslimmer within the GiftZOT 1.0 bundle. After the mystery bundle was unveiled, our Web site traffic increased significantly. Clearly, it is a signal that tell us that Xslimmer is starting to get known. Right now, we are planning another couple of marketing actions, that will happen within the next 2 months.

Right now, I am going back to work on Xslimmer's 1.1.3 Slim History.

Xslimmer 1.1.2 has been released

After the release of the first non-beta of Xslimmer we have been quite busy. Lots of emails with questions, suggestions, and so on. Now we are back with our implementation roadmap, and today we have released version 1.1.2.

In this new version you will find the dock-drop feature: applications can now be dropped to Xslimmer's dock icon, making it even easier to slim them down. Apps can also be dropped on the application icon. This was requested by several people since the application was made known. In addition, we had still to optimize one heavy-duty loop. This optimization has also made it into this release, along with an optimization into checking applications dropped against the blacklist. Finally, we introduce some changes into de animation between windows that should make them smoother, particularly in PowerPC systems.

And now, to work on 1.1.3. Take care.

Xslimmer is Out!

That is right! We got there. After 20 days of public beta, we are ready to launch commercially. From this moment, you can buy a license of Xslimmer, and, for a limited time only, is just $6.95.

Thanks go to all people who have helped us during the testing period.

1.0.8.RC2 is out. 1.1 Coming soon!

We have a new version of Xslimmer out. Unless we get any last minute surprises, it will be the last beta version. Next Saturday night, the night of the 18th to the 19th of November, Xslimmer 1.1 will be launched.

This will be the first commercial version of Xslimmer. To support our launch we are planning different marketing actions. First of all, we will have, for a limited time, an special introductory offer. For this period of time, a full license of Xslimmer will cost only $6.95. In addition, we are also planning different limited time offers whose deals are being worked upon with different Mac sites. You probably know who they are. If you want to suggest to us any special action, you are more than welcome.

Getting there, at last!

Xslimmer 1.0.7.RC2

We have released a new version of Xslimmer, 1.0.7.RC2. With the previous release, 1.0.6.RC1 we believe to have achieved significant application stability. The new release will build upon that, featuring:

- Speed boost: 3x app analysis speed after drag.
- Reduced memory consumption: Previously, applications with a significant amount of files could take up several megabytes of memory. Due to this, dropping a significant amount of apps onto Xslimmer could end up filling up the system's memory, forcing the Mac to paginate, thus becoming very slow. In 1.0.7 each application will take only a few kilobytes. I tested it with 240+ apps, and memory consumption did not even increase by 1 megabyte.
- Centralized application blacklisting: New system to prevent slimming applications that fail to behave correctly after slimming due to integrity checks. This new system will differ from the current protected applications scheme. The protected application scheme will be for you to voluntarily protect whichever app or path you want to protect. The blacklist system will be able to gather the latest information from the Internet, and protect apps known to fail.
- Projected application size: You can see how much space you will save before actually slimming.
- Slight GUI modifications.

As these changes are pretty significant, version 1.0.7 is now our second release candidate, or RC2.

Stay tuned.

Xslimmer v1.0.4 - Beta License Key

In order to improve your testing experience, we have included a license key in the new beta release of Xslimmer. If you did download Xslimmer before version 1.0.4, you can visit our home page at http://www.xslimmer.com and download the key directly in there. The key is valid until November 15th.

Public Beta is Out!

Xslimmer public beta has started! Please download your copy and tell us what you think and if you encounter any issues. We are really willing to hear your opinion about the application we have been developing for the last few months.