Compatybility Telemetry Yes, No, Meybe?

I've seen the benefits of telemetry first-hand in the Insider builds, particularly when I was running the Dev builds. It's been highly beneficial in that context. But at the same time, there's not much of a line the end-user can draw to make boundaries without jumping thru some obscure hoops. Knowing that you're willing to have the user delete those goes a long way toward more trust.

Just as well: it works great for my non-sandbox installation purposes--knowing that 95% or so of Plus' features go unused on here as it is.

 

I was thinking for a long time if I should start this thread or just continue business as usual and throw the odd broken build at the user bases from time to time. But given that I am under the impression that there is a significant number of users who just don't care about telemetry I decided to make this inquiry to see if there is a mode of telemetry which could be implemented without antagonizing the super privacy conscientious fraction of the user basis.

Also, about @Survivor’s warry that this thread itself may stain sandboxie, really, would it? I mean have you ever in the entire 21st century have seen a more open and user-oriented approach to deal with the question of collecting telemetry data?
Did anyone of here knew that the original sandboxie installer sent a ping to Invincia/Sophos on every installation/update/uninstallation https://github.com/sandboxie/sandbo...badf98c11501377b/install/SandboxieVS.nsi#L766 containing the unique MachineGuid from HKLM\SOFTWARE\Microsoft\Cryptography


As it seems there is a reasonable approach to let the Telemetry mechanism be a separate optional component which the installer offers (pre-selected though) during installation. When installed, once the first report is ready to be sent show a prompt to the user asking if he would like to contribute to the improvement of sandboxie by submitting non personal telemetry data without any unique identifiers. Offering, additionally to a simple yes (send always)/no (disable telemetry), the option to view the data file which has been assembled (it probably will not be XML but JSON which is also very human readable), and then the option to "Send" (and when the next report is ready ask again), "Discard" (this report and ask again for the next) as well as "Send Always" (send and send in future without further prompts).

So, such an approach would give the user two opportunities to not send any telemetry data,
only if the user a) does not unselects the component during installation and b) explicitly presses send on the later prompt, anything could be sent.

I think such a mechanism should provide a high level of confidence in its integrity and would be difficult to object to.


I mean let’s be honest if you could unselect the windows telemetry client during windows installation, no one would have ever complained about windows having optional telemetry, it would have been a non-issue only MSFT's attitude of forcing it on everyone without even an proper off switch is what caused the uproar in the first place and have Telemetry in general a bad vibe.

 

I don't think so. Telemetry of commercial software have had bad press. People have some vague association that any telemetry equals bad thing.
People are quite irrational when it comes to data sharing practices. On one hand person can give away all kinds of data by using Windows Defender or even rest of Windows with default privacy settings, regular web browsing, not to mention shopping or having Facebook or GMail account. At the same time user can become upset that telemetry without any personal information nor machine ID is collected and send to the open-source app developer.

 

Well said.

Sandboxie is all about security, so why on earth would any user of Sandboxie be happy to have it include spyware?

Which lets cut the nonsense here. I use Sandboxie and think it is great to see it still being developed but I also don't like spyware and ignoring the fact that telemetry is spyware just because the developer is on here is absolutely insane......I can't get my head around this mentality.

Would the same people who are happy to see spyware be included with Sandboxie also have the same opinion when other companies do the same? Everyone knows the answer.

 

