Enabling that NoScript option is not as good an option for 2 reasons. First it will impart my trust of GOG to all third party sites that GOG uses, not something I'm willing to do. Secondly it is a global option so any site I allow scripts automatically allows all their 3rd party sites. So, in my view, that option is worst than simply allowing cloudfront.net to start with.

There are two things I value more than DRM free software, Security and Privacy, and allowing scripts from cloudfront or any other sites weakens both of those primary values. Therefore I am faced with a decision, either risk using unknown sites where I don't know the core values and motivation of the companies behind them, or using a broken web site. While the former may win occasionally I don't see that happening often and certainly not for impulse purchases. I can imagine that over time I will be questioning more and more why I keep visiting a broken site - a shame as there have been some releases over the last few days that have peaked my curiosity.

it appears to be IE 9

That's a violent crime.

Just an aside I jammed the shitty JS into Greasemonkey, which I'm already using. A bit half-assed but...

Well, I suppose you could say that technically it can, but, as you obviously know, you require some kind of user interaction, usually from the less Internet savvy ones. :-)

EDIT: Sorry, just a silly observation of mine -- having a beer, scanning through the GOG threads in general! :-)

People who have limited (or no) understanding of modern web security... *SCNR* ;-P

That's right. But JavaScript can be used to detect vulnerabilities in the browser or browser's plugins.

A few weeks ago NYT, BBC, MSN, AOL were affected by malicious ads, injecting code via JS:
http://blog.trendmicro.com/trendlabs-security-intelligence/malvertising-campaign-in-us-leads-to-angler-exploit-kitbedep/


But more important: as a good dev please include your tracking code in a way that it doesn't crash the whole website if it can't be loaded.

While having Firefox's tracking protection enabled it will do so (JS enabled, FF46.0.1). Entry from the console:
> The resource at "https://d3tvtfb6518e3e.cloudfront.net/2/angular-opbeat.min.js" was blocked because tracking protection is enabled.

There is (imho) a good example how to implement GA without breaking functionality when for some reason (like DNT) a third-party service is not available:
https://hacks.mozilla.org/2016/01/google-analytics-privacy-and-event-tracking/

Please consider privacy and DNT as "not evil" :)

I'm not sure that's right.

You could have an HTML/JavaScript button (e.g. labelled "I'm not a robot") that when clicked writes a file to the disk. The contents of that file could be anything.

I agree you need the user to approve it, but if you open a nice file selection window, I don't see a reason why at least some users will not approve it.

And the file can be anywhere the user wishes it to be.

See for example, MaGog's "Export My Data" button, which allows the user to save his MaGog data anywhere he wishes. And the contents of that file could be anything MaGog wishes it to be (don't worry, it's not malware -- it's just a text file, but that's because MaGog is good, not evil).

In my case it would show the save-as-dialog, but with the default auto-save this could work.
From there you need to find a way to load/execute that file which requires further steps/exploits.

Worst thing I read in the last days was loading an Linux ELF executable:
https://www.bluecoat.com/security-blog/2016-04-25/android-exploit-delivers-dogspectus-ransomware

I agree, but you don't even have to find a way to execute it. Just writing a 500GB inert text file can be pretty malware by itself.

At least this way the machine wouldn't end in a botnet or steal user credentials :)

Nevertheless, in my opinion it was a bad move to include scripts from 3rd party domains in the first place.
At first the crappy Google captcha and now a dubious cloudfront.net script. Don't blame users for best practise not allowing all scripts, but start to do the same. It's also not very comforting to tell us, that it's "HTTP only" by the way.

And since we're already talking about security and best practise, GOG's login is far from it. Giving the user direct feedback about the correctness of the entered e-mail is very bad design. The "User not found" message is almost made for abuse. Via try and error, one could verify actual e-mail addresses of GOG users! (even with the captcha)
Why don't you just say wrong data, when either the password or the e-mail address is wrong. It would solve the issue immediately and is common standard.

I had this problem for a few days. None of the images would load and I couldn't even open the menu. Of course, the main site loads improperly in Dolphin (with Jetpack, at least) anyhow, as do a few others. In Firefox for Android, it works mostly ok, but the main page is as wide as the headline images, so when you scroll them, it scrolls the whole page. But hey, small inconveniences for being able to look at and access the site wherever I go.