Background info

Recently, Sandboxie has reverted to free mode on multiple occasions after deciding that I should reactivate. This happened on:
- a laptop with no hardware or software changes;
- a desktop, after connecting SATA backup drives that newer versions of Sandboxie hadn't seen.

The requirement to immediately reactivate was in all cases unexpected, and in two cases where internet access was unavailable, extremely disruptive. Sandboxie is an indispensable tool I have come to count on, and over time, I've developed a workflow that depends on multiple active sandboxes. Unfortunately, these become disabled in free mode.

Because not everyone is tethered to the internet 24/7, the sudden requirement to find and/or pay for an internet connection can be infuriating, especially when working on a deadline or running a presentation. And sometimes, it's asking the impossible - think of a traveller on an overseas flight.

Request

I sincerely appreciate tzuk's efforts to make activation as painless as possible, and he's done a great job. I particularly appreciate that, regardless of activation state, Sandboxie never puts your computer at risk.

As a minor adjustment, however, I propose that when a properly activated Sandboxie requires reactivation before the end of a normal 90-day interval, it allow at least a 3-day grace period before reverting to free mode. The purpose is to allow legitimate users to work without fear of disruption.

Changing to a 3-day grace period, I feel that is like giving up on the whole concept of system code, and is a last resort. So no. Having said that, your description does suggest that activation should be a bit more stable.

Please save a copy of this registry sub-tree

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum

When activation next expires, save another copy of the same sub-tree, and let me see both copies (post here, send email, whatever). I'll evaluate the differences and see what can be done about it.

Later Edit: I said "save" the registry, but I actually mean export as a text file.

Hi,

I disagree with the statement that Sandboxie doesnt put your computer at risk, because I use and rely on forced programs and multiple sandboxes, 2 features which become unavailable on deactivation.

As proposed can I recommend some sort of configuration memory where if Sandboxie has been activated with a particular hardware configuration, changes to a different configuration will require reactivation, but changes back to the previous configuration would not.

Another solution would be to extend the grace period only per special request, ie, customers who write in with a genuine petition. This will allow you to track who is using this feature to minimise abuse

Perhaps you have a point blaq. I don't really want to exclude display devices from the system code so keeping track of old system codes might be a good idea after all. But I still want to exclude hot-pluggable devices like Mike's backup drives -- if they are indeed external devices which were plugged in. That kind of a device should not be part of the system code in the first place.

Tzuk, you sound confident so I'm sure the syscode will be perfected in no time.

But now that I think about it, what about cases where a user legitimately has to replace a part? A while ago, I was on an overseas business trip when my WiFi card inexplicably stopped working. Replacing it ballooned into a day-long ordeal. Would it really be necessary in an already hectic situation to insist that Sandboxie be reactivated immediately? It can't wait? SandboxIE is no longer just about IE, and people depend on it.

I hope you can see how this could throw a wrench in someone's day. This is a bad analogy, but Sandboxie is kind of like your car: even if there are alternative ways to get where you need to go (or to get things done on your computer), if you're counting on your car (Sandboxie) and it suddenly refuses to start, it'll leave you scrambling.

I guess I don't really see how a short grace period would undermine your goal of combating piracy, which I fully support. And I don't really see what you gain by so aggressively and abruptly choking off the user, save for a more satisfying "f- you" to the pirates. Can you let us know your thinking?

The next time activation expires and I'm on a plane, I will be cursing your name. Ok ok, I will.


They're internal drives. They're usually disconnected, but will become hot-pluggable when I get a SATA backplane.

Can you tell us what types of hardware changes trigger reactivation, or is it secret? Is there any tolerance for one component to change, but not two? I would think that, as long as the system drive remains the same, connecting other drives would be irrelevant to Sandboxie.


Sandboxie still catches forced programs, but they aren't allowed to run anymore.

Mike, the problem with an extended grace period is this.

If the starting time of the grace period is not recorded anywhere then you get 3-day countdown every time you restart your computer. This is like the 1-hour countdown that you get today. Only 3-days is ridiculous because it's easy to find some time to restart your computer once in three days.

On the other hand if the start time is recorded somewhere then as a pirate you just alter this date occasionally.



I see. Well if they're internal then I think they should factor into the activation.



There is zero tolerance, but only some types of hardware get into the system code, with the intention that it's only going to be stuff "in" your computer as opposed to stuff that you connect externally. But even if there was some tolerance, you could argue that two components had to be replaced on the day that you did not have access to the Internet to reactivate. In other words it's always going to be possible to find some edge case. And I don't want this topic to deteriorate into the "activation is bad" kind of topic.

The problem is not so much storing the date of the grace period as there are techniques to prevent pirates from accessing that information. The problem is more finding some way for the computer to measure elapsed time.

Also, protecting the activation mechanism by being vague IMO is not the way to go. The most robust systems are those that are open and have been pounded on, rather than relying on security by obscurity.

Think of this thread as not so much 'activation is bad' rather 'how to improve activation'

The system code has to be digitally signed by Sandboxie.com before the Sandboxie software will accept it. So there is no reliance on obscurity, and I could explain just how I compute the system code, but why bother?

I don't know the sentiment of the average Sandboxie user, but it seems to me that the general userbase consists of technically minded people who work in the IT field and have a relatively good grasp of general software principles.

I know for me personally, it would put me at ease knowing the exact proceedure, rather than having to rely on a blanket statement like "sandboxie.com collects no personally identifiable information during the activation process" etc which just about every program that does activation does.

How technically minded you are was not my point. My point was that you're not going to be able to do anything with the information anyway. Suggesting this has anything to do with personal information -- when you already know the system code is an opaque 16-digit number -- I feel is an attempt to pressure me into getting what you want. And I don't like it.

Tzuk, I see now why this request could be problematic. Thanks for your patient explanation.


Ok. It seems that once Sandboxie has seen a drive, it can be freely connected or disconnected - so all is good.


Agreed. Although, as long as we understand that activation is here to stay, I hope it's ok to discuss "how to improve activation," as blaq says. Even if nothing changes, understanding why Sandboxie must be a certain way can be helpful.

(Sorry for the late reply, as I was again without internet.)

As Mike said, I've come to accept the fact that activation is here to stay - given the fact that I've currently got Sandboxie installed in a range of applications, and have recommended it to a range of people, I was asking about the activation process to put my mind at ease and to be able to advise others as well.

For example, the obvious question would be if the 16-digit number is the only information about the system that's transmitted, or if there's other information that gets added on.

For me most importantly, I would like to know what sort of hardware gets used to make up the 16digit code. For example, one of the individuals I support runs a video editing business where they are constantly swapping out 1TB HDDs for different projects. I hadn't thought about it till this thread - but if for example the 16digit code takes into consideration the serial numbers of each HDD there might be a problem with activation.

Which is why I was saying that perhaps a concrete listing of what goes into the mix - to stop us from guessing.

Also, is it possible to obtain pre 3.46 style keys for users who intend to purchase Sandboxie but are using 3.46 or lower?

blaq, according the google the hard disk serial number is something like 20 characters, so that doesn't fit into 16-digits anyway...

You've been switching video cards and that triggers reactivation. Why should switching harddisks be any difference?

Anyway. I've implemented the suggestion you made, Sandboxie will be keeping up to 10 different system codes, I hope this will help.

Hmm, maybe that's why reactivation was triggered on my laptop, which had both integrated and discrete graphics. But then again, I never actually switched the GPU.


I replied in this thread: data/information privacy statement