I don't think it's shady at all. Canonical build a complete operating environment. They take the majority of the code from the community, patch it heavily, contribute their own functionality and server resources, and integrate it all. They aren't simply selling a CD with stuff they've burned from the web. What the end user gets is Ubuntu, not a software collection.
When that user installs Ubuntu, installs a media player from Canonical's app centre, and then buys music, that sale is directly attributable to Ubuntu. If Banshee didn't exist, Canonical would use another media player to do the same thing or write their own if there wasn't one suitable. The actual media player in use isn't important. Canonical built the product, Canonical pushed the service, and Canonical runs the servers behind the app centre.
On a side note, doesn't just about every distro do the same thing with Firefox's default homepage and Google? Except without contributing anything at all back to Mozilla.org?
I'm not particularly enthused about the way the article writer spun this. It sounds like somebody at Canonical overstepped his bounds and made a mistake. But the article author keeps saying Canonical shouldn't have... Canonical shouldn't have... Canonical shouldn't have... the author sounds like he has an axe to grind and is using this screwup as an excuse. It reads like he's seen that somebody made a mistake but is deliberately pushing the idea that Canonical the organisation did this deliberately.
As the article points out, an 'app' is very different from an 'application'.
The article is wrong. The two words mean the same thing. One is an abbreviation of the other. At a stretch, they may have different connotations, but even that's borderline.
I have never heard someone refer to an iPhone program as an 'application'
I hear it all the time. Apple's own documentation uses the terms "app" and "application" synonymously. Their main iOS development guide is called "iOS Application Programming Guide". The first paragraph reads:
This document is the starting point for learning how to create iOS applications. It contains fundamental information about the iOS environment and how your applications interact with that environment. It also contains important information about the architecture of iOS applications and tips for designing key parts of your application.
They seem pretty clear on the matter to me.
If someone calls something an 'app', no one will think they are talking about a desktop application.
Plenty of people will, "application" in the context of desktop applications has been routinely shortened to "app" since at least the mid 80s. "Killer app" is the example some people here have given. When people feel the need to differentiate between a desktop application and a web application, it is practically the norm to use the terms "desktop app" and "web app".
Also another complaint with the article: applications have always referred to more than just 'a self-contained piece of software installed on a PC or Mac'. All other operating systems have applications as well.
Then Apple took ownership, trimmed it to three letters, and within months the word 'app' became synonymous with small widgets of code for smartphones.
Er, no, just because something runs on a smartphone, it doesn't stop it being an application. A video editor a dev team put together with a few hundred thousand lines of code doesn't become "a small widget" simply because the amount of memory it has to play with is less than the computer sitting on your desk. What a ridiculous, pointless article.
they are acquiring association data from the tracked users. These fake users entered 'delhipublicschool40 chdjob' into the Bing search bar, then clicked on a link to 'a Credit Union website'.
The point many people are making is that the only existence of that link is as a result Google gave for that query. Google is the sole source of that association and it's finding its way into Bing's results, not because Bing crawled the web and figured out the association itself, but because Google figured out the association and Bing noticed people using Google successfully to follow that association.
Yes, it may be the case that Bing are doing this via a generic mechanism to track what users click on - Google never accused them of querying their engine directly to simply grab results - but the end effect is that Bing's user tracking is copying Google search results into Bing's search results.
The real question is how indirect this observation has to be before it is okay to do it. Google don't rely solely on page content themselves, they take notice of links other people provide on their pages, etc. Clearly relying on associations other people make is okay in the most general sense. But Microsoft are now aware that some of their data is coming directly from a competitor's algorithm. That's about as close as you can get without Microsoft deliberately scraping Google in particular.
The real question is whether Microsoft are going to blacklist Google's domains from their Bing tracking, or simply look the other way and benefit from it. I think their response has given some indication of that, and I think that if they are aware this is happening and don't take this simple step to avoid the copying, it is definitely over the line. They could quite easily have responded with something like "Our Bing toolbar tries to figure out links between keywords and websites and in this case it did too good a job, so we've blocked it from listening in on Google.com". I'd consider that to be a decent, ethical response to the problem and Microsoft did nothing of the sort.
Then that was a bug in Darcs. example.com was never a guarantee that any particular URL served from that domain would fail. Also note that they said that the URL would fail. That is not the same as the domain not existing. example.com has existed for years and years. Presumably they were appending a random string to http://example.com/ and hoping to get a 404. If the test suite was expecting example.com to not exist, then it never would have worked in the first place.
That's not even close to being true. HTML 3 was published in draft form in 1994, but was scrapped when the browser vendors went off to do their own thing. Eventually, the interoperable parts of the crap that the browser vendors invented was codified as HTML 3.2 in January 1997. HTML 4 came along shortly afterwards in December 1997. At most you can say that there was a three year gap, but since nobody really counts the HTML 3 draft, in reality the gap between specifications is less than a year, not the decade you make it out to be.
I've also been a web developer since the 90s. In my experience, I've always been waiting for the browsers to catch up with the specs. I don't know how people can say that the W3C are too slow with a straight face. There's no point publishing spec after spec if the browsers are years behind them.
You'll get pages that becomes invalid with time despite they were valid before.
That is a result of backward-incompatible changes, not the absence of version numbers.
No, that's not right at all. If a document is valid HTML 4.01 Strict (for example), then no amount of backward-incompatible changes to later versions of HTML will make that document invalid. Take away the version numbers and that is no longer the case.
How does removing the version number help the people who need to implement and work with the standard?
It doesn't, it's a fucking disaster. I'll give a concrete example. I used HTML 5 audio on a site with a Flash fallback for browsers that didn't support it. All is good and well. One day, I start getting complaints that the audio is broken. Turns out that a) the HTML 5 spec had changed and b) Firefox had changed to match in a minor point release. Firefox 3.51 worked, Firefox 3.5.2 didn't, as I recall. The new API was indistinguishable from the old API in as much as all the same objects and functions were there, but a return value had changed. So, even with the best practice method of feature detection, anybody writing to the old API was screwed.
So I fixed it up by removing the HTML 5 audio and made the decision to wait until HTML 5 was published in its final form. Something that I should have done to begin with really, it's madness to use HTML 5 at the moment as it's just not finished yet. You don't know what is going to change.
And now they want to do away with a "final" version altogether? Gee thanks, guys! How am I going to be able to trust it to be stable enough to rely on ever again? What's going to stop the same thing from happening over and over again?
Apple have this exact attitude and they just posted a record revenue of $26bn for this quarter, beating Wall St estimates by $2bn. Looking at their iPhone sales alone, they are the largest mobile phone vendor in the world by revenue. They have $60bn in cash reserves and no debt.
All other things being equal, sure, more customers = more profit. But all other things are rarely equal, so summing an entire company's future up into one single factor is idiotic.
If the Mozilla foundation wanted to support H.264, they'd release a plug-in that ties into codecs installed on the system.
MS did exactly this.
Of course Microsoft did that. That's exactly what they want. If Firefox did that too, then you'd end up with the situation where Firefox users running on Windows would be able to view H.264 and Firefox users on a Free operating system would not. And all the websites with "Firefox" as a tick box on their compatibility checklist would happily tick it and be on their merry way. Meanwhile, bye-bye cross-platform web. Can't possibly think why Microsoft would like that and Mozilla wouldn't.
Why would Google seem like an odd pioneer for mobile payments? They run a payment gateway and they maintain one of the biggest mobile operating systems. If anything, they are the most obvious company in the world to do this.
One wonders if Apple could be persuaded to strip access to the unique phone identifiers from apps.
Apple won't do this any time soon. They are very demanding when it comes to backwards compatibility, and even if they kept the API but gave a dummy identifier, this would break many apps. The most I can see happening is that Apple may put a clause in their guidelines. But they did that already, and got criticised for it. It's possible that they could generate a different permanent dummy identifier on a per-app basis, but this would still break several uses for the UDID.
Referring to the UDID as "personal information" strikes me as being quite inaccurate. It uniquely identifies a device, not a person. You cannot use the UDID to get any actual personal information unless the user gives that information. The only way to get personal information without the user's consent when you only have a UDID is for developers to collude; if a user gives personal information to one app that records it along with their UDID, then the developer of that app shares that information with another developer who only has the UDID, obviously that will work. But the same arguments mostly apply to things like IP addresses as well, and those aren't usually considered to be personal information.
important accounts such as email, banking or shopping and social networking sites
Okay, a vulnerable email account can lead to compromising other accounts, banking and shopping sites can cost you money... since when is Twitter or Facebook an "important" account in the same category as your bank account!?
In case anybody was wondering about that documentation, Apple specifically warn against this in the documentation for this API:
Be sure to validate the input you get from URLs passed to your application; see "Validating Input" in Secure Coding Guide to find out how to avoid problems related to URL handling.
And in that Secure Coding Guide, you will read things like this:
Any time your program accepts input from an uncontrolled source, there is a potential for a user to pass in data that does not conform to your expectations. If you don't validate the input, it might cause problems ranging from program crashes to allowing an attacker to execute his own code.
If your application has registered a URL scheme, you have to be careful about how you process commands sent to your application through the URL string. Whether you make the commands public or not, hackers will try sending commands to your application. If, for example, you provide a link or links to launch your application from your web site, hackers will look to see what commands you're sending and will try every variation on those commands they can think of. You must be prepared to handle, or to filter out, any commands that can be sent to your application, not only those commands that you would like to receive.
Apple are right, the responsibility is on the app developers. The data passed in through a URL is untrusted data. It's not just websites that you surf to that can send data to your app this way, other apps can too. That's its designed purpose; to "secure" this functionality on Apple's end would essentially be to remove it.
Applications that tell the system that they handle a URL and then blindly trust data they receive through that mechanism are essentially the same as web applications that blindly trust data they receive through URLs. It's a newbie web developer mistake, and many iOS developers have made the same mistake. This doesn't mean that Apple have a responsibility to "fix" this any more than it's the responsibility of HTTP to protect naïve web developers from trusting data they receive in URLs.
If there's one company that knows how to make interfaces, it's Apple
Sadly, their expertise in software doesn't seem to extend to web interfaces. Their developer portal for iOS development is shockingly bad and I've run across a number of cross-browser problems and missing functionality. iTunes Connect is even worse - I reported a major data loss bug to them that was triggered by using tabs, and their solution was "don't use tabs". Quite honestly Facebook and Apple are right down there at joint bottom when it comes to buggy and just plain broken web apps. Words cannot express how dismal their efforts are. If they were ever to get together and have a web baby, the sun would explode and I would welcome the fiery oblivion.
I haven't kept up with Rails development, precisely due to attitudes like these, but hopefully the injection of Merb will bring with it an injection of - yes I'll say that word - professionalism.
Who modded this insightful? The problems that Virginia are experiencing right now are caused by a single point of failure. Terry Childs, regardless of your opinions of his conviction, made himself a single point of failure. So out of every sysadmin in the entire fucking world, you picked the absolute least appropriate person for the job.
Slashdot Mirror
I don't think it's shady at all. Canonical build a complete operating environment. They take the majority of the code from the community, patch it heavily, contribute their own functionality and server resources, and integrate it all. They aren't simply selling a CD with stuff they've burned from the web. What the end user gets is Ubuntu, not a software collection.
When that user installs Ubuntu, installs a media player from Canonical's app centre, and then buys music, that sale is directly attributable to Ubuntu. If Banshee didn't exist, Canonical would use another media player to do the same thing or write their own if there wasn't one suitable. The actual media player in use isn't important. Canonical built the product, Canonical pushed the service, and Canonical runs the servers behind the app centre.
On a side note, doesn't just about every distro do the same thing with Firefox's default homepage and Google? Except without contributing anything at all back to Mozilla.org?
I'm not particularly enthused about the way the article writer spun this. It sounds like somebody at Canonical overstepped his bounds and made a mistake. But the article author keeps saying Canonical shouldn't have... Canonical shouldn't have... Canonical shouldn't have... the author sounds like he has an axe to grind and is using this screwup as an excuse. It reads like he's seen that somebody made a mistake but is deliberately pushing the idea that Canonical the organisation did this deliberately.
Did George Broussard go to work for Nokia or something?
The article is wrong. The two words mean the same thing. One is an abbreviation of the other. At a stretch, they may have different connotations, but even that's borderline.
I hear it all the time. Apple's own documentation uses the terms "app" and "application" synonymously. Their main iOS development guide is called "iOS Application Programming Guide". The first paragraph reads:
They seem pretty clear on the matter to me.
Plenty of people will, "application" in the context of desktop applications has been routinely shortened to "app" since at least the mid 80s. "Killer app" is the example some people here have given. When people feel the need to differentiate between a desktop application and a web application, it is practically the norm to use the terms "desktop app" and "web app".
iOS and Android are operating systems.
Er, no, just because something runs on a smartphone, it doesn't stop it being an application. A video editor a dev team put together with a few hundred thousand lines of code doesn't become "a small widget" simply because the amount of memory it has to play with is less than the computer sitting on your desk. What a ridiculous, pointless article.
The point many people are making is that the only existence of that link is as a result Google gave for that query. Google is the sole source of that association and it's finding its way into Bing's results, not because Bing crawled the web and figured out the association itself, but because Google figured out the association and Bing noticed people using Google successfully to follow that association.
Yes, it may be the case that Bing are doing this via a generic mechanism to track what users click on - Google never accused them of querying their engine directly to simply grab results - but the end effect is that Bing's user tracking is copying Google search results into Bing's search results.
The real question is how indirect this observation has to be before it is okay to do it. Google don't rely solely on page content themselves, they take notice of links other people provide on their pages, etc. Clearly relying on associations other people make is okay in the most general sense. But Microsoft are now aware that some of their data is coming directly from a competitor's algorithm. That's about as close as you can get without Microsoft deliberately scraping Google in particular.
The real question is whether Microsoft are going to blacklist Google's domains from their Bing tracking, or simply look the other way and benefit from it. I think their response has given some indication of that, and I think that if they are aware this is happening and don't take this simple step to avoid the copying, it is definitely over the line. They could quite easily have responded with something like "Our Bing toolbar tries to figure out links between keywords and websites and in this case it did too good a job, so we've blocked it from listening in on Google.com". I'd consider that to be a decent, ethical response to the problem and Microsoft did nothing of the sort.
Then that was a bug in Darcs. example.com was never a guarantee that any particular URL served from that domain would fail. Also note that they said that the URL would fail. That is not the same as the domain not existing. example.com has existed for years and years. Presumably they were appending a random string to http://example.com/ and hoping to get a 404. If the test suite was expecting example.com to not exist, then it never would have worked in the first place.
That's not even close to being true. HTML 3 was published in draft form in 1994, but was scrapped when the browser vendors went off to do their own thing. Eventually, the interoperable parts of the crap that the browser vendors invented was codified as HTML 3.2 in January 1997. HTML 4 came along shortly afterwards in December 1997. At most you can say that there was a three year gap, but since nobody really counts the HTML 3 draft, in reality the gap between specifications is less than a year, not the decade you make it out to be.
I've also been a web developer since the 90s. In my experience, I've always been waiting for the browsers to catch up with the specs. I don't know how people can say that the W3C are too slow with a straight face. There's no point publishing spec after spec if the browsers are years behind them.
No, that's not right at all. If a document is valid HTML 4.01 Strict (for example), then no amount of backward-incompatible changes to later versions of HTML will make that document invalid. Take away the version numbers and that is no longer the case.
It doesn't, it's a fucking disaster. I'll give a concrete example. I used HTML 5 audio on a site with a Flash fallback for browsers that didn't support it. All is good and well. One day, I start getting complaints that the audio is broken. Turns out that a) the HTML 5 spec had changed and b) Firefox had changed to match in a minor point release. Firefox 3.51 worked, Firefox 3.5.2 didn't, as I recall. The new API was indistinguishable from the old API in as much as all the same objects and functions were there, but a return value had changed. So, even with the best practice method of feature detection, anybody writing to the old API was screwed.
So I fixed it up by removing the HTML 5 audio and made the decision to wait until HTML 5 was published in its final form. Something that I should have done to begin with really, it's madness to use HTML 5 at the moment as it's just not finished yet. You don't know what is going to change.
And now they want to do away with a "final" version altogether? Gee thanks, guys! How am I going to be able to trust it to be stable enough to rely on ever again? What's going to stop the same thing from happening over and over again?
Apple have this exact attitude and they just posted a record revenue of $26bn for this quarter, beating Wall St estimates by $2bn. Looking at their iPhone sales alone, they are the largest mobile phone vendor in the world by revenue. They have $60bn in cash reserves and no debt.
All other things being equal, sure, more customers = more profit. But all other things are rarely equal, so summing an entire company's future up into one single factor is idiotic.
Of course Microsoft did that. That's exactly what they want. If Firefox did that too, then you'd end up with the situation where Firefox users running on Windows would be able to view H.264 and Firefox users on a Free operating system would not. And all the websites with "Firefox" as a tick box on their compatibility checklist would happily tick it and be on their merry way. Meanwhile, bye-bye cross-platform web. Can't possibly think why Microsoft would like that and Mozilla wouldn't.
Why would Google seem like an odd pioneer for mobile payments? They run a payment gateway and they maintain one of the biggest mobile operating systems. If anything, they are the most obvious company in the world to do this.
Apple won't do this any time soon. They are very demanding when it comes to backwards compatibility, and even if they kept the API but gave a dummy identifier, this would break many apps. The most I can see happening is that Apple may put a clause in their guidelines. But they did that already, and got criticised for it. It's possible that they could generate a different permanent dummy identifier on a per-app basis, but this would still break several uses for the UDID.
Referring to the UDID as "personal information" strikes me as being quite inaccurate. It uniquely identifies a device, not a person. You cannot use the UDID to get any actual personal information unless the user gives that information. The only way to get personal information without the user's consent when you only have a UDID is for developers to collude; if a user gives personal information to one app that records it along with their UDID, then the developer of that app shares that information with another developer who only has the UDID, obviously that will work. But the same arguments mostly apply to things like IP addresses as well, and those aren't usually considered to be personal information.
Okay, a vulnerable email account can lead to compromising other accounts, banking and shopping sites can cost you money... since when is Twitter or Facebook an "important" account in the same category as your bank account!?
They don't even need to do that. Fox News has argued in court that they have the right to lie to the public. They won the lawsuit on that basis.
Totally agreed. Try applying those low standards to any other product.
Any other product category, you'd consider the product to be broken and return it.
In case anybody was wondering about that documentation, Apple specifically warn against this in the documentation for this API:
And in that Secure Coding Guide, you will read things like this:
[disclaimer: iOS developer]
Apple are right, the responsibility is on the app developers. The data passed in through a URL is untrusted data. It's not just websites that you surf to that can send data to your app this way, other apps can too. That's its designed purpose; to "secure" this functionality on Apple's end would essentially be to remove it.
Applications that tell the system that they handle a URL and then blindly trust data they receive through that mechanism are essentially the same as web applications that blindly trust data they receive through URLs. It's a newbie web developer mistake, and many iOS developers have made the same mistake. This doesn't mean that Apple have a responsibility to "fix" this any more than it's the responsibility of HTTP to protect naïve web developers from trusting data they receive in URLs.
Sadly, their expertise in software doesn't seem to extend to web interfaces. Their developer portal for iOS development is shockingly bad and I've run across a number of cross-browser problems and missing functionality. iTunes Connect is even worse - I reported a major data loss bug to them that was triggered by using tabs, and their solution was "don't use tabs". Quite honestly Facebook and Apple are right down there at joint bottom when it comes to buggy and just plain broken web apps. Words cannot express how dismal their efforts are. If they were ever to get together and have a web baby, the sun would explode and I would welcome the fiery oblivion.
What do you expect? The baker had no more croissants.
Which assumptions and replies are you referring to?
This is something I wrote a while back: These are not the actions of people who care about writing the best code possible, these are the actions of people with egos chasing features and attention.
I haven't kept up with Rails development, precisely due to attitudes like these, but hopefully the injection of Merb will bring with it an injection of - yes I'll say that word - professionalism.
Who modded this insightful? The problems that Virginia are experiencing right now are caused by a single point of failure. Terry Childs, regardless of your opinions of his conviction, made himself a single point of failure. So out of every sysadmin in the entire fucking world, you picked the absolute least appropriate person for the job.
You know I was pretty surprised that the first comment attached to the article didn't contain the words "Kessel Run".