Funny that you mention "storage vendors". In Germany we have to pay a fee as compensation on storage like USB sticks, because it is potentially used to store copyright material. It's outrageous.
Finland had a similar tax before. At least here the purpose of the tax was to offset the loss of income incurred from (perfectly legal) private copying (i.e. making copies for yourself or your close friends). In this sense our tax did not excuse piracy.
On the other hand one might not agree to offsetting costs from legal copying and use the tax as an excuse for piracy anyway.
Well, if the copying is legal, then noone deserves to be compesated for it, obviously.
Furthermore, I don't even agree with offsetting costs from illegal copying (since there are no provable costs), hence my moral interpretation of the tax.
The storage device is where the copy of the copyrighted media resides. The CPU, speakers, headphones, video display, RAM, etc. are all transitory in their involvement of piracy; but the hard drive/USB stick is "where" the violation is taking place.
Again, devil's advocate here! This is mostly a thought exercise.
Some media companies have tried to sue switch makers over the fact that their switches temporarily hold copies of the sent media in their cache without a license.
It is the same in Russia. But does it implicate that, according to No-double-pay-for-one-service principle we can legally pirate stuff and store it on our storage drives?
Am I stupid or is this guy calling a XSS "Arbitrary Code Execution"?
It also seems to be a self-xss (a XSS on his account profile, which only he can see).
How can you write so much text and be unclear about what you are doing? No wonder Paypal didn't understand anything.
My understanding is that the author is saying they are able to do arbitrary code execution on Paypal's servers (at least the ones hosting their help center). If I understand correctly, one could upload executable code to certain profile fields in one's developer account and then get their help center to execute those.
I suppose the criticality of that would depend on what all was hosted on their help center server as well as what other servers one could gain access to via it.
Indeed this is one of the most verbose and rambling exploit descriptions I've seen... apparently you can inject some script/HTML code into a field in your profile, but I don't see how that could lead to this:
but can also remotly execute arbitrary codes to access local web-server files or configs
Imo it's a very good thing that they have to spend a lot of time researching. Along the way they will see and learn many different things and in the end provides experience. Thus I agree with _almosnow.
It's been proven that spending more than 45mins searching for a solution damages learning. That what developer bootcamps are based on. (I'll see if I can dig out research on it).
That it's so interesting. A lot of people said that to me. But to me it felt more natural to highlight old code. Probably because I had this bias in the back of my mind that old code could be bad code.
In my experience, it's often the new/changed code that is the most interesting. It's often the code that is causing some unexpected bug. 'No one sews a patch of unshrunk cloth on an old garment. Otherwise, the new patch pulls away from the old cloth, and a worse tear is made'
Physical things often become darker with age due to dirt or corrosion. Examples are wood and metal, or an old vs. a new wall painted in the same color. They all become darker over time. Therefore I think it't more intuitive to think of darker things as older.
I didn't want to make it look that way. The color indication is without any judgment. It's just interesting how code evolved over time. In fact you should reverse the color gradient or use different colours, so you can read code how you prefer it.
Yeah, I didn't really see this post as reading into it one way or the other. I was more just broadcasting how I don't know what to make of the age of code.
More, I think context plays a big role and it is difficult to see what new is brought to the table at times. Worse, what old was accidentally discarded?
The CAPTCHA example is incomplete. It is missing the part that actually makes it difficult for robots to solve. The purpose of the example was to provide a list of ways to implement an effective CAPTCHA.
I am not the author of G-WAN. I am not claiming to have done anything.
This whole thread is based on a misunderstanding. G-WAN does not have any CAPTCHA support. The example merely demonstrates how to use G-WAN's image generation API.
The CAPTCHA example is not meant to be used without modification in an application. CAPTCHAs are not a feature of G-WAN.
No where did anyone claim to have invented stateful web applications.
I do not have an example handy, so hopefully an explanation is enough.
The CAPTCHA example has two parts: generating the CAPTCHA values and presenting them in a way that is easy for humans to solve, but difficult for computers.
This example only implements part one, but gives some methods of how one could implement part two. This is why it is so easy for you to write a script to solve it.
Using mouse cursor hovering, one could change the background color behind the image based on an event (such as a mouseover of an input field) that is probable for a human to make, but less so for a computer. This is difficult for a computer to solve, but not impossible to break.
G-WAN applications are persistent, meaning it is trivial to record stateless actions the client has made in the past for use in the future. The client would have to provide a known good value from the past in order to solve the CAPTCHA. This is what is meant by "previous state or shared secret".
> Using mouse cursor hovering, one could change the background color behind the image based on an event (such as a mouseover of an input field) that is probable for a human to make, but less so for a computer. This is difficult for a computer to solve, but not impossible to break.
How would this reveal the CAPTCHA value to a human but not to a computer? If the string is readable over only some background colors, then it's written on a transparent-backed image, so the whole background-changing script can be ignored. Just OCR the image with the transparent background.
If you're suggesting the CAPTCHA itself be the movement of the mouse over specific inputs, rather than deciphering a string, then this is trivial to break as well. The code that watches the mouse events and does whatever it does to indicate human-ness has to be written in JavaScript and transmitted to the browser... which means it's sitting right there to be analyzed and copied by the bot author. They don't need to replicate the mouse movement, just trigger the same code the correct movement triggers.
Requiring previous state adds nothing to the test either. If a human has to visit a certain sequence of pages before submitting a form, the bot can make the same sequence of HTTP requests and replay the same cookies or however you track the state.
It doesn't sound like you know what you're talking about.
> If the string is readable over only some background colors, then it's written on a transparent-backed image, so the whole background-changing script can be ignored. Just OCR the image with the transparent background.
The CAPTCHA image contains false values for misdirection, hence the requirement of running the background changing script.
Here is a list of claims made on the example CAPTCHA page:
BG Ability
color to
generation solve (as defined by the author)
---------- ---------
mouse cursor hovering difficult
previous state impossible
input
shared secret
I have no way to know precisely what the author means by those words since the given example does not demonstrate any of them. I cannot match the left and right columns.
For example, if I claimed that a CAPTCHA based off a "shared secret" only a trusted user has is impossible to solve, then one might ask the question, "Why is a CAPTCHA needed for a trusted user?". Is this what the author of the CAPTCHA example meant? I do not know.
My only purpose of posting in this thread was to show that the OP's premise that "this is the best example of how not to implement it." is flawed because no such example was given in the first place.
Nothing about that sounds unique from existing CAPTCHA systems, nor does it sound hard to break. You're going to use CSS or Javascript to "hide" it from a computer? That uhm, doesn't make much sense (to me).
Not to mention something like Sikkuli (in JPython) can actually make your mouse hover and record values...
Plus how is that easy for humans to solve?
1. They need to know they can put their mouse over the text
2. Then record the text
3. Sum the numbers
4. Write the result...
If I had to do this every time I wanted to login to a site I'd seriously consider switching. And this is the 'best' captcha impossible to break - for humans. Machines can solve it easily.
http://www.geek.com/news/germany-increases-usb-flash-drive-t...