Yes: Don't use Javascript to send HTTP requests. Just like we had to tell everyone not to use SSI's because of vulnerabilities created by those, we should stop using Javascript to send HTTP requests. If you can demonstrate a real need for a web page that sends HTTP requests in the background, I can demonstrate a real applet that does the job with fewer security risks. There were webmail interfaces a long time before XMLHTTPRequest was invented, and they were immensely popular. So why did we reinvent the wheel?
Another problem is the users themselves. People like the convenience of a web interface, and don't want to be tied to one computer using an email client. I try to get people to encrypt confidential emails, but as soon as I say, "So you need to set up Thunderbird..." I am met with skepticism. One friend of mine was worried that someone might be reading her emails (because she had used a predictable password); I set up Thunderbird with GPG for her, but within a few weeks she was back to the web interface.
When it comes to convenience vs. privacy or security, people will choose convenience.
As I understand, he was actually trying to sell software, and needed a short, easy to remember term to describe what the software was doing. "AJAX" was apparently the best he could do (I personally would have gone with "triforce," but then again, I'm not in marketing...).
Or, since every other phone maker sells phones across networks, and Apple is going for exclusive contracts elsewhere, we can conclude that your "Well, Apple may have realized..." and "it may be this" are just speculation. Look at Apple's marketing campaigns. They love being exclusive, it is driving their sales. The fact that Apple products appear to be floating above everything else is the best marketing campaign Apple has thought of. "Think different" and "I'm a cool guy personifying a Mac, there is a geeky guy personifying the rest of the market." iPods only officially work with iTunes, and iTunes music can't be played on anything else. Mac OS X only officially runs on Apple hardware, and until very recently, Apple hardware only officially ran Mac OS X. And iPhones are only available with one carrier, even though other phones are available on every other carrier.
Sorry to burst your bubble, but Apple isn't some shiny, brilliant group of engineers that love seeing their products in use. Apple's moves have nothing to do with creating superior technology, unless they can get a hold of it for free; their moves have to do with making money, as much as possible as fast as possible, and putting up a facade of being on a completely different level than the rest of the market drives up their sales.
Yes, from a code perspective, PHP and ASP look very similar. But from an execution perspective, they are not. PHP is basically run like a CGI program (I am speaking from an Apache perspective here) -- when you request a PHP page, a process is forked off that executes the PHP program, and STDOUT for that program will be the web page that is returned. This is sped up with mod_php, but the basic model is the same: a process is forked off to handle your request. It is a very lightweight, UNIX-esque model, which is not surprising since the original CGI spec was written well before Java and Windows were relevant in the server world.
Application servers like.NET are different -- heavy, with lots of metadata to make database development easier, and with a focus on object oriented language features (I don't develop much in.NET, but with JEE, pages are basically represented with objects, and data displayed on the page is represented by members of the object). What you aren't told is that decreased development time comes at the expense of decreased server capacity -- on the same hardware, a CGI website can support more concurrent users than an application server. There are scalability arguments for JEE and.NET, although those arguments are shot down with real data (the 2.6 series kernel features very efficient forking, on the order of O(1), and beats thread spawning on Windows!). It isn't very important for development on an intranet, since it is unlikely that you will have hundreds of millions of requests per day on an internal network, but for public websites, this consideration is very important (think Slashdot effect).
About the same amount of time for them to switch back to their old DHTML code, when the new code stopped working on some browsers (including my browser).
Well, they have millions of users, who are fed ads with every page request. I'm pretty sure that they are making a lot of money -- or else Google wouldn't be doing so well either.
Probably because it would cost so much for FB to migrate to.NET (or any application server). Think about how much traffic FB gets -- now think about how much extra hardware they would need to aquire to switch from a CGI-esque technology like PHP to a big and heavy AS like.NET, let alone the man hours needed to recode everything.
Sorry, I guess that like me, you are not special enough to be in the exclusive Apple club. I cannot run iTunes on my computer, nor can I access iTunes 7 shares over my LAN. Remember: Apple is EXCLUSIVE! Apple is a high standard than everything else; you can't have everyone using Apple hardware and software, or else Apple wouldn't have that image of something that is "better" than what everyone else has.
Why else would they deliberately limit their market by refusing to license iPhones to other carriers?
This hash has absolutely no technical use. The iPods worked fine before the hash, and exhibit the same level of functionality with the hash. All the hash does is restrict how the iPod can be synced.
Or can you demonstrate a legitimate, technical need for that hash to be there?
The software is part of the configuration of the phone, not the phone itself. Software (including firmware) is not some tangible thing like a car engine. Software is just another form of data -- data that directs the behavior of the hardware. A better comparison is taking your new Chevy, and reconfiguring the the buttons on your dashboard, so that they are more comfortable for you, and Chevy claiming that voids your warranty when your brakes fail.
Oh no, certainly not. But a developer could probably tell what effect his code will have on the hacked iPhones (developers should be sitting down and carefully designing code before writing it). The developers would probably mention it as a footnote or afterthought, but I doubt they would simply skip over it when their manager says, "OK, tell us what this update does and how it will affect the customers."
If they grant you a warranty on the phone, then that warranty is on THE PHONE. If you change the configuration of the phone, including the software, they can only get out of their warranty obligation if your configuration actually damaged the phone. The iPhone is billed as a computer (and it is), so installing different software on it should not void the warranty, unless that software deliberately damaged the phone. If they install software and your phone that stops the phone from working, I fail to see how they are not responsible for fulfilling the warranty.
But I can see them simply re-locking the phone as part of the warranty. IANAL, by the way.
Apple knows that the best course is to protect their exclusive contract, not to leave the phones as-is, and certainly not to shrug off people hacking their iPhones. Apple isn't doing this because they dislike their customers; they are doing it because they don't respect their customers. They also happen to be thwarting attempts to sync iPods with software other than iTunes -- I suppose this is also a completely normal, acceptable practice, to prevent people who use Amarok or Rhythmbox from syncing up their iPod?
Maybe they didn't tell their developers to find a way to cause hacked iPhones to stop functioning. But I doubt that when one of their developers said at a meeting, "...and this update will cause unlocked iPhones to stop functioning..." they thought anything other than, "Good!"
"Becoming" evil? Apple is not some shrine of ethics or panacea of consumer/developer friendliness. This is a company that has tried suing bloggers for talking about upcoming Apple products. One of the first companies to employ TPM-style chips on a widespread basis. The company that takes 50 times more than they give -- GUI, OOP, BSD, KHTML, etc. The company that is locking down iPods so that I won't be able to use them with my computer anymore (because, GASP, I don't run an OS that they support with iTunes!).
If you are surprised by Apple's behavior, you should take a look at some news archives and see what Apple has done in the past. And if you think that they won't try to shut off unlocked iPhones, you REALLY need to review the news archives. In the Apple world, "lock-in" takes on an entirely new meaning.
AJAX is not a technology, it is a loosely defined method of designing a web app. It originally referred to an IE-only technique of transferring data between a web browser and a server, but has since been used to describe all sorts of things, even things that don't involve XMLHttpRequest objects. I have seen designs that use hidden frames to send POST requests to a server as "AJAX," and among non-programmers, I have even heard AJAX used to refer to plain old DHTML pages. "AJAX" was invented during a marketing meeting to refer to a set of technologies that some sales rep was trying sell, at least as I have heard it.
Nothing at all. It is a colloquial term, like AJAX. It refers to any number of things, from social networking to web apps, as long as it is done without applets. I think.
I thoroughly agree with you on this one. Unfortunately, I stand alone when I ask a question like, "What has a GUI added to this system? Why wasn't a text-base solution sufficient?" People think I am some kind of lunatic if I propose a non-AJAX/Application Server/wiz-bang solution to a problem. I understand that sort of mentality from end-users, but from programmers?
My advice is to analyze the needs of the system before designing it. Don't assume a GUI or AJAX front end is the best possible way to do things. My favorite example is the library system in my county: their computers are using a console system for check in/check out, card processing, etc. The beauty of it is that the bar code scanner they use behaves like a keyboard, so that each scan is just a series of a numeric keystrokes following by an end-of-line. It is simple, the 80 year old librarians have no problem using it, and it doesn't require any difficult to coordinate mouse movements (as anyone who has studied this knows, using the mouse requires a lot of brain activity than using the keyboard). The console very accurately maps the workflow; a GUI wouldn't add very much, other than sheer lines of code, and a web interface would actually slow down the people who need to use it.
Sure, there are cases where a GUI or web interface is better than a console interface. But that is why an analysis is needed before any code is written. As your friend's situation demonstrates, a well design system can work for many years without any trouble.
Well, it really depends on what you are trying to do. Personally speaking, if I were designing some sort of publicly accessible website, I would be looking at what will perform best under very heavy loads (and CGI programs running on a system with highly optimized forking win on this, in my opinion. And apparently in the Slashdot maintainers' opinions, since this website is coded in PERL). If you are coding something for an internal intranet in a medium sized corporation, you might have a bit more flexibility, and can get away with a heavier framework to make your life easier.
Then again, I advocate writing web apps in C++ or Ada, so you might be inclined to accuse me of being 20 years behind the times. I'll say this: if you can handle the formal design process, a C++ web app is no problem at all.
In theory, yes, the FBI should prosecute them. In practice, I doubt it will happen.
Speaking of theory, as long as they are operating here in the states, a denial of service attack is breaking the law. At the very least, they probably knocked out a few of their ISP's routers during the attack, which is technically harmful to their ISP. IANAL, but I think that is a violation of the law.
Oh not, the FBI isn't interested in big companies that break computer laws. They are interested in teenagers and organized crime. But flash your corporate charter, and suddenly, you aren't a hacker, you are defending the profits of a major content studio from hackers who are using deCSS.
Funny you should say this, because to date, the only radial menu system I have ever encountered was an open source window manager. I would say that counts a massive step forward in UI design (I live for the day when radial menus are the norm, but like Dvorak keyboards, it probably won't happen).
Red Hat is not all about support, they continue to sell licenses for Red Hat Enterprise Linux.
The GPL is based on copyrights. So is the BSD license. So were all software license up to the 1980s.
Microsoft does distribute a "services for UNIX" pack, that is mostly GPL'ed code. I didn't say it is their entire revenue model, but it is an important part of some of their large enterprise sales.
Novell is now a Linux distributor.
Sun wouldn't be relevant if it wasn't for their software, which is increasingly GPL'ed.
IBM's mainframe business is now centered around Linux, and I wouldn't hesitate to say that their mainframe division remains one of their most important sources of revenue. Especially now that they don't manufacture PCs, and the smallest systems they sell are servers running Red Hat Enterprise Linux.
Yes, some of these companies jealously guard their IP. But IBM, Red Hat, and Sun certainly don't; in fact, they formed an IP alliance, and have made promises not to sue anyone over IP violations. I would hardly argue that these companies need to employ DMCA-style copyright abuse in order to make money, considering that they are still among the largest players in the computer industry and they aren't going to leave any time soon. In fact, my point all along has been that copyrights should be enforced, just not in the way that the authors of the DMCA clearly envisioned. The DMCA is an example of copyrights applied in a completely backward direction. The goal of copyrights are to encourage authors (including musicians and programmers) to produce new works, not to have people sue each other left and right because they were unable to figure out another way to bring in revenue from their work.
Really, why do people think that copyrights are meant to bring in money for authors? Copyrights are just meant as a way to encourage progress, which is why we have a fair use doctrine. The DMCA began a process of demolishing fair use; after all, how can I possibly do a remix of a song if I am legally barred from decrypting it? This is a backwards step, and moves us towards a society based on one person or group of people controlling another. My argument isn't against copyrights as a whole, it is against the DMCA and the mentality that surrounds it; a selfish mentality, where no one may help their neighbor, have control over content that they purchase, or make any level of fair use copies.
Slashdot Mirror
Yes: Don't use Javascript to send HTTP requests. Just like we had to tell everyone not to use SSI's because of vulnerabilities created by those, we should stop using Javascript to send HTTP requests. If you can demonstrate a real need for a web page that sends HTTP requests in the background, I can demonstrate a real applet that does the job with fewer security risks. There were webmail interfaces a long time before XMLHTTPRequest was invented, and they were immensely popular. So why did we reinvent the wheel?
When it comes to convenience vs. privacy or security, people will choose convenience.
As I understand, he was actually trying to sell software, and needed a short, easy to remember term to describe what the software was doing. "AJAX" was apparently the best he could do (I personally would have gone with "triforce," but then again, I'm not in marketing...).
Sorry to burst your bubble, but Apple isn't some shiny, brilliant group of engineers that love seeing their products in use. Apple's moves have nothing to do with creating superior technology, unless they can get a hold of it for free; their moves have to do with making money, as much as possible as fast as possible, and putting up a facade of being on a completely different level than the rest of the market drives up their sales.
Application servers like .NET are different -- heavy, with lots of metadata to make database development easier, and with a focus on object oriented language features (I don't develop much in .NET, but with JEE, pages are basically represented with objects, and data displayed on the page is represented by members of the object). What you aren't told is that decreased development time comes at the expense of decreased server capacity -- on the same hardware, a CGI website can support more concurrent users than an application server. There are scalability arguments for JEE and .NET, although those arguments are shot down with real data (the 2.6 series kernel features very efficient forking, on the order of O(1), and beats thread spawning on Windows!). It isn't very important for development on an intranet, since it is unlikely that you will have hundreds of millions of requests per day on an internal network, but for public websites, this consideration is very important (think Slashdot effect).
About the same amount of time for them to switch back to their old DHTML code, when the new code stopped working on some browsers (including my browser).
Well, they have millions of users, who are fed ads with every page request. I'm pretty sure that they are making a lot of money -- or else Google wouldn't be doing so well either.
Probably because it would cost so much for FB to migrate to .NET (or any application server). Think about how much traffic FB gets -- now think about how much extra hardware they would need to aquire to switch from a CGI-esque technology like PHP to a big and heavy AS like .NET, let alone the man hours needed to recode everything.
Why else would they deliberately limit their market by refusing to license iPhones to other carriers?
Or can you demonstrate a legitimate, technical need for that hash to be there?
The software is part of the configuration of the phone, not the phone itself. Software (including firmware) is not some tangible thing like a car engine. Software is just another form of data -- data that directs the behavior of the hardware. A better comparison is taking your new Chevy, and reconfiguring the the buttons on your dashboard, so that they are more comfortable for you, and Chevy claiming that voids your warranty when your brakes fail.
Because the iPhone is cool.
Oh no, certainly not. But a developer could probably tell what effect his code will have on the hacked iPhones (developers should be sitting down and carefully designing code before writing it). The developers would probably mention it as a footnote or afterthought, but I doubt they would simply skip over it when their manager says, "OK, tell us what this update does and how it will affect the customers."
But I can see them simply re-locking the phone as part of the warranty. IANAL, by the way.
Maybe they didn't tell their developers to find a way to cause hacked iPhones to stop functioning. But I doubt that when one of their developers said at a meeting, "...and this update will cause unlocked iPhones to stop functioning..." they thought anything other than, "Good!"
If you are surprised by Apple's behavior, you should take a look at some news archives and see what Apple has done in the past. And if you think that they won't try to shut off unlocked iPhones, you REALLY need to review the news archives. In the Apple world, "lock-in" takes on an entirely new meaning.
AJAX is not a technology, it is a loosely defined method of designing a web app. It originally referred to an IE-only technique of transferring data between a web browser and a server, but has since been used to describe all sorts of things, even things that don't involve XMLHttpRequest objects. I have seen designs that use hidden frames to send POST requests to a server as "AJAX," and among non-programmers, I have even heard AJAX used to refer to plain old DHTML pages. "AJAX" was invented during a marketing meeting to refer to a set of technologies that some sales rep was trying sell, at least as I have heard it.
Nothing at all. It is a colloquial term, like AJAX. It refers to any number of things, from social networking to web apps, as long as it is done without applets. I think.
My advice is to analyze the needs of the system before designing it. Don't assume a GUI or AJAX front end is the best possible way to do things. My favorite example is the library system in my county: their computers are using a console system for check in/check out, card processing, etc. The beauty of it is that the bar code scanner they use behaves like a keyboard, so that each scan is just a series of a numeric keystrokes following by an end-of-line. It is simple, the 80 year old librarians have no problem using it, and it doesn't require any difficult to coordinate mouse movements (as anyone who has studied this knows, using the mouse requires a lot of brain activity than using the keyboard). The console very accurately maps the workflow; a GUI wouldn't add very much, other than sheer lines of code, and a web interface would actually slow down the people who need to use it.
Sure, there are cases where a GUI or web interface is better than a console interface. But that is why an analysis is needed before any code is written. As your friend's situation demonstrates, a well design system can work for many years without any trouble.
Then again, I advocate writing web apps in C++ or Ada, so you might be inclined to accuse me of being 20 years behind the times. I'll say this: if you can handle the formal design process, a C++ web app is no problem at all.
...will load plugins on demand anyway (if you select that option). It can also block plugins for certain domains.
Speaking of theory, as long as they are operating here in the states, a denial of service attack is breaking the law. At the very least, they probably knocked out a few of their ISP's routers during the attack, which is technically harmful to their ISP. IANAL, but I think that is a violation of the law.
Oh not, the FBI isn't interested in big companies that break computer laws. They are interested in teenagers and organized crime. But flash your corporate charter, and suddenly, you aren't a hacker, you are defending the profits of a major content studio from hackers who are using deCSS.
Funny you should say this, because to date, the only radial menu system I have ever encountered was an open source window manager. I would say that counts a massive step forward in UI design (I live for the day when radial menus are the norm, but like Dvorak keyboards, it probably won't happen).
Yes, some of these companies jealously guard their IP. But IBM, Red Hat, and Sun certainly don't; in fact, they formed an IP alliance, and have made promises not to sue anyone over IP violations. I would hardly argue that these companies need to employ DMCA-style copyright abuse in order to make money, considering that they are still among the largest players in the computer industry and they aren't going to leave any time soon. In fact, my point all along has been that copyrights should be enforced, just not in the way that the authors of the DMCA clearly envisioned. The DMCA is an example of copyrights applied in a completely backward direction. The goal of copyrights are to encourage authors (including musicians and programmers) to produce new works, not to have people sue each other left and right because they were unable to figure out another way to bring in revenue from their work.
Really, why do people think that copyrights are meant to bring in money for authors? Copyrights are just meant as a way to encourage progress, which is why we have a fair use doctrine. The DMCA began a process of demolishing fair use; after all, how can I possibly do a remix of a song if I am legally barred from decrypting it? This is a backwards step, and moves us towards a society based on one person or group of people controlling another. My argument isn't against copyrights as a whole, it is against the DMCA and the mentality that surrounds it; a selfish mentality, where no one may help their neighbor, have control over content that they purchase, or make any level of fair use copies.