The acceptance of telemetry, within Sandboxie software, I believe, (as I've stated above) is the thin edge of a wedge. I would not want users to be bullied or nagged into accepting telemetry, just through a small consensus snapshot of opinion, as their views, in not wanting invasive access to their systems, seems valid.
I understand that David wants feedback but imposing it within the software with a default 'ON' switch would be a terrible idea. A separate software, that users can opt into when they feel like, it seems a better way to go and is more respectful to users generally and I believe too be more ethically sound.
I'm all for feedback to help Sandboxie development but not forced down our throats as a default obligation.within the program.

 

It depends on what data that is gathered. If data is strictly technical, does not include my documents, PII nor machine/OS identifiers then it is ok for me most of the time.

 

@sdmod does the approach as I laid out in https://www.wilderssecurity.com/thr...metry-yes-no-meybe.448213/page-2#post-3110348 fulfills your request for it being a "A separate software"?

If not than what you are asking for is a separate installer, which lets be honest no one will bother to install, people are lazy, so it would be a waste of my time to even write it.
No one does anything without an incentive, doing something needs energy and in nature everything living tries to spent as little energy as can be. LOL

I think it is reasonable to lay the system out such that people who just don't care will end up with it enabled, because they don't care. What they presumably care about though is a future sandboxie build not regressing on already existing software compatibility. So summed up its in their interest, wouldn't you say that this is a fair assessment?

And about Telemetry vs. Spyware, sure "MSFT Telemetry" == "EVIL Mega Spyware" but this is not a universal truth it depends on what data will be collected by any given telemetry implementation. Like in the example in https://www.wilderssecurity.com/threads/compatybility-telemetry-yes-no-meybe.448213/#post-3110341 with firefox.

And as I said initially what is needed is in no way related to a user usage statistics like how many hours user x played candy crush on PC y, or personal data of any kind.
What is needed is which processes if any used certain sys calls, did a process if any ever hit a particular code block in the SbieDll, what 3rd party dll's are loaded into sandboxed processes which may cause issues. Which compatibility templates are activated, which security/isolation features are being disabled and which processes seam to needs that to run properly.
Probably the most sensitive information that may be included is if the program name itself is for some reason confidential like keygen.exe, patch.exe or 8168008.exe LOL for which we can add a hard coded exclusion list, IgnoreProcess=keygen.exe IgnoreProcess=patch.exe IgnoreProcess=*activator*.exe or something.

 

@DavidXanatos all what you wrote in the answer, was why I had a hard time to put it down without being accusative, as I think this piece of software, as well as others, need the full trust of the people. Your example with FireFox was good, it really sneaked in, without a real notification and is unlike the message of the browser, when you install it new, the button with a message about your rights, but then having the telemetry as opt out hidden in the bottom of general settings. Not the best way of trust. Or the scandal around Avast, once trusted tool, is used with a bad feeling too. There are so much more. But the point is really yes, you are very open with it and I think you do a great job with it. However it triggers the gag reflex.

The privacy crap all over invading us was only to explain better where I come from

The old one box only is true, I forgot about that one, even if for my use cases it never bugged and I guess most people were bothered.

Interesting point with Sophos and the machine ID, no didn't know that, but I guess it was their way of license check. Intrusive though no doubt and good to know, even if it is not happening anymore.


@reasonablePrivacy I absolutly agree to you here, though not fitting with me, no FB, no Twitter, no no no. I made an account here after long thoughts but no MS account in Windows or at Github, special after it was taken over by the MS. However yep in the time I played UT3 online, which went over the Epic servers. So who knows what they collected, though at that time Epic was still a company which listened and had unlocked the UT series after some month of soft DRM. Keep in mind that the usual users, you talk about, who spread their faces and opinions all over the web, are not the audience of Sandboxie, I would say.

The argument once the door is open and some not so integer dev steps in, it might secretly been added. However in the same go, any software you use, could do this anyway, without us knowing. As I think nobody is daily scanning all actions a program does. At one point we are all users of other peoples software even the most skilled one will once simply use something. This was also the point I jumped up and down, trusting David, but a security centered software does get a kind of stain with such function. Big credit goes to DAVID though, how open he discusses all his decisions. Kudos to that, whatever comes. I like the kind of integrety.

It is this kind of interaction which shows me again, that there are still enough people here, which makes it worth to post things and discuss.

Final word to @DavidXanatos, the approach you want to go now, seems a good one and as long as you're that open, you definitive earned the trust. But keep in mind as open source, we need to be on the lookout, not that our friends from the ASN come and infiltrate more functions LOL
One more suggestion would be to make it a module in Sandboxie. Let the decision to activate it as you wrote and in case you activated it, go with your idea of asking and giving the possibilty to open. You can also leave the option, well I don't want to send it this time, but maybe the next. Just because you don't want the data of that session sent.
A report is ready to send to ...
Click to show/ open report
o Send this report only
o Send this and all future reports
o Do not send this report, ask again
o Never sent a report, do not ask again
Select and press [OK] [Cancel] where cancel would simply skip like do not send now and ask again.

Like this it is available all time, even if you general wouldn't like to use it. But you can let it run in case of issues.

So in general, it is still a trust thing and this cannot be TPM trust to someone who claims to have my best interest, it should be a trust I give because I think/ feel I can give. David deserves the trust for sure as he proofs also with the way he wants to make it now. I would vote for the trust, we want to give, choice option, as described above. This serves all, it can be deactivated, it can be forever switched on, or being on demand. I could live with it, even if it makes me shiver.

 

To paraphrase, the road to software $#1* is paved with ethical telemetry
And my gut tells me that it will be coming to Sandboxie-Plus very soon.
So, @DavidXanatos , if that is indeed so, may the force be with you

 

Definitely not anytime soon, if at all, I'm still not sure if enough users will use it to justify putting in the required work of implementing it.

And I'm thinking if there are viable alternatives.
One method people used to use in the good old days was to put in a message box some ware to see if a certain code path will be used, which stayed something like:
"IF YOU EVER SEE THIS MESSAGE, please call me at +111 222 333 456 789 or email me at me@domain.com and say [XYZ] has happened"
or a more familiar example "SBIE2205 Service not implemented: %2" not quite the same but could be built upon.

Now I wouldn't want to go through "mmh does this ever happen", release a build, wait for a week or two, see if I got any emails, that's just to long of a turn around time given our rather short development cycles.

But something like a instruction file, something that could be downloaded along each update check, that can dynamically add some diagnostic messages/events, which then would be collected in a new "Diagnostic" tab. The tab would be normally hidden but if a diagnostic event is recorded it would be set visible and graphically emphasized to ensure its noticed.
The tabs content would not be volatile like the message log, that is it would be saved between runs of sandman.
And it would offer a button to upload the diagnostic log, or the user could just copy it and email it and clear it afterwards.

Now obviously such an approach is much more limited and requires active user participation so again not sure if its worth the afford.
It would not help us to find out which compatibility templates are obsolete for example. And just enabling legacy behavior preset should not trigger a diagnostic event, so no insight in this either.
And it does not help with the initial goal to know which sys calls should be audited for the hardened box mode.

I think this is the main limitation a report an issue approach is bad as it requires an issue to be created in the first place. And a collection of events will annoy users if will trigger to often so it can only be used in rare occasions.

 

David, thank you for that rare insight into the mind of a "passionate" developer.
I was pretty much convinced that you were looking for a quick resolution to the
frustrating syscall issues. Well, you have shown us why it is sometimes such a
struggle to do the right thing by your software (that you love) and by your users
(especially here at wilders). Hats off to you and our best wishes

 

@DavidXanatos

I'm all for feedback and user/developer interaction but not telemetry within Sandboxie itself.
Tzuk had a very active forum in his day and I'm more for that type of user interaction, rather than blind 'glued in' telemetry.
I've never liked telemetry within software no matter how innocent it seems or whatever the views of the developer at the time of initiating it. I don't like software that has to constantly 'back and forth' actively. It puts a burden on me automatically, that I don't want and is intrusive.
I know that many softwares tag us in some way with 'phone homes' etc and I just don't like that type of 'given' that the software developer thinks it's alright to form some kind of online connection within the software to your pc. I avoid that sort of software whenever possible.
Ideally I prefer my software to be 'dumb' and when purchased. it's mine and nobody elses business, the umbilical cord has been cut and I own it.
I always liked Freeware and although a good concept to share software and software development it was often burdened by sneaky phone homes and tags and loaded with malware and crap. Lots of otherwise good software has been spoiled and become unusable, by a thoughtless developer.
If I want to say something about my machine or have any criticism or suggestions for the software then I'll say it, not have it bled automatically out of me.
I am for feedback but not telemetry.
I like small utilitarian software that is unintrusive..
I like software development that is almost 'hobbyist' and development often goes off on projects when there is a sniff of money.
I know that software developers have to live but engineering software that would be simple and utilitarian into 'product' is the death of it to me.
I do not like rentware incrementware or creepware and prefer a life time licence and a sense of ownership
There may be problems with that software but it can be discussed with an active and enthusiastic developer through forums.
I think general user developer discussion through a forum is fantastic but often lazy concensus based decisions from over eager users wanting the next best thing can lead to bad and often irreversible negative changes being made.

Sorry that I am 'all over the place' with this post but i feel strongly about these sorts of issues.

Input of information from users, by choice to a developer as feedback during development to help the software and developer to progress is good.
Not actively from within the software.

I admire and respect David for taking on the Sandboxie project.

My opinion is that is becoming over complicated for basic users with the constant changes.
Users then pick their favourite version and stick with it and back off from the development race.

I (for example) have my favourite version of Shadow Defender and I stick with that even though I've been interested in the 'development' as it's gone along, I don't like to be used as a 'Guinea Pig' and am not 'mad' necessarily for 'the latest thing'.

 

Yes same over here, I don't think telemetry should be included in a tool like Sandboxie. I hate it when apps are trying to phone home. On the other hand, in the other topic about telemetry, David Xanatos said that it will be implemented in a telemetry.dll file which you can simply delete.

 

@smod for various utilitarian software an active community plus feedback when an issue occurs is certainly good enough.
But this does not work for any kind of software, for example for Task Explorer that would be sufficient, as it has only to deal with itself and a public build of windows.
Sandboxie is however a completely different thing, as it has to deal with a myriad of 3rd party processes deeply integrating with them where each of those is doing something completely different.
So while in the case of Task Explorer any change can be reasonably tested locally before release, for Sandboxie this is not possible, first I cant run a test suite of 10 000 programs second I don't even know which programs to test in the first place. Ofcause Firefox, Edge, Chrome is a starting point but that's just a fraction of things which which sandboxie has to work.

This is why the idea of crowd sourcing those data came up, as mentioned before a couple times, its often a question of what if anything is using some particular code. Having this on file in a crowd sourced database would allow to quickly look up the names of processes which use some specific sys call, than google those download the appropriate demo versions and do the required targeted testing.
So in that sense; its not about making anyone a 'Guinea Pig', quite the opposite, the current approach is to make anyone who downloads a pre-release build a 'Guinea Pig' and see who squeaks, and if no one does, next hope in the public release, not to many will encounter a problem with the new security restriction.

An event driven approach will not help here I think.

What do you think about an implementation as outlined in this post: https://www.wilderssecurity.com/thr...metry-yes-no-meybe.448213/page-2#post-3110348 ?
Its not quite go to some other web page and download a second telemetry installer, but the next best thing.

 

If the telemetry was none invasive or personal and it was off by default at installation of Sandboxie and would need an active choice to run it and was deletable like a dll and if a user could choose to switch back off again if he changed his mind later then it might work.
I am never happy with telemetry...data mining, hacking and software development changing hands make me feel uncomfortable.
I'm old fashioned, I admit it.
I see and understand the need that you have to advance the software and keep your finger on the the pulse, I'm just very uncomfortable with telemetry and any type of spyware by default or software that puts the onus on the user to make difficult choices and especially if they are new to that software. If it was an on switch by default and required the user to know why he might have to turn it off...a lot of new users would leave it on just through lack of confidence and understanding of the pros and cons.
I wont say any more about it because I get the feeling that I might be repeating myself.
Security and privacy might be just a dream, a fantasy, as people are endlessly telling us.
People give themselves, their friends and family away by the bucket load these days, just for the sake of an easy life and convenience. Maybe me too and with all my 'protestations'...I hope and pray, that isn't the case.
We are going down a drain fast and it is likely irreversible. Maybe it's always been so.

 

IIUC this telemetry is about software rather than hardware.

 

I don't support the idea of telemetry on any level, please do not do it

 

He's going to. Accept it.
He's established mechanisms for people be able to NOT install the telemetry module.

 

This is not yet decided, if I would have a decision I would not make a public inquiry.
And frankly I'm wondering if its worth the trouble, given that many seam to not even like an approach with 2 opportunities to opt out.

As I wrote earlier many times I myself am one of the people who first thing disables all telemetry and cranks up the firewall to 11, but then as a developer I see how useful that can be, and I know many people who just don't care a bit about telemetry, or even install the windows telemetry data viewer to view it as if it would be some sort of entertainment LOL.

Hence I though it would be a good idea to gauge the community opinion on this subject, if it shows to be overwhelmingly positive or at least neutral why not use telemetry to improve the software.
If it shows to be a bad idea... keep thinking how else to improve it...

 

Don't overthink it, just do a separate telemetry module. Those willing to send data to you to improve sandboxie will use it.

 

I have another idea; aside of the Pre-Release and Release channels I could Introduce a Nightly Build one, which would not be distributed through GitHub releases but using a custom updater tool. Let’s call it Sandboxie-Live or something like that. It would always have the very newest binaries, so not like currently where you need to wait a week or two for a particular fix, but you get the fix as soon as I upload it to github, automajically installed by a background updater service. That “price” for that awesome service, its bundled with a data collection module, and of cause the chance of getting the odd broken build may go up, will remain to be seen, but there would be a method to quickly downgrade to yesterdays or before that build, etc…

Now how useful the collected data would be would depend on how many users would participate, but the offered faster updates may for many be worth it?

What do you think?

 

Would this Sandboxie Live be a certificate-version with all functions enabled?

 

No it would require a certificate like any other.

 

@DavidXanatos, you sir are a saint!

I commend you for trying to keep everyone happy (including Windows 7 support; all the work you've done to bring Classic into Plus (as well as Classic ongoing support); and now the discussion on telemetry) but at some point you have to do what's right for you.

I know there's been some dismay at your suggestion of telemetry—some which frankly has been shameful—but the approach you've outlined is more than acceptable, and whilst some may not like it they'll just disable the telemetry and carry on, for us Windows users have to be a pragmatic breed!

Alternatively, why don't you just poll the supporters and contributors?

 

So really we all should go along with anything and have a one sided (pro spyware) opinion just because he develops Sandboxie.

~ OT Remarks Removed ~