Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

Comment Re:Wait a mintue (Score 1) 272

No, but that's not really the point (actually, all of the others have added additional security features, but they all had sandboxing last year). The point is that Firefox does not implement the core mechanisms for security that the others all had last year (and, mostly, the year before and the year before that too). This makes is uninteresting as a target.

Comment Re:Wait a mintue (Score 1) 272

This is a reliability measure, not a security measure. The process that plugins run with is not sandboxed and runs with ambient authority. It can read every file in the user's home directory and can open arbitrary network connections. If Flash crashes, then it won't crash Firefox (which is a good thing), but if Flash is compromised then it's exactly the same as if Firefox were compromised. In contrast, if Flash is compromised in Safari or Chrome, the attacker has access to a process running with very restricted privileges and an IPC channel to the browser. To do anything useful, the attacker must use the IPC channel to compromise the sandboxed renderer process, then do the same thing again (though likely with a different vulnerability) to compromise the main browser process (the one that runs with ambient authority). You need, at a minimum, three exploits: one in Flash and two in the browser, to get from a malicious Flash app to a user-level compromise in Chrome or Safari. With Firefox, you need just the first one to do the same amount of damage.

Comment Re:What? (Score 1) 272

Now look at the entitlements for that process. It runs without any sandboxing. A crash in the plugin won't crash the browser, but a compromise of that plugin will give enough privileges to attach a debugger to the main process (on OS X the system will prompt for this, because it looks suspicious, but it can still open arbitrary network connections and read every file in your home directory). Reliability and security often have similar mechanisms, but don't confuse one for the other.

Comment Re:Gas (Score 1) 60

OPEC has been surprisingly stable compared to historic cartels, largely due to the Saudi dominance and willingness to bear the brunt when the inevitable cheating occurred.

They're playing a different game now, though: that shale isn't going away, and the price of producing it is a ceiling on the cartel price.

*All* cartels eventually end by cheating; some just get there faster than others . . .

(And the *real* key to the Debars cartel was somehow convincing people that the least desirable gemstone, the plain white wine, was the most desirable and only thing to put in an engagement ring . . . before that, diamonds were *less* valuable than rubies, sapphires, etc. . . .)

hawk

Comment Meh.. (Score 1) 294

One thing is that thought has been brout up for over a hundred years now. Thus far it has not been true. One day it might be, but hard to say when. Historically we've managed to develop ambitions to offset the reduction of needed labor of a new advance. We generally couldn't have foreseen how that was going to go down until it happened, so not knowing what that would look like doesn't mean we are at the end of the road.

The real problem is perceiving a world where we need people to work half as hard as they do today a 'threat'. That people should be able to have education, sustenance, shelter, and medicine without worry throughout their lifetime is not something to be avoided, but to be embraced. A number of people worry that people are wired such that this would be devastating to their psyche, and yet people retire all the time, go through college without fretting so much. Yes, once you get into a career you get caught up in it, but spending a good few months away can fix that.

Of course there's also the issue of fairness in a world that is 'partially' post scarcity. If you generally don't need most people to work, but desperately need some of them to, it can be tricky. To some extent reduced hours can alleviate, but some tasks don't lend themselves to such a strategy, and you can only have so-short of time frames for people to work (if you needed 5 minutes of work a week out of the average person, it'd be awkward and highly inefficient to work just for 5 minutes).

Comment Enough with the AI and the sex robots already (Score 2) 294

We have been promised AI was just around the corner since the 50s and the 60s.

Show me even one system that is able to match human beings in creativity and resourcefulness. No, Deep Blue does not count: playing chess, or even go, is not the same as creating the LIGO experiment.

We have been promised sex robots for years now. All this time, Google has been struggling to make self-driving cars.

Don't believe me? Google "google self-driving cars shortcomings"... Turns out even the mighty Googleplex cannot make self-driving cars that handle, say, a bit of rain and snow. Or potholes and unexpected construction works.

And we are talking about cars, where the level of tolerance is about, say 15cm to 20cm.

Sex robots should be able to handle facial recognition, tolerance of a centimeter at best, a couple of millimeters at worst, not to mention level of... er... interaction that are way beyond even the most advanced stuff we have in labs now. And I don't want to imagine patching sex robots for the latest security exploits, when the "Internet of Things"(Gosh, I hate that fscking market-speak) is the cesspit of horrors it is right now.

Oh, and just imagine the bedlam if confidentiality of sex-robot ordering is breached, Ashley-Madison style...

Sure AI, or at least neural networks and expert systems, may replace a lot of white-collar jobs, and good ridance to them (Lawyers and Bankers, especially, better brace for a richly-deserved comeuppance). But HAL is definitely not in our future. And no sex robots either.

