Yes indeed. Apple marketing have done a great job with GCD, apparently lots of people think it's something revolutionary. The more mundane truth is that it's a fancy thread pool. BFD. Thread pools fall squarely into the realm of "traditional approaches to multicore programming" that the Microsoft engineer in the article says doesn't work, and adding some bells/whistles like global load balancing isn't going to change that.
Thread pools have their place - they are an appropriate tool for certain types of work - where you have lots of small independent tasks. I used the equivalent API in Java in a program I recently wrote to download and decompress audio samples. That worked great because each sample is independent and thus the problem is "embarrassingly parallel". The issue is, embarrassingly parallel problems are kind of rare. We already know how to max out your cores with those problems and have done for decades - now what about the rest? Apple has no answer for that.
Why Java for Android? This is a good question. There are several reasons (that the Android team have discussed).
One is that ARM native code is bigger, size-wise, than Dalvik VM bytecode. So it takes up more memory. Unlike the iPhone, Android was designed from the start to multi-task between lots of different (user installed) apps. It's quite feasible to rapidly switch between apps with no delay on Android, and that means keeping multiple running programs in RAM simultaneously. So trading off some CPU time for memory is potentially a good design. Now that said, Java has some design issues that make it more profligate with heap memory than it maybe needs to be (eg utf16 for strings) so I don't have a good feel for whether the savings are cancelled out or not, but it's a justification given by the Android team.
Another is that Java is dramatically easier to program than a C-like language. I mean, incredibly monstrously easier. One problem with languages like C++ or Objective-C is that lots of people think they understand them but very few programmers really do. Case in point - I have an Apple-mad friend who ironically programs C# servers on Windows for his day job. But he figured he'd learn iPad development. I warned him that unmanaged development was a PITA but he wasn't convinced, so I showed him a page that discussed reference counting in ObjC (retain/release). He read it and said "well that seems simple enough" - doh. Another one bites the dust. I walked him through cycle leaks, ref leaks on error paths (no smart pointers in objc!), and some basic thread safety issues. By the end he realized that what looked simple really wasn't at all.
By going with Java, Android devs skip that pain. I'm fluent in C++ and Java, and have used both regularly in the past year. Java is reliably easier to write correct code in. I don't think it's unreasonable to base your OS on it. Microsoft has moved a lot of Windows development to.NET over the last few years for the same reasons.
Fortunately, being based on Java doesn't mean Android is inherently inefficient. Large parts of the runtime are written in C++, and you can write parts of your own app in native code too (eg for 3D graphics). You need to use Java to use most of the OS APIs but you really shouldn't be experiencing perf problems with things like gui layout - if you are, that's a hint you need to simplify your app rather than try to micro-optimize.
You've gone from "files signed by known providers should be whitelisted" to "zomg end of software freedom!" which is crazy. Having a valid signature means the file can be skipped, but not having one doesn't mean the file would necessarily be identified as bad. I agree with the OP - why the hell isn't BitDefender whitelisting files signed with known good keys? Surely that's one of the first things a virus scanner should implement?
Because it's comparing apples (people who wanted a gun and so bought one) vs oranges (people who may or may not have wanted one but are legally required to have one anyway).
Direct3D on OpenGL is actually a lot more mature than OpenGL on Direct3D thanks to years of development by the Wine teams. It's good enough to play a lot of modern, cutting edge games. ANGLE by contrast is still very new, it's not clear how much it supports right now.
That said, I'm not arguing that web 3D graphics should be based on Direct3D:-) I actually quite liked the Google O3D approach - define a new API that respects the platform and performance constraints of the web. Soldering OpenGL onto HTML doesn't feel like a very intuitive fit to me. Perhaps the way it'll go is Web3D ends up used primarily by NativeClient modules. Who knows.
It's worth noting that at the time YouTube was bought there was no equivalent of the Content ID technology in use. It prevents people simply re-uploading content that was taken down - Google developed it in-house.
Why would it double the download size? Did you RTFA? ANGLE is a translation layer that converts OpenGL calls into Direct3D calls. That is probably going to be "largeish" but it doesn't mean actually bundling drivers with Chrome itself.
The problem this solves - in many cases OpenGL drivers on Windows don't actually exist or are unusably bad. If I was feeling uncharitable, I'd say the web/html5 community seems to be doing another video tag fiasco, in trying to set another standard that ignores marketplace realities (cross platform opengl is dead). By releasing ANGLE Google is trying to make Web3D not entirely irrelevant. This is only one of the many hurdles originally identified by the Chrome 3D graphics team.
Onscreen keyboards are good for avoiding generic keylogging viruses. Keylogging and looking for passwords isn't too hard (especially if you can look for email address + tab + word with no spaces in + enter) but defeating an onscreen keyboard means either writing a program to search specifically for that implementation or recording/compressing/uploading/watching full videos of all screen activity which is way too heavy.
Of course two-factor transaction signing is even better....
OK so this is how it works. There are websites out there like these which allow you to quickly check your newly infected EXE against all the main AV products out there. Signature based AV is basically obsolete because there are lots of programs out there that will happily scramble your EXE for you, in the scene these are known simply as "crypters" and you will find many people in the PPI world advertising their crypter as being FUD (fully undetectable). Good article on this here. Of course with enough downloads eventually somebody savvy will catch on, unless your work is really good, and then your binary and uploading IP address are usually banned. At which point they do exactly what you'd expect - spin a new binary, get a new IP address and do it all over again.
If you're relying on only 15-20 other downloaders to certify something as "clean" and you regularly download warez you probably already have a rootkit on your system and have no idea it's even there.
If you're torrenting pirated apps isn't that exactly "downloading random EXE files and running them"? It's not like the people producing the cracked versions are liable if there are problems. You don't even know who they are. And with an 80% miss rate on commercial AV products, there's really no guarantee that these things are clean. BTW your Windows anti-malware solutions sucks, a lot of bots/droppers these days are protected with something like hacker defender which isn't going to trigger any startup monitoring tool.
There aren't that many botnets out there. I think most reputable observers peg it at around 6 or 7 big ones, from a spam perspective anyway. So taking one down is actually pretty awesome. Remember when McColo disappeared and spam levels dropped massively overnight? It wasn't that McColo itself pumped out spam, it was that the botnet C&C servers lived there.
As somebody who actually has to deal with the impacts of large botnets as part of my job at Google, I'd like to congratulate and thank the guys at Microsoft for this victory. Whether it has a noticeable impact on spam or not, it sends a powerful message to people thinking of making their own botnet - it can all end suddenly.
Building and maintaining a botnet is already pretty hard work.... between AV firms, Microsofts MSRT, users noticing problems and wiping the OS, removals by rival botnets and generally improving PC security botnet building has gone from something every man and his dog was doing to something very few can do well. Hardly any botnets become big. Most abuse I deal with comes in via bots that are apparently being shared or rented out to different (sometimes competing) spammers. That's an encouraging sign.
They obviously could modify and redistribute Firefox, they would simply face a choice between licensing the same patents or removing the ability to play h.264 (and thus relying implicitly on Flash which isn't going anywhere)
In practice, there aren't many (any?) successful forks of Firefox. It wouldn't exactly cause problems for millions of people. And if some new fork did come along, then by the time the organization behind it reached the "millions of users" stage they'd already need funding anyway.
You're right that specialization is fundamental and not needing to understand, say, CPU architecture is an improvement.
On the other hand, just because you don't need to understand how computers work anymore, doesn't mean it's a bad idea to do so.
I have been interviewing a lot of Java programmers lately. Many of them have a very weak understanding of how Java actually works. For a lot of projects, this doesn't matter. However it is very typical that, for instance, candidates underestimate the memory usage of their code by half because they don't know Java characters are 16 bit. Perhaps it's not surprising that Java programs have a reputation for being slow and bloated. And it goes without saying that for many real world programming problems, you are working within a memory and CPU budget, so not knowing the basic costs of the abstractions you work with is going to cause problems sooner or later.
Joel on Software has a good article on leaky abstractions. In my humble opinion, every working programmer should have read and pondered it.
There are actually several environments like that. You might want to check out HTMLUnit if you're a programmer. Alternatively the spammer community has done a great job of producing fully visual web-app automation environments, for instance, check out UBot Studio. If you can live with the presence of "solve captcha" and "generate random username" type commands and the community that comes with them, it might do what you want. Just be aware that a lot of websites treat screen scraping as abuse. Typically if they want to make data accessible there'll be an API, for instance Google offers REST APIs for many of its services.
Except that Adobe have said they do want to fix it, but can't, because Apple refuses the provide the APIs they need. So again, "proprietaryness" doesn't seem to be the problem here, open source html5 implementations would have the same issue.
I don't think openness of the standard is a benefit in this specific instance. Flash has to be optimized once per platform (so, 3 times). HTML5 video has to be optimized once per browser per platform, which is considerably more work. If only one popular browser doesn't do a good job, HTML5 video will be an unsuitable solution (because that browser will still need to use flash, and at that point you might as well deploy flash for everyone).
The hardware acceleration that Flash is benefitting from on Windows isn't h264 decoding from what I understand. It's actually colorspace conversion. Flash allows authors to overlay arbitrary graphics on top of video, which means mixing data from RGB and video colorspace. That in turn meant hitting non-accelerated codepaths. Adobe, Microsoft and the driver devs worked on fixing that and now Flash is super smooth on Windows. Apple meanwhile have either not created or not exposed the necessary APIs, so Flash sucks balls on a Mac and instead of Getting Shit Done, Jobs seems to prefer privately insulting the Flash developers (calling them lazy).
You seriously believe that you vs Uncle Sam might actually end with anything other than you being dead? What kind of bizarre fantasist are you? The US military spending is so huge that if the government wants you dead, you are SOL. If you have a handgun to defend yourself from the government then you need a reality check.
And how much space is wasted on your screen currently due to most lines being shorter than N characters? I use a single emacs window stretched across dual screens, and Google imposes an 80 column limit on its C++ code so with a slightly larger font this means I can fill the screen with code. But still, often some of that code is just guff that happens to surround the function I'm interested in. The CodeBubbles idea looks really nice and I can't wait to try it out for myself.
My understanding is that Apple now approves most apps in a few days.
And some apps (like Google Voice) are permenantly "pending". I think that's exactly what Hizonner meant - Apple is inconsistent. Some apps are approved quickly and others aren't. You can't know ahead of time which yours will be.
This is the biggest issue with Apple. Even so, it has affected a few percent of all the apps available for the platform
The problem is you don't know that. You're assuming it. Remember that not only can a developer not talk about the agreement they signed, but they can't talk about rejection either. For every developer who chose to violate that agreement by speaking out when their app was rejected for some stupid reason, there are probably a lot more who didn't because they fear Apples lawyer army (and hey, they did sign the agreement). For all you know, 90% of all apps are rejected permanently.
This is by far the biggest problem with the AppStore agreement. It's creating the exact opposite of Adam Smiths informed market. Nobody knows what the rules are, when they are enforced or how often because Apple tries hard to ensure developers work in an information vacuum.
Nobody would tolerate Microsoft doing this, because there's an understanding that computers matter and that just because Microsofts platform is for many devs the only way to make money shouldn't mean Microsoft have absolute control over everything that happens on it. And in fairness, Microsoft have never tried to pull this kind of stuff. Windows always supported multiple, competing SDKs. There was never any kind of "instant death" rules or absurd contracts.
Fortunately right now it's hard to argue smartphone apps really matter, especially the kind of dross found on the App Store. The only businesses that rely on the iPhone are Apple and app developers - once the majority of all businesses are using iPhone apps as part of their core competencies it might be time to demand the iPhone live up to the standards of openness set by Windows (and MacOS and Linux).
Try GWT and an associated GUI designer like Instantiations. I have used GWT but not the gui designers myself. GWT works pretty well for certain things. The Google Closure JS libraries can provide nice GUI (the stuff used to build google apps) if you want to work purely in JavaScript. As for Delphi/VB esque components like data grids, try ExtGWT, a rich gui library for GWT. Though I question the wisdom of trying to build a desktop style GUI on the web as I suspect one reason people like web apps is their typically simpler UI paradigms.
Of course it's convenient for Google to call only that privacy and completely ignore the fact that every Chrome installation has identifier about where you downloaded it, when you installed it.
That's hardly a new thing in software. Think of license keys! The ID is used to accurately count installs and nothing more.
everything you type to browser bar is sent to Google, any domain you visit is sent to Google, and so on...
In the Chrome I'm running that can all be switched off by pressing wrench -> options -> privacy and unchecking the boxes. Of course you'll be without some useful features, but the choice is offered.
Just because Google has no offices or data centers in China would not mean it would be unavailable there.
Well, if you go to China you'll find that it's amazingly easy to trigger the GFW. Browsing the English web is really flaky. Even if the Chinese govt didn't pro-actively block Google (as they have done with Facebook and YouTube) it'd still be a pain to use it.
Censored perhaps, but how difficult would it be for "Scientists" to get around that, or be exempted from it?
I don't think the Chinese government offers "exemptions" except for foreign journalists (sometimes). I also suspect they view circumvention dimly. The whole point of the GFW is to stop smart, influential people from getting ideas they shouldn't!
Slashdot Mirror
Yes indeed. Apple marketing have done a great job with GCD, apparently lots of people think it's something revolutionary. The more mundane truth is that it's a fancy thread pool. BFD. Thread pools fall squarely into the realm of "traditional approaches to multicore programming" that the Microsoft engineer in the article says doesn't work, and adding some bells/whistles like global load balancing isn't going to change that.
Thread pools have their place - they are an appropriate tool for certain types of work - where you have lots of small independent tasks. I used the equivalent API in Java in a program I recently wrote to download and decompress audio samples. That worked great because each sample is independent and thus the problem is "embarrassingly parallel". The issue is, embarrassingly parallel problems are kind of rare. We already know how to max out your cores with those problems and have done for decades - now what about the rest? Apple has no answer for that.
Why Java for Android? This is a good question. There are several reasons (that the Android team have discussed).
One is that ARM native code is bigger, size-wise, than Dalvik VM bytecode. So it takes up more memory. Unlike the iPhone, Android was designed from the start to multi-task between lots of different (user installed) apps. It's quite feasible to rapidly switch between apps with no delay on Android, and that means keeping multiple running programs in RAM simultaneously. So trading off some CPU time for memory is potentially a good design. Now that said, Java has some design issues that make it more profligate with heap memory than it maybe needs to be (eg utf16 for strings) so I don't have a good feel for whether the savings are cancelled out or not, but it's a justification given by the Android team.
Another is that Java is dramatically easier to program than a C-like language. I mean, incredibly monstrously easier. One problem with languages like C++ or Objective-C is that lots of people think they understand them but very few programmers really do. Case in point - I have an Apple-mad friend who ironically programs C# servers on Windows for his day job. But he figured he'd learn iPad development. I warned him that unmanaged development was a PITA but he wasn't convinced, so I showed him a page that discussed reference counting in ObjC (retain/release). He read it and said "well that seems simple enough" - doh. Another one bites the dust. I walked him through cycle leaks, ref leaks on error paths (no smart pointers in objc!), and some basic thread safety issues. By the end he realized that what looked simple really wasn't at all.
By going with Java, Android devs skip that pain. I'm fluent in C++ and Java, and have used both regularly in the past year. Java is reliably easier to write correct code in. I don't think it's unreasonable to base your OS on it. Microsoft has moved a lot of Windows development to .NET over the last few years for the same reasons.
Fortunately, being based on Java doesn't mean Android is inherently inefficient. Large parts of the runtime are written in C++, and you can write parts of your own app in native code too (eg for 3D graphics). You need to use Java to use most of the OS APIs but you really shouldn't be experiencing perf problems with things like gui layout - if you are, that's a hint you need to simplify your app rather than try to micro-optimize.
You've gone from "files signed by known providers should be whitelisted" to "zomg end of software freedom!" which is crazy. Having a valid signature means the file can be skipped, but not having one doesn't mean the file would necessarily be identified as bad. I agree with the OP - why the hell isn't BitDefender whitelisting files signed with known good keys? Surely that's one of the first things a virus scanner should implement?
Because it's comparing apples (people who wanted a gun and so bought one) vs oranges (people who may or may not have wanted one but are legally required to have one anyway).
Direct3D on OpenGL is actually a lot more mature than OpenGL on Direct3D thanks to years of development by the Wine teams. It's good enough to play a lot of modern, cutting edge games. ANGLE by contrast is still very new, it's not clear how much it supports right now.
That said, I'm not arguing that web 3D graphics should be based on Direct3D :-) I actually quite liked the Google O3D approach - define a new API that respects the platform and performance constraints of the web. Soldering OpenGL onto HTML doesn't feel like a very intuitive fit to me. Perhaps the way it'll go is Web3D ends up used primarily by NativeClient modules. Who knows.
In fact if you read the source you'll see it was developed by TransGaming.
It's worth noting that at the time YouTube was bought there was no equivalent of the Content ID technology in use. It prevents people simply re-uploading content that was taken down - Google developed it in-house.
Why would it double the download size? Did you RTFA? ANGLE is a translation layer that converts OpenGL calls into Direct3D calls. That is probably going to be "largeish" but it doesn't mean actually bundling drivers with Chrome itself.
The problem this solves - in many cases OpenGL drivers on Windows don't actually exist or are unusably bad. If I was feeling uncharitable, I'd say the web/html5 community seems to be doing another video tag fiasco, in trying to set another standard that ignores marketplace realities (cross platform opengl is dead). By releasing ANGLE Google is trying to make Web3D not entirely irrelevant. This is only one of the many hurdles originally identified by the Chrome 3D graphics team.
Onscreen keyboards are good for avoiding generic keylogging viruses. Keylogging and looking for passwords isn't too hard (especially if you can look for email address + tab + word with no spaces in + enter) but defeating an onscreen keyboard means either writing a program to search specifically for that implementation or recording/compressing/uploading/watching full videos of all screen activity which is way too heavy.
Of course two-factor transaction signing is even better ....
OK so this is how it works. There are websites out there like these which allow you to quickly check your newly infected EXE against all the main AV products out there. Signature based AV is basically obsolete because there are lots of programs out there that will happily scramble your EXE for you, in the scene these are known simply as "crypters" and you will find many people in the PPI world advertising their crypter as being FUD (fully undetectable). Good article on this here. Of course with enough downloads eventually somebody savvy will catch on, unless your work is really good, and then your binary and uploading IP address are usually banned. At which point they do exactly what you'd expect - spin a new binary, get a new IP address and do it all over again.
If you're relying on only 15-20 other downloaders to certify something as "clean" and you regularly download warez you probably already have a rootkit on your system and have no idea it's even there.
If you're torrenting pirated apps isn't that exactly "downloading random EXE files and running them"? It's not like the people producing the cracked versions are liable if there are problems. You don't even know who they are. And with an 80% miss rate on commercial AV products, there's really no guarantee that these things are clean. BTW your Windows anti-malware solutions sucks, a lot of bots/droppers these days are protected with something like hacker defender which isn't going to trigger any startup monitoring tool.
There aren't that many botnets out there. I think most reputable observers peg it at around 6 or 7 big ones, from a spam perspective anyway. So taking one down is actually pretty awesome. Remember when McColo disappeared and spam levels dropped massively overnight? It wasn't that McColo itself pumped out spam, it was that the botnet C&C servers lived there.
As somebody who actually has to deal with the impacts of large botnets as part of my job at Google, I'd like to congratulate and thank the guys at Microsoft for this victory. Whether it has a noticeable impact on spam or not, it sends a powerful message to people thinking of making their own botnet - it can all end suddenly.
Building and maintaining a botnet is already pretty hard work .... between AV firms, Microsofts MSRT, users noticing problems and wiping the OS, removals by rival botnets and generally improving PC security botnet building has gone from something every man and his dog was doing to something very few can do well. Hardly any botnets become big. Most abuse I deal with comes in via bots that are apparently being shared or rented out to different (sometimes competing) spammers. That's an encouraging sign.
They obviously could modify and redistribute Firefox, they would simply face a choice between licensing the same patents or removing the ability to play h.264 (and thus relying implicitly on Flash which isn't going anywhere)
In practice, there aren't many (any?) successful forks of Firefox. It wouldn't exactly cause problems for millions of people. And if some new fork did come along, then by the time the organization behind it reached the "millions of users" stage they'd already need funding anyway.
The reality is somewhere between the two.
You're right that specialization is fundamental and not needing to understand, say, CPU architecture is an improvement.
On the other hand, just because you don't need to understand how computers work anymore, doesn't mean it's a bad idea to do so.
I have been interviewing a lot of Java programmers lately. Many of them have a very weak understanding of how Java actually works. For a lot of projects, this doesn't matter. However it is very typical that, for instance, candidates underestimate the memory usage of their code by half because they don't know Java characters are 16 bit. Perhaps it's not surprising that Java programs have a reputation for being slow and bloated. And it goes without saying that for many real world programming problems, you are working within a memory and CPU budget, so not knowing the basic costs of the abstractions you work with is going to cause problems sooner or later.
Joel on Software has a good article on leaky abstractions. In my humble opinion, every working programmer should have read and pondered it.
There are actually several environments like that. You might want to check out HTMLUnit if you're a programmer. Alternatively the spammer community has done a great job of producing fully visual web-app automation environments, for instance, check out UBot Studio. If you can live with the presence of "solve captcha" and "generate random username" type commands and the community that comes with them, it might do what you want. Just be aware that a lot of websites treat screen scraping as abuse. Typically if they want to make data accessible there'll be an API, for instance Google offers REST APIs for many of its services.
Except that Adobe have said they do want to fix it, but can't, because Apple refuses the provide the APIs they need. So again, "proprietaryness" doesn't seem to be the problem here, open source html5 implementations would have the same issue.
I don't think openness of the standard is a benefit in this specific instance. Flash has to be optimized once per platform (so, 3 times). HTML5 video has to be optimized once per browser per platform, which is considerably more work. If only one popular browser doesn't do a good job, HTML5 video will be an unsuitable solution (because that browser will still need to use flash, and at that point you might as well deploy flash for everyone).
The hardware acceleration that Flash is benefitting from on Windows isn't h264 decoding from what I understand. It's actually colorspace conversion. Flash allows authors to overlay arbitrary graphics on top of video, which means mixing data from RGB and video colorspace. That in turn meant hitting non-accelerated codepaths. Adobe, Microsoft and the driver devs worked on fixing that and now Flash is super smooth on Windows. Apple meanwhile have either not created or not exposed the necessary APIs, so Flash sucks balls on a Mac and instead of Getting Shit Done, Jobs seems to prefer privately insulting the Flash developers (calling them lazy).
You seriously believe that you vs Uncle Sam might actually end with anything other than you being dead? What kind of bizarre fantasist are you? The US military spending is so huge that if the government wants you dead, you are SOL. If you have a handgun to defend yourself from the government then you need a reality check.
OpenID and OAuth are open standards.
And how much space is wasted on your screen currently due to most lines being shorter than N characters? I use a single emacs window stretched across dual screens, and Google imposes an 80 column limit on its C++ code so with a slightly larger font this means I can fill the screen with code. But still, often some of that code is just guff that happens to surround the function I'm interested in. The CodeBubbles idea looks really nice and I can't wait to try it out for myself.
And some apps (like Google Voice) are permenantly "pending". I think that's exactly what Hizonner meant - Apple is inconsistent. Some apps are approved quickly and others aren't. You can't know ahead of time which yours will be.
The problem is you don't know that. You're assuming it. Remember that not only can a developer not talk about the agreement they signed, but they can't talk about rejection either. For every developer who chose to violate that agreement by speaking out when their app was rejected for some stupid reason, there are probably a lot more who didn't because they fear Apples lawyer army (and hey, they did sign the agreement). For all you know, 90% of all apps are rejected permanently.
This is by far the biggest problem with the AppStore agreement. It's creating the exact opposite of Adam Smiths informed market. Nobody knows what the rules are, when they are enforced or how often because Apple tries hard to ensure developers work in an information vacuum.
Nobody would tolerate Microsoft doing this, because there's an understanding that computers matter and that just because Microsofts platform is for many devs the only way to make money shouldn't mean Microsoft have absolute control over everything that happens on it. And in fairness, Microsoft have never tried to pull this kind of stuff. Windows always supported multiple, competing SDKs. There was never any kind of "instant death" rules or absurd contracts.
Fortunately right now it's hard to argue smartphone apps really matter, especially the kind of dross found on the App Store. The only businesses that rely on the iPhone are Apple and app developers - once the majority of all businesses are using iPhone apps as part of their core competencies it might be time to demand the iPhone live up to the standards of openness set by Windows (and MacOS and Linux).
Try GWT and an associated GUI designer like Instantiations. I have used GWT but not the gui designers myself. GWT works pretty well for certain things. The Google Closure JS libraries can provide nice GUI (the stuff used to build google apps) if you want to work purely in JavaScript. As for Delphi/VB esque components like data grids, try ExtGWT, a rich gui library for GWT. Though I question the wisdom of trying to build a desktop style GUI on the web as I suspect one reason people like web apps is their typically simpler UI paradigms.
That's hardly a new thing in software. Think of license keys! The ID is used to accurately count installs and nothing more.
In the Chrome I'm running that can all be switched off by pressing wrench -> options -> privacy and unchecking the boxes. Of course you'll be without some useful features, but the choice is offered.
Well, if you go to China you'll find that it's amazingly easy to trigger the GFW. Browsing the English web is really flaky. Even if the Chinese govt didn't pro-actively block Google (as they have done with Facebook and YouTube) it'd still be a pain to use it.
I don't think the Chinese government offers "exemptions" except for foreign journalists (sometimes). I also suspect they view circumvention dimly. The whole point of the GFW is to stop smart, influential people from getting ideas they shouldn't!