Compatybility Telemetry Yes, No, Meybe?

The hardened sandbox types still have often compatibility issues with various software, here it would be mighty helpful to collect data on which programs use what system calls in order to look into expanding the list of allowed syscalls in the hardened mode.
Given that there are close to 500 NT syscalls in total, its not feasible to just evaluate all of them, hence it is required to select only the once commonly used.
For example by collecting telemetry of the Type:

chrome.exe:NtCreateFile,NtOpenKey,NtCreateSection,NtSleepEx,NtCreateProcess,NtCreateThreadEx,...
notepad.exe:NtCreateFile,NtOpenKey,...

So really harmless in no way personal, just a means to have a sys call list for a myriad of processes without the need to run all of them on selves.
What can be inferred from this is of cause what programs are being used sandboxed in general, and roughly how often.

And if we would to add such a mechanism, it would be expedient to collect a couple more likewise harmless data, used version of sandboxie, list of active compatibility templates, list of processes which crashed while sandboxed.

What do you think?

Also I have created a poll about telemetry here: https://www.wilderssecurity.com/threads/telemetry-yes-no-maybe.448212/ I'm looking only for the insight if to do that at all, and if yes should it be opt in or opt out.

 

I think it's a good thing to implement (Opt-In Telemetry is ok (off by default) and I'll leave it off).
It would be even better to do it separately per sandbox, just like the Tracing tab on every sandbox. Not telemetry for all my sandboxes simultaneously.

 

I think it's a bad idea to implement telemetry into Sandboxie. Could the telemetry be released as a totally separate/standalone module/program? So that anyone who'd like to participate could run it, standalone, beside Sandboxie (and maybe get a discount or gain some other kind of bonus)? Something like BSA was used with Sandboxie. I think this would be the only way to do it, if telemetry is really needed, in my humble opinion.

 

May I ask why it's a bad idea?

 

I think it's a good idea to implement telemetry into Sandboxie.
default off & I'll opt in

 

You can delete the telemetry.dll like David suggested here

https://www.wilderssecurity.com/threads/telemetry-yes-no-maybe.448212/#post-3109913

 

I think the catch 22 with telemetry is the "I don't care" group of users, i.e. people that will neither opt in nor opt out, they just leave the defaults whatever they may be.
And the goal is of cause to have as many users have it enabled as possible without upsetting anyone. And the group of "I don't care" users should end up with telemetry enabled.
Hence the only workable options are opt-out, or a configuration dialog with the right choice pre-selected.

Now the enabled by default has the issue that between Installation and a user finding where to disable it it is set to not what the user would want.
I myself from the perspective of a user would feal cheated, and since we should adhere to the golden rule, this is not a viable option.

Therefor the only option left is to present a pre-checked checkbox on a popup dialog some ware to the user and unless he objects enable it.

We have 3 options where to ask
1. by the installer itself
2. by the first start wizard
3. by a dedicated pop up dialog, if neither 1 or 2 was already shown with the new option.

 

We should be able to preview the data before submitting. (Maybe page for it? 'Options > Telemetry Data')

I also support this suggestion.

 

I was thinking some time ago about adding a plugin/(3rd party component) system to sandman, the plan is to add components like
7zip.dll - for box import/export
imdisk.sys - for RAM resident sandboxes
and whatever else will come...

And one of this else's could be a telemetry module so something like SbieMetry.dll

If the user leaves the telemetry check box checked when he clicks next on whatever screen offers it the module would be downloaded on demand, and would not be present as such in the installers.

What do you think?

 

I don't support the idea of telemetry on any level. It seems to go against everything that Sandboxie is about. I also think that it could be a 'thin edge of a wedge' and if you decided to pass Sandboxie project on, became unable to develop it, or in the worst case scenario passed away, then others that took over the development, could expand on 'the door that is already open', with a negative impact, on privacy and security.
My main feeling is that it goes against the Sandboxie 'ethic'. If you absolutely insist on imposing telemetry on Sandboxie users, then default as 'off' is the only ethical option as the program is becoming more and more complicated and users new to Sandboxie, would just simply, blindly use the default settings, if the telemetry was default 'on'

