there's no good reason to state the name of the element twice (at beginning and end).
As somebody else pointed out, it helps a great deal when hunting down the cause of an error. But the real reason is that it makes the parser a lot simpler.
SGML has optional closing tags. When they were designing XML, they deliberately avoided using them, because it makes the parser more complicated and reliant upon the DTD.
Given the sequence <foo><bar> , is the bar element inside the foo element? There's no way of knowing without consulting the DTD.
The DTD might have defined the foo element type as having an optional closing tag, and the ability to contain bar elements, in which case, yes, the bar element is inside the foo element.
The DTD might have defined the foo element type as having a mandatory closing tag, and the ability to contain bar elements, in which case, yes, the bar element is inside the foo element, and you expect a closing foo tag sometime later in the document.
The DTD might have defined the foo element type as having an optional closing tag, and not able to contain bar elements, in which case, bar is a sibling of foo, not a child.
The DTD might have defined the foo element type as having a mandatory closing tag, and not able to contain bar elements, in which case, not only does foo not contain bar, but it's an error condition.
The parser has to obtain the DTD and keep track of all of this just to parse the document. As experience has shown with SGML, it's difficult to get these things right. Furthermore, there's a new need for parsers on low-powered devices where CPU, memory and network connectivity are at a premium.
A simpler parser was necessary for reasons like this. Mandatory closing tags aren't a burden, they are an asset.
People in production environments aren't going to apply a patch created by Joe in his basement, they're going to want an official kernel patch.
People in production environments will typically use the fix their vendor supplies them with. If Linus is notified of a security hole, everyone has to wait for him to fix it. If the LKML is notified of a security hole, Redhat can fix it, evaluate Joe Basement's patch and possibly use it, or apply Linus' patch when he gets around to it. Either way, as far as time-to-fix is concerned, the end-user can only benefit from the LKML being notified instead of Linus alone.
This is just the most publicly seen instance but broken XML does this every single day.
XML never does this. XML parsers, upon finding a problem must stop parsing and throw a fatal error. It's in the specification.
Instead of mindlessly knee-jerking because you don't like XML, try reading the article. The greater-than symbol that causes problems is the delimiter for the email address - syntax that goes back to 1982's RFC 822 - long before XML's time.
I'd gladly ask the Apache and PHP guys to fix their "nobody" user problem, and start PHP with separate accounts.
Apache 2 threaded MPMs can run different vhosts under different users, so this has been fixed for over two years. If PHP was thread-safe, you wouldn't have a problem, but as this story highlights, PHP doesn't play nice with threads.
The latest version of SpamAssassin is 3.0.2. I've found that 3.0.1 misclassifies all Outlook 2003 email as spam, I haven't had a chance to see if 3.0.2 is the same yet.
Also, this spec is pretty far behind the times. IE has had this functionality for over 3 years.
Big deal. Microsoft haven't even finished implementing PNG and CSS, and they are both over eight years old. Microsoft implemented a useful object, other browsers followed suit, and then the W3C developed a specification to do the same thing in a slightly better way. I don't see why anybody should fault the W3C for that.
I love how everyone in the Linux community expects MS to drop everything they are doing and adopt this new W3C standard because it's a STANDARD.
It's not a standard. It's a recommendation, but lots of people confuse the terms. And I don't expect Microsoft to drop everything they are doing to implement new specifications, but I do expect the world's largest software corporation to be able to implement specifications within a decade or so. When they haven't made any improvements in three years, and other browser developers with a fraction of Microsoft's resources can do it, it's hard to give Microsoft any credit whatsoever.
So what about all of us who have written code already because there was no W3C standard?? Should we all be good programmers and go back and change our code just because?
You are arguing against a point I didn't make. Go back and read what I wrote again. I said "you may not think that it's worth your while to implement the W3C approach, but that's your call.".
Anyway, IE hopefully will end up implementing the W3C spec eventually, but April 2004 in the world of corporations (at least those that make money over the Internet) it is still relatively new.
I agree, it is still relatively new. Which is why I wouldn't recommend implementing it without an XMLHttpRequest fallback. Hence the whole "you still have to mollycoddle, so it might not be worth your while" bit.
In your environment maybe.. (I take it you are either at a University) but not mine.
I find that following W3C specifications first and foremost, and using other things as fallbacks gets me the most reliable cross-user-agent behaviour. That's in a business setting, but it's true for any setting where interoperability is a concern, in my opinion.
I beg your pardon? It doesn't matter if the government has easy hooks to play man in the middle by giving *their* set of keys for users?
No, it doesn't. PGP's whole web of trust is based around avoiding man-in-the-middle attacks. If you are susceptible to man-in-the-middles from server intrusions, it means that you aren't using PGP correctly, in which case, you are already susceptible to man-in-the-middles, and whether or not the government happens to have access to the server is irrelevent.
Sure, it's detectable (with extra work), but most people would trust the keyserver initially and not bother to check with the other user.
Well then they've thrown away the security that PGP provides, haven't they? PGP keyservers have never been trustworthy. The whole concept of an external organisation being trusted to provide you with authentic keys is flawed, which is why PGP was never designed with that as a requirement.
If you do a little digging you'll see that remote web service calls from the browser are still a relatively "new" thing. There is no W3C standard as of yet.
This is incorrect, DOM 3 Load and Save was finalised back in April, and it has been implemented by multiple browsers already. You still have to mollycoddle Internet Explorer of course, so you may not think that it's worth your while to implement the W3C approach, but that's your call.
Anyone know how to make updates run in another thread so they don't stop the browser if they're really slow?
Here's your problem, right here:
http.open ('POST', '/_bin/preview.cmo', false);
The third parameter to the open method is false, which means you're explicitly asking for synchronous behaviour. If you had left it to its default value, true, you would have asynchronous behaviour, and you can hook into the onreadystatechange event to catch the load. Check an XMLHttpRequest tutorial for the details.
How about we not worry about userland programs being "insecure" when the real issue is that the malware was installed on the machine in the first place.
The problem is that these programs can be the method by which the malware gets on the machine.
Example: Google Desktop Search contains a buffer overflow. You visit a malicious web page. Nothing happens. Later that day, when GDS is indexing your web browser cache, it processes the malicious page, and infects your system.
I wonder how feasible it would be for other word processors, such as AbiWord, to use this format natively. Or, at least appear to use the format natively.
It matters a lot if, let's say, you encrypt a sensitive email with a fake public key not belonging to the person you think it is.
No, it doesn't matter in the slightest how you got the key. PGP operates under the assumption that it's not practical to always use a trusted medium to exchange keys. It doesn't trust keys by default.
PGP uses the concept of a "web of trust" to decide whether you should trust a key or not. If you can securely verify the legitimacy of a public key, then you can sign it, so that people who trust your judgement can also trust the key. In reverse, you can trust keys that people you trust have signed.
How the keys are transferred is completely irrelevent to this mechanism. You could download a public key from Gnutella or Usenet, and as long as it's been signed by somebody you trust, or you can verify the fingerprint over a secure medium, it's trustable.
So, your scenario would play out as follows:
Download "trojan" public key.
Not signed by somebody you trust? Throw the key away.
Signed by somebody you trust, but the signature is invalid? Throw the key away.
Signed by somebody you trust, and the signature is valid? The key is trustworthy.
The balance between how practical and how secure your web of trust is depends on how much trust you place in others. It doesn't depend on the medium you transfer keys under in the slightest. That is why it doesn't matter if there are backdoors in the keyserver. No amount of tampering with it could make the web of trust any less secure.
If you think about your line of reasoning, if what you said were true, PGP would be pretty damn insecure to begin with, as you'd necessarily be trusting an external entity (the PGP keyserver admins) with all your communications.
It doesn't matter. Keyservers are merely a method of distributing keys, not establishing trust. You can establish trust by a number of methods, such as manually verifying the fingerprint with the person yourself using a trusted medium (e.g. face to face) or having somebody you trust sign the key (after verifying their key, of course).
The real danger to public key cryptography taking off is that it will become commonplace to simply trust keys without verifying them. Everyone will feel more secure, but the security will be an illusion.
Or, linux could simply have an easy way for programs to query for the files they want to use. Like a database of librarys. Then it doesn't matter where the distro puts said files/usr/lib/usr/bin/opt/lib, whatever, the program can just go ask this standard database every linux distro has.
The linker already does this. Have a look at/etc/ld.so.conf.
With the current setup, If I manually install something, its a bitch to remove, and even more of a bitch to get apt/pacman/whatever to know where those librarys are when dependancy checking.
Oh, I see. The problem is that RPM etc aren't capable of figuring out if something has been installed by an external process? I don't know how other distros deal with it, but with Gentoo, you can simply "emerge --inject".
I don't see how this is a problem for normal desktop users though - first people start out by saying that they don't know how to compile stuff manually, and then when somebody suggests using RPM etc, they say "what about all the stuff they compiled by hand"?
RPM, deb, ebuilds, tar.bz2, tar.gz, all are to complicated for the normal user.
Last time I used an RPM-based distro, installing an application was as simple as clicking on its RPM, and it would simply show up in the menus. That was years ago. Sure things like ebuilds are more difficult - Gentoo is aimed at the power-user, not the average desktop user.
I think Staticly compiled binaries are the way to go!
Hmm... let's see, assuming KDE:
$ du -sh/usr/qt/3/lib/ 17M/usr/qt/3/lib/ $ du -sh/usr/kde/3.3/lib/ 159M/usr/kde/3.3/lib/
So you want 176MB to download with every GUI application... and you'll have to download an update for every app on the system whenever a security hole is found in what was a shared library... and each application will have slightly different versions of the libraries, so an improvement in, say, the file selector dialogue will only show up once all the applications on your system have been updated. Sounds great!
Your browser detecting technique is broken. If you send different content to clients depending on which HTTP request headers are sent, you need to send an appropriate Vary response header. Otherwise public caches could serve the wrong content to the wrong browsers, resulting in Firefox users getting "upgrade to Firefox" and non-Firefox users getting the content intended for Firefox users.
Of course the fact that Slashdot's HTML code is completely invalid under any DTD has nothing to do with it. (<-Sarcasm)
Er, no, it really doesn't have anything to do with validity. It's a Firefox rendering bug. Read the bug report, the comments attached to it, and the source of the (valid) testcases that demonstrate the problem if you don't believe me.
Slashdot Mirror
If this thing has been independently invented five times, then it shouldn't be novel enough to warrant patent protection.
As somebody else pointed out, it helps a great deal when hunting down the cause of an error. But the real reason is that it makes the parser a lot simpler.
SGML has optional closing tags. When they were designing XML, they deliberately avoided using them, because it makes the parser more complicated and reliant upon the DTD.
Given the sequence <foo><bar> , is the bar element inside the foo element? There's no way of knowing without consulting the DTD.
The DTD might have defined the foo element type as having an optional closing tag, and the ability to contain bar elements, in which case, yes, the bar element is inside the foo element.
The DTD might have defined the foo element type as having a mandatory closing tag, and the ability to contain bar elements, in which case, yes, the bar element is inside the foo element, and you expect a closing foo tag sometime later in the document.
The DTD might have defined the foo element type as having an optional closing tag, and not able to contain bar elements, in which case, bar is a sibling of foo, not a child.
The DTD might have defined the foo element type as having a mandatory closing tag, and not able to contain bar elements, in which case, not only does foo not contain bar, but it's an error condition.
The parser has to obtain the DTD and keep track of all of this just to parse the document. As experience has shown with SGML, it's difficult to get these things right. Furthermore, there's a new need for parsers on low-powered devices where CPU, memory and network connectivity are at a premium.
A simpler parser was necessary for reasons like this. Mandatory closing tags aren't a burden, they are an asset.
It's a barrier to entry and an identifier you can use to ban. How many email spammers use their own email addresses?
You don't have to make it impossible for people to spam, you just have to waste their time enough to discourage them.
People don't spam Slashdot to get pagerank though. Since there are so many links on the pages already, any possible pagerank gained would be minute.
You can get around that by removing the rel attribute for people who authenticate against their provided email address.
PS: It's not a tag, it's an attribute value.
Actually, Internet Explorer allows third-party cookies, just as long as there's a P3P policy to go along with it.
People in production environments will typically use the fix their vendor supplies them with. If Linus is notified of a security hole, everyone has to wait for him to fix it. If the LKML is notified of a security hole, Redhat can fix it, evaluate Joe Basement's patch and possibly use it, or apply Linus' patch when he gets around to it. Either way, as far as time-to-fix is concerned, the end-user can only benefit from the LKML being notified instead of Linus alone.
XML never does this. XML parsers, upon finding a problem must stop parsing and throw a fatal error. It's in the specification.
Instead of mindlessly knee-jerking because you don't like XML, try reading the article. The greater-than symbol that causes problems is the delimiter for the email address - syntax that goes back to 1982's RFC 822 - long before XML's time.
Apache 2 threaded MPMs can run different vhosts under different users, so this has been fixed for over two years. If PHP was thread-safe, you wouldn't have a problem, but as this story highlights, PHP doesn't play nice with threads.
The latest version of SpamAssassin is 3.0.2. I've found that 3.0.1 misclassifies all Outlook 2003 email as spam, I haven't had a chance to see if 3.0.2 is the same yet.
Big deal. Microsoft haven't even finished implementing PNG and CSS, and they are both over eight years old. Microsoft implemented a useful object, other browsers followed suit, and then the W3C developed a specification to do the same thing in a slightly better way. I don't see why anybody should fault the W3C for that.
It's not a standard. It's a recommendation, but lots of people confuse the terms. And I don't expect Microsoft to drop everything they are doing to implement new specifications, but I do expect the world's largest software corporation to be able to implement specifications within a decade or so. When they haven't made any improvements in three years, and other browser developers with a fraction of Microsoft's resources can do it, it's hard to give Microsoft any credit whatsoever.
You are arguing against a point I didn't make. Go back and read what I wrote again. I said "you may not think that it's worth your while to implement the W3C approach, but that's your call.".
I agree, it is still relatively new. Which is why I wouldn't recommend implementing it without an XMLHttpRequest fallback. Hence the whole "you still have to mollycoddle, so it might not be worth your while" bit.
I find that following W3C specifications first and foremost, and using other things as fallbacks gets me the most reliable cross-user-agent behaviour. That's in a business setting, but it's true for any setting where interoperability is a concern, in my opinion.
No, it doesn't. PGP's whole web of trust is based around avoiding man-in-the-middle attacks. If you are susceptible to man-in-the-middles from server intrusions, it means that you aren't using PGP correctly, in which case, you are already susceptible to man-in-the-middles, and whether or not the government happens to have access to the server is irrelevent.
Well then they've thrown away the security that PGP provides, haven't they? PGP keyservers have never been trustworthy. The whole concept of an external organisation being trusted to provide you with authentic keys is flawed, which is why PGP was never designed with that as a requirement.
This is incorrect, DOM 3 Load and Save was finalised back in April, and it has been implemented by multiple browsers already. You still have to mollycoddle Internet Explorer of course, so you may not think that it's worth your while to implement the W3C approach, but that's your call.
Here's your problem, right here:
The third parameter to the open method is false, which means you're explicitly asking for synchronous behaviour. If you had left it to its default value, true, you would have asynchronous behaviour, and you can hook into the onreadystatechange event to catch the load. Check an XMLHttpRequest tutorial for the details.
The problem is that these programs can be the method by which the malware gets on the machine.
Example: Google Desktop Search contains a buffer overflow. You visit a malicious web page. Nothing happens. Later that day, when GDS is indexing your web browser cache, it processes the malicious page, and infects your system.
The OpenOffice format is being standardised by OASIS and the KOffice developers have decided to use it as the native format in future.
No, it doesn't matter in the slightest how you got the key. PGP operates under the assumption that it's not practical to always use a trusted medium to exchange keys. It doesn't trust keys by default.
PGP uses the concept of a "web of trust" to decide whether you should trust a key or not. If you can securely verify the legitimacy of a public key, then you can sign it, so that people who trust your judgement can also trust the key. In reverse, you can trust keys that people you trust have signed.
How the keys are transferred is completely irrelevent to this mechanism. You could download a public key from Gnutella or Usenet, and as long as it's been signed by somebody you trust, or you can verify the fingerprint over a secure medium, it's trustable.
So, your scenario would play out as follows:
The balance between how practical and how secure your web of trust is depends on how much trust you place in others. It doesn't depend on the medium you transfer keys under in the slightest. That is why it doesn't matter if there are backdoors in the keyserver. No amount of tampering with it could make the web of trust any less secure.
If you think about your line of reasoning, if what you said were true, PGP would be pretty damn insecure to begin with, as you'd necessarily be trusting an external entity (the PGP keyserver admins) with all your communications.
It doesn't matter. Keyservers are merely a method of distributing keys, not establishing trust. You can establish trust by a number of methods, such as manually verifying the fingerprint with the person yourself using a trusted medium (e.g. face to face) or having somebody you trust sign the key (after verifying their key, of course).
The real danger to public key cryptography taking off is that it will become commonplace to simply trust keys without verifying them. Everyone will feel more secure, but the security will be an illusion.
The linker already does this. Have a look at /etc/ld.so.conf.
Oh, I see. The problem is that RPM etc aren't capable of figuring out if something has been installed by an external process? I don't know how other distros deal with it, but with Gentoo, you can simply "emerge --inject".
I don't see how this is a problem for normal desktop users though - first people start out by saying that they don't know how to compile stuff manually, and then when somebody suggests using RPM etc, they say "what about all the stuff they compiled by hand"?
Last time I used an RPM-based distro, installing an application was as simple as clicking on its RPM, and it would simply show up in the menus. That was years ago. Sure things like ebuilds are more difficult - Gentoo is aimed at the power-user, not the average desktop user.
Hmm... let's see, assuming KDE:
So you want 176MB to download with every GUI application... and you'll have to download an update for every app on the system whenever a security hole is found in what was a shared library... and each application will have slightly different versions of the libraries, so an improvement in, say, the file selector dialogue will only show up once all the applications on your system have been updated. Sounds great!
Your browser detecting technique is broken. If you send different content to clients depending on which HTTP request headers are sent, you need to send an appropriate Vary response header. Otherwise public caches could serve the wrong content to the wrong browsers, resulting in Firefox users getting "upgrade to Firefox" and non-Firefox users getting the content intended for Firefox users.
Er, no, it really doesn't have anything to do with validity. It's a Firefox rendering bug. Read the bug report, the comments attached to it, and the source of the (valid) testcases that demonstrate the problem if you don't believe me.
No, it's a bug in Firefox, and even if it wasn't, it wouldn't be ironic.
He's got nothing on this guy.
Just because public caches can't see it, it doesn't mean that private caches can't. For instance, the browser cache, which is what is relevent here.