So how many key presses (counting autorepeat as one press, since it takes at least as much time as a key press) did it take to type those 4 characters? Using predictive text on an English language phone, you don't worry about the predictions until the whole word is displayed, since it is quicker just to keep typing than to choose partial completions all the time like that. That it is easier to choose predictions earlier in Japanese does not surprise me, but it doesn't support the notion that Japanese is easier to type on a phone keyboard.
English has common words too, so I don't see how Japanese has an advantage here. The alphabet is about half the size (compared with kana), so Japanese's shorter average word length is at the expense of more keystrokes to get at many of the letters. Also English predictive text software requires one keypress for each letter, the way you describe it, there is no completion for kana, so you need to press each key up to 5 times, and wait for the timeout when typing words like tachitai.
I guess having a cost barrier to entry (weather stations are not cheap) ensures that only people who have a genuine interest participate. If the general public started participating, they might end up installing the equipment incorrectly, or maliciously injecting bogus data, and the quality of the data collected would deteriorate.
The thing is, Japanese is far easier to enter on a keypad phone than English,
I don't think its really any easier, just that Japanese have to use "predictive text" type input methods on computers too, so its the same interface for them, just with fewer keys. For English speakers, its a whole different way of inputting, that many people still can't get their heads around. The fastest English txters I know turn off predictive text, because they think it slows them down, I think in reality it is just that they can't change their mindset from typing everything out manually to letting a dictionary do the work.
I think people splitting hairs about the use of the term "brick" are missing the point.
Bricked is when you need to take out the soldering iron and connect up a JTAG cable. If you can still communicate with the firmware loader over USB, it isn't bricked.
That sort of blandization of the high street has happened across the board in the UK, not just with books. I don't know what people without internet access do these days when they want something that isn't a lowest common denominator fly off the shelves product.
If you have a Tomcat/J2EE environment running open source, you will soon be having to deal with a single vendor with control over your environment, because most systems only give lip service to PostgreSQL but fully support MySQL. Expect the support bills to go up.
In the J2EE world, this is less of a problem than PHP etc, due to the fact that database access is abstracted through JDBC. Usually the problems in prepackaged J2EE apps are limited to the database initialization scripts, and if the app is at all popular PostgreSQL versions of these scripts will be available.
Oracle tried to build their own J2EE server (or maybe they bought some obscure one), but it has failed miserably. For the last 5 years, you either run an IBM J2EE stack (Websphere, DB2 usually on IBM hardware), open source (JBoss or Tomcat, MySQL, PostgreSQL or Derby on GNU/Linux), or you use Oracle with WebSphere. This purchase has been expected for at least 5 years, not so Oracle can kill Websphere, but so they can have a decent J2EE server to compete against the integrated solutions offered by IBM and open source.
I don't know about the admin password, but TFA seems to be saying that the DNS can be changed through UPnP, at least on some routers. That aside, I'm a bit surprised that they conclude that UPnP is the problem here, not Flash . If a remote Flash application can connect to arbitrary URLs within your local network, then the security hole is much bigger than UPnP.
No, it didn't say that the attack failed in those browsers, it said it might fail if the router's HTTP server was strict about line endings and a particular version of the Flash plugin was used.
I had just worried that some worm could find my gateway and enable it so that its friends could come in... but I read what you're saying as saying that if it got as far as being able to do that, it wouldn't need such an entry point anyway, it would already be inside and set up for business.
Except for this Flash bug, where the worm, written in Flash ActionScript, does not normally have access to do anything dangerous, but it apparently can open ports on your gateway. I still can't get to TFA to read the details, but I imagine that a feature intended for opening ports so that more efficient UDP based protocols can be used for streaming media has been implemented insecurely. The secure way to implement it would be to only open UDP ports that the Flash client was listening on, but for this to be exploitable it must be allowing arbitrary ports to be opened.
If Flash is a plug-in, not an applet, and is therefore trusted, and Flash is the thing that is doing the network connecting, then is Flash the thing that is holding my security in its hands, or does it have some way of making sure that the program it runs is subject to a more restrictive security model, such as I'm imagining applets to have?
Flash is responsible for enforcing security of Flash applications, the same way that the Java plugin is responsible for enforcing security of applets, and the browser is responsible for enforcing security of Javascript.
1. Its the Macromedia Flash player that's being talked about here, as the rest of your questions assume.
2. I don't know enough about Flash to answer this. Perhaps it relies on the browser for its network support, which would make the network capabilities differ depending on the browser.
3. I'm more familiar with Java and Javascript, but I presume that Flash uses a similar sandbox, restricting what Flash applications can do. For instance, Java applets downloaded from example.com can only make network connections back to example.com, and cannot read or write local files etc.
4. If it is anything like the Java applet sandbox, then it shouldn't be able to access general webpages, only the page it was loaded from. WPA and the administration password for your router have nothing to do with UPnP IGD. If you are running XP, you can tell if your router has UPnP IGD enabled by opening the Network Connections control panel, and seeing if your router shows up as an Internet Gateway device.
If the firmware has UPnP IGD enabled, then your machine is vulnerable to this attack.
The vulnerability is really Flash not restricting what untrusted scripts can do. The router's UPnP IGD profile is working as designed - an application on a machine within the firewall requests that an incoming port be forwarded, so the router does that. This is useful for VoIP, IM, P2P and other applications that need to be contactable from the outside world. Malicious programs that are running on your machine can always initiate outgoing connections, so generally the UPnP IGD is not allowing anything that cannot already be done. In the case of Flash, it is probably blocking most outgoing connections, so UPnP does expand the possibilities for a malicious Flash app to initiate connections with your machine. But unless Flash also allows you to open server sockets, the attacker would also need to find an exploitable service running on your machine.
All this should be detectable by a decent firewall program running on your local machine.
The only security you have, is that it's difficult to complete these kinds of transactions anonymously.
It's difficult to complete these kinds of transactions anonymously, and still get your hands on the money. Which is why the exploit in this case was to set up a regular payment to a charity.
The problem is people turning up ridiculously early for their flights and causing congestion at every point in the airport as they sit around waiting and join queues hours in advance of when they need to be there. When I flew from Heathrow just before Christmas, security were controlling access to the building, and the queues were all short and smooth. When I turned up at 7:30 for a 10am flight, the people in front of me got turned away - their flight was at 14:30, and they, like many, had come to sit around the airport for seven hours.
I'm sure a lot of the problems could be sorted by going back to opening checkin 2 hours before the flight instead of the current dire warnings from travel agents and airlines to check in 3 hours before the flight, which just scares inexperienced tourists into turning up even earlier than they are advised.
What possibly would I need to change settings on if I am 'out'.
Coming back from holiday is the main use case I can see, where you want to set the heating low while you are away, or turn off aircon in summer, then turn it up just before you come back. The other use case would be for people with irregular hours, for whom timers don't offer the flexibility they need.
Slashdot Mirror
It does that too, at least in the Sony Ericsson K850i.
I presume you mean "HamasakiAyumi". It certainly is possible with the current implementation of T9.
So how many key presses (counting autorepeat as one press, since it takes at least as much time as a key press) did it take to type those 4 characters? Using predictive text on an English language phone, you don't worry about the predictions until the whole word is displayed, since it is quicker just to keep typing than to choose partial completions all the time like that. That it is easier to choose predictions earlier in Japanese does not surprise me, but it doesn't support the notion that Japanese is easier to type on a phone keyboard.
English has common words too, so I don't see how Japanese has an advantage here. The alphabet is about half the size (compared with kana), so Japanese's shorter average word length is at the expense of more keystrokes to get at many of the letters. Also English predictive text software requires one keypress for each letter, the way you describe it, there is no completion for kana, so you need to press each key up to 5 times, and wait for the timeout when typing words like tachitai.
I guess having a cost barrier to entry (weather stations are not cheap) ensures that only people who have a genuine interest participate. If the general public started participating, they might end up installing the equipment incorrectly, or maliciously injecting bogus data, and the quality of the data collected would deteriorate.
I don't think its really any easier, just that Japanese have to use "predictive text" type input methods on computers too, so its the same interface for them, just with fewer keys. For English speakers, its a whole different way of inputting, that many people still can't get their heads around. The fastest English txters I know turn off predictive text, because they think it slows them down, I think in reality it is just that they can't change their mindset from typing everything out manually to letting a dictionary do the work.
Bricked is when you need to take out the soldering iron and connect up a JTAG cable. If you can still communicate with the firmware loader over USB, it isn't bricked.
That sort of blandization of the high street has happened across the board in the UK, not just with books. I don't know what people without internet access do these days when they want something that isn't a lowest common denominator fly off the shelves product.
In the J2EE world, this is less of a problem than PHP etc, due to the fact that database access is abstracted through JDBC. Usually the problems in prepackaged J2EE apps are limited to the database initialization scripts, and if the app is at all popular PostgreSQL versions of these scripts will be available.
Oracle tried to build their own J2EE server (or maybe they bought some obscure one), but it has failed miserably. For the last 5 years, you either run an IBM J2EE stack (Websphere, DB2 usually on IBM hardware), open source (JBoss or Tomcat, MySQL, PostgreSQL or Derby on GNU/Linux), or you use Oracle with WebSphere. This purchase has been expected for at least 5 years, not so Oracle can kill Websphere, but so they can have a decent J2EE server to compete against the integrated solutions offered by IBM and open source.
I don't know about the admin password, but TFA seems to be saying that the DNS can be changed through UPnP, at least on some routers. That aside, I'm a bit surprised that they conclude that UPnP is the problem here, not Flash . If a remote Flash application can connect to arbitrary URLs within your local network, then the security hole is much bigger than UPnP.
No, it didn't say that the attack failed in those browsers, it said it might fail if the router's HTTP server was strict about line endings and a particular version of the Flash plugin was used.
Except for this Flash bug, where the worm, written in Flash ActionScript, does not normally have access to do anything dangerous, but it apparently can open ports on your gateway. I still can't get to TFA to read the details, but I imagine that a feature intended for opening ports so that more efficient UDP based protocols can be used for streaming media has been implemented insecurely. The secure way to implement it would be to only open UDP ports that the Flash client was listening on, but for this to be exploitable it must be allowing arbitrary ports to be opened.
Flash is responsible for enforcing security of Flash applications, the same way that the Java plugin is responsible for enforcing security of applets, and the browser is responsible for enforcing security of Javascript.
1. Its the Macromedia Flash player that's being talked about here, as the rest of your questions assume. 2. I don't know enough about Flash to answer this. Perhaps it relies on the browser for its network support, which would make the network capabilities differ depending on the browser. 3. I'm more familiar with Java and Javascript, but I presume that Flash uses a similar sandbox, restricting what Flash applications can do. For instance, Java applets downloaded from example.com can only make network connections back to example.com, and cannot read or write local files etc. 4. If it is anything like the Java applet sandbox, then it shouldn't be able to access general webpages, only the page it was loaded from. WPA and the administration password for your router have nothing to do with UPnP IGD. If you are running XP, you can tell if your router has UPnP IGD enabled by opening the Network Connections control panel, and seeing if your router shows up as an Internet Gateway device.
If the firmware has UPnP IGD enabled, then your machine is vulnerable to this attack.
The vulnerability is really Flash not restricting what untrusted scripts can do. The router's UPnP IGD profile is working as designed - an application on a machine within the firewall requests that an incoming port be forwarded, so the router does that. This is useful for VoIP, IM, P2P and other applications that need to be contactable from the outside world. Malicious programs that are running on your machine can always initiate outgoing connections, so generally the UPnP IGD is not allowing anything that cannot already be done. In the case of Flash, it is probably blocking most outgoing connections, so UPnP does expand the possibilities for a malicious Flash app to initiate connections with your machine. But unless Flash also allows you to open server sockets, the attacker would also need to find an exploitable service running on your machine.
All this should be detectable by a decent firewall program running on your local machine.
Audi claim better mileage and performance than a manual for their multitronic gearboxes used in the A4 and A6.
It's difficult to complete these kinds of transactions anonymously, and still get your hands on the money. Which is why the exploit in this case was to set up a regular payment to a charity.
The madwifi Linux drivers for Atheros chipsets allow multiple access points to be configured on a single wifi card.
On Windows, they are both modifers and action keys. On GNU/Linux they are most often configured as modifiers.
Reverse psychology doesn't affect Minnesota teenagers? Talk about planting ideas into students' heads!
The problem is people turning up ridiculously early for their flights and causing congestion at every point in the airport as they sit around waiting and join queues hours in advance of when they need to be there. When I flew from Heathrow just before Christmas, security were controlling access to the building, and the queues were all short and smooth. When I turned up at 7:30 for a 10am flight, the people in front of me got turned away - their flight was at 14:30, and they, like many, had come to sit around the airport for seven hours.
I'm sure a lot of the problems could be sorted by going back to opening checkin 2 hours before the flight instead of the current dire warnings from travel agents and airlines to check in 3 hours before the flight, which just scares inexperienced tourists into turning up even earlier than they are advised.
Coming back from holiday is the main use case I can see, where you want to set the heating low while you are away, or turn off aircon in summer, then turn it up just before you come back. The other use case would be for people with irregular hours, for whom timers don't offer the flexibility they need.
You're forgetting that by the time you've driven 100,000 miles, the cost of gas will be at least 10 times what it is now.
If the US unilaterally imposes sanctions because they don't like the WTO's ruling, then the WTO will just keep increasing the punishment.