Any idea what this is?

rorywalsh · 28 January 2022 19:09

Can you let me know version you are using? JUCE used to collect some data when it was owned ROLI, but once that changed they changed that too. If you are only using version 2.8, can you try the latest beta from here. Click published and grab the latest installer. The iPhone stuff could be an #ifdef, I was recently looking into Cabbage on iOS and added a few ifdefs. Otherwise it’s something from JUCE. Note that I haven’t written any analytical stuff, I wouldn’t even know where to start.

Paul2 · 28 January 2022 19:32

Thanks Rory.

OK will give it a try, I assume that I must first uninstall the current version which is 2.8.

No worries, didn’t mean to imply that you wrote them, my guess would be the same as yours,
i.e. probably ROLI.
Assuming of course that it’s not just part of a ifdef, like you mentioned.

Come to think of it, perhaps it is just part of an ifdef as I see that there are also names of many DAWs
in the compiled dll.

Are those maybe to accommodate certain workarounds for Cabbage when running as a plugin?

Anyways, it’s the weekend so time for a movie whilst firmly planted on the couch with a cold one.

rorywalsh · 28 January 2022 20:52

Good thinking!

Yes, your can query the host that a plugin is running in via reserved channels.

Paul2 · 29 January 2022 11:45

OK so the VST plugin, definitely sends analytical data.
Below a packet dump of the moment the plugin is loaded into the DAW.

Ignore the line in yellow, it’s just general DHCP stuff on my network.
And checking the destination IP, we get…

I also inspected the payload, not much critical info is sent but, it is a bit unnerving.

BTW you should see the rubbish that Windows sends, everything from data about what apps
you are running, to checking for XBOXs on the network to who knows what else.

rorywalsh · 29 January 2022 12:07

I’ve no idea why this is happening. It can only be something from the JUCE code base. They have an analytics module, but I don’t link to it in the build

Paul2 · 29 January 2022 12:18

No big deal, gonna try two things to have some fun and games with those peeping toms.
Will try each one separately:

Block that IP, see if it changes to another and if the plugin will continue to function with no response.
Hack the URL in the dll and re-route it to 127.0.0.1

Paul2 · 29 January 2022 13:27

UPDATE:

Turns out to be even easier to stop the analytical data.

Using Notepad (Important - must be run as admin), open the following file:
C:\Windows\System32\drivers\etc\hosts

At the end of the file, append the following on new lines:

0.0.0.0 google-analytics.com
0.0.0.0 www.google-analytics.com

Now save it.

Problem solved.
I though that the trick of using the “hosts” file went out the window with Win7 but, still works in Win10.

EDIT:

Are there any embedded fonts in the compiled dll?
These could also cause analytical data to be sent.
Seen it before, especially with, surprise, surprise, Google fonts.

rorywalsh · 29 January 2022 18:47

There is! The main font comes as embedded into the binaries. Good detective work!. I’m not sure it’s a google font, I’ll have to check, it has been embedded for a long time. Wow, that’s sneaky, but not all that surprising I guess.

Paul2 · 29 January 2022 19:33

Didn’t go too far back, but it’s also in 2.7.0 (32 bit) which is the version @richardk
based his compilation on.

Yep, unfortunately too many ways to get data out of one’s computer.

For those that are reading this, don’t be put off using Cabbage, there are plenty other apps
which send much more info about you back to HQ, including Windows, Apple and Android.
“All your base are belong to us”

If it really bothers anyone, I have mentioned 3 ways to stop it.
Now back to creating more VSTs, really enjoying it.

richardk · 29 January 2022 22:53

Interesting, good spot.

Looks like this doesn’t exist in the current JUCE code but I built using 5.4.7 (commit 1e71c07a49), and likely this is the culprit:

github.com

juce-framework/JUCE/blob/1e71c07a492f01022f9064560c95c2bcd938847c/modules/juce_gui_basics/misc/juce_JUCESplashScreen.cpp#L230


        #if JUCE_IOS

         agentOSName << " like Mac OS X";

        #endif



         String userAgent;

         userAgent << "Mozilla/5.0 ("

                   << deviceDescription << ";"

                   << agentCPUVendor << " " << agentOSName << ";"

                   << SystemStats::getDisplayLanguage() << ")";



         ReportingThreadContainer::getInstance()->sendReport ("https://www.google-analytics.com/collect", userAgent, data);



         appUsageReported = true;

     }

 }

