It's actually a very thin excuse, from an engineering perspective. Epic is an always online client, so it's always at the mercy of some server outage or another. Furthermore, it gave them access to a lot more information that Valve specifically classifies as "private user data".
-
-
Furthermore, it most likely means they did this to avoid storing steam data on their own servers to reduce resource cost. If they pull from steam api and want to keep it up they would have to rewrite that data on their database in case steam went down.
1 reply 0 retweets 0 likes -
The local client could call the API and store retrieved information to the local user machine only and only rewrite if a new version was able to be retrieved. I'm happy to chat with you more on API use, if you'd like...
2 replies 0 retweets 2 likes -
Also this doesn't resolve the issue if the steam api goes down and epic requests the friends's list.
1 reply 0 retweets 0 likes -
That's because API uptime is a thin excuse to access another programmes private userdata. There are thousands of applications out there using APIs properly just fine, despite downtimes. You're acting like EGS needs realtime access here... It's just a one-time friend's list sync.
2 replies 0 retweets 2 likes -
I disagree. Decreasing downtime is always high priority in any work I have done. I am not sure what your experience is with development on a production environment is but maybe we are miss understanding each other here.
1 reply 0 retweets 0 likes -
My work has been split between systems and InfoSec engineering, also IT risk analysis and auditing. The reason why I'm an Executive IT Consultant is because I have a strong grasp of multiple facets of IT ecosystems. I am the tech adviser to Enterprise Architects, essentially.
1 reply 0 retweets 3 likes -
Replying to @Mortiel @SonOfATech and
Given that, I can say strongly that uptime management should always be balanced with industry best practice and, you know, not making the company liable for law suits. That's what IT risk should be looking at within Epic. If they have a risk dept.
1 reply 0 retweets 3 likes -
I would assume they just tasked a low level dev to integrate steam friends sharimg amd thats how the whole mess started. Not a grand conspiracy at the board room table to farm user data.
1 reply 0 retweets 0 likes -
Not to be repeating myself a third time, but I never said that it was... I said that I suspect it was done because Epic didn't want Valve to be able to revoke access. The point here is that said userdata is the user's and Valve's right to revoke access. Epic is ignoring that.
2 replies 0 retweets 2 likes
We avoid integrating any avoidable closed-source APIs everywhere due to non-Steam-specific general concerns about security and unexpected behavior. On reading the file, Epic’s view is: is the user’s data on the user’s machine and they have the right to import it if they choose.
-
-
Replying to @TimSweeneyEpic @SonOfATech and
It's clear what Steam's API can access and provide. It also only gives you want you ask for. Steam is not Facebook, and the comparison is disingenuous at best. However, the problem is that the client *copies the local data before being asked*. Doesn't matter if it uploads it.
1 reply 0 retweets 2 likes -
Replying to @Mortiel @TimSweeneyEpic and
It does matter if it uploads though right? The upload is where your InfoSec concerns would be valid rights If all they are transferring is the same data that’s publicly available, after the user consents to getting the data, what are we concerned with?
0 replies 0 retweets 0 likes
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.