It's an inherent flaw that makes web delivered applications an impossibillity.
Woah there, Nelly! While I'd agree that it makes it difficult to deliver totally secure web applications, there is ample evidence that applications that do not need security can be delivered over the web just fine. An "impossibillity"[sic] indeed!
The fix is to require all servers to declare what other servers contain scripts that they are prepared to work with. This might be done through a separate page in a known location or might be through HTTP headers (I can see arguments either way) but it does mean that it would be possible to stop malicious injection from third-party sites. (Well, the attackers would have to go back to other classes of threats, such as hacking trusted servers, but that's a separate issue.)
The benefits for write-once media are actually pretty clear. Suppose you've got to keep audit trails for a database containing financial data; writing it to write-once media is a pretty good way of doing it, since it's then easy to show that it wasn't tampered with. Rewritable media is useful for other things (e.g. live data).
In other news, it was today revealed that Central America is not a non-fucking continent either. A stunned analyst revealed that, irrespective of the copulatory status of the geographic region, it stubbornly remains a part of North America.
Our company e-mail signature contains GIF images. When a client replied to us, quoting the original e-mail, the ISP would scan the e-mail, detect the inline GIF, and block the e-mail.
The easiest way, if you're insisting on delivering HTML documents dressed up as email, is to at least keep things like company logos on a webserver and just use conventional refs to the images. Not only is it something that spammers don't do (having a server up at a known address being trickier than splatting emails out of zombies) but it also allows client software to cache things like your company logo so that it only gets sent once rather than on every damn message. As far as I can see, no legit email ever needs attached inline images (i.e. ones that are referred to by cid: urls) so blocking them is a good thing.
It's expensive too. Unless we're going to specially tax the holders of the copyright that was violated to cover the complete costs of keeping the pirate in jail, so making it an initiative with zero cost to the public purse. Of course, that would mean that the *AA's paymasters would suddenly have a great big new cost looming out of the blue, especially as the decision to prosecute wouldn't technically be in their hands...
I think it's about the right time for me to file suit against Media Rights Technologies for not employing me at a salary of $10,000,000/year to refill their coke machines.
MRT have machines that dispense cocaine? Wow! Isn't that illegal? It does explain a lot about this lawsuit though...
The best thing about Civ2 over the later versions was the fun series of advisers. OK, they were cheesy (especially as there really wasn't that many different videos, and only the Anarchy ones were really neat) but I think it's a shame that the concept hasn't been taken forward with modern tech. By comparison, the Civ3 versions (which were effectively just static graphics) were just lame, so much so that Civ4 doing away with them was an improvement.
Now, if we could have that on top of the Civ4 engine playing the SMACX ruleset/situation... I'd have myself a desert island wherever I was as I'd be playing that obsessively for a few years even in the middle of a bustling city! (I suppose it is a good thing for my career that nobody's done this yet...)
Oh, and Civ2 and SMAC had definitely the best wonder videos.
Not that it will matter much, they're still only ~ $2K, easily within reach of even casual phishers.
But they'll (hopefully) have had to first prove a suspicious certificate authority that they're a bona fide corporation. Which is a very different thing to what happens at the moment, where all too often all they check is whether you gave a valid credit card number. What *I* worry about is some scummy CA who just takes the $2K and signs the cert without doing the checking; that would be very bad and I have my suspicions about the business ethics of some in that market.
Or at least they will be if you don't fight to take back what you should already have according to the constitution. I really hope that the fight won't require actual battles on the streets though.
Mod parent up as Interesting. Yeah, I know it's a joke, but it's also an excellent illustration of why writing ontologies is hard: the meaning of a word is a slippery thing, inclined to run away from you.
Having occasionally seen movies containing Chevy Chase, is there some way I can get zero knowledge of them after the fact? I'd love to recover from the trauma.
DRM is an enabling technology for censorship (eg "un-leakable documents") Do we really want that?
For some things? Yes. (I'd like documents containing my credit card number to be unleakable! Your employer might well want their detailed business plan to be unleakable.) But for things that are going to be distributed to the general public anyway? Don't be ridiculous.
Microprocessor Report has plenty of integrity (e.g. when they a chip gets a certain level of performance, you can believe it) but it's also hellishly expensive, as it costs nearly $900 for a single year online-only subscription. Given that it's really aimed at pro chip designers, this isn't surprising.
Apple, if I remember correctly, was one of the founders of ARM
You either remember incorrectly or can't tell the difference between Acorn and Apple. (Did you even read that link you posted? I can understand people not RTFA, but not reading the contents of something you link to? Sheesh...)
Keep this in mind, because the reality is, even Microsoft can't even afford a sustained and honest Research and Development lab.
But the reality is you're wrong. Firstly, MS do keep a highly regarded research lab, and they'd not be highly regarded if they weren't sustained and honest. Secondly, there are much bigger companies than MS who also have excellent research labs. Sure it's true that such labs are often involved in research projects funded by governments (everyone always loves external funding, wherever you are) but their main work is in doing things to support their owner, which is as it should be. But the largest fraction of this is actually Development, which means the part of the process where they take the outcome of the Research (a neat theory or cool effect) and convert it into a product that can support part of the business model of the rest of the corporation (possibly by being sold on to someone else).
All this "Web 2.0" stuff adds one important attack vector, and that is scripts downloaded from a malicious website that manipulates the user's experience of the real site (e.g. to make extra transfers and yet hide the details of those from your view of the log). The proper solution to this is to only allow scripted control of a site (other than from scripts downloaded from the same site) if the controlled site specifically declares that it is OK for scripts from the other site to do so, a policy which would need to be enforced by everyone's browsers. (Yeah, I know. Good luck with getting IE to adopt a sensible default-deny policy on anything.) Of course, this measure completely stuffs most mashups, but is that such a bad thing?:-)
The main difference between the UK and Canada would be that Canadians have far larger homes. From my very informal view of both countries (based on living in Canada and spending 6 months in the UK) homes in Canada are roughly 2x the size of British homes.
Another factor that might be important (I don't know for sure, as I've not been in a typical Canadian home) is that British homes tend to use gas for heating and cooking (though cooking is a bit less common than heating) and will not normally have air-con. Those are major sources of consumption; anything dealing with heat always is.
You seem to be confused. Though self-signed certificates are fine enough for testing, they have a problem when you try to use them for securing real communications over the 'net. The problem? The bad guys can create them too, making it possible for them to do a "perfect" attack on the website (with the help of a bit of DNS attacking). That would be Bad. I really think that being able to have an encrypted conversation with scum isn't a big step forward. The only way around this is to have a third party, trusted by your client software, that verifies that a certificate is actually for what it claims to be. That's what the standard web PKI system does. Add in something like CRLs or OCSP and you can even remove most of the technical weaknesses in the PKI system that you've spotted.
But there are a number of other issues. Firstly, certificates have other uses than securing communications with websites (notably signing and/or encrypting documents or code) which have other vulnerability profiles. Secondly, PKI currently only really talks about identity; nothing is said about what that identity assertion means, and that's quite different from how identity is typically managed in meatspace. Both of those points hinge on trust; what we've got are identity assertions, but what we're after are trust assertions. Thus, on the first point I suspect that webs-of-trust built on top of PKI will be the best approach, and on the second I feel that there's much work still to be done, with a key part of the process being when the certificate signing bodies take proper legal responsibility for their actions; for example, if GoDaddy were to sign off on something that was part of a deceitful trademark infringement and I was to get scammed because of it, I should have recourse against GoDaddy as well as the scammers. There are probably other things that need doing, many of which may not be technical but rather regulatory; a tech fix isn't always the best solution.
It makes allot more sense to just share and load the same libs.
Nice dream. Doesn't work too well unfortunately except in highly centralized distribution schemes like those used by Linux distributions. Since the primary distribution mode of FF/TB is by direct user download, it is better for those programs to go out with the libraries that they need so that they work for people. The alternative, pitching ordinary users into library versioning hell, is far worse.
In other words: Theory? Meet Real World Practice. Practice? Say Hi to Ivory-Tower Theory.
I still don't understand why I need to have multiple copies of gecko shared libraries / dlls in memory since the split-up of mozilla into firefox, thunderbird, and sunbird. How is this waste of space supposed to be more efficient?
It's because it makes distribution much simpler. If this bothers you (though why it should when even entry-level machines have vast amounts of memory available even after loading the OS) get Seamonkey instead and stop griping here.
Water has very unusual properties, in fact, that make it more probable that life would evolve on a planet with lots of liquid water than, say, one covered in methane or liquid carbon dioxide.
Although we believe that to be true, we do not know for sure. We've far too little data in this area to draw any real conclusions yet. Not that I know any way to know when we might have enough; it would require study of a significant fraction of the galaxy for us to start to get some idea of what the real conditions for life starting are. (Once life has started, I imagine it will tend to continue for a long time and the usual evolutionary patterns will apply. But it's the first step that's a big unknown.)
Slashdot Mirror
The fix is to require all servers to declare what other servers contain scripts that they are prepared to work with. This might be done through a separate page in a known location or might be through HTTP headers (I can see arguments either way) but it does mean that it would be possible to stop malicious injection from third-party sites. (Well, the attackers would have to go back to other classes of threats, such as hacking trusted servers, but that's a separate issue.)
The benefits for write-once media are actually pretty clear. Suppose you've got to keep audit trails for a database containing financial data; writing it to write-once media is a pretty good way of doing it, since it's then easy to show that it wasn't tampered with. Rewritable media is useful for other things (e.g. live data).
Film at 11.
The best thing about Civ2 over the later versions was the fun series of advisers. OK, they were cheesy (especially as there really wasn't that many different videos, and only the Anarchy ones were really neat) but I think it's a shame that the concept hasn't been taken forward with modern tech. By comparison, the Civ3 versions (which were effectively just static graphics) were just lame, so much so that Civ4 doing away with them was an improvement.
Now, if we could have that on top of the Civ4 engine playing the SMACX ruleset/situation... I'd have myself a desert island wherever I was as I'd be playing that obsessively for a few years even in the middle of a bustling city! (I suppose it is a good thing for my career that nobody's done this yet...)
Oh, and Civ2 and SMAC had definitely the best wonder videos.
All your rights are belong to the fascists.
Or at least they will be if you don't fight to take back what you should already have according to the constitution. I really hope that the fight won't require actual battles on the streets though.
Mod parent up as Interesting. Yeah, I know it's a joke, but it's also an excellent illustration of why writing ontologies is hard: the meaning of a word is a slippery thing, inclined to run away from you.
Having occasionally seen movies containing Chevy Chase, is there some way I can get zero knowledge of them after the fact? I'd love to recover from the trauma.
It's a "Darrieus" turbine, and has nothing to do with the ancient Persian king.
All this "Web 2.0" stuff adds one important attack vector, and that is scripts downloaded from a malicious website that manipulates the user's experience of the real site (e.g. to make extra transfers and yet hide the details of those from your view of the log). The proper solution to this is to only allow scripted control of a site (other than from scripts downloaded from the same site) if the controlled site specifically declares that it is OK for scripts from the other site to do so, a policy which would need to be enforced by everyone's browsers. (Yeah, I know. Good luck with getting IE to adopt a sensible default-deny policy on anything.) Of course, this measure completely stuffs most mashups, but is that such a bad thing? :-)
You seem to be confused. Though self-signed certificates are fine enough for testing, they have a problem when you try to use them for securing real communications over the 'net. The problem? The bad guys can create them too, making it possible for them to do a "perfect" attack on the website (with the help of a bit of DNS attacking). That would be Bad. I really think that being able to have an encrypted conversation with scum isn't a big step forward. The only way around this is to have a third party, trusted by your client software, that verifies that a certificate is actually for what it claims to be. That's what the standard web PKI system does. Add in something like CRLs or OCSP and you can even remove most of the technical weaknesses in the PKI system that you've spotted.
But there are a number of other issues. Firstly, certificates have other uses than securing communications with websites (notably signing and/or encrypting documents or code) which have other vulnerability profiles. Secondly, PKI currently only really talks about identity; nothing is said about what that identity assertion means, and that's quite different from how identity is typically managed in meatspace. Both of those points hinge on trust; what we've got are identity assertions, but what we're after are trust assertions. Thus, on the first point I suspect that webs-of-trust built on top of PKI will be the best approach, and on the second I feel that there's much work still to be done, with a key part of the process being when the certificate signing bodies take proper legal responsibility for their actions; for example, if GoDaddy were to sign off on something that was part of a deceitful trademark infringement and I was to get scammed because of it, I should have recourse against GoDaddy as well as the scammers. There are probably other things that need doing, many of which may not be technical but rather regulatory; a tech fix isn't always the best solution.
In other words: Theory? Meet Real World Practice. Practice? Say Hi to Ivory-Tower Theory.
That depends. If they say "the internet is going down a series of tubes", we should laugh and agree.