Sandboxie was once a user friendly simple to understand tool, needing little user input, with good defaults, but I believe that it is becoming over complicated and is now usable (in it's full extent) to an exclusive, 'tech savvy', insider group.
That is not to say that I don't give David full credit for his energy and focus on developing Sandboxie but I believe that the development is inadvertantly spinning out of control.

 

To be honest I myself am one of the people who disables all Telemetry and cranks up the firewall up to 11 first thing I do, heck I even wrote a tool for this LOL (see my signature).
But when working on sandboxie I ran many times into code where I wondered either if it will ever be used or which software may make sbie use this code path to be able to test it, and was thinking "... some telemetry here would surely come in handy right now..."
It simply is not feasible to test each and every software out there oneself, so crowd sourcing the required data seams like the only practical approach.

The question is how to do that...

"is" yea we are getting there...
"was" certainly not, as it was sandboxie did not protect user data from ex-filtration only from alteration, in old sandboxie any sandboxed virus with internet access could read the memory of any of your unsandboxed programs (like password managers crypto wallets and alike) and send that data of to its masters.

About "is" yea that's kind of what I'm working towards with the security improvements, privacy enhanced box types, and alike...

I see why this may look this way, more and more options in the GUI that look scary and have descriptions which only an expert could understand, but the thing is that a certain portion of those was already in sandboxie just did not have a UI, like the /ignoreUIPI switch for OpenWndClass, or AnonymousLogon=n, or etc...

Many others were added as more and more security holes were locked down to allow users to keep software compatible if they would to run into an incompatibility caused by the new restrictions. And since we don't know how many of these options are really used they just stay in the GUI just in case. Hence some telemetry about used configurations could help a lot in finding out which options would be removed from the UI or should be at least hidden from a non expert view.

Last but not least we have the issues with Privacy Enhanced and Security Hardened box types, a lot of software can run in those only once the user took some time to hunt down the required resources to grant access to using the trace log feature. This is not very user friendly and being able to synthesize some reasonable default presets which provide a acceptable compatibility with commonly used software would be a great improvement in user experience.


So as you see some sort of insight into the software usage would help a long way in creating a UI which would not be overwhelming.
My current approach and to be frank the approach I always run is (once (not for sandboxie) I had to split a class containing settings into 2 because I reached the limit of how many members MSVC could put into one object LOL), I don't know what the users need, just give them every possible option I can come up with and let them set the right presets for their individual use cases. Obviously this is not compatible with most users, once a certain level of flexibility is reached.

 

Maybe concentrate on the biggest programs (browsers , email client, Office or so + X..). Otherwise it could end as a full time job fixing compatibility issues for strange niche programs.
You also need a break

 

IMO telemetry is not evil in itself, telemetry is just a tool. From what I see on different forums, and from my own experience as a programmer, usually the developers ask the user for some sort of telemetry data (extended logs, for instance) only when the user encounters a problem. So the application should have some form of telemetry/logging information useful for developers, but that information should be sent only if the user(s) encounter a problem and they want it to be solved.

 

Again @DavidXanatos , I support telemetry in this case because I trust you. Period.
But please, allow the user to select which and when a sandbox can send telemetry to you...

For me it's better to include the telemetry binaries within the installer to prevent any unexpected issue.

 

For someone who is just boxing one browser, any telemetry should be opt-in. In my use-case, there is no need for it.

 

Happy to have telemetry on as long as I can approve what's being sent, otherwise it'll be disabled for me.

 

Well solving problems is a good thing, preventing them to appear in the first place is how ever even better. And that's the idea when i wonder if doing a particular change, for example blocking access to a particular resource that is better of not being accessible, I could either.
1. block it, leave a setting to unblock it, release it and see how many will complain that their software now is crashing.
2. add some telemetry code to tell me which software if any is accessing that resource, then in the next version I can block it in general while adding compatibility templates for the software that still needs it.

Option 1. is disruptive to the users, that is not a great experience. Option 2. requires Telemetry, some people (me included) don't like it, others don't care and just want their software to run smooth.

Its basically: guessing and observing the result vs. being able to make an decision based on hard data.

Example: some time ago diversenok found a nice exploit using symlink object creation, not the once in the FS but the once in the NT namespace, and well that exploit shouldn't be left open, and who would use symlink objects in windows normally anyways, so lets block it completely, problem solved. Well apparently there is software that uses this like MinGW and this was now broken, solution add full name virtualization and filtering. With the sys call telemetry this issue would have been noticed and no user would have to deal with broken software.

@Mr.X Sure i can add a box preset DisableTelemetry=y or alike to exclude selected boxes
EDIT: I could also add in future builds some inteligen presets like disable by default telemetry for boxes located on a ramdisk, as it stands to argue that those are probably particularly confidential.

@simbun how do you imagine this exactly?
1.) a general list of connected information's to check/uncheck what to send
2.) review every entire telemetry report, possibly a few pages long each time before it is sent?

 

