*In an interview [theregister.co.uk], the Director of IE product management, Roger Capriotti, said IE9 would play WebM video if the WebM codec is installed on the system.
Just FYI, so will Safari on MacOS. My copy plays HTML5-embedded Theora and Vorbis files right now. You just have to install the codecs. The browser uses whatever the layers underneath it support.
It won't play on the iPad or iPhone because there's no way to install the codecs at the OS level on those devices. Know what? The same's going to be true of "windows phone 7". On the desktop, IE9 and Safari will both play WebM just fine if the user installs the codecs. On the handheld, there isn't likely to be a way to install 'em. Same exact behavior.
If you care about information continuing to flow if/when the TCP/IP networks are shut down, maybe you should look into setting yourself up as a UUCP node and making peering arrangements? Remember how UUCP mail and news worked? It was a bit like telephone-based bit torrent. It was completely decentralized. As long as you could set up a phone connection with your nearest peers, the data would flow.
You don't need to mod it. Hold down the "sleep" button for a little while and you'll get a red slider on the screen. Slide it and the device will do an orderly shutdown, completely powering off.
Can't you just put a "turn 3g on/off" widget on one of the home screens?
In versions of the OS prior to 4.0, "turn 3G off" means "use the slower EDGE instead of the faster 3G, in order to lower battery drain". In these older versions, the only way to disable TCP/IP over GSM is to disable GSM.
In 4.0, that setting is still there, but there's also a "turn off networking over cellular", which ensures all TCP/IP traffic goes out over wifi or not at all, while leaving voice and SMS active.
If you are extremely worried about this, just put your device into "airplane mode" before putting it to sleep. It won't try to talk to anything at all.
If you're only slightly worried about it, well, OS4 has an option to disable using the cellular connection for data at all, forcing all data over wifi but still leaving the ability to receive SMS and phone calls on. (OS4 brings more tools for managing your bandwidth use than previous releases ever had.)
Part of the problem is that these ways are not sure-fire.
The app reviewers are overloaded and the app review process gets gummed up, and so sometimes mistakes are made and things are not enforced consistently. So, you can have an app that gets through the process just fine for a while, and then gets rejected. Sometimes, it should have been rejected to begin with, but wasn't, and that makes people think that what they're doing is okay, and they got an explicit "wink" and approval.
The (specific, not only) problem is that inconsistent enforcement makes it seem more like there are inconsistent rules than is actually the case.
I stand by my statement. Stuff like the cartoon app are why I wrote "I haven't seen many rejections yet", using the word "many" instead of "any".
Yeah, stuff like that happens, and that sucks. But in terms of percentage of rejected apps, I see way more that are like the strange desktop replacement, or the attempt to bring "Dashboard" to the iPad, or an attempt to provide a hosted development environment... stuff that, if it doesn't clearly cross a line, certainly nudges up close to one.
More arbitrary rejections certainly do happen, and the satirical comic example is a good one, and those suck. But the majority of rejections aren't always as arbitrary as people make them out to be. IMO, of course.
More transparency would be awesome, but I'm not sure "blindsided" is quite the right term here.
There are folks who know they're violating the terms of the developer agreement (eg. games that use LUA internally). There are folks who know they're completely in the clear, conforming to every rule and guideline. And there are edge cases.
I think the "blindsiding" is only happening (a) in the edge cases, or (b) in the folks who have been violating the rules all along, but who have slipped through the app approval process anyway. Apple's approval process has been overloaded, the people involved in it have been overworked, and all sorts of things that ought to have been rejected have gotten through. (One can draw parallels to the patent approval process.) As Apple has time and resources to ramp up, things that slipped through before get caught.
But they're still... I don't know, I haven't seen many rejections yet that a majority of Apple developers I know couldn't kinda understand. "Oh, yeah, that's too bad, but I can understand why that got rejected." So I have a little trouble using the term "blindsided".
The question isn't "why was this okay before, but it's not okay now?". The question is "if this isn't okay, and was never okay, by what error did it slip through before, and what can we do about it?".
A nice step would be the accepting of responsibility on Apple's part. "You know, we made a mistake and your app should never have gotten through. It's only through our own error that it got through in the past. We understand that this error caused you to invest more. Because of the sudden change of direction from us that you, the developer, are experiencing, we are liable to you for such-and-such." Maybe "such-and-such" is an expedited approval chain for revisions that attempt to address the issues. Maybe "such-and-such" is financial compensation if no mitigation is possible.
The approval process needs more transparency (so fewer developers are surprised by rejections), and needs to scale better (so the error rate doesn't skyrocket when usage outstrips projections).
No, the C API on Chrome OS and Android is closed. It's Google only.
Well, remember, we're talking about Google. If they identify this as a need, they can already fill it. But let's assume they won't take that route:
Sure, the APIs are somewhat closed. But the network protocols aren't, and Chrome OS uses X11, doesn't it?
I've already done light development on my own iPad by using ssh, VNC, and X11 (yes, I have all the appropriate clients/servers installed on my iPad). I find it hard to believe that ChromeOS would be less capable of this.
On the XBox 360? Look into "Kodu Game Lab" and maybe eventually XNA.
World of Warcraft? There's a rich XML-and-LUA-based modding system; you can start with "hello world" apps and produce richly customized user interfaces with complex tools added to them.
The Wii? Install the web browser, and show them a bunch of the games that are optimized for the special version of Flash that the Wii has, and then poke at one of the dev kits that works with that.
Really, just knowing that they're doing "gaming" doesn't tell us enough to know what might best serve as a bridge to other things.
If application compatibility is an issue for you, why not ditch apple's proprietary device and buy one of the many Android devices? Or if you're a *nix user, an n900?
Because application compatibility is simply not the only issue. It's an issue, but one among many.
Related concept: the FSF recently asserted that Apple sets up the iPhone ecosystem so that Apple's interests come first, and the interests of Apple's business partners come second, and the interests of the actual end-user buying the device come third.
Well, let's say I accept that. Does that mean I should not buy an iPhone?
What if, even granting that prioritization, the iPhone is still the device that serves my interests better than any other device does? Should I accept a device that benefits me 60% less than an iPhone, simply because by doing so I make sure that the benefit to other parties is lowered by significantly more than that 60%?
(You may say "yes". I know many people who wouldn't, though, and hopefully this exercise helps you see why.)
Much more troublesome, for security, is the fact that there are no known methods of secure computing that are economically competitive with insecure ones, not to mention the issue of legacy systems.
You hit the nail on it right there, with the "economically competitive" part. That's the problem.
Sure, if you've got a bunch of custom hardware running custom software that's thoroughly engineered and audited, and that never exchanges data with the rest of the world, you can have considerably higher security than someone using off-the-shelf parts and software on a commodity hardware platform connected to public networks. But it would be economic suicide. The value you give up in productivity is considerably higher than the value you gain in increased security.
This is why I'm glad to see experimentation in this area. What the game console vendors are doing with their platforms (eg. "XNA"), what Apple is doing with the iPhone, what AT&T is doing with the Android-based-and-yet-locked-down Backflip... these experiments in "curated computing" might point in the direction of economically viable secure computing.
Maybe. Whether it works out or not, we'll learn something by having attempted it.
But when it's a large corporation, we somehow think they should be held to a higher standard? No, I don't think they should. They're holding themselves to the same standard the average person would.
Then we strongly disagree. They must be held to a significantly higher standard than an average person.
If I have an accident, the consequences to a complete stranger in a completely different part of the world are minor, because essentially I'm just some mostly-anonymous nobody with no special powers or privileges.
As the consequences to the rest of the world for having an accident go up, the standards for preventing accidents and being held accountable for them must also go up.
I'm pretty sure Google did think of this. I think that's why their license says something vaguely like "we license these patents to anyone who doesn't bring a patent suit against people who use VP8".
Think about how that plays out. The owners of the H.264 patents correctly (let's say) note that VP8 violates them. But, they're also using patens that Google now owns themselves. Sure, they can go after VP8 users, but if they do, they can no longer use the On2 patents that they'd otherwise have had permission to keep on using.
It might work. I think it's the only way (apart from abolishing software patents, which I would find preferable but which I'm not willing to bet on) to solve the "open codec" problem that actually could work.
If this is how it's going to work out, and the H.264 people figure that out quickly enough, and they want to remain relevant in the marketplace in the coming years, their correct counter-move would be to offer their own patents up on exactly the same licensing terms.
Nothing I wrote had anything to do with how long a wipe took, it was based on what triggers the wipe, and how to prevent the phone from ever realizing that condition had been met. I think it's possible that you're confused.
For the iPhone for example, a remote wipe for a typical "MobileMe" user requires that user to go to a web site and press the "remote wipe" button. A phone that's in airplane mode will never receive the resulting signal, and won't be wiped.
So if a pickpocket gets the phone and immediately dodges into an alleyway, and puts it in airplane mode (or takes out the SIM card), a remote wipe cannot work, at all, period.
As I understand it, doing any of the following should be able to prevent a remote wipe from happening:
* put it into "airplane mode" * remove the SIM (assuming GSM with no wifi) * remove the battery
If you need the SIM or battery to get the data off the device, you can then take it to a faraday cage and put the SIM or battery back in once you're sure no signal can get to the phone. Yes?
Anything that protected against these "attacks" would also make it so the phone's user couldn't access their data when the signal strength was sufficiently poor. Which some folks might choose as their configuration, but then they're open to a new kind of denial-of-service attack.
Remote wipe is useful when you want to prevent a random schlub (eg. pickpocket, guy at bar) from getting data off a randomly-acquired phone (eg. "iPhone HD"). I do not think it's useful for preventing a professional with intent from getting data off a phone they're targeting specifically because of its data. Am I wrong?
Whose ethics? Yours? Mine? The Pope's? Bin Laden's?
Exactly my point. You can't safely go around making unilateral assertions about ethical behavior as if everyone involved has already agreed on everything. (Of course, I can't either.)
Myself, I consider it "stealing" if someone takes something they're not entitled to, whether or not someone else is deprived of anything or harmed by this individual act. I do know many people happen to disagree. That's a basis for starting a discussion, right there, not a basis for shutting down a discussion by declaring that "the other side" obviously has no idea what they're talking about.
(Now, I wonder how many people will try to have a discussion, how many will foam at the mouth and rant, and how many will specifically target my admittedly-stupid spelling errors. Wanna place bets?)
This constant effort in changing our language is frustrating.
When you steal something you deprive the previous owner of their copy.
I just wanted to point out that this has never been universally agreed upon, not globally.
When you steel, you get something you are not entitled to have.
Some people think there's only a wrong if it deprives someone of something they are entitled to. But others think there's a wrong if someone gets something they're not entitled to.
I completely accept that there's a legitimate point over which people can disagree here. I do not accept that one side gets to unilaterally declare that their definition is the only valid one. Go ahead and say that what's under discussion is arguably not theft, but if you assert that it's flatly not theft, as a fact, well, I don't think you're being completely reasonable.
You just blew my mind. I've had a Nintendo DS for several years without this ability... in fact, I don't even thing there's a way to store data of that size on my DS. What on earth are you talking about?
They may be talking about the DSi, which has an SD card slot and a media player. You just load the files up on the SD card and pop it in and you can play them, it's very easy and pretty nice.
(But maybe that's not what they're talking about, since that plays AAC, not MP3. I load mine up with music from the iTunes store all the time. At this time I have more devices that can play AAC than MP3, including a bunch of devices that have no problem playing both, like the XB360 and Chumby and iPod.)
Slashdot Mirror
*In an interview [theregister.co.uk], the Director of IE product management, Roger Capriotti, said IE9 would play WebM video if the WebM codec is installed on the system.
Just FYI, so will Safari on MacOS. My copy plays HTML5-embedded Theora and Vorbis files right now. You just have to install the codecs. The browser uses whatever the layers underneath it support.
It won't play on the iPad or iPhone because there's no way to install the codecs at the OS level on those devices. Know what? The same's going to be true of "windows phone 7". On the desktop, IE9 and Safari will both play WebM just fine if the user installs the codecs. On the handheld, there isn't likely to be a way to install 'em. Same exact behavior.
If you care about information continuing to flow if/when the TCP/IP networks are shut down, maybe you should look into setting yourself up as a UUCP node and making peering arrangements? Remember how UUCP mail and news worked? It was a bit like telephone-based bit torrent. It was completely decentralized. As long as you could set up a phone connection with your nearest peers, the data would flow.
Actually by then, it'll be IPv6.1 ...
...unless you're running on a Microsoft operating system, in which case it'll be "IPv6.11 for Workgroups".
You don't need to mod it. Hold down the "sleep" button for a little while and you'll get a red slider on the screen. Slide it and the device will do an orderly shutdown, completely powering off.
Can't you just put a "turn 3g on/off" widget on one of the home screens?
In versions of the OS prior to 4.0, "turn 3G off" means "use the slower EDGE instead of the faster 3G, in order to lower battery drain". In these older versions, the only way to disable TCP/IP over GSM is to disable GSM.
In 4.0, that setting is still there, but there's also a "turn off networking over cellular", which ensures all TCP/IP traffic goes out over wifi or not at all, while leaving voice and SMS active.
Won't that kill phone calls too?
Following the instructions from the small part of my message you quoted will, yes.
Following the other instructions in my message won't. That'll keep SMS and voice active while ensuring TCP/IP goes out over wifi or not at all.
If you are extremely worried about this, just put your device into "airplane mode" before putting it to sleep. It won't try to talk to anything at all.
If you're only slightly worried about it, well, OS4 has an option to disable using the cellular connection for data at all, forcing all data over wifi but still leaving the ability to receive SMS and phone calls on. (OS4 brings more tools for managing your bandwidth use than previous releases ever had.)
Part of the problem is that these ways are not sure-fire.
The app reviewers are overloaded and the app review process gets gummed up, and so sometimes mistakes are made and things are not enforced consistently. So, you can have an app that gets through the process just fine for a while, and then gets rejected. Sometimes, it should have been rejected to begin with, but wasn't, and that makes people think that what they're doing is okay, and they got an explicit "wink" and approval.
The (specific, not only) problem is that inconsistent enforcement makes it seem more like there are inconsistent rules than is actually the case.
...is like dancing about architecture.
I stand by my statement. Stuff like the cartoon app are why I wrote "I haven't seen many rejections yet", using the word "many" instead of "any".
Yeah, stuff like that happens, and that sucks. But in terms of percentage of rejected apps, I see way more that are like the strange desktop replacement, or the attempt to bring "Dashboard" to the iPad, or an attempt to provide a hosted development environment... stuff that, if it doesn't clearly cross a line, certainly nudges up close to one.
More arbitrary rejections certainly do happen, and the satirical comic example is a good one, and those suck. But the majority of rejections aren't always as arbitrary as people make them out to be. IMO, of course.
More transparency would be awesome, but I'm not sure "blindsided" is quite the right term here.
There are folks who know they're violating the terms of the developer agreement (eg. games that use LUA internally). There are folks who know they're completely in the clear, conforming to every rule and guideline. And there are edge cases.
I think the "blindsiding" is only happening (a) in the edge cases, or (b) in the folks who have been violating the rules all along, but who have slipped through the app approval process anyway. Apple's approval process has been overloaded, the people involved in it have been overworked, and all sorts of things that ought to have been rejected have gotten through. (One can draw parallels to the patent approval process.) As Apple has time and resources to ramp up, things that slipped through before get caught.
But they're still... I don't know, I haven't seen many rejections yet that a majority of Apple developers I know couldn't kinda understand. "Oh, yeah, that's too bad, but I can understand why that got rejected." So I have a little trouble using the term "blindsided".
The question isn't "why was this okay before, but it's not okay now?". The question is "if this isn't okay, and was never okay, by what error did it slip through before, and what can we do about it?".
A nice step would be the accepting of responsibility on Apple's part. "You know, we made a mistake and your app should never have gotten through. It's only through our own error that it got through in the past. We understand that this error caused you to invest more. Because of the sudden change of direction from us that you, the developer, are experiencing, we are liable to you for such-and-such." Maybe "such-and-such" is an expedited approval chain for revisions that attempt to address the issues. Maybe "such-and-such" is financial compensation if no mitigation is possible.
The approval process needs more transparency (so fewer developers are surprised by rejections), and needs to scale better (so the error rate doesn't skyrocket when usage outstrips projections).
Well, remember, we're talking about Google. If they identify this as a need, they can already fill it. But let's assume they won't take that route:
Sure, the APIs are somewhat closed. But the network protocols aren't, and Chrome OS uses X11, doesn't it?
I've already done light development on my own iPad by using ssh, VNC, and X11 (yes, I have all the appropriate clients/servers installed on my iPad). I find it hard to believe that ChromeOS would be less capable of this.
On the XBox 360? Look into "Kodu Game Lab" and maybe eventually XNA.
World of Warcraft? There's a rich XML-and-LUA-based modding system; you can start with "hello world" apps and produce richly customized user interfaces with complex tools added to them.
The Wii? Install the web browser, and show them a bunch of the games that are optimized for the special version of Flash that the Wii has, and then poke at one of the dev kits that works with that.
Really, just knowing that they're doing "gaming" doesn't tell us enough to know what might best serve as a bridge to other things.
Because application compatibility is simply not the only issue. It's an issue, but one among many.
Related concept: the FSF recently asserted that Apple sets up the iPhone ecosystem so that Apple's interests come first, and the interests of Apple's business partners come second, and the interests of the actual end-user buying the device come third.
Well, let's say I accept that. Does that mean I should not buy an iPhone?
What if, even granting that prioritization, the iPhone is still the device that serves my interests better than any other device does? Should I accept a device that benefits me 60% less than an iPhone, simply because by doing so I make sure that the benefit to other parties is lowered by significantly more than that 60%?
(You may say "yes". I know many people who wouldn't, though, and hopefully this exercise helps you see why.)
You hit the nail on it right there, with the "economically competitive" part. That's the problem.
Sure, if you've got a bunch of custom hardware running custom software that's thoroughly engineered and audited, and that never exchanges data with the rest of the world, you can have considerably higher security than someone using off-the-shelf parts and software on a commodity hardware platform connected to public networks. But it would be economic suicide. The value you give up in productivity is considerably higher than the value you gain in increased security.
This is why I'm glad to see experimentation in this area. What the game console vendors are doing with their platforms (eg. "XNA"), what Apple is doing with the iPhone, what AT&T is doing with the Android-based-and-yet-locked-down Backflip... these experiments in "curated computing" might point in the direction of economically viable secure computing.
Maybe. Whether it works out or not, we'll learn something by having attempted it.
But when it's a large corporation, we somehow think they should be held to a higher standard? No, I don't think they should. They're holding themselves to the same standard the average person would.
Then we strongly disagree. They must be held to a significantly higher standard than an average person.
If I have an accident, the consequences to a complete stranger in a completely different part of the world are minor, because essentially I'm just some mostly-anonymous nobody with no special powers or privileges.
As the consequences to the rest of the world for having an accident go up, the standards for preventing accidents and being held accountable for them must also go up.
I'm pretty sure Google did think of this. I think that's why their license says something vaguely like "we license these patents to anyone who doesn't bring a patent suit against people who use VP8".
Think about how that plays out. The owners of the H.264 patents correctly (let's say) note that VP8 violates them. But, they're also using patens that Google now owns themselves. Sure, they can go after VP8 users, but if they do, they can no longer use the On2 patents that they'd otherwise have had permission to keep on using.
It might work. I think it's the only way (apart from abolishing software patents, which I would find preferable but which I'm not willing to bet on) to solve the "open codec" problem that actually could work.
If this is how it's going to work out, and the H.264 people figure that out quickly enough, and they want to remain relevant in the marketplace in the coming years, their correct counter-move would be to offer their own patents up on exactly the same licensing terms.
Huh?
Nothing I wrote had anything to do with how long a wipe took, it was based on what triggers the wipe, and how to prevent the phone from ever realizing that condition had been met. I think it's possible that you're confused.
For the iPhone for example, a remote wipe for a typical "MobileMe" user requires that user to go to a web site and press the "remote wipe" button. A phone that's in airplane mode will never receive the resulting signal, and won't be wiped.
So if a pickpocket gets the phone and immediately dodges into an alleyway, and puts it in airplane mode (or takes out the SIM card), a remote wipe cannot work, at all, period.
See?
As I understand it, doing any of the following should be able to prevent a remote wipe from happening:
* put it into "airplane mode"
* remove the SIM (assuming GSM with no wifi)
* remove the battery
If you need the SIM or battery to get the data off the device, you can then take it to a faraday cage and put the SIM or battery back in once you're sure no signal can get to the phone. Yes?
Anything that protected against these "attacks" would also make it so the phone's user couldn't access their data when the signal strength was sufficiently poor. Which some folks might choose as their configuration, but then they're open to a new kind of denial-of-service attack.
Remote wipe is useful when you want to prevent a random schlub (eg. pickpocket, guy at bar) from getting data off a randomly-acquired phone (eg. "iPhone HD"). I do not think it's useful for preventing a professional with intent from getting data off a phone they're targeting specifically because of its data. Am I wrong?
Whose ethics? Yours? Mine? The Pope's? Bin Laden's?
Exactly my point. You can't safely go around making unilateral assertions about ethical behavior as if everyone involved has already agreed on everything. (Of course, I can't either.)
Myself, I consider it "stealing" if someone takes something they're not entitled to, whether or not someone else is deprived of anything or harmed by this individual act. I do know many people happen to disagree. That's a basis for starting a discussion, right there, not a basis for shutting down a discussion by declaring that "the other side" obviously has no idea what they're talking about.
Honest question: why is "law" the only place that matters? Why can we not also bring "ethics" into the discussion?
The law can take a while to catch up when the environment changes in a way the law-makers and precedent-seetters didn't anticipate.
Why is the discussion confined to systems of law, and not also systems of ethics?
(Now, I wonder how many people will try to have a discussion, how many will foam at the mouth and rant, and how many will specifically target my admittedly-stupid spelling errors. Wanna place bets?)
This constant effort in changing our language is frustrating.
When you steal something you deprive the previous owner of their copy.
I just wanted to point out that this has never been universally agreed upon, not globally.
When you steel, you get something you are not entitled to have.
Some people think there's only a wrong if it deprives someone of something they are entitled to. But others think there's a wrong if someone gets something they're not entitled to.
I completely accept that there's a legitimate point over which people can disagree here. I do not accept that one side gets to unilaterally declare that their definition is the only valid one. Go ahead and say that what's under discussion is arguably not theft, but if you assert that it's flatly not theft, as a fact, well, I don't think you're being completely reasonable.
They may be talking about the DSi, which has an SD card slot and a media player. You just load the files up on the SD card and pop it in and you can play them, it's very easy and pretty nice.
(But maybe that's not what they're talking about, since that plays AAC, not MP3. I load mine up with music from the iTunes store all the time. At this time I have more devices that can play AAC than MP3, including a bunch of devices that have no problem playing both, like the XB360 and Chumby and iPod.)