esailija

From the project root, copy the files in

`\WebKitLibraries\win\tools\vsprops`

Into `C:\tools\vsprops`

Worked for me.

Those are not the whitehat terms at all.

But that doesn't matter since the argument was ridiculous in the first place. If you cannot understand or read rules, that doesn't meant they don't apply to you. Also, he understands English very well.

Yes, I heard he is going to black market next. That's a good lesson I think.

Nowhere I saw good faith, just greed for money. He was even asking for money in the initial bug "reports". http://4.bp.blogspot.com/-4LbrTjyKBXc/Ug5sokeeR0I/AAAAAAAAAJ...

Even worse confusion is "reward" and I almost had a stroke before I realized it's not facebook. Facebook paying the reward would have been ridiculous since then everyone would know their whitehat tos doesn't mean shit.

Encouraging ignorance is even worse than encouraging malice :P

I think you are here: https://news.ycombinator.com/item?id=6231466 . And please don't bother defending, just dropping by.

Yes I fell into the "all languages" trap. Maybe "most mainstream languages" is more in line with what I meant. :P

That is a vague reply with no apparent relevance to anything I said except the amount $500 which was not to be taken literally. My point was that facebook isn't doing this to save money and believing so is idiotic.

The point is not to individually judge the harmful effects of using an exploit publicly. That would be absurd. You have no right to say that the video posted on the girl's facebook wall was not a big deal. And I have no right to say that it was a big deal. The only sensible thing is to disallow any public usage of exploits whatsoever.

It looks like preserving the integrity of their ToS to me. If you believe it is because of $500, you are a total idiot and I will not talk to you.

It is some link to a youtube video, posted to a public user's facebook wall through the exploit. That's what the screenshot shows.

I don't think you guys understand. You can't publicly use the exploit and then back away and use the white hat system after the fact. It clearly shows him spamming some profile before even making the first contact.

There is no such thing as an actual hoisting mechanism. Yes, declared functions are available anywhere in the surrounding scope, just like in any other language. It would be ridiculous if for example you couldn't call a method in Java inside another method unless it was syntactically placed before the target.

Global scope pollution is completely irrelevant here - declarations are available in the surrounding scope, not global. If the surrounding scope is global (which it never is in node.js), then that's your problem.

Where is the part that checks if the name was invalid and then asks again?

Yeah GUI widgets done in js in general for some reason have really poor quality and no attention to subtle details that make up the polished experience on desktop. Well at least they take 2 KB instead of 5 KB gzipped, that's totally a win.

And when the engine cannot do that for you, there is always Math.imul

Your entire complaint is very superficial and easy to fix with any convention you like. For example: http://jsfiddle.net/AXTdj/3/ I included "overhead" calculations.

This is the key. With good conventions and tools it is perfectly fine language. The concept of "Programming into one's language" from Code Complete applies strongly:

> Programmers who program "in" a language limit their thoughts to constructs that the language directly supports. If the language tools are primitive, the programmer's thoughts will also be primitive.

> Programmers who program "into" a language first decide what thoughts they want to express, and then they determine how to express those thoughts using the tools provided by their specific language.

I disagree with Coffeescript though, nothing will make that shit readable to me. :P

That is a really gross exaggeration.

jQuery only lost 10% of its size on full builds when it eliminated IE6-8.

There is still plenty of stuff left to handle. Naive code that only handles common success case is of course going to be small. Even if the modern browsers didn't have bugs and behaved exactly the same, you would still have most of the stuff there.

jQuery features amazing event model with endless corner cases and optimizations* handled, powerful ajax library (Think of stuff like prefilters and transports) and so on.

* For example your typical delegation implementation traverses the propagation path over and over again for each handler, while probably not even checking for simple selectors.

In both selector tests, the code calls `.html()` as well. It also uses a direct #id selector, I.E. does not "search the entire DOM" like it says.

Also, the code doesn't call into DOM directly but uses jQuery .html() for "reading" and .html(Math.random()) for "writing".

The case is extremely misrepresented indeed.

This is not a problem in e.g. PHP, out of the box it can embed json in script tags, with default settings you never get the sequence `</script>` (you get `<\/script>` instead) and it even escapes U+2028` and U+2029 which are syntax errors in Javascript string literals but not in JSON.

Enforced privacy is not as common as people think either, so you don't really even need to pull out the Smalltalk argument. In Java, C#, PHP etc it is not possible for the developer to actually enforce privacy like you can in JS because the privates are readily accessible through reflection if needed.

Another point is that the Javascript enforced privacy pattern only supports private, so 2 internal classes cannot get at each other even if they are maintained together as a package. That encourages creating god objects which is not surprisingly what I commonly see in projects that use enforced privacy in Javascript.

In the eyes of compliant parser (assuming JSON supported comments) it is just a comment like "_type": "int" is just a key-value pair.

However, when using ad hoc parser, then all bets are off what the result is in both cases again, not just the comment case. Regardless of comment support in JSON the same problem appears to exist.

Yes I get that. What I don't get is how "_processing_instruction": "whatever" is any different.

If JSON had comments, then of course any JSON parser could understand those comments just as well as they can currently understand "_type": "int". What am I missing?

Since this is usually downplayed because the "code is shared", to be more specific, for example in V8 in x64 (node.js, Google Chrome), the theoretical minimum memory used by a function object is 72 bytes:

- Map pointer: 8

- Properties pointer: 8

- Elements pointer: 8

- Code entry pointer: 8

- Initial Map/prototype pointer: 8

- SharedFunctionInfo pointer: 8

- Context pointer: 8

- Literals/Bindings pointer: 8

- Weak fields pointer: 8

So if you have a Person class with 30 methods, the methods are taking 30 * 72 = 2160 bytes at the very least. The actual data for a person might take 200 bytes, if we store e.g. full name, age and address so in this case there is like 10x overhead. If you print the details of 200 people per page request and there are 100 people connecting to your server, you are wasting 200 * 100 * 2160 =~ 40 megabytes on memory on storing all these useless function objects at that moment. That is just crazy.

And in GC language it's never just memory, a GC will eat exponentinally more CPU time when the amount of memory you use reaches closer and closer to limits.

Your code on the client side is merely a convenience for malicious advertisement code if accessible. How your client side code interacts with the server is what matters and the malicious code can do whatever your code can do with same privileges if you are including it on your page.

If you are running untrusted code in JS then real private methods have only given you a very false sense of security. You should have run it in a sandboxed process instead.

What is meant by true/enforced privacy is that the only way to access something is to modify the original source. This is not the default anywhere else, as you know, but is encouraged by some (Crockford for example) in Javascript.

Enforced/True privacy is very bad, and the badness is multiplied by the fact that in Javascript it cannot be fine-tuned so when you are making it private for random application code, you are also making it private for other internal classes.

Those warnings are not part of the language, and can be done with underscore prefixed Javascript too in your build step, a fine example of programming into one's language.

The cookie scenario is not really practical since you can prevent javascript from reading cookies with httponly and I could bet a lot google uses httponly cookies where it matters.

The real threats I imagine is social engineering it enables or running code on the users' machines through browser plugin vulnerabilities. Also, running signed Java with a fake certificate is just a dialog confirmation from the user.

But I agree on your other point.