othermaciej

Safari on OS X has some good mitigation a these days, such as running the web content in a separate sandboxed process, which Friefox does not do. I suspect attackers either failed to find or did not want to burn their WebProcess sandbox escape.

Getting sandbox escapes from Mac Safari and iOS Safari requires completely different exploits. The code execution stage of a complete exploit could be shared, but it could also be shared with Chrome. So you'd think the same argument of iOS Safari exploit market value would apply either way.

My theory is that not much research has been done yet on breaking the WebProcess sandbox. Which makes me sad.

WebKit code execution against Chrome is also likely to work (in modified form, but same basic exploit) against desktop or mobile Safari. Desktop Safari sandbox escape is likely to be completely different from MobileSafari sandbox escape. And in all three cases, the sandbox escape is the harder part.

So that logic does not explain to me why people are going after Chrome but not Safari.

I honestly don't know why it is. In particular, I don't have specific reason to believe Mac Safari's sandbox is more bulletproof than Windows Chrome's, but I guess Safari has the advantage of not being exposed to Windows kernel bugs.

Safari's desktop share is somewhere between 5.5% and 15.5% depending on whose stats you trust:

http://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Sta...

Is it crazy to consider that significant?

"All"? Not Safari yet (knock on wood). Which is a big change from back in the day when it was usually pwned first in this contest. Or are you saying it's not a major browser?

Typically you get a much smaller number of RSUs than options. Though there's no strike price. So RSUs are often worth more if the stock doesn't move much, but worth a lot less if there is a huge run-up.

iOS and Android are successful because they offer a great selection of powerful APIs, not because of the particular binary representation they use for applications.

NaCl actually offers crappier APIs than the Web platform, and it runs in a box where it can't directly manipulate the real Web APIs. asm.js is intriguing because it offers a very natural path to a foreign function interface to all the stuff exposed to JS.

We've tried this experiment - it's called XHTML. For a long time, adoption by authors of the strict error handling it offered was stymied by lack of support in MSIE. So it's not a full counter-factual. However, we have learned two things:

(1) Now that MSIE does support true XML parsing of XHTML, almost no one is choosing to use it over HTML.

(2) Of the few experts who conditionally served either text/html or application/xhtml+xml depending on the UA, or serve XML unconditionally now, almost all have bugs in their sites which can get them to produce ill-formed XML which then shows an error page in the browser (for instance, submitting comments with certain sorts of errors). This is evidence that the draconian error handling approach is too challenging even for experts and imposes the costs of small mistakes on users.

This post, if you read it to the end, doesn't reject the principle of being liberal in what you accept. Rather, it proposes being liberal in a formally specified an interoperable way - i.e. specs should explicitly define behavior for all inputs, including any error correction.

HTML5 takes this path with its parsing algorithm, and in fact is cited as an example in the post. However, the designers of the parsing algorithm saw it as being an application of Postel's Principle, rather than an example of the opposite.

The post is really more nuanced than it sounds and would better be titled "Specifications Should Define How to be Liberal in What You Accept".

It was an overly subtle joke, took me a while to get it myself.

In your previous comments you wrote: "The owners of the hotel were warned repeatedly by local law enforcement and an intervention of local hotel owners; specific measures were suggested to minimize the problems at this place and weren't taken". But the judge's opinion says pretty much the exact opposite.

I respect your long track record of commenting constructively on HN. But as far as this specific case goes, I think readers would do well to be skeptical of your confident-sounding pronouncements.

I think it's a joke - "Wilt" and "Wither" both being opposites of "Bloom".

Prof. Kerr doesn't explicitly mention it, but this amended version of the statute would likely have made Aaron Swarz's conduct in the MIT/JSTOR case not chargeable as a felony by removing or raising the bar for many of the felony enhancements. (The federal definition of a felony is a crime that carries a maximum penalty of more than a year so this is a little obscure.)

It would likely restore sanity to many other questions of computer crime law as well by requiring circumvention of a technological measure to count as unauthorized access, rather than merely exceeding the TOS.

Supporting reforms like this seems like a potentially very meaningful way to channel the anger at Aaron's treatment.

This article didn't actually give useful information on how to make trillions of dollars or on how anyone else has done so.

Offenses involving contraband or smuggling are usually strict liability offenses, so mens rea is irrelevant in most such cases.

Even granting applicability of mens rea / actus reus analysis here, I believe your analysis is wrong. It's true that attempting to do something actually illegal and failing is often still an offense (usually of the "attempted" variety), but incorrectly believing that what you intend to do is a crime, when it actually isn't, does not automatically make that act criminal. For example, if you think jaywalking is a crime in a jurisdiction where there is no law against it, that will not in itself render your jaywalking criminal. That would be an absurd result.

Yes, "almost never" - it's rare enough that it makes the news when it happens.

The action that should be taken based on the fact that wage stickiness causes unemployment is at minimum to avoid making them more sticky, e.g. by regulating wage cuts as if they are "monopoly abuse".

> In short "you take a 5% cut in pay or I fire you and hire > the next person who walks in that door." It doesn't even > need to be said: "you will take a 5% cut in pay" implies "or > you'll have to quit and find another job."

