No I don't agree that it should be allowed to continue, but how is naming&shaming people going to fix anything? Nothing is going to come of this, other than maybe some other hackers will see them as weak targets. Do you expect this list to be read on prime time CNN or something? People who want to buy something online aren't going to search through GitLab to check if the site has been hacked (maybe they should though), they just look for the green padlock and assume it's safe.

As I said, and GitLab suggested, OP should at least contact them. If you contact them and they say they won't do anything, now that's a different story...

> So far, between Oct 10 and Oct 14, 631 stores have been fixed. [0]

So it sounds like does a pretty good job of fixing things

[0] https://gwillem.gitlab.io/2016/10/14/github-censored-researc...

> No I don't agree that it should be allowed to continue, but how is naming&shaming people going to fix anything?

Someone will make a browser extension that uses this list to warn users?

Well, from the responses he's got it's pretty obvious some shop owners just don't care. I can imagine if they're being publicly shamed about it, they might start caring and actually do something about it. So yeah, it helps.

Sites will always continue to carry malware. Naming and shaming without looking at all the parties involved is a crude and ineffective way of changing things.

Change the browser, change the payment system, educate the user by using plugins, propose enhanced security methods in ECMAscript. Write about how easy it is to make missteps on the net. These are all alternatives which might help in a more permanent fashion.

That's like saying "corruption will always exist, investigative journalism is crude and ineffective - instead educate people to spot corruption and live with better morals".

There's nothing ineffective about uncovering a problem and using transparency to create an incentive to fix it. Crude, yes, but not ineffective at all.

What GL did might be considered complicit in skimming users, especially if they acted under pressure from fraudulent shops or even the skimmers themselves (how do we know?).

Did you even bother to read the article before commenting?

There is nothing a client can do when the server is compromised.

Actually, yes, I did read the article. When I read 'Javascript malware', I understand this to be ECMAScript which is executing on the clients machine but delivered by the origin site. The ECMAscript has access to the keyboard while the window has focus, so could do a MITM. Like I said, there are various ways to prevent this from happening:

1. Instruct users never to enter card details directly into a website, but rely on a redirect to the card provider. This would change the origin. When properly setup, this should catch 99% of the problems.

2. Provide stricter browser controls, so third-party ECMAscript is not loaded into the browser by CORS. Again, instruct the user or have us make better browsers.

3. Lobby for better payment services. Here in the Netherlands, payment is done using iDEAL, on a separate origin (using redirects) and the payment is validated using a separate device.

The secondary problem is with the websites, the primary problem is with the supporting technology.