I certainly wouldn't want or expect to be able to check/uncheck each item (maybe just send/do not send), but it would make me feel a lot more comfortable if I could scan through and check that it's just a bunch of resource entries as per your example.

Don't get me wrong, the fact I have your software installed shows that I trust you implicitly, but we're using it for security/privacy and so it should be expected that we might want to vet the information that we're voluntarily supplying.

 

So the mechanism should do somethign liek this; pop up a message saying: a telemetry report is ready to be sent, do you want to: sent, view, discard
view would open a text editor with a xml or json encoded i.e. human readable payload which is what woudl be sent to the server?

 

That sounds good to me. The easier it is to parse the more likely it is that I'm going to scan and send it on, xml can get quite busy depending upon the structure.

 

Its reasonable... but I'm not sure about the right way to get there... we wouldn't want to annoy users who don't care with an additional prompt after they already allowed for telemetry. So the dialog with the allow telemetry check box, or radio button would need to, offer 3 options,
Enable Telemetry
Collect Telemetry but prompt before sending (giving the option to audit and delete)
Disable Telemetry

Would it be to confusing to use a check box and its semi checked (indeterminate) state as the audit option?

 

I think if you wanted to have Enabled as default whilst appeasing as many people as possible you should have something like:

Enabled ☑ Review ☑
Disabled ☐

Then on the telemetry review screen you should include a link to the section in the GUI where you can view/amend the telemetry settings.

 

This is why I think it's a bad idea, my personal opinion: Sandboxie is my favourite program of all time and I hate the tought of SBIE collecting stuff and calling home. It wasn't doing that before and I love it for that too. I don't want to be wondering if a bug accidentally turned telemetry on in a future version by accident.
As I wrote before, if needed, I would like the telemetry to be a separate program/module which can be run by a user who's having problems for it to collect into, which can then be reviewed (eg. xml format) and approved/disapproved to be sent to the SBIE server. And, as I wrote before too, the users who feel like it, or gain some bonus by doing so, could run this separate SBIE telemetry app at all times to collect data and help with the development.
As I'm rarely writing here, I'd also like to say that I'm thankful that Sandboxie development hasn't stopped and is continuing. And also thankful for all the help I've gotten regarding Sandboxie it the past 13 years that I've been using it. I hope Sandboxie lives on and stays my favourite program forever.

 

@DavidXanatos When I read this topic in the night, I was shocked. I believe your intentions are honorable, however even the existence in a security and protective software like sandboxie, leaves a bad taste, stains the great tool it is.
I am not the user of the first hour like some who have installers of the very first iteration, but I use it for a looooong time, when it was still in the originators hands.
Who allowed btw anybody to use it as is full features all time, but if you wanted to buy and support you could. No nags, no locks. Sophos also moved on the same way, encouraging to pay, but you could use it full featured free too.
There are plenty of reasons, I want but finaly don't pay, which are all going around my personal space called privacy. Should I post here even, yeah maybe not, the great AI will identify me. Well, I am not dead just trying to minimize.

When Sandboxie became open source we didn't know what will happen, you jumped in and gave it a new life. I think you did an outstanding job and anyone using it might think the same. There were active and hot discussions here around all topics. Not working, classic vs plus, look and feel, ... nice, engaged sometimes crossing the borders, but it felt good.

Then the first bang, locking features down, open source mhhh, OK, well, I don't need those. More decisions to bring people to '"donate", even a nag screen popped up lately if I am not wrong. WOW what happened, well OK. Now Telemetry, harmless, yes sure, hey in god we trust, right?
OT: Wait what is the EU talking about, scanning E2E messages, breaking all encryptions, just for the good of humankind.
I believe this is not your intention, but it feels wrong.
Someone even suggested, hey let the free ones be forced with telemetry and only the paying users can choose. WHAT, HELLOOO? Are we already that conditioned from the kind of Microsofts and Apples, is our brains so mixed up.

We talk Open Source, where people can or cannot support in any way. In my opinion even being part of the discussion around the software and reporting issues, suggestions, helping solving problems are part of it IMO. If someone can't do any of it, that should be fine also. Isn't that the spirit.

