5 ms·
I’ll post Epic Games response in the thread here also. ——————————— We use a tracking pixel (tracking.js) for our Support-A-Creator program so we can pay creat
by slashink 8y ago
I’ll post Epic Games response in the thread here also.
———————————
We use a tracking pixel (tracking.js) for our Support-A-Creator program so we can pay creators. We also track page statistics.
The launcher sends a hardware survey (CPU, GPU, and the like) at a regular interval as outlined in our privacy policy(see the “Information We Collect or Receive” section). You can find the code here.
The UDP traffic highlighted in this post is a launcher feature for communication with the Unreal Editor. The source of the underlying system is available on github.
The majority of the launcher UI is implemented using web technology that is being rendered by Chromium (which is open source). The root certificate and cookie access mentioned above is a result of normal web browser start up.
The launcher scans your active processes to prevent updating games that are currently running. This information is not sent to Epic.
We only import your Steam friends with your explicit permission. The launcher makes an encrypted local copy of your localconfig.vdf Steam file. However information from this file is only sent to Epic if you choose to import your Steam friends, and then only hashed ids of your friends are sent and no other information from the file.
Epic is controlled by Tim Sweeney. We have lots of external shareholders, none of whom have access to customer data.
Daniel Vogel
VP of Engineering
Epic Games Inc.
- foxes 8y ago>The launcher makes an encrypted local copy of your localconfig.vdf Steam file. This should not be done preemptively.
- sigmar 8y agoTotally agree. It is too difficult for the average consumer to find out what is does with that "local copy." Software shouldn't touch another program's file without user consent.
- AnIdiotOnTheNet 8y agoIt's high time we started enforcing that by default at the OS level.
- ocdtrekkie 8y agoThat's what UWP does on Windows. And it was immediately derided by nearly everyone for being too closed down.
- AnIdiotOnTheNet 8y agoThat's because any benefit UWP brought was outweighed by all its drawbacks, at least for me.
- noxxten 8y agoUWP was broadly criticized because of how it operated. Every notification I got from UWP was something along the lines of "In order to rename this file, _____ program needs access to LITERALLY EVERY FILE AND PERMISSION AVAILABLE ON YOUR COMPUTER AND/OR HOME NETWORK" Maybe if these notifications were less vague, they wouldn't be hounded as annoying and useless... Just saying.
- Wowfunhappy 8y agoIt’s notable that you bring this up in a news story about PC gaming, which is a prime example of why this shouldn’t be enforced. There are huge community efforts around modding games—adding features, updating old titles, improving performance, etc etc. All of this is essential to PC gaming, and all of it becomes impossible if software is sandboxed.
- tacomplain 8y agoYou can surely think about a model of sandboxing with public and private (even internal for company wide) restrictions.
- stordoff 8y agoI'm not sure why this is the case. I don't see why you wouldn't be able to edit things that are in the sandbox (you create it in the first place, after all), whilst making sure things in the sandbox can't access anything outside it. AFAICT, it's basically just running as a different user. User user gets edit access, Epic user only gets access to its own folder.
- ramy_d 8y agoGP says it does have consent. what's the issue?
- hug 8y agoIt copies the info prior to consent, just in case you might consent later. That behaviour is a little bit gross.
- saintPirelli 8y agoBut is it malevolent or just a little lazy? I can't decide.
- y4mi 8y agoif it were malevolent, they'd just load it into ram and send it to the server without persisting on the drive... (and without asking)
- wgoodall01 8y agoI mean really, what's the difference? They can access that file at any time they want anyhow---as long as they only send it to their server after user consent, I'm really failing to see a problem here. Making a copy of one file they can already access to another place they can also already access isn't really violating anyone's privacy. It's what they DO with the information that matters.
- sigmar 8y ago>It's what they DO with the information that matters. 99% of end users will not be able to reverse engineer the binary and find out that copy is never transmitted. The fact it is 'touching' private files at all without any consent degrades trust. Furthermore, if I want to delete all traces of Steam from my computer how the hell would I know there is a copy of steam's localconfig in a different program's folder? or what if I backup or share privately/publicly my EpicLauncher directory without realizing all my steam contacts are in there?
- snthd 8y agoIt's probably to keep things working through a change in steam.
- tokyodude 8y agothis is all greet but I shouldn't have to trust app makers. the os shouldn't allow an app to read another app's data without permission. the os also shouldn't allow an app to view what other apps are running Epic might be doing the right thing today. Will they tomorrow? Is every library they use trustworth forever?
- ourmandave 8y ago"I am altering the deal. Pray I don't alter it any further." ~ Darth Vader You can read the changes to the ToS at www.palpatine2020.com/toremotetomakeaneffectdemonstration
- chris_mc 8y agoI'm starting to think something like flatpak or snap is necessary, but in a more sandboxed way, to enforce on the user level that certain apps won't have access to certain files. I would like to see options to fully sandbox an app (has it's own separate permissions for certain documents) or not sandbox it at all (for things we trust implicitly that need that access).
- danShumway 8y agoflatpak permissions + Wayland are (imo) some of the best things happening on Linux right now. You could always kind of do the same stuff with containers and custom wrappers around each program, but it's really cumbersome. I want this to be the normal. Right now, it's basically a free for all -- record the screen, send network requests, fingerprint hardware, scan for files, examine other processes. The default, out-of-the-box security settings for most distributions are unacceptable. I'm really excited to see that sandboxing on native is starting to move in the same direction as the web; I'm hoping that within the next year or two we start to see dramatic improvement here.