In practice this almost never happens. Employers are very reluctant to cut nominal wages, even if they could afford to hire more workers that way and get a more economically efficient outcome. This phenomenon is called "sticky wages" and is believed to be a significant cause of unemployment in recessions.

In summary, the relationship between unemployment and labor pricing power is believed, by many economists (most notably Keynsians but also e.g. market monetarists) to be about the opposite of what you said - stickiness of wages causes greater unemployment, rather than unemployment causing downward pressure on wages.

If you look at the graph with the longer time horizon, you can see that Estonia, Lithuania and Latvia had stronger growth pre-crisis, a bigger bubble, a bigger collapse from the bubble, and a stronger recovery from the performance trough. Only by measuring by performance from their GDP peak do they look bad, and it's not obvious why this is the natural measure of recovery policies. You would think performance from the trough of the crisis or from some neutral pre-crisis point would be more relevant.

Here is another article with more graphs explaining this point: http://blogs.cfr.org/geographics/2012/07/02/postcrisis/ -- though you will find some debate in the comments.

I don't think we have entered the long term yet, so how can you so confidently say what the long term effects are?

Iceland is much smaller than either, yet it is the poster child for this thread.

Using 2007 as the starting year for Latvia and Estonia is kind of cherry picking. See here: http://marginalrevolution.com/marginalrevolution/2012/07/the...

Note that the MR post is polite and humble, and gives fair consideration to both sides of the issue, unlike just about anything written by a certain ny times columnist.

Estonia and Latvia are doing pretty well with austerity: <http://www.businessweek.com/articles/2012-07-19/krugmenistan...;

It's understandable that regular readers of Krugman may not know this since he goes to great pains to deny the obvious on this point.

I tentatively don't agree with your Rindler horizon analysis. Inside an inertial frame, you don't see the Rindler horizon, because only the accelerating observer can see it. If you are in the accelerating frame of the observer, the apparent position of the Rindler horizon will vary, depending on your position, so you can't actually cross it; but in any case you are not in an inertial frame. Physical laws that hold in any inertial frame do not necessarily have to hold when observing from a non-inertial frame (for example ability to signal between any two points).

At this point, my understanding of physics gets hazy so I'm not sure how much this extrapolates to the black hole case.

The "AR" in "AR-15" stands for "ArmaLite", the original manufacturer, not for "Assault Rifle". An AR-15 is not actually an assault rifle, which implies the capability of fully automatic fire (pull the trigger, spray bullets). The AR-15 is semi-automatic (one shot per trigger pull, but with no manual action required to reload).

http://en.wikipedia.org/wiki/AR-15

The post you linked actually does look like crackpottery, and your endorsement of it looks like crackpottery too. Highlighting how your point of view is suppressed by mainstream science just makes it seem more like crackpottery.

The basic mistake in this whole argument is that there is no such thing as an inertial frame or near-inertial frame that crosses an event horizon. An inertial frame outside the event horizon will appear to be fully outside it from within the frame, even if extended.

Event horizons can exist in GR even without black holes, for example, an accelerating observer sees an apparent horizon or Rindler horizon, where signals beyond it will never reach him.

But there is no near-inertial frame that, from within the frame itself, appears to cross the Rindler horizon.

You are technically correct, the best kind of correct! But I think we both agree there is absolutely no sense in which anything in browser engines is UCS-2, and that browsers will not in fact replace characters beyond the BMP with the replacement glyph, as the top-level comment claimed. It is kind of embarassing that the top rated comment (as of writing) but says completely false things.

Safari uses UTF-16, not UCS-2. I believe this is true of other browsers as well. Otherwise this would render the replacement char, but it doesn't, it renders correctly:

javascript:var x = '𝌆';document.write(x);

What's complex about the design? The main page seems brutally simple compared to Google or Bing. And the search results pages do not seem to have more interactable elements than Google/Bing. What is your metric of simplicity here?

Your one example is use of the color red, which may be an issue of taste or branding but not really simplicity. (And there are reasonably popular sites with very prominent red elements, like cnn.com)

His argument would apply to tablets, where Windows 8 does run, about equally well.

MPEG-LA? No. But MPEG itself is working on a royalty-free profile of AVC called WebVC: <http://mpeg.chiariglione.org/meetings/geneva11-1/geneva_pres.... That may not have happened without VP8.

Wow, I didn't notice that the thread continued for so long after I posted.

The things you cite are pretty much all because I would never give 0% probability to a future event. Who knows? Things change. But I think it is quite unlikely that NaCl will become a widely accepted part of the Web platform, and I think that would be a bad thing in its current state.

My "highly pragmatic and specific" criticisms seem to me like they say the same thing as Brendan's original slide bullets, just with more detail. I did not mention "no view source", but I agree that is a significant downside, if not necessarily as much of a showstopper as the others. Being a single-vendor-controlled technology is the biggest showstopper.

Another big issue that I didn't mention, and which I think also aligns with Brendan's criticisms, is that adding a major new technology to the web platform requires tremendously compelling use cases and a good argument that they cannot be handled with existing technologies. I don't think that case has really been made for NaCl.

And yes, I did jokingly coin the term "ActiveG" to refer to NaCl. Though I believe it was another wag who later referred to Dart as "GBScript".