So in a nutshell I think this is a very bad idea.
Locked features
Telemetry
what's next.
Does it fit to the spirt of this program, as well as open source? Not in my opinion,

We don't need to discuss the impertinence of Microsoft, to demand even from open source a paid certificate, so the owners of the PCs where their glorious system runs, can install a software without nag screens. But yeah it is the company of weird decisions, TELEmetry, calling home, forcing people into directions they don't want to go. TPM, locked down bootloaders, ... name it all.If the cert is to expensive then well get rid of it and we need to press yes all time. Or find another way.
What did Linux do to eat with the devil of UEFI lockdown, license a linux bootloader which can be used by all. Still some hardcores like arch doesn't official support this. Which makes sense too, how dare they to take over our hardware we bought. Cars where soon you cannot choose anymore one of them which doesn't phone your life home to the manufacturers servers and all sing happily ever after, oh how nice, all so my playlist is safely stored.
OK, I drift off, sorry. I think you see, where I am coming from.

So clear, no please do not do this.
It already got a stain now just to read about it and this doubt will stay now, will it be in one day, without us knowing, was it already!? Oh yes anyone can read the source code. No, only some of the users could.

Now on the other hand, a feature giving the user the chance to send you an error report, which was not always present, but only triggered manual by the user, "please monitor now", then "this is what will be send" and finaly "click actively to send it", would be a GOOD way to take all sides into account.

Anything which runs in the background and might sneak out? NO.


I tell you this took me some hours in the night and now to write, dismiss, write review to hopefully make it clear and explain where the No and option comes from.
I am aware that this might polarize in any way possible, but I had to give you the input.

Thanks for all the great work anyhow!!

 

@Survivor I generally share your sentiment towards the general bad direction the world is developing towards.
But some things should not be mixed together, EU spying on chat messages is a separate issue of its own.
And locked down UEFI firmware without an option to disable secure boot, kernel lockdown in linux and alike are yet an other atrocity.

I think you are miss remembering, sandboxie showed a nag screen after 30 days once every 12 hours, and force processes as well as the use of more than one active sandbox at a time was restricted to paying customers. Only in the last sophos release, which went open source, this restrictions were lifted.
And I did not bring those back, the only premium features in sandboxie plus are new features which were never present in sandboxie before, I think this is fair.

No there is no other way, its not about a nag screen when downloading, driver certification is about your windows not loading a unsigned driver period, full stop, no prompt no nothing. Only if you set your OS to boot in test mode you can load self signed drivers, and this means any self signed drivers also those signed by malware authors. Besides a lot of DRM software will complain and not allow you to use your licensed immaterial property on a system booted this way.

Also I have to clarify that various open source software comes with telemetry like Firefox, Ubuntu and many other Distros (https://www.summertime.tech/dtw.EN.html), Qt Creator (https://doc.qt.io/qtcreator/creator-telemetry.html), etc...

And about telemetry in general it can be very helpful to avoid issues, an approach where the user must actively submit a issue report is not a great user experience, as it means something must be broken first, instead it is better to avoid breaking things in the first place, see the real life example I brought up here already https://www.wilderssecurity.com/threads/compatybility-telemetry-yes-no-meybe.448213/#post-3110172

Also like with any technology Telemetry can be used for good, for bad or out right abused.
On the example of firefox, likely no one would object if they would collect only a list of used html tags a br video img etc.... and probably many would object to collecting full url's and likely even just domain names already goes to far.

It is really always about what is being collected, ... well and the trust that what is said is collected is really all there is.

I already went through breaking things and than rushing a new release to fix that, and with some I was thinking will this cause issues or will it be fine. Currently I have another potential security issue in front of me and without further insights my only recourse is: lets add a new restriction and see if anyone complains because it broke something. Also I often come across some very special case code that has more potential to break something that to help, but currently no one complains, who knows what could work better when its removed, many these workarounds are super old and probably no longer needed. So it would be great to add some trace event there and see if any sandboxie in the world that sends telemetry ever runs into that piece of code.

To make it as clear as possible what is needed are technical data about process execution and internal control flow which for what its worth are very much non personal. Probably the most sensitive information will be the name of the exe/dll file loaded.

And as already mentioned earlier it would be implemented as a external binary or set of binaries, so if in doubt, just delete the components.