Feel free to mod me down now.

Comment Re:Gas (Score 1) 60

But you see, it isn't even "oversupply."

Rather, it's "decreasing but not eliminating the artificial supply constraint."

Even today's prices are higher than they would be without the cartel.

That said, the world changed with the Saudi policy of letting prices go below our production cost.

Oh, dear, they'll sell us their oil for less than it costs to produce our own. I'm terrified.

And don't throw me in the briar patch, either . . .

hawk

Comment Re:Devices should be de-brickable (Score 1) 160

Yes, yes, that's all very clever of you, except for the fact that iPhones do have that. You can reset the firmware, or all the internal storage, from a plugged-in computer. Almost every single byte of internal flash can be rewritten by Apple, or, hell, by an end user with iTunes. (I think the only parts that can't be overwritten are the parts that allow the phone to enter recovery.)

These 'bricked' phones? They enter recovery mode just fine, and all their internal memory can be rewritten just fine. Everything works fine there.

The problem here is that the current time, of course, is not part of a system recovery, because the damn current time is not saved to the phone's flash memory. How would that even work?

The clock in an iPhone operates the same way the clock in a PC operates, in a separate very low-power clock-tracking chip that runs off a battery. (Which in this case is the device battery.) There is absolutely no way to alter this from outside the device, and, really, no device has even needed such an ability before. iOS just has a really stupid bug.

And the way the iPhone is designed does not allow easy removal of the battery, which, really, is the problem here. If Android had this problem, it would be laughed off, 'Just unplug the battery, that will fix it'. But you can't do that with an iPhone.

I suspect that, within days, Apple will have produced a iOS update that can be put on the device (Even after it has been 'bricked'.) that either checks the time and fixes it, or just doesn't have whatever bug is causing this in the first place. (In fact, it should be possible to put a tiny image on there whose sole purpose is to change the clock, and then put the *original* image back.)

Comment They can still be useful (Score 1) 278

Pagers tend to have better reception than cell phones, at least fairly recently when I last looked this up for my own curiosity. Also, many paging companies have "TAP" servers that you can dial into with a modem to send pages. This is could make a nice last-resort fallback for when a data center has lost network access and you can still provide outbound alerting via a backup landline.

Comment Why is the splash screen cyan? (Score 1) 98

It seems like emulated old versions of Windows end up with cyan where they're supposed to be white, and it's been this way for ages. I used to run Win 3.1 under PC-Task on my Amiga to handle one specific business app, and the splash screens even back then were cyan instead of white. That's still true in my browser just now when I launched a couple of the article's emulators. Why would that be? Is there some bug in ancient VGA hardware that Windows exploited to render white instead of greenish-blue?

Comment Re:This is a big bitchslap to Mozilla (Score 3, Interesting) 272

OTOH, Xen has long touted its security focus and has a really tiny attack surface so I'm happy to be using that in Qubes OS as well.

Excuse me? Xen had more than 100 security alerts in 2015, some extremely severe.

And Xen is based on qemu, which has been proved to be fairly insecure in its own right.

Using Qubes OS, which is based on Xen, which is based on qemu is... How to put it mildly? Maybe not the best idea if you are security conscious.

In the words of Theo De Raadt: "You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes."

I agree with him. It's turtles all the way down.

Comment Re:Wait a mintue (Score 4, Informative) 272

The former. All modern browsers except Firefox have decomposed their browser into multiple processes, so that a compromise from one site will only gain control over an unprivileged (i.e. isolated from other stuff the user cares about) process. They also run plugins in separate processes and have fairly narrow communication paths between them. Firefox is still a massive monolithic process, including all add-ons, plugins, and so on.

This basically means that you just need one arbitrary code execution vulnerability in Firefox and it's game over. In contrast, if you have the same in Chrome, Edge, or Safari, then it's just the first step - you now have an environment where you can run arbitrary exploit code, but you can't make (most) system calls and you have to find another exploit to escape from the sandbox. Typical Chrome compromises are the result of chaining half a dozen vulnerabilities together.

Comment Re:This is a big bitchslap to Mozilla (Score 4, Interesting) 272

It also scales based on processor resources. They hit serious TLB scalability issues at around 17 processes (varies a bit between CPUs, in some systems - particularly mobile - you'll hit RAM limits sooner), so if you have more tabs open than this, you will start having multiple independent sites share the same renderer process.

Slashdot Top Deals

Established technology tends to persist in the face of new technology. -- G. Blaauw, one of the designers of System 360

Working...