News for hackers. Stuff that matters.
Re:GitHub censored my research data by edejong on Saturday October 15, 2016 @03:28AM (#12713105)
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.

Re:GitHub censored my research data by lazyjones on Saturday October 15, 2016 @07:31AM (#12713596)
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?).

Re:GitHub censored my research data by premium-concern on Saturday October 15, 2016 @05:41AM (#12713400)
Did you even bother to read the article before commenting?

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

Re:GitHub censored my research data by edejong on Sunday October 16, 2016 @10:34AM (#12718762)
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.