#else

 ignoreUnused (appUsageReported);

#endif



#if JUCE_DISPLAY_SPLASH_SCREEN

 if (splashDisplayTime == 0

Basically there is a constant JUCE_REPORT_APP_USAGE , and when the splash screen is called, even if it is not displayed, then an attempt is made to contact google-analytics

Data sent looks to be
app type, name, version, manufacturer (ie Cabbage version etc), CPU type, OS, unique system ID.

Paul2 · 30 January 2022 09:36

Thanks @richardk that is definitely the culprit.

Of the data sent, the only two that can be considered a bit worrying are:

Unique System ID - probably made up from a few serial numbers from various pieces of hardware on the system. Most processors will have a CPU serial number, the hard disks each have a number, and each network card will have a unique MAC address.
IP address - from this your ISP and country can be determined.
Must however mention that the “internal” network address will not be known, it will be your
public IP address assigned by your ISP.

As @rorywalsh mentioned, this analytical data sending, has been included from several versions back.
The question is, what to do about it, if anything?

On any given day, I use Windows, Mac and Linux (Debian) but currently,
only trying Cabbage on Windows, hence the solutions I’ve written about, pertain only to that OS.

My approach then was as follows:

Modify my hosts file.
Patch/modify any VSTs that I already compiled.
Patch/modify my existing version of Cabbage so that future VSTs are “taken care of”.

Found this much easier and quicker than trying to find a version of Cabbage without it.
(and certainly much less work than re-compiling Cabbage).

This of course, may not suit other users that are concerned with the analytical data and have
supplied plugins to clients or, use another OS.

For now, I only intend to use Cabbage on Windows and for my own personal use, so I’m sorted.

The patching can of course be applied to Mac and Linux as well, albeit slightly differently.
This then negates the need to change the current version of Cabbage being used.

I will not publicly share the patching method used, as this could be against the terms of use.
@rorywalsh can I send you a PM with the details rather?
You can then decide if you would like to implement the patching of existing plugins via a dedicated
program with versions for the different OS’s.

The user then has several options:

Do nothing, carry on as before, it’s not that big of a threat anyway, but it is irritating and sneaky.
Upgrade to another version that does not contain the sending of analytical data.
Patch the existing version of Cabbage and any plugins that have already been made.
This would involve a program (one per OS) that Rory could make available on the Cabbage website.
You could call it the…“CabbagePatch”… Couldn’t resist, sorry.

rorywalsh · 30 January 2022 11:46

For now I can build a version that doesn’t use any embedded text and see if that helps?

Paul2 · 30 January 2022 13:50

If you think it will help, absolutely.

BTW what is the preferred method of upgrading Cabbage?
Uninstall old version then install new version or, just simply install the newer one?

rorywalsh · 30 January 2022 17:16

I usually just install over the previous version

richardk · 8 February 2022 22:50

I have rebuilt my 32-bit XP compatible binaries with the JUCE usage reporting removed:

http://csound.1bpm.net/builds/cabbage-windows_x86_32-XPCompat-2.7.0a-binaries.zip

Also updated the thread I posted the link to the build in originally.

Paul2 · 9 February 2022 02:52

Many thanks for that @richardk

EDIT:

Richard, just tried to download it, however there seems to be something wrong.
The whole /builds section of your website is not responding.

richardk · 9 February 2022 18:25

Loads OK from here, and webpagetest.org says it is alright. Is anything responding on the site? Does it just timeout?

I will look into doing another 32bit build of the current code in the next week or so - I think there have been a few changes since.

Paul2 · 9 February 2022 19:51

More details:

richardk · 10 February 2022 02:23

Strange, all of the pages are on the same server and builds is the second slimmest page there. Archive should take the longest to load as it uses a database backend.

I have put the new build on a different server, here:
http://dev.1bpm.net/cabbage-windows_x86_32-XPCompat-2.7.0a-binaries.zip

Paul2 · 10 February 2022 10:01

Hi @richardk

Worked like a charm, the 21MB file was downloaded almost instantaneously.
Thank you.

BTW, just one small issue, nothing major…because that server uses http and not https,
Chrome has a bit of a flap and says it can’t be downloaded securely, just ignore it and click on “KEEP”.