AJAX is great... for applications where the state is not particularly important (i.e., enough to be bookmarked). A product catalog and shopping cart is not one of this type.
What are you talking about? You can use AJAX for a product catalogue and shopping cart easily without breaking things.
What matters is that important entry points should be addressable by URI. When somebody adds something to their shopping cart, it doesn't matter that immediately following the action, the resulting view isn't addressable, because the shopping cart state is part of the session, not simply the page that is being addressed.
Look at any halfway decent shopping cart system - when you have something in your shopping cart, that's indicated on every page on the website. You don't need to be able to address the shopping cart directly, because the last page the user was on will include this information no matter where they were in the site. And, because it's part of the session and not any particular page, that information will always be up to date - you don't need to keep giving them a new URI every time you update the cart.
If you act in a way actively against sharing copyright material, you should be okay.
No, if you don't act in a way actively encouraging copyright infringement, you should be okay. The Court said:
"We hold that one who distributes a device with the object of promoting its use to infringe copyright, as shown by clear expression or other affirmative steps taken to foster infringement, is liable for the resulting acts of infringement by third parties"
Actively encouraging copyright infringement is not the same as not actively preventing copyright infringement. A program can't determine whether something is copyright infringement or not; if they had ruled that you need to actively prevent copyright infringement, then it would essentially outlaw file sharing entirely.
Numerous apps have shown that it's possible to create a webmail app using basic HTML and server-side code. But GMail isn't exclusively for "us", it's also for "normal" users, who like/need nice, fast, slick functionality.
You seem to be confusing graceful degradation with highest common factor design.
Graceful degradation is when a page offers the "nice, fast, slick functionality" by using Javascript, but still works when Javascript is not available. Developers who know what they are doing can easily write code that works in both situations.
You seem to be arguing against highest common factor design, which is when you don't use a feature like Javascript unless you know it's going to be available to all of your users. I don't think that's necessary and I certainly wouldn't advocate it.
As somebody else pointed out, Google have since added an extra interface to GMail for non-Javascript users, but this isn't graceful degradation any more than having a separate text-only version of a website is graceful degradation.
But it's a beast of an application, GMail, and it's understandable, albeit annoying, that Google chose not to.
Instead they chose to do all the work once, and then do all the work again for a slightly less fancy version. I wouldn't have chosen to waste my time developing two versions instead of one degradable one, but I guess it's Google's prerogative to waste their time how they see fit.
I'm interested in what would happen if someone tried calling a local zone page (like a help file) and then executing the javascript from that page.
As far as the computer is concerned, the Javascript is executing in the context of the malicious page, and whatever security applies to that page applies to the Javascript. The idea you have is a non-issue.
The vulnerability being discussed is that it's not clear to the user that the popup that executes is from the malicious page. You can't use this to escalate privileges on the computer because the computer isn't the one that is being confused. You can use this to escalate privileges granted by the user though, by tricking them into typing passwords, etc.
Unless your application really relies on JavaScript (eg. GMail, etc)
What features of GMail really rely upon Javascript? Labels? No. Search? No. 2GB space? No. I can't think of any reason why GMail should require Javascript. People turn a blind eye because Google are so popular, but Javascript isn't exactly their strong suit. GMail could degrade gracefully, but they didn't bother.
You are forgetting that the normal way in which browsers have presented HTTP authentication for years is in a popup window. I'd expect many people to have logged into legitimate sites with what appears to be a popup to them.
they probably ought to stay away from malicious sites to begin with.
What's a "malicious site"? There have been worms and viruses that insert malicious code into whatever HTML they can access. Suddenly, the definition of "malicious site" includes the website of every organisation that is susceptible to worms and viruses.
Actually, Konqueror 3.4.1 isn't affected either (it displays the hostname in the popup title bar).
These kinds of security holes are far harder to find than simple buffer overflows, because the real flaw is that the user misunderstands information that is presented in a particular context. There's no real technical error, it's purely a user interface issue. You have to think about how a user would perceive any particular information under all kinds of different contexts.
This also means that open-source doesn't confer all of the security advantages that it does when applies to mistakes in the code, as everybody can see the UI even in a closed-source browser like Internet Explorer.
If this is the case and you doing system adminstration for 30 people will only take 1% of your time, then the sysadmin work load / person is around 0.0003.
It also means that, assuming the Ask-Slashdotee works a typical 40-hour week, the boss thinks that each employee needs 48 seconds of support each week.
If the boss really won't take no for an answer, my suggestion would be to point out that the "1% of your time" will be taken up for the next few months by reading that sysadmin book, so it might be a good idea to hire a sysadmin in the meantime to set up the network.
...everyone knows that unless the Beatles continue to make money from recordings made fifty years ago, they'll have to quit music and get day jobs. Then society won't get any new Beatles music, and then where will we be?
It seems to me that copyrights are turning from a temporary privilege into an actual property right, despite all indications that only a self-interested minority of our society wants that. So when are copyright holders going to pay property tax on their holdings?
Acid2 tests a lot of corner-case mis-constructions of CSS, and tests that the browser handles the cock-up in the prescribed manner. It doesn't actually test that _correct_ CSS is handled correctly.
This is the second or third time I've seen this posted in this article alone. You are completely wrong. You would know this if you had actually read the code or even just the guided tour.
The guided tour explains that there are a number of features tested; it lists eleven areas of the specifications that are tested, and error handling is just one of them. The vast majority of the test is testing that correct CSS is handled correctly.
It does both. I've seen this misconception stated a few times now, it's just wrong.
The Acid test is not just a test for error handling. Error handling is something that is defined by the CSS 2.1 specification (and earlier specifications). In order to test full CSS compliance, they need to include errors as part of the test. This does not mean that all the test does is error handling, merely that it is one of the things the test does.
CSS 2.1 is not yet a w3c recommendation, only a candidate Browsers than conform to it rather than CSS 2.0 are broken.
This is incorrect.
The W3C implemented a change in procedure between the times CSS 2.0 and CSS 2.1 were published. What used to be called recommendations are now only candidate recommendations until they are widely implemented.
Ian Hickson, who is on the CSS working group and employed by Opera, says this:
CSS2.1 is in CR, which is the call for implementations stage. It is appropriate for implementors to implement CSS2.1. It is not a draft.
(Note that CSS2.1 and CSS2 are at the same state in the W3C process -- they are both at the "call for implementations" stage. The difference is that the name of that stage changed between 1998 and 2004. What used to be called "REC" or "Recommendation" is now called "CR" or "Candidate Recommendation". The new stage currently called "Recommendation", which indicates that the specification has reached a very high level of implementation maturity, didn't exist back in 1998.)
CSS2.1 is what CSS implementations should be using as reference if they want to implement CSS level 2.
There's no profit in something that doesn't break and doesn't need to be renewed.
The manufacturers of battery-powered devices don't usually make any money selling batteries themselves, and if their devices didn't have to use batteries, it would give them a significant commercial advantage. If nuclear batteries ever become commercially viable, one of these manufacturers will do it. There's no need to wait for traditional battery manufacturers to sell them.
If all three of 'left', 'width', and 'right' are 'auto' [This is the case]: First set any 'auto' values for 'margin-left' and 'margin-right' to 0. Then, if 'direction' is 'ltr' [This is the case] set 'left' to the static position and apply rule number three below; otherwise, set 'right' to the static position and apply rule number one below.
The "rule number three" says that it is shrink-to-fit.
Your mistake is in referring to 10.3.3, which explains what to do for non-replaced block-level elements in normal flow. You should be referring to 10.3.7, which explains what to do for non-replaced block-level elements that are absolutely positioned.
1. Bandwidth hungry (Bad for the many people still on Dail Up)
Except Flash can reduce bandwidth. It does have vector graphics, you know, something that's been a long time coming in the feeping creature called SVG (did you know the SVG specification even has bits for networking and sound in there? Who needs their image files to connect to the Internet or play sound?).
2. Allows for the most annoying of Advertising gimmics
I can block Flash easily. I can't block Javascript + CSS without severly hampering lots of websites. It's not the most annoying advertising gimmick.
3. Disabled unfriendly, as screen readers for the blind can't read flash.
Completely untrue. "JAWS now reads information from Macromedia Flash animations as easily as any other part of a web page."
4. Google and most (all?) search engines don't do flash either.
This is just cookies in another form. Do you tell people cookies are evil too?
Don't get me wrong, I think 99% of Flash use is pointless and annoying, but that's a case of using the wrong tool for the job, not because Flash is inherently evil.
He tries to revoke the license just for them retroactively.
No he isn't doing that. The copying rights for PearPC that the CherryOS people obtained through the GPL license were terminated under section 4 of the GPL:
4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
This came up once before when Stallman told everybody that the KDE developers needed to ask forgiveness in order to use GPLed code (after Trolltech GPLed Qt in an attempt to solve the licensing issue). The KDE developers' response was "no, we just need to download another copy to get a new license". The termination of rights is clearly valid, but whether you can obtain new ones simply by downloading the GPLed software again or not is probably a grey area that would need to be addressed by a court.
These two statements seem to contradict each other.
They don't contradict each other whatsoever.
The first statement says "Internet Explorer doesn't use secret interfaces provided by the operating system".
The second statement says "other parts of the operating system rely on APIs that Internet Explorer provides".
The former is a statement about which APIs Internet Explorer uses, the latter is a statement about which APIs Internet Explorer supplies.
It uses the exact same interface as any other program in which case it can be pulled out and replaced without affecting anything else in the OS.
Well, you can pull it out and replace it without affecting anything else in the OS - provided you replace it with something else that provides the same API. As far as I am aware, there's nothing that provides the same API to applications that Internet Explorer does.
used to create a navigation using list items for links (since the navigation is a list of links), displays fine in Firefox (anchors fill their block), but displays funny in IE (where the anchors fill their block, but with a gap on the left where the list marker would be)
Neither are incorrect. The difference lies in whether they default list-style-position to inside or outside, and whether the indentation is accomplished with padding/margins on the ul elements/li elements. IIRC, Opera does things in a way that is different to both Gecko and Internet Explorer.
Make sure you specify both margin and padding for both lists and list items when you remove the markers, and you'll get consistent cross-browser results.
Wouldn't supporting CSS 2.1 or CSS 3 imply support for CSS 2?
No. Some parts of CSS 2.0 were removed for CSS 2.1 because the browser vendors found it too difficult to implement. I guess it still hasn't been dumbed down enough for Microsoft.
Slashdot Mirror
What are you talking about? You can use AJAX for a product catalogue and shopping cart easily without breaking things.
What matters is that important entry points should be addressable by URI. When somebody adds something to their shopping cart, it doesn't matter that immediately following the action, the resulting view isn't addressable, because the shopping cart state is part of the session, not simply the page that is being addressed.
Look at any halfway decent shopping cart system - when you have something in your shopping cart, that's indicated on every page on the website. You don't need to be able to address the shopping cart directly, because the last page the user was on will include this information no matter where they were in the site. And, because it's part of the session and not any particular page, that information will always be up to date - you don't need to keep giving them a new URI every time you update the cart.
No, if you don't act in a way actively encouraging copyright infringement, you should be okay. The Court said:
Actively encouraging copyright infringement is not the same as not actively preventing copyright infringement. A program can't determine whether something is copyright infringement or not; if they had ruled that you need to actively prevent copyright infringement, then it would essentially outlaw file sharing entirely.
You seem to be confusing graceful degradation with highest common factor design.
Graceful degradation is when a page offers the "nice, fast, slick functionality" by using Javascript, but still works when Javascript is not available. Developers who know what they are doing can easily write code that works in both situations.
You seem to be arguing against highest common factor design, which is when you don't use a feature like Javascript unless you know it's going to be available to all of your users. I don't think that's necessary and I certainly wouldn't advocate it.
As somebody else pointed out, Google have since added an extra interface to GMail for non-Javascript users, but this isn't graceful degradation any more than having a separate text-only version of a website is graceful degradation.
Instead they chose to do all the work once, and then do all the work again for a slightly less fancy version. I wouldn't have chosen to waste my time developing two versions instead of one degradable one, but I guess it's Google's prerogative to waste their time how they see fit.
As far as the computer is concerned, the Javascript is executing in the context of the malicious page, and whatever security applies to that page applies to the Javascript. The idea you have is a non-issue.
The vulnerability being discussed is that it's not clear to the user that the popup that executes is from the malicious page. You can't use this to escalate privileges on the computer because the computer isn't the one that is being confused. You can use this to escalate privileges granted by the user though, by tricking them into typing passwords, etc.
What features of GMail really rely upon Javascript? Labels? No. Search? No. 2GB space? No. I can't think of any reason why GMail should require Javascript. People turn a blind eye because Google are so popular, but Javascript isn't exactly their strong suit. GMail could degrade gracefully, but they didn't bother.
This is not true. They abandoned their trademark application.
iCab recently passed the second Acid test.
You are forgetting that the normal way in which browsers have presented HTTP authentication for years is in a popup window. I'd expect many people to have logged into legitimate sites with what appears to be a popup to them.
What's a "malicious site"? There have been worms and viruses that insert malicious code into whatever HTML they can access. Suddenly, the definition of "malicious site" includes the website of every organisation that is susceptible to worms and viruses.
Actually, Konqueror 3.4.1 isn't affected either (it displays the hostname in the popup title bar).
These kinds of security holes are far harder to find than simple buffer overflows, because the real flaw is that the user misunderstands information that is presented in a particular context. There's no real technical error, it's purely a user interface issue. You have to think about how a user would perceive any particular information under all kinds of different contexts.
This also means that open-source doesn't confer all of the security advantages that it does when applies to mistakes in the code, as everybody can see the UI even in a closed-source browser like Internet Explorer.
There's some informative discussion at the Wikimedia Commons.
Obviously this was a rushed job. Typical Debian, always cutting corners, never taking the time to do things properly :P.
It also means that, assuming the Ask-Slashdotee works a typical 40-hour week, the boss thinks that each employee needs 48 seconds of support each week.
If the boss really won't take no for an answer, my suggestion would be to point out that the "1% of your time" will be taken up for the next few months by reading that sysadmin book, so it might be a good idea to hire a sysadmin in the meantime to set up the network.
It seems to me that copyrights are turning from a temporary privilege into an actual property right, despite all indications that only a self-interested minority of our society wants that. So when are copyright holders going to pay property tax on their holdings?
No, it's just one of the things it tests. Read this comment.
This is the second or third time I've seen this posted in this article alone. You are completely wrong. You would know this if you had actually read the code or even just the guided tour.
The guided tour explains that there are a number of features tested; it lists eleven areas of the specifications that are tested, and error handling is just one of them. The vast majority of the test is testing that correct CSS is handled correctly.
Where is everyone getting this misinformation?
It does both. I've seen this misconception stated a few times now, it's just wrong.
The Acid test is not just a test for error handling. Error handling is something that is defined by the CSS 2.1 specification (and earlier specifications). In order to test full CSS compliance, they need to include errors as part of the test. This does not mean that all the test does is error handling, merely that it is one of the things the test does.
This is incorrect.
The W3C implemented a change in procedure between the times CSS 2.0 and CSS 2.1 were published. What used to be called recommendations are now only candidate recommendations until they are widely implemented.
Ian Hickson, who is on the CSS working group and employed by Opera, says this:
The manufacturers of battery-powered devices don't usually make any money selling batteries themselves, and if their devices didn't have to use batteries, it would give them a significant commercial advantage. If nuclear batteries ever become commercially viable, one of these manufacturers will do it. There's no need to wait for traditional battery manufacturers to sell them.
Firstly, the errors are there on purpose, to check the error handling conformance.
As for whether the <textarea> is shrink-to-fit or not, the CSS 2.1 specification has this to say.
The "rule number three" says that it is shrink-to-fit.
Your mistake is in referring to 10.3.3, which explains what to do for non-replaced block-level elements in normal flow. You should be referring to 10.3.7, which explains what to do for non-replaced block-level elements that are absolutely positioned.
Except Flash can reduce bandwidth. It does have vector graphics, you know, something that's been a long time coming in the feeping creature called SVG (did you know the SVG specification even has bits for networking and sound in there? Who needs their image files to connect to the Internet or play sound?).
I can block Flash easily. I can't block Javascript + CSS without severly hampering lots of websites. It's not the most annoying advertising gimmick.
Completely untrue. "JAWS now reads information from Macromedia Flash animations as easily as any other part of a web page."
Also untrue.
This is just cookies in another form. Do you tell people cookies are evil too?
Don't get me wrong, I think 99% of Flash use is pointless and annoying, but that's a case of using the wrong tool for the job, not because Flash is inherently evil.
No he isn't doing that. The copying rights for PearPC that the CherryOS people obtained through the GPL license were terminated under section 4 of the GPL:
This came up once before when Stallman told everybody that the KDE developers needed to ask forgiveness in order to use GPLed code (after Trolltech GPLed Qt in an attempt to solve the licensing issue). The KDE developers' response was "no, we just need to download another copy to get a new license". The termination of rights is clearly valid, but whether you can obtain new ones simply by downloading the GPLed software again or not is probably a grey area that would need to be addressed by a court.
They don't contradict each other whatsoever.
The first statement says "Internet Explorer doesn't use secret interfaces provided by the operating system".
The second statement says "other parts of the operating system rely on APIs that Internet Explorer provides".
The former is a statement about which APIs Internet Explorer uses, the latter is a statement about which APIs Internet Explorer supplies.
Well, you can pull it out and replace it without affecting anything else in the OS - provided you replace it with something else that provides the same API. As far as I am aware, there's nothing that provides the same API to applications that Internet Explorer does.
Neither are incorrect. The difference lies in whether they default list-style-position to inside or outside, and whether the indentation is accomplished with padding/margins on the ul elements/li elements. IIRC, Opera does things in a way that is different to both Gecko and Internet Explorer.
Make sure you specify both margin and padding for both lists and list items when you remove the markers, and you'll get consistent cross-browser results.
No. Some parts of CSS 2.0 were removed for CSS 2.1 because the browser vendors found it too difficult to implement. I guess it still hasn't been dumbed down enough for Microsoft.