I don't buy the argument that we should be expected to spend the money up-front to guard against storms that big.
You're missing the point, which is that the badly maintained canal made the situation worse than it would have been had the canal never been built (at which point nobody would have lived in the area in question because it would _always_ flood). People would have been better off if they had done nothing at all, but that's not what they did.
Is it just me, or does this sound like RISC fanboyism from the 1990s? The "advantages" of RISC are not nearly so clear these days. Indeed, it is getting rather hard to find real RISC chips. While there are chips based on RISC ISA idea (like being load/store and such), they are not RISC. RISC is about having few instructions and instructions that are simple and only do one thing. Those concepts are pretty much thrown out when you start having SIMD units on the chip and such.
I wouldn't say that's what RISC was about at all; the basic idea was to have only instructions that could be implemented using a few simple pipeline stages. This is a substantial improvement over the microcoded architectures that were prevalent prior to RISC, because it can be much more easily pipelined (or, indeed, pipelined at all). I don't see SIMD as incompatible with RISC in any fashion; it just happens that the instruction operates on very wide data, but it's still a relatively simple instruction that should be able to complete quite quickly.
These days complex processors are the norm. They have special instructions for special things and that seems to work well. RISC is just not very common, even in systems with a RISC heritage.
I'd say it's more the other way around. Even in systems with a CISC ISA (e.g. x86), you tend to find that under the hood the CISC instructions are translated into a series of microops that are then dispatched in a system that is somewhat RISC-like. The most common processor family in the world is the ARM family, and all of those processors subscribe pretty well to the original principles of RISC, from instruction set to internal design of the processor core.
All of these are much more faithful to the principles of RISC than the chip described in TFA, whose instruction performs two memory accesses on each execution -- note that the removal of such instructions and consequent simplification of the execution pipeline (by having only a single pipleline stage that could access memory) was the original motivation behind RISC architectures.
Unless there simply isn't, e.g., a signed telnetd package, you don't need undiscovered vulnerabilities for this to be a potential for major problems.
Installing telnetd doesn't make it run; you'd have to add it to inetd or run it manually, either of which require logging in as root.
Installing software is rarely an issue, it's only running it. Stuff that installs setuid root needs careful examination, but there's little enough of that that I'd guess they've audited it quite thoroughly over the years...
Give me the most highly rated Zinfandel and I probably would give a pretty low reguard compaired to a more moderately rated Shiraz, the same goes for region, I personally think the highest quality Australian or South American wines pale in comparison to the mid-line quality wines from Sonoma or France.
Obviously this is a matter of taste, but personally I'd have to disagree, at least with regard to the Australian stuff. Several mid-range Australian wines (e.g. Penfolds Bin 389) compare favourably with similarly priced Californian and French wines in my experience. I don't have the experience with the higher quality wines to make the comparison with those, but I can only assume that as there are numerous wines that have received better reviews than 389 that they are actually, at least in some fashion, better.
This is true of more than wines, go check your top shelf vodkas, most of them taste just as good as a $25 bottle of "lesser" vodka.
Depends what you want from your vodka, I guess. If you want it to taste "pure" (as is generally the case for mixing) then you definitely want the cheap stuff, which usually has an ingredient list that reads "water, ethanol, glycerol" -- i.e., it's synthetic vodka with no flavour other than the alcohol and the slight sweetness of the glycerol. _Real_ vodka has some trace flavours remaining from the source grains. Some people don't like that flavour.
...Heston Blumenthal's output. Who hasn't? The only reason the rest of us don't have kitchens filled with expensive gadgets (and experienced help) is lack of finance.:)
There is no reason that a word document cannot have those headers. A MS OOXML.docx file is nothing but a zip archive full of stylesheets, markup and content.
A valid word file absolutely can have SWF headers at the start of the file, and still be valid.
A valid zip archive starts with the bytes 50 4b 03 04 hex. Anything expecting a docx file should be checking they are present.
You are essentially saying "Word documents should not be validated based on the word document standards, but on my arbitrary standards that prevent this specific issue."
The word document standards say it's a zip file. The zip file standards say the zip file starts with the local file header, which starts with the above bytes. The standard is not in the slightest arbitrary. The problem is that implementations are too lax and accept files that do not conform to the published standards.
Update your graphics card drivers. Presuming your system is handling the load OK, which it should be these days, the fault lies with your card and driver. Not much Youtube can do about it.
Except everything else works fine. It's just flash doesn't seem to be able to cope with playing videos without stuttering.
Actually, I'm not convinced it isn't a firefox issue. Doesn't seem to happen when I'm using Internet Explorer.
Adobe's plugin doesn't need to depend on what the file was served as (that's for the browser to do). However this is Adobe's problem. The flash plugin should be validating whatever is passed to it before executing it. It should refuse to execute a flash file that has any non-flash component appended (e.g. a flash executable disguised as a zip shouldn't run even if both the flash and zip parts are valid).
The problem is that it can't tell that until the file is completely downloaded, but flash is a streaming format (i.e. it starts executing while it is still downloading). What you're asking is a technical impossibility.
Would you have suggested checking for SWF headers before this issue was published?
No. I would have suggested checking for zip file headers (0x04034b50 as a little-endian dword) at the start of the file. The zip file format specifies such headers, and it is only the fact that most zip processing software doesn't check for them that allows the prepending. If docx is defined as being a zip file, it should follow all the rules for such a file.
Simply set your desktop to that resolution then. Problem solved.
You must be new here (as in to PC gaming). Most Windoze-based games released from when DirectX was first launched up until about 7 or 8 years ago change the screen resolution to their own predefined resolution (which varies according to the age of the game, starting at 640x480 for the earliest ones and working up to 1024x768 for the later ones) when they start. Some have.ini file or command line settings to prevent this happening (e.g. civ3, one of my favourites of the era, can be made to do this), but quite a lot don't. Games that actually ask you what resolution to run in or that can be persuaded to run in a window rather than full screen are a fairly new innovation.
Stop thinking like a tech. Start thinking like a criminal or defense attorney.
You only have to fool one of the jurors, not all 12.
"Well hell, Facebook says he posted on it from home at that time, and that's clear across town. He couldn't have done it." Ta da, hung jury.
Well, yeah, but given that 11 of them probably think "the police say he did it so he must have done it", you've only got one you _can_ convince of that...
Maybe you can explain why the downstream site needs a cookie to accomplish affiliate marketing when other means, such as embedding a code in the URL, are available.
There are two problems with embedding codes in URLs for affiliate marketing.
1. People copy links and send them to other people. Search engines pull links out of web sites and index them. If you only use a code in your URLs to identify origin of visitors, you can suddenly find you are paying an affiliate for customers that did not come directly from them, but only indirectly.
2. Many affiliate schemes offer to pay the affiliate even if the customer goes away after clicking the link and then returns up to (e.g.) 30 days later. This can only be implemented using cookies.
Except you can already block all that with your web browser, if you don't like it.
Why put undue burden on site owners when cookie blocking features *already exist* in every browser out there? That's why this law is retarded-- not because of the intention (which I also kind of agree with, to an extent).
Where it is technically possible and effective, in accordance with the relevant provisions of Directive 95/46/EC, the user's consent to processing may be expressed by using the appropriate settings of a browser or other application.
So the entire thing is pointless and inaffective; anyone ever sues under it, you just argue that the settings of their browser that control acceptance of cookies were set to accept them, and therefore the user had implicitly consented to receiving them, point the court at this paragraph of the recital (which is an explanation of the intent of the directive) and that should be it.
I have doubts about this - with the Panama canal under Allied control, getting to the east coast USA from Japan would have been VERY far-ranging.
Apparently they had a maximum range of 39,000km (about twice as far as equivalent US models), which does put such a trip well within possibility. It would have been a one way trip, of course, although there may have been enough range for them to reach German-occupied France after launching an attack on east-coast USA (my quick google-map calculation suggests that 35,000km would have been enough for such a mission).
Seriously... they (buffering) have trouble (buffering) offering (buffering) (waiting) standard video.
The problem I have with youtube isn't buffering. It's the fact that the video often freezes for no apparent reason even when the bar shows there's like a minute or more's worth of video in the buffer and ready to play.
How do you know it's disabled? The BIOS TOLD you it was disabled.
If you don't trust your BIOS, there's a jumper on your motherboard that resets AMT to its default state (i.e. no authentication methods configured, so nobody can access it except locally).
AMT can rewrite the BIOS - as can the machine itself if it gets cracked even with AMT actually off.
Well, yes. You can't _entirely_ trust a machine that you haven't built yourself from individual transistors.
At some point you have to trust that something works as advertised, and AMT is designed to be disablable. So you have to trust your machine's vendor hasn't hijacked something to prevent you from disabling it, but here's some news: there are a lot of other ways they could do this if they wanted. They could insert their own back door in the system's chipset, something that snoops on the bus for a certain network packet being received and then takes over the system, for example. I fail to see, however, why any of them would bother.
Also: If there's a bug in the BIOS / WAN interface firmware, an exploit of THAT might successfully utilize some AMT functionality even if it's "turned off" - potentially leading to turning it all on or otherwise pwning the machine.
Yes, but it could well do so even without AMT being present. In order to achieve this, the firmware would need to contain a bug that allows an attacker to pretend to be interacting with the machine via some local method (usb port, keyboard, etc.). Such a bug would be a serious problem, and would almost certainly allow the attacker the ability to execute arbitrary code, and therefore give them the ability to (e.g.) reflash your bios, install a rootkit in your OS, or any other such insidious method of taking over your system. I fail to see why the presence of AMT would make this any worse than it already is.
And then you yell upstairs "Honey, can you hit rewind on the computer for me?":-)
I'm sure that as we speak, somebody somewhere is working on an Android/iPhone/Palm-pre app that lets you use your phone to hook up to your wireless lan and operate as a remote control for VLC.
At least javascript is confined mostly to a single PAGE - please tell me I'm reading this incorrectly.
I'm not sure where you're wrong here, but you do seem to be. The consequences of a server being vulnerable to this kind of attack are _exactly the same_ as if the server is vulnerable to a cross site scripting attack: scripts can be executed in the context of the server, allowing attackers access to stored cookies, download files from sections of the site he is logged in to, and make requests in those sections too.
Wrong. The two properties of Flash that make it vulnerable to this class of attack are:
1. It relies upon a same-origin security model, and
2. Unlike JavaScript code, Flash objects can be executed by simply being loaded by a browser
The second isn't really necessary; you can trigger this issue by tricking the user into visiting a page with embedded flash. There are two critical points you don't note, however:
1. Unlike Javascript, the origin it uses when embedded in a page is the origin of the flash object, not the origin of the page that embedded it. 2. It ignores content type headers and will execute however it is served.
the special vulnerability here is that you can 'inline' the flash in other formats and be valid for both checks
Actually, you're misreading the article here. This is a problem with almost all file formats, because there are a small number of releatively common formats (especially those based on zip files) where the applications that use them start reading at the end of file rather than the start, thus such files can be combined with _any_ file format that starts reading from the start and ignores junk at the end (which is to say, almost all modern file formats, and absolutely all formats that are designed for streaming use). So I'm pretty sure you could do this with silverlight, also.
How is HTML 5 - as opposed to moonlight/silverlight/flash - not vunerable (potentially) to the same sort of attack?
Two reasons:
1. If you upload an HTML file to a server with this problem, it will (hopefully) not send it back as text/html, thus the browser will not execute anything in it.
2. If you upload javascript to a server with this problem and attempt to embed it in a web page, it may well be executed, but it will be executed in the context of the page it is embedded in. Thus the onus is on page designers not to point script tags at sources of javascript they don't trust (which is relatively easy, and it is widely known that you need to guard against it). If you do this with flash or silverlight, it is executed in its own context based on the server it was downloaded from. Thus the onus is on server operators not to serve flash or silverlight files they don't trust (which is not actually any harder, but most aren't aware that they need to so a large number are vulnerable).
Slashdot Mirror
I'm on dial-up, you insensitive clod!
What're you talking about? That's only 11 hours!
I don't buy the argument that we should be expected to spend the money up-front to guard against storms that big.
You're missing the point, which is that the badly maintained canal made the situation worse than it would have been had the canal never been built (at which point nobody would have lived in the area in question because it would _always_ flood). People would have been better off if they had done nothing at all, but that's not what they did.
Is it just me, or does this sound like RISC fanboyism from the 1990s? The "advantages" of RISC are not nearly so clear these days. Indeed, it is getting rather hard to find real RISC chips. While there are chips based on RISC ISA idea (like being load/store and such), they are not RISC. RISC is about having few instructions and instructions that are simple and only do one thing. Those concepts are pretty much thrown out when you start having SIMD units on the chip and such.
I wouldn't say that's what RISC was about at all; the basic idea was to have only instructions that could be implemented using a few simple pipeline stages. This is a substantial improvement over the microcoded architectures that were prevalent prior to RISC, because it can be much more easily pipelined (or, indeed, pipelined at all). I don't see SIMD as incompatible with RISC in any fashion; it just happens that the instruction operates on very wide data, but it's still a relatively simple instruction that should be able to complete quite quickly.
These days complex processors are the norm. They have special instructions for special things and that seems to work well. RISC is just not very common, even in systems with a RISC heritage.
I'd say it's more the other way around. Even in systems with a CISC ISA (e.g. x86), you tend to find that under the hood the CISC instructions are translated into a series of microops that are then dispatched in a system that is somewhat RISC-like. The most common processor family in the world is the ARM family, and all of those processors subscribe pretty well to the original principles of RISC, from instruction set to internal design of the processor core.
All of these are much more faithful to the principles of RISC than the chip described in TFA, whose instruction performs two memory accesses on each execution -- note that the removal of such instructions and consequent simplification of the execution pipeline (by having only a single pipleline stage that could access memory) was the original motivation behind RISC architectures.
Why does nobody ever seem to benchmark stuff like this with GPGPU apps? Would be nice to see how it performs on something that can really tax it...
Unless there simply isn't, e.g., a signed telnetd package, you don't need undiscovered vulnerabilities for this to be a potential for major problems.
Installing telnetd doesn't make it run; you'd have to add it to inetd or run it manually, either of which require logging in as root.
Installing software is rarely an issue, it's only running it. Stuff that installs setuid root needs careful examination, but there's little enough of that that I'd guess they've audited it quite thoroughly over the years...
Too bad this isn't Gentoo and I don't have root on it.
Have you considered user mode linux? Gives you a virtual root on your own FS image, doesn't need root to run...?
Give me the most highly rated Zinfandel and I probably would give a pretty low reguard compaired to a more moderately rated Shiraz, the same goes for region, I personally think the highest quality Australian or South American wines pale in comparison to the mid-line quality wines from Sonoma or France.
Obviously this is a matter of taste, but personally I'd have to disagree, at least with regard to the Australian stuff. Several mid-range Australian wines (e.g. Penfolds Bin 389) compare favourably with similarly priced Californian and French wines in my experience. I don't have the experience with the higher quality wines to make the comparison with those, but I can only assume that as there are numerous wines that have received better reviews than 389 that they are actually, at least in some fashion, better.
This is true of more than wines, go check your top shelf vodkas, most of them taste just as good as a $25 bottle of "lesser" vodka.
Depends what you want from your vodka, I guess. If you want it to taste "pure" (as is generally the case for mixing) then you definitely want the cheap stuff, which usually has an ingredient list that reads "water, ethanol, glycerol" -- i.e., it's synthetic vodka with no flavour other than the alcohol and the slight sweetness of the glycerol. _Real_ vodka has some trace flavours remaining from the source grains. Some people don't like that flavour.
...Heston Blumenthal's output. Who hasn't? The only reason the rest of us don't have kitchens filled with expensive gadgets (and experienced help) is lack of finance. :)
There is no reason that a word document cannot have those headers. A MS OOXML .docx file is nothing but a zip archive full of stylesheets, markup and content.
A valid word file absolutely can have SWF headers at the start of the file, and still be valid.
A valid zip archive starts with the bytes 50 4b 03 04 hex. Anything expecting a docx file should be checking they are present.
You are essentially saying "Word documents should not be validated based on the word document standards, but on my arbitrary standards that prevent this specific issue."
The word document standards say it's a zip file. The zip file standards say the zip file starts with the local file header, which starts with the above bytes. The standard is not in the slightest arbitrary. The problem is that implementations are too lax and accept files that do not conform to the published standards.
Update your graphics card drivers. Presuming your system is handling the load OK, which it should be these days, the fault lies with your card and driver. Not much Youtube can do about it.
Except everything else works fine. It's just flash doesn't seem to be able to cope with playing videos without stuttering.
Actually, I'm not convinced it isn't a firefox issue. Doesn't seem to happen when I'm using Internet Explorer.
Adobe's plugin doesn't need to depend on what the file was served as (that's for the browser to do). However this is Adobe's problem. The flash plugin should be validating whatever is passed to it before executing it. It should refuse to execute a flash file that has any non-flash component appended (e.g. a flash executable disguised as a zip shouldn't run even if both the flash and zip parts are valid).
The problem is that it can't tell that until the file is completely downloaded, but flash is a streaming format (i.e. it starts executing while it is still downloading). What you're asking is a technical impossibility.
Would you have suggested checking for SWF headers before this issue was published?
No. I would have suggested checking for zip file headers (0x04034b50 as a little-endian dword) at the start of the file. The zip file format specifies such headers, and it is only the fact that most zip processing software doesn't check for them that allows the prepending. If docx is defined as being a zip file, it should follow all the rules for such a file.
Simply set your desktop to that resolution then. Problem solved.
You must be new here (as in to PC gaming). Most Windoze-based games released from when DirectX was first launched up until about 7 or 8 years ago change the screen resolution to their own predefined resolution (which varies according to the age of the game, starting at 640x480 for the earliest ones and working up to 1024x768 for the later ones) when they start. Some have .ini file or command line settings to prevent this happening (e.g. civ3, one of my favourites of the era, can be made to do this), but quite a lot don't. Games that actually ask you what resolution to run in or that can be persuaded to run in a window rather than full screen are a fairly new innovation.
Or, for a lower tech solution, just get someone else to do it.
Or, for a higher tech one, there's always autoit.
Stop thinking like a tech. Start thinking like a criminal or defense attorney.
You only have to fool one of the jurors, not all 12.
"Well hell, Facebook says he posted on it from home at that time, and that's clear across town. He couldn't have done it." Ta da, hung jury.
Well, yeah, but given that 11 of them probably think "the police say he did it so he must have done it", you've only got one you _can_ convince of that...
Maybe you can explain why the downstream site needs a cookie to accomplish affiliate marketing when other means, such as embedding a code in the URL, are available.
There are two problems with embedding codes in URLs for affiliate marketing.
1. People copy links and send them to other people. Search engines pull links out of web sites and index them. If you only use a code in your URLs to identify origin of visitors, you can suddenly find you are paying an affiliate for customers that did not come directly from them, but only indirectly.
2. Many affiliate schemes offer to pay the affiliate even if the customer goes away after clicking the link and then returns up to (e.g.) 30 days later. This can only be implemented using cookies.
Except you can already block all that with your web browser, if you don't like it.
Why put undue burden on site owners when cookie blocking features *already exist* in every browser out there? That's why this law is retarded-- not because of the intention (which I also kind of agree with, to an extent).
Actually, RTF directive:
So the entire thing is pointless and inaffective; anyone ever sues under it, you just argue that the settings of their browser that control acceptance of cookies were set to accept them, and therefore the user had implicitly consented to receiving them, point the court at this paragraph of the recital (which is an explanation of the intent of the directive) and that should be it.
I have doubts about this - with the Panama canal under Allied control, getting to the east coast USA from Japan would have been VERY far-ranging.
Apparently they had a maximum range of 39,000km (about twice as far as equivalent US models), which does put such a trip well within possibility. It would have been a one way trip, of course, although there may have been enough range for them to reach German-occupied France after launching an attack on east-coast USA (my quick google-map calculation suggests that 35,000km would have been enough for such a mission).
Seriously...
they (buffering) have trouble (buffering) offering (buffering) (waiting) standard video.
The problem I have with youtube isn't buffering. It's the fact that the video often freezes for no apparent reason even when the bar shows there's like a minute or more's worth of video in the buffer and ready to play.
How do you know it's disabled? The BIOS TOLD you it was disabled.
If you don't trust your BIOS, there's a jumper on your motherboard that resets AMT to its default state (i.e. no authentication methods configured, so nobody can access it except locally).
AMT can rewrite the BIOS - as can the machine itself if it gets cracked even with AMT actually off.
Well, yes. You can't _entirely_ trust a machine that you haven't built yourself from individual transistors.
At some point you have to trust that something works as advertised, and AMT is designed to be disablable. So you have to trust your machine's vendor hasn't hijacked something to prevent you from disabling it, but here's some news: there are a lot of other ways they could do this if they wanted. They could insert their own back door in the system's chipset, something that snoops on the bus for a certain network packet being received and then takes over the system, for example. I fail to see, however, why any of them would bother.
Also: If there's a bug in the BIOS / WAN interface firmware, an exploit of THAT might successfully utilize some AMT functionality even if it's "turned off" - potentially leading to turning it all on or otherwise pwning the machine.
Yes, but it could well do so even without AMT being present. In order to achieve this, the firmware would need to contain a bug that allows an attacker to pretend to be interacting with the machine via some local method (usb port, keyboard, etc.). Such a bug would be a serious problem, and would almost certainly allow the attacker the ability to execute arbitrary code, and therefore give them the ability to (e.g.) reflash your bios, install a rootkit in your OS, or any other such insidious method of taking over your system. I fail to see why the presence of AMT would make this any worse than it already is.
And then you yell upstairs "Honey, can you hit rewind on the computer for me?" :-)
I'm sure that as we speak, somebody somewhere is working on an Android/iPhone/Palm-pre app that lets you use your phone to hook up to your wireless lan and operate as a remote control for VLC.
At least javascript is confined mostly to a single PAGE - please tell me I'm reading this incorrectly.
I'm not sure where you're wrong here, but you do seem to be. The consequences of a server being vulnerable to this kind of attack are _exactly the same_ as if the server is vulnerable to a cross site scripting attack: scripts can be executed in the context of the server, allowing attackers access to stored cookies, download files from sections of the site he is logged in to, and make requests in those sections too.
Wrong. The two properties of Flash that make it vulnerable to this class of attack are:
1. It relies upon a same-origin security model, and
2. Unlike JavaScript code, Flash objects can be executed by simply being loaded by a browser
The second isn't really necessary; you can trigger this issue by tricking the user into visiting a page with embedded flash. There are two critical points you don't note, however:
1. Unlike Javascript, the origin it uses when embedded in a page is the origin of the flash object, not the origin of the page that embedded it.
2. It ignores content type headers and will execute however it is served.
the special vulnerability here is that you can 'inline' the flash in other formats and be valid for both checks
Actually, you're misreading the article here. This is a problem with almost all file formats, because there are a small number of releatively common formats (especially those based on zip files) where the applications that use them start reading at the end of file rather than the start, thus such files can be combined with _any_ file format that starts reading from the start and ignores junk at the end (which is to say, almost all modern file formats, and absolutely all formats that are designed for streaming use). So I'm pretty sure you could do this with silverlight, also.
How is HTML 5 - as opposed to moonlight/silverlight/flash - not vunerable (potentially) to the same sort of attack?
Two reasons:
1. If you upload an HTML file to a server with this problem, it will (hopefully) not send it back as text/html, thus the browser will not execute anything in it.
2. If you upload javascript to a server with this problem and attempt to embed it in a web page, it may well be executed, but it will be executed in the context of the page it is embedded in. Thus the onus is on page designers not to point script tags at sources of javascript they don't trust (which is relatively easy, and it is widely known that you need to guard against it). If you do this with flash or silverlight, it is executed in its own context based on the server it was downloaded from. Thus the onus is on server operators not to serve flash or silverlight files they don't trust (which is not actually any harder, but most aren't aware that they need to so a large number are vulnerable).