Posted June 02, 2016
phaolo
Durik - Half-Orc
phaolo Sorry, data for given user is currently unavailable. Please, try again later. View profile View wishlist Start conversation Invite to friends Invite to friends Accept invitation Accept invitation Pending invitation... Unblock chat Registered: Dec 2013
From Italy
adaliabooks
"Vell, Zaphod's just zis guy, you know?"
adaliabooks Sorry, data for given user is currently unavailable. Please, try again later. View profile View wishlist Start conversation Invite to friends Invite to friends Accept invitation Accept invitation Pending invitation... Unblock chat Registered: Jun 2013
From United Kingdom
Posted June 02, 2016
Johny.: You could just look into the network panel in your browser and see exactly what is sent where.
For now - aside of Google Analytics, there's only sending encountered JavaScript errors data. I've prepared one myself so I can attach it to this post.
I'm curious... will it spot and report any errors on the page or just ones it's been asked to watch for? For now - aside of Google Analytics, there's only sending encountered JavaScript errors data. I've prepared one myself so I can attach it to this post.
For example if my script (or BE) causes an error will it get sent to you guys?
Because that would be really helpful for debugging for me XD
Johny.GOG
☕️
Johny.GOG Sorry, data for given user is currently unavailable. Please, try again later. View profile View wishlist Start conversation Invite to friends Invite to friends Accept invitation Accept invitation Pending invitation... Unblock chat GOG.com Team
Registered: Dec 2014
From Poland
Posted June 02, 2016
I've prepared a special script for your user ID. Nice new t-shirt you have there.
For example if my script (or BE) causes an error will it get sent to you guys?
Because that would be really helpful for debugging for me XD We'll get AF/BE errors only if they happen to be inside of angular's $apply or cause our code to crash. I was wondering one day to create a simple AF/BE detection and either ignore those, or send as additional info. ;) Didn't do it.
Johny.: You could just look into the network panel in your browser and see exactly what is sent where.
For now - aside of Google Analytics, there's only sending encountered JavaScript errors data. I've prepared one myself so I can attach it to this post.
adaliabooks: I'm curious... will it spot and report any errors on the page or just ones it's been asked to watch for? For now - aside of Google Analytics, there's only sending encountered JavaScript errors data. I've prepared one myself so I can attach it to this post.
For example if my script (or BE) causes an error will it get sent to you guys?
Because that would be really helpful for debugging for me XD
Post edited June 02, 2016 by Johny.
adaliabooks
"Vell, Zaphod's just zis guy, you know?"
adaliabooks Sorry, data for given user is currently unavailable. Please, try again later. View profile View wishlist Start conversation Invite to friends Invite to friends Accept invitation Accept invitation Pending invitation... Unblock chat Registered: Jun 2013
From United Kingdom
Posted June 02, 2016
Johny.: We'll get AF/BE errors only if they happen to be inside of angular's $apply or cause our code to crash. I was wondering one day to create a simple AF/BE detection and either ignore those, or send as additional info. ;) Didn't do it.
Ah. You might get a few of mine then, but not many. Usually I just call $apply or $evalAsync when I have already made changes to scope variable elsewhere.
I think there is the odd case where I have some code inside the call but not the bits likely to cause errors :)
adaliabooks
"Vell, Zaphod's just zis guy, you know?"
adaliabooks Sorry, data for given user is currently unavailable. Please, try again later. View profile View wishlist Start conversation Invite to friends Invite to friends Accept invitation Accept invitation Pending invitation... Unblock chat Registered: Jun 2013
From United Kingdom
Posted June 02, 2016
There is nothing wrong with being careful and blocking various scripts etc. as a matter of course if you don't know what they do or why they are there (and if blocking them does not effect your use of a website you should probably go right ahead), though I personally can't be bothered and don't care.
But in this specific case it can be (and has been) shown the script is not sending any personal data (yes they get your IP address and probably country of origin, but neither of those are really all that helpful) from Gog to Cloudfront. On top of that, I very much doubt that Amazon's terms of service for Cloudfront allow them to access and use the data from people who use their services (though I could be wrong, particularly if there is a free option as someone previously mentioned) so it's not Cloudfront who would have this data, it's Opbeat.
Are they going to sell that data (IP and country) on? Possibly, though I doubt it. What use is it to anyone?
They will probably be getting thousands, if not millions, of accesses to that script every day so to identify any one single user from that will be exceedingly difficult.
I have no particular issue with the general concept of what you're saying, just that it's not actually applicable to these specific circumstances. The script isn't sending personal data, it's not being used for data mining. It's being used to improve the website, for our benefit as end users.
But in this specific case it can be (and has been) shown the script is not sending any personal data (yes they get your IP address and probably country of origin, but neither of those are really all that helpful) from Gog to Cloudfront. On top of that, I very much doubt that Amazon's terms of service for Cloudfront allow them to access and use the data from people who use their services (though I could be wrong, particularly if there is a free option as someone previously mentioned) so it's not Cloudfront who would have this data, it's Opbeat.
Are they going to sell that data (IP and country) on? Possibly, though I doubt it. What use is it to anyone?
They will probably be getting thousands, if not millions, of accesses to that script every day so to identify any one single user from that will be exceedingly difficult.
I have no particular issue with the general concept of what you're saying, just that it's not actually applicable to these specific circumstances. The script isn't sending personal data, it's not being used for data mining. It's being used to improve the website, for our benefit as end users.
Lukaszmik
New User
Lukaszmik Sorry, data for given user is currently unavailable. Please, try again later. View profile View wishlist Start conversation Invite to friends Invite to friends Accept invitation Accept invitation Pending invitation... Unblock chat Registered: Jul 2011
From United States
Posted June 05, 2016
All the big data-miners are interested in one thing - getting as detailed profile of a specific user as possible. All in the name of "targeted advertisement," though it can end up being used for other things, too. Every single additional data point has the potential of making such record all the more accurate.
All the large names are constantly advertising open positions for statisticians and behavioral scientists. They are not just interested in "what you did," but are actively trying to work with the data available to determine "what you will do."
I hardly consider that a good thing, given the implications for the future (there is already a strong push for introduction of "pre-crime" punishment in the U.S.).
"Population control" is not a good thing, and whether the corps mean it or not they are working hard on making it possible.
So there is no chance of cloudfront script use being rolled back for now?
I looked at Amazon's policies. Their AWS privacy policy only protects the "content" (i.e. whatever scripts you are hosting with them), but not the data coming in or going out.
AWS is a subsidiary of Amazon.com, Inc. or its affiliates (“Amazon.com”). As a subsidiary of Amazon.com, AWS follows the same information practices as Amazon.com, and Account Information we collect is subject to the Amazon.com Privacy Notice. By visiting the AWS site, you are accepting the practices described in the Amazon.com Privacy Notice. Please note that, if you have an account on www.amazon.com and an Amazon.com cookie, Account Information gathered by AWS, may be correlated with any personally identifiable information that Amazon.com has and used by AWS and Amazon.com to improve the services we offer.
The "Amazon.com" policy is, basically, "All UR data R belong to us."
Computers make working with this kind of amount of traffic so easy...
All the large names are constantly advertising open positions for statisticians and behavioral scientists. They are not just interested in "what you did," but are actively trying to work with the data available to determine "what you will do."
I hardly consider that a good thing, given the implications for the future (there is already a strong push for introduction of "pre-crime" punishment in the U.S.).
"Population control" is not a good thing, and whether the corps mean it or not they are working hard on making it possible.
So there is no chance of cloudfront script use being rolled back for now?
adaliabooks: Are they going to sell that data (IP and country) on? Possibly, though I doubt it. What use is it to anyone?
If nothing else, it will let them know for certain somebody is very much interested in P.C. games. Depending on how the specific sub-page invokes the script, it probably even provides them with clear data on what specific title you are interested in at the moment. I looked at Amazon's policies. Their AWS privacy policy only protects the "content" (i.e. whatever scripts you are hosting with them), but not the data coming in or going out.
AWS is a subsidiary of Amazon.com, Inc. or its affiliates (“Amazon.com”). As a subsidiary of Amazon.com, AWS follows the same information practices as Amazon.com, and Account Information we collect is subject to the Amazon.com Privacy Notice. By visiting the AWS site, you are accepting the practices described in the Amazon.com Privacy Notice. Please note that, if you have an account on www.amazon.com and an Amazon.com cookie, Account Information gathered by AWS, may be correlated with any personally identifiable information that Amazon.com has and used by AWS and Amazon.com to improve the services we offer.
adaliabooks: They will probably be getting thousands, if not millions, of accesses to that script every day so to identify any one single user from that will be exceedingly difficult.
That's why all these companies are heavily investing into huge data warehouses and analytics development. And you can very easily identify a single user - in the core market (western countries) IPs are mostly static. For those who access the internet on a dynamic IP, you can easily narrow that down by looking up their IP provider (who are registered with specific IP ranges), and use software/hardware fingerprinting to determine if it's the same machine. Computers make working with this kind of amount of traffic so easy...
Johny.GOG
☕️
Johny.GOG Sorry, data for given user is currently unavailable. Please, try again later. View profile View wishlist Start conversation Invite to friends Invite to friends Accept invitation Accept invitation Pending invitation... Unblock chat GOG.com Team
Registered: Dec 2014
From Poland
Lukaszmik
New User
Lukaszmik Sorry, data for given user is currently unavailable. Please, try again later. View profile View wishlist Start conversation Invite to friends Invite to friends Accept invitation Accept invitation Pending invitation... Unblock chat Registered: Jul 2011
From United States
Posted June 07, 2016
Johny.: I never wrote that there is no chance - I wrote the opposite, but we don't want to remove things without thinking like crazy people. :P
btw - it's removed.
Credit where it's due - you actually completely surprised me with how fast this was taken care of. I was expecting a month at the least, if not "indefinitely working on it." btw - it's removed.
No Amazon anymore, Google is block-able, all is well :)
Thank you.