New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
With regards to the malware allegations #350
Comments
Feel free to ask any questions here! |
Backing up @sylveon here. As he said, this permission is used by any win32 app in the store today. Just look at these apps and scroll to the bottom of their pages. You'll see the same permission. The person who originally made this claim seems misinformed. |
Just wanted to add that it's perfectly fine if you don't trust us 100% on this. Makes sense; never trust strangers, especially online! If you want to verify our claims, you can use tools like Microsoft's Process Monitor to see with your own eyes, in real time, what TTB is doing. ProcMon is able to show you every filesystem read, every registry access, every network connection - pretty much everything a program does. All you'll see is explained above by @sylveon. Just note that Process Monitor will also have a bit of noise from system libraries and stuff which is completely normal; if you see anything which you think is abnormal, get in touch with us and we'd be happy to clarify what it is and what causes it. Thanks for understanding, and we encourage everybody who might be suspicious to poke and play around! After all, it's always good to be cautious, so good on you for taking the time to check this post out and investigate. |
Also, would just like to add - apparently, some people have claimed that "TTB uses admin privileges and anything that uses admin privileges for something this small is dangerous." However, TranslucentTB does not require administrator privileges and never asks for them, because we don't need them. |
It's literally impossible to submit an app using admin to the store unless you're Microsoft... |
Another addition - yes, it is true that you cannot verify the code submitted to an app store. If you've ever used an app store version of a popular open-source application - Telegram or Signal messengers, for example - from the Play Store, iOS App Store, or Microsoft Store, the same trust issue applies*. On Linux, you have no way to verify that key packages used for, say, cryptography cannot steal your information if you download them with a package manager. The point is, that there is easy no way for us to demonstrate that the code on the Windows Store is the same as the GitHub. This is a design aspect of most App Stores (F-Droid is an exception). This issue affects all pre-compiled open source code, such as Firefox, Visual Studio Code, Blender, and also anything on an app store. There is (probably) nothing that we can do to increase trust and transparency further - if you have a suggestion, raise an Issue or get in touch! If you don't trust us to submit a genuine binary to the Windows Store out of malice (we've already explained the permission use above), the parent post of this thread says:
This way, you can be sure that you're only running the open-source code that we make publicly available, with no possible potential of hidden tricks. [*] Correction: it is possible to reproduce our builds. You'd have to download the .appx, extract the .exe, remove the signed digital certificate, and then check the binary against a self-compiled, unsigned version. Or you could decompile the .exe I guess. |
Here's a slightly more comprehensive list of popular/official apps on the Microsoft Store that also have this permission:
|
I've checked the guys content out and... just the typical "Linux better" kind of guy. Angry about anything Windows, nothing else. |
Those wannabe security guys need to stop talking. The original poster rectified his claims, but numerous other posters and reposters are still claiming it and not retracting their statement. |
But our apps do have access to all files, peripheral devices, apps, programs, and the registry. So what exactly are you suggesting is poorly worded here? What is the suggested alternative? |
Users assume that if an app has a permission, it will use it (because otherwise why would it have it). So saying that the app has access to all files, peripherals, programs and the registry, while technically correct, will be confusing to the user because most Win32 apps on the Store (including TranslucentTB) in fact do not access any of these. Several of the people saying TTB was malware even believed that the version on GitHub had less permissions, while it was the complete contrary: it runs completely unsandboxed with no restrictions, as does every Win32 app not obtained from the Store! This is a clear example that users are completely disconnected with the difference between the Store and normal apps, and see this permission as being sketchier than an unsigned installer on a GitHub repo... As an existing alternative, while not ideal, the app package installer lists the runFullTrust cap as "Uses all system resources". I would prefer to see something like "run unsandboxed", and the wording on the "more details" page could also be updated to explain that this permission runs the app as if it was installed from a source outside the Store. |
Why not ditch the App Store altogether? Is it really worth the effort? |
Most of our userbase comes from the Store (> 4M Store acquisitions, only 1M total downloads on GitHub), GitHub isn't really the most intuitive for users, it's basically effortless for us to support and it provides us with automated crash reports that the GitHub version doesn't. |
Yes, because there's no alternative interpretation.
Not sure how you could know that.
There is no difference, from a security standpoint, between full-trust apps from the Store and the loose GitHub binaries.
The sandbox you're thinking of is not a security boundary and is therefore irrelevant. The description takes this into account by presenting the worst possible case. |
Well for one the registry is write-virtualized so packaged Win32 apps can't even write to the actual system registry. And, by a quick look on the Store many Win32 apps are utilities and programs which certainly don't need complete hardware access. (e.g. Spotify certainly doesn't need access to all my files, programs, and etc.)
Nope, but users don't get that and think GitHub is safer, because GitHub has no such "this app can access all files" text. While the file/registry virtualization is not a security feature, it's still a feature that makes the chances of a packaged program doing damage to the system lower.
I was comparing against the normal low IL/AppContainer sandbox that non-full trust (UWP) apps run in, which is actually a security boundary. |
The point is, a full-trust app on GitHub/Microsoft Store is not sandboxed in a way that allows Microsoft to definitely control/say what an app can and cannot do. So it's impossible to detail these app's capabilities in the Microsoft Store. You must assume they are touching everything. I don't like it either and get similar complaints for our app, but there really is no other solution to be had here. |
I think documenting partial trust support for Win32 and then giving us capabilities to enable the parts we need would be better, but I'm not holding my breath for that. |
So somebody has been making waves on TikTok about this app potentially being malware/scamware or other bad things.
This is caused by the Store entry saying this:
This is what the runFullTrust restricted capability shows up as. It is a restricted capability used by all Win32 apps on the Store. To get access to this capability, developers must individually communicate with a MS engineer and justify their use case. Once approved, any app submissions (including updates to existing apps) are also always manually reviewed rather than automated.
You can spot this restricted capability on other apps present in the Store like ShareX, Telegram, Spotify, iTunes, Ear Trumpet and WhatsApp desktop. Some UWP apps like Nightingale and OneLocker also use it because some of their use cases do not work in the UWP sandbox (respectively, localhost loopback and global keyboard shortcuts).
The
runFullTrust
permission is required because the UWP sandbox prevents most Win32 apps from doings that they expect to work (for example not even tray icons work). If you are interested in making the UWP sandbox more compatible with Win32 apps, you can upvote/follow this Project Reunion issue microsoft/WindowsAppSDK#219TranslucentTB is Win32 because it uses undocumented API calls (specifically, SetWindowCompositionAttribute) and Win32 windowing APIs to perform its work, both of which are blocked in UWP apps. Unconstrained background execution is also required for TTB to work properly, which UWP is still rather a mixed bag at doing.
The only filesystem/registry access being done is to read and write the configuration files, which are already stored in a region of the filesystem that normal UWP apps can also access. We do not read the registry in Store builds, desktop builds do only to allow the app to automatically start on boot. The app also writes log files, but those aren't uploaded anywhere, they're only used for users to voluntarily submit in this issue tracker if they encounter issues. All of this usage is covered by our privacy policy available here: https://translucenttb.github.io/privacy-policy
You can inspect all of this yourself because TranslucentTB is open source (after all, this message is posted on GitHub, a platform for open source software), and build your own copy if you don't trust my own builds. I am willing to offer assistance to anybody willing to do so, just contact me on the Discord server.
I understand the permission in the Microsoft Store is rather poorly worded, but this is something completely outside of my influence. I too wish it was better worded.
I'm really sad that somebody assumed evil intent in something that has been sipping up most of my free time for the past 3 years :(
In other news we have Azure Pipelines set up and you can try preview builds of things I commit, including less broken multi-monitor support and native ARM64 builds! Here's the latest build as of the time of writing: https://dev.azure.com/sylve0n/TranslucentTB/_build/results?buildId=56&view=artifacts&pathAsName=false&type=publishedArtifacts. Be warned it may crash and some stuff isn't fully working yet. And this one you can also actually review the build process to confirm that it comes from the sources published here.
The text was updated successfully, but these errors were encountered: