You ask a kid what they want to be today and they want to be a rap star.... The only time they see or hear about space is when goes wrong or, worse, blows up and kills people.
To be fair, that's when we normally hear about rap stars, too.
The current Rehabilitating Mr Wiggles answers this question: because it's kind of a dick thing to do.
Seriously though, if everyone went around killing each other whenever it suited them, you'd always be in danger of being killed yourself. There's very compelling reasons for a society to collectively agree that killing each other is a bad thing and that it won't be tolerated. No need for a fear of divine retribution.
I think the news part is that Amazon sends you the entire movie when you play the 2 minute "preview". Most people would assume the preview would in fact be a two minute clip without the rest of the movie attached.
How could it possibly be easier for artists without the choice of being with a big label?
Maybe the main effect of big labels is that they centralise spending. The vast majority of bands are unheard of and being in the band is more than likely costing them money. This is a known fact. But it's also a fact there's a relatively small number of bands that have become very very wealthy. Many of these are the "flavour of the day" pushed by the big labels, because big labels have a strong marketing reach -- they can even go so far as to pay popular radio stations to play their artists' songs, giving them exposure they wouldn't otherwise have.
So big labels can be beneficial to the artists they choose to really promote. But from a business point of view, it's more efficient (and therefore profitable) to sell 10 million copies of one album than 1 million copies of 10 albums, or 10,000 copies of a thousand albums. Therefore there's a natural tendency for them to actively promote as few albums as they can.
If there were no big labels, then you might have more specialised market segments. The big chunk of the money-for-music pie that goes to superstar artists on major labels would be divided amongst a lot more different bands. This redistribution of income from the top might be enough to raise the median income amongst artists... which would probably qualify as "being easier for [the majority of] artists".
Just thinking aloud here so there may be flaws in my reasoning and/or it may not apply in real life.
Actually, I think it'd work just fine. Just handle it how we handle secure web sites: your organisation pays for a certificate identifying them. This is trusted by everyone else because they buy it from one of the big CAs whose certificate ships with all OSes, web browsers, or in this case, mail servers.
While a small business and even an individual can easily afford $20 a year for an instant certificate with basic "domain control" validation, it will quickly become prohibitive to continually buy new ones because your certificate keeps ending up on blacklists (because you're spamming, or relaying mail for spammers). In reality, end users won't care, because their email provider (company or ISP) will buy the certificate.
The problem is getting people to do it. If nobody signs their messages, then there's no benefit to requiring signed messages. Since there's no benefit, nobody will sign their messages.
Nit-pit: you generally need or want maintenance/support on your proprietary software, so it's not a one-off cost to acquire it, but a yearly or three-yearly license/maintenance fee. Thus, comparing an 80k purchase to an 80k salary isn't quite fair. However, that's irrelevant.
Most paid programmers work for consultancies that hire out their services for relatively short-term contracts in order to solve particular business needs. i.e. you don't go out and hire a full-time permanent programmer in order to write you something; instead, you pay another company to write it for you. If you need changes made, you hire them again (or someone else). Yes, this is like buying a proprietary software package, but the difference being it's only for use and not useful enough outside of your business for anyone to actually want to sell.
Think of it like most other IT jobs. Small businesses don't usually hire a fulltime systems/network administrator to manage their 10 desktops and an Exchange server; they pay another company to provide that resource when they need it. If you're a really big company that does need lots of internal software, then you might hire permanent programmers because there's always processes that could be improved upon, or you might have sufficient internal apps that there's always bugs and improvements to be made, and so on. But most businesses would simply hire on an as-needed basis.
The question then is, if you're a consultancy providing programmers for hire, why would you give away the software you write for clients? It makes more sense to hoard it so you can re-sell it to others at near original price, while actually only doing some quick customisation. The bigger your pool of software, the less actual work you need to do in order to satisfy customer needs. That means you can either undercut your competition (in terms of time to completion and/or price), or simply make craploads of profit.
I think the answer is probably: you'd do that if everyone else was doing it. So what you'll find is a small number of "open source consultants" customising open source packages to fit their clients needs, and being able to undercut the proprietary shops because of it. Once this is happening enough, formerly proprietary places will start using OSS as well because they're finding it too hard to win contracts since they have to charge so much more. From there, the rest of the dominoes will fall like a house of cards. Checkmate.
Well, the main benefit is in centralising the locations of spam. As it is now, a lot comes from zombie PCs with dynamic IPs. Send and forget works in their favour, because it doesn't matter if the machine moves around or even if it gets cleaned if it's already sent your message out.
By making it a requirement that they keep their system online in order for people to receive the spam message proper, theoretically you degrade their mobility a bit. This makes community blacklists more useful, because once you've spammed a bunch of people using a particular domain name everyone will start blocking or discarding messages that refer to that domain. So now that $10/year for a domain name becomes $10 per X thousand messages. It also may make it easier to track down spammers.
In reality, I don't think it'd make much difference. It's no magic bullet, and there's pretty obvious "solutions" to the problems this would cause spammers.
I think it's more the style of writing. The ACs post is full of inflammatory terms, starting with "Partisan Political hack rags" and ending with "Obama is a fucking disaster waiting to happen". flyingsquid's post was not only much better written, but also avoided using inflammatory terms. It may have been just as critical of Palin as the ACs post was toward Obama, but the criticisms were written in such a manner as to sound reasonable rather than trollish.
You can already use electrical cabling for networking, and given that appliances are all going to have to be connected to power anyway that seems a logical method. It could also simplify discovery and autoconfiguration.
I would really like to see something like browser viewer for a molecule (that is inherently 3D) and its chemical interactions, pictures of animals from the web, movie scenes, basically anything other than text, done better on the whole in 2D than 3D.
Plus, what is to stop text from being rendered in a way that the immediately relevant stuff is in front of you from the start? With 3D you can also use the back (or sides as well) of text boxes to display additional information (for example a log of events)
I think what's really missing is 3D input devices. Rotating a text box so you can see additional information on the side of it would be a nuisance and does not improve in any way upon having a button that shows the additional information.
This also applies to your obvious examples of where 3D is better than 2D, e.g. representations of animals and other real life objects. To make use of the additional information, you need a way to request the computer to show you that information. Since all our input devices are also 2D, telling it how we want it to position a 3D model is always a little bit awkward.
I think the other problem is that all the obvious 3D input methods seem to require more energy/effort to use than 2D equivalents, making them comparatively unpleasant to use for extended periods of time.
But, you could be right. I don't think 3D UIs will be interesting to the general public though until we at least have 3D output devices.
Tell that to the Compiz Fusion community, etc.
Am I missing something huge? I like Compiz, but it's hardly a 3D interface. The closest to "3D" is the "desktop cube" which hardly qualifies as being a 3D navigation task. It just looks cool.
Leaving aside the fact that pirated versions will be fixed so as not to require "activation" in the first place, it's fairly logical. Presumably the person on the support line will request the serial number as well as other details (e.g. your name or, the city you live in). If they also check it against a database of issued serial numbers, you wouldn't be able to just use a keygen. So every serial number that gets leaked to the "pirate community" can activate at most 3 copies of the game; and then maybe another 3 assuming poor communication amongst the people who allow manual activation over the phone. By that time the serial would be flagged as a pirated one.
Monopolies themselves are not illegal. Certain business practices may be illegal if you are considered to be a monopoly that would otherwise be perfectly acceptable. Typically anything which could be construed as leveraging your monopoly in one market to help you in another could come under scrutiny. But even then it's very much dependent on circumstances, which is why you can have a massive trial in which a company can be convicted of illegally abusing their monopoly... and then have nothing actually happen.
Possibly if a record label required you to purchase some specific device from a specific manufacturer in order to listen to their music they'd be doing something illegal; however that's very unlikely since individual labels don't have any kind of monopoly, much less an "illegal" one.
Okay, I forgot one important property of certificate-based authentication: even if you present your certificate to a hostile party, they can't use it to pretend to be you. That and mutual authentication pretty much negates phishing as an attack vector altogether, whether it's via social engineering, DNS spoofing or some other method of covertly hijacking communications between two parties. The only way to interfere with such a transaction would be to compromise the security of either the user's computer or the server. Or I guess you could try to recreate the user's private key through brute force, but that seems impractical enough to be a nonissue.
So taken together with your acknowledgement that the unanimous polling is probably overkill for web surfing we can conclude that a) "unanimous multi-polling" doesn't really solve anything (and certainly not the attacks this article is about) and b) we already have the tools necessary to provide a very strong level of protection for secure transactions over the internet.
This veered far away from "fix DNS spoofing", so to get it back on track:
We really need some way to detect the poison and purge it and notify users and admins that the poisoning happened.
Well there's some variations of your proposal that seem simpler. For example, what if the resolver sent its resolution requests to all the name servers for a particular domain, and only accepted the response if they all matched? Now an attacker has to simultaneously poison at least 2 responses. To up the ante, the resolver could additionally request another trusted resolver to also resolve it, which would also do the same thing. So now there's at least 4 responses you have to simultaneously poison, without requiring client-side changes or multiple independent pools.
This still results in any sites which return different responses for different requests suddenly disappearing from the internet though, which I don't think is an acceptable price to pay.
A simpler way to mitigate the problem would be to have your resolver cap the TTL. This limits the maximum amount of time your cache can be poisoned for, requiring attackers to continually re-poison it. This alone might make the cost:benefit ratio low enough to make it not worth doing.
Ultimately, I still think the long-term solution for the majority of resolvers is to detect and block people who are trying to poison their caches. While many won't be in a position to do this currently due to IP spoofing, that is a problem that really ought to be fixed anyway -- DNS poisoning is hardly the only abuse made possible by IP spoofing. The only ones who really can't protect themselves from this are public resolver operators like OpenDNS, as ISPs should be preventing their customers from sending packets from IP addresses which weren't assigned to them. Unfortunately many don't, and many that do only do it at their borders rather than on customer's individual links, so their resolvers are likely vulnerable to attacks from their clients.
Not having a go at you, but why is OSX sending an application "cmd+w" and not "close window" or somesuch, and "cmd+m" instead of "minimize window"? Have Mozilla gone out of their way to break the UI on MacOS, or does the MacOS window manager really expect every application to know what keystrokes are magical?
Both explanations seem pretty bizarre. Maybe there's a third?
Sharepoint 2007 is a good example. Editing of the content is via a browser-based interface, which is quite script heavy. What's interesting is just how script heavy it is. While testing on an old laptop we have connected to an external link, I was a bit dismayed at how slow loading our site was. I got the impression that the browser was pausing before displaying the page for some reason.
Opening up task manager, I saw that before IE displayed the page, it would spin on 50% CPU (on an old hyperthreaded P4) for over 5 seconds before finally rendering the page. After some experimenting which yielded consistent results, I tried Firefox and the difference was dramatic, to say the least.
The upshot of all this is that we may need to recommend to our clients that they use Firefox to edit their Sharepoint 2007 sites, because it provides a significantly better experience than IE does if you have older hardware. On my own desktop at work (a reasonably modern Core 2 Duo) IE does spike the CPU usage, but generally it's for less than a second or two so it's not really distracting. Firefox is faster, but both are quick enough that it doesn't make a real difference to a human.
Completely off-topic: I used refreshes of the task manager process listing to judge how long IE was spinning for. I always assumed the default setting was to refresh the list once per second, and some quick testing now confirms that that is what it does. If you go to View -> Update Speed, the default setting is "Normal". The status tip for this setting says "Updates the display every two seconds". Clearly a lie - or is it? If you select "Normal", then the display does in fact update every two seconds, and there doesn't seem to be any way to get it to go back to refreshing once per second.
Press a button and your surfing browser asks two other DNS servers, preferably separately managed, for a lookup of the name, and compares the IPs. Perhaps it also checks who owns the IPs, so that big sites can still load balance without using exotic tricks.
If a user suspected a site was fake, they wouldn't be providing it their credentials in the first place. If they don't suspect it's a fake, why would they ask for a second (or third) opinion?
I would assume that Akamai and Apple (for instance) should be able to arrange so that only IPs owned by Apple respond to requests for Apple's servers.
This seems... impractical. In order for an organisation to fully leverage Akamai's network, they'd have to pay for at least one dedicated IP address at every major ISP in the world. Maybe when the whole internet is on IPv6 that could be viable, but you'd still need some highly scalable way of authoritatively identifying who "owns" which IP address. I'm pretty sure the ARIN and APNIC and RIPE (etc.) WHOIS servers would melt if every DNS lookup also resulted in a ownership database query.
Checks done in the background put the user to sleep.
This I completely disagree with: checks done in the background are what prevents users from falling asleep at the wheel! Do you seriously believe that you could teach every internet user how to verify that a DNS and IP address chain is legitimate? If so, why are there hundreds of thousands of compromised systems out there whose owners either don't know or don't care that they're spewing garbage on to the internet 24x7? Even if we do somehow achieve this utopian enlightenment of even a significant minority of internet users, do you seriously believe that people will routinely do a full, serious check every single time they access a secure site? Even though 99% of the time everything checks out fine?
That's important to remember. The attack won't come when you expect it; it will come on an ordinary day when you're not on the look out for suspicious activity. This is why it's absolutely imperative that security verification does not require an alert user to consciously and conscientiously verify the identity of the site every single time they access it. Forcing people to do this just leads to complacency, because 99% of the time everything is legit and you're just wasting their time. You need a system that can detect the 1% of the time when things seem a bit suspect, and at that point enlist the aid of a human.
Where did this idea that the general purpose browser should be used for secure transactions come from?
Economic realities, I suppose. Where did this idea that a bank will be able to produce a "banking application" that's some kind of Fort Knox come from? What's the incentive? If forced to do this, the bank will produce something that is "good enough" to make their customers feel like the bank is taking security seriously, while minimising the cost of producing it. It will be an exercise in security theatre. You might improve this by legislating that banks must provide an application that meets certain requirements (which is why I said "if forced to do this"), but I have my doubts whether this would actually work. Or you could let the banks sell their application at a profit, but I'm not sure that'd work: consumers would largely opt for the cheapest options they can find.
Even if all this does actually somehow work, it's now tremendously expensive to do anything secure over the internet. All this cost might be acceptable for large financial institutions, but why are they the only ones deserving of "proper" security?
With that in mind, can you see why you and the bank shouldn't really trust each other without a certificate exchange? That does rely on you to refrain from exposing your certificate
I don't see that a certificate exchange is necessary. After all, your certific
ssl -- you can only trust your bank if your bank can trust you. They have to see your certificate, too. Where do you get your certificate?
Why can't you trust your bank if your bank can't trust you? My bank has an SSL certificate which does a reasonable job of ensuring that when I connect to online.westpac.com.au, I'm connecting to a server operated by Westpac, and not some other server that my hijacked DNS is mistakenly pointing me to, and that someone on a router between me and my bank isn't eavesdropping. It's unnecessary for my bank's server to trust me at this point; they trust me after I supply my customer number and password over the encrypted connection.
Yes, ideally there'd be more security than that, e.g. an RSA token and/or a client certificate. If I did have a certificate, I presume it would have been given to me by the bank either in person or via the post. Regardless, a username and strong password are "good enough" if you know that a) your own system is secure and b) you really are talking to the server you think you're talking to.
The servers within the pool regularly check each other and flag and sequester rogues.
What exactly do they check each other for? Every possible hostname? Every hostname they've ever looked up? Every hostname of popular sites? Every hostname for every financial institution that pool operator happens to know about?
When a client gets a mismatch, it would report that mismatch to all three pools, and the pools would send messages around to all servers to unwedge their caches for that IP address.
This seems troublesome. Either we verify with all the other pools that we really do have a mismatch whenever a client alerts us, in which case we make it really easy for people to DoS us and/or the other pools; or we don't verify it and just flush our caches, which makes it really easy for clients to DoS us and/or the DNS servers of the target site. The latter seems like it would make it much easier to poison caches as well, seeing how if your attempt fails you can just tell the servers to drop their cached records and make another lookup. Granted you have to poison a lot more servers at the same time, but you also greatly reduce the time between retries.
Yes, each bank supplies a dedicated browser for its own customers... you can get cross platform browsers with most of the necessary functionality as library classes in Java and Perl, and probably other languages
Right, and you really think each bank (or even your particular bank) is going to supply a secure and accessible browser for every OS you want to use? Of course not. There's a lot of online banking interfaces that don't work properly in anything other than Internet Explorer, blissfully ignorant of the other 20%+ of browser market share.
I grant that this is technically possible, but it's just not realistic. Banks aren't browser vendors. Besides which, if a bank is going to issue their own special software for banking, why would they make a web browser and not a custom app? If the industry went this way, then I absolutely 100% guarantee you that we'd end up with a whole bunch of poorly designed custom applications with really crappy security that relies on obscurity more than anything else. I'm so confident that this would happen, I'd put money on it.
Yeah, I need to think this out some more, but that's the general idea.
Certainly. The following issues come to my mind immediately:
1. Why would anyone who is capable of setting up a pool of such servers (or a single server in the pool) with all this special code be incapable of applying patches to prevent their DNS servers from having their cache poisoned in the first place? You're creating a very complex system in order to solve a problem which is already pretty much solved by much simpler means (better randomization). The only reason this article
Anything that's important will be using SSL, so even if someone does hijack your bank's DNS entries your browser will warn you that their certificate isn't signed by someone you trust. The only real worry is from typos or bad links, which is why it's recommended practice to never click links in emails to go to sites that you're going to have to log in to, but rather to use a bookmark or type and check the address yourself.
As for the "check against lots of different servers" idea, there's three main problems.
1. If the "pools" are very independent of each other (i.e. different management) then it just makes DoS attacks against certain sites very easy (get in the pool, behave for a while, then start serving nonsense results for www.example.com - voila, anyone using your server to verify addresses will reject that domain).
2. If the pools are under the same management, then they're very likely to be running the same software version on the same platform under the same firewall protection, etc. So an attacker may need to compromise some more servers, but they're all identical.
3. For your financial institutions example, how does the browser know which "check servers" to use? You can't rely on a single reply from one of their authoritative servers, since you don't trust them. If you ask a bunch of other servers, then you're trusting all of them not to be trying to DoS the site in question (and also not to be poisoned themselves).
I guess you could be intending that each bank supplies a browser for use with its website, but then you take a lot of the convenience out of using online banking; in particular, cross-platform support would be a problem.
Slashdot Mirror
Scarcity of bandwidth can be permanently alleviated by an adequate buildout of infrastructure.
Really? Who's going to pay for the infrastructure that can handle an ever-increasing amount of usage? And with what money?
It was designed to break up on re-entry, so if it made it to the ground in one piece some people would have been very angry.
You ask a kid what they want to be today and they want to be a rap star. ... The only time they see or hear about space is when goes wrong or, worse, blows up and kills people.
To be fair, that's when we normally hear about rap stars, too.
The current Rehabilitating Mr Wiggles answers this question: because it's kind of a dick thing to do.
Seriously though, if everyone went around killing each other whenever it suited them, you'd always be in danger of being killed yourself. There's very compelling reasons for a society to collectively agree that killing each other is a bad thing and that it won't be tolerated. No need for a fear of divine retribution.
AC fails at reading the thread.
The post you are responding to was responding to this:
Do you think a vendor is going to undercut their distributor by directing you to a cheaper source? I don't think so.
I think the news part is that Amazon sends you the entire movie when you play the 2 minute "preview". Most people would assume the preview would in fact be a two minute clip without the rest of the movie attached.
How could it possibly be easier for artists without the choice of being with a big label?
Maybe the main effect of big labels is that they centralise spending. The vast majority of bands are unheard of and being in the band is more than likely costing them money. This is a known fact. But it's also a fact there's a relatively small number of bands that have become very very wealthy. Many of these are the "flavour of the day" pushed by the big labels, because big labels have a strong marketing reach -- they can even go so far as to pay popular radio stations to play their artists' songs, giving them exposure they wouldn't otherwise have.
So big labels can be beneficial to the artists they choose to really promote. But from a business point of view, it's more efficient (and therefore profitable) to sell 10 million copies of one album than 1 million copies of 10 albums, or 10,000 copies of a thousand albums. Therefore there's a natural tendency for them to actively promote as few albums as they can.
If there were no big labels, then you might have more specialised market segments. The big chunk of the money-for-music pie that goes to superstar artists on major labels would be divided amongst a lot more different bands. This redistribution of income from the top might be enough to raise the median income amongst artists... which would probably qualify as "being easier for [the majority of] artists".
Just thinking aloud here so there may be flaws in my reasoning and/or it may not apply in real life.
Actually, I think it'd work just fine. Just handle it how we handle secure web sites: your organisation pays for a certificate identifying them. This is trusted by everyone else because they buy it from one of the big CAs whose certificate ships with all OSes, web browsers, or in this case, mail servers.
While a small business and even an individual can easily afford $20 a year for an instant certificate with basic "domain control" validation, it will quickly become prohibitive to continually buy new ones because your certificate keeps ending up on blacklists (because you're spamming, or relaying mail for spammers). In reality, end users won't care, because their email provider (company or ISP) will buy the certificate.
The problem is getting people to do it. If nobody signs their messages, then there's no benefit to requiring signed messages. Since there's no benefit, nobody will sign their messages.
Nit-pit: you generally need or want maintenance/support on your proprietary software, so it's not a one-off cost to acquire it, but a yearly or three-yearly license/maintenance fee. Thus, comparing an 80k purchase to an 80k salary isn't quite fair. However, that's irrelevant.
Most paid programmers work for consultancies that hire out their services for relatively short-term contracts in order to solve particular business needs. i.e. you don't go out and hire a full-time permanent programmer in order to write you something; instead, you pay another company to write it for you. If you need changes made, you hire them again (or someone else). Yes, this is like buying a proprietary software package, but the difference being it's only for use and not useful enough outside of your business for anyone to actually want to sell.
Think of it like most other IT jobs. Small businesses don't usually hire a fulltime systems/network administrator to manage their 10 desktops and an Exchange server; they pay another company to provide that resource when they need it. If you're a really big company that does need lots of internal software, then you might hire permanent programmers because there's always processes that could be improved upon, or you might have sufficient internal apps that there's always bugs and improvements to be made, and so on. But most businesses would simply hire on an as-needed basis.
The question then is, if you're a consultancy providing programmers for hire, why would you give away the software you write for clients? It makes more sense to hoard it so you can re-sell it to others at near original price, while actually only doing some quick customisation. The bigger your pool of software, the less actual work you need to do in order to satisfy customer needs. That means you can either undercut your competition (in terms of time to completion and/or price), or simply make craploads of profit.
I think the answer is probably: you'd do that if everyone else was doing it. So what you'll find is a small number of "open source consultants" customising open source packages to fit their clients needs, and being able to undercut the proprietary shops because of it. Once this is happening enough, formerly proprietary places will start using OSS as well because they're finding it too hard to win contracts since they have to charge so much more. From there, the rest of the dominoes will fall like a house of cards. Checkmate.
Well, the main benefit is in centralising the locations of spam. As it is now, a lot comes from zombie PCs with dynamic IPs. Send and forget works in their favour, because it doesn't matter if the machine moves around or even if it gets cleaned if it's already sent your message out.
By making it a requirement that they keep their system online in order for people to receive the spam message proper, theoretically you degrade their mobility a bit. This makes community blacklists more useful, because once you've spammed a bunch of people using a particular domain name everyone will start blocking or discarding messages that refer to that domain. So now that $10/year for a domain name becomes $10 per X thousand messages. It also may make it easier to track down spammers.
In reality, I don't think it'd make much difference. It's no magic bullet, and there's pretty obvious "solutions" to the problems this would cause spammers.
I think it's more the style of writing. The ACs post is full of inflammatory terms, starting with "Partisan Political hack rags" and ending with "Obama is a fucking disaster waiting to happen". flyingsquid's post was not only much better written, but also avoided using inflammatory terms. It may have been just as critical of Palin as the ACs post was toward Obama, but the criticisms were written in such a manner as to sound reasonable rather than trollish.
You can already use electrical cabling for networking, and given that appliances are all going to have to be connected to power anyway that seems a logical method. It could also simplify discovery and autoconfiguration.
I would really like to see something like browser viewer for a molecule (that is inherently 3D) and its chemical interactions, pictures of animals from the web, movie scenes, basically anything other than text, done better on the whole in 2D than 3D.
Plus, what is to stop text from being rendered in a way that the immediately relevant stuff is in front of you from the start? With 3D you can also use the back (or sides as well) of text boxes to display additional information (for example a log of events)
I think what's really missing is 3D input devices. Rotating a text box so you can see additional information on the side of it would be a nuisance and does not improve in any way upon having a button that shows the additional information.
This also applies to your obvious examples of where 3D is better than 2D, e.g. representations of animals and other real life objects. To make use of the additional information, you need a way to request the computer to show you that information. Since all our input devices are also 2D, telling it how we want it to position a 3D model is always a little bit awkward.
I think the other problem is that all the obvious 3D input methods seem to require more energy/effort to use than 2D equivalents, making them comparatively unpleasant to use for extended periods of time.
But, you could be right. I don't think 3D UIs will be interesting to the general public though until we at least have 3D output devices.
Tell that to the Compiz Fusion community, etc.
Am I missing something huge? I like Compiz, but it's hardly a 3D interface. The closest to "3D" is the "desktop cube" which hardly qualifies as being a 3D navigation task. It just looks cool.
Leaving aside the fact that pirated versions will be fixed so as not to require "activation" in the first place, it's fairly logical. Presumably the person on the support line will request the serial number as well as other details (e.g. your name or, the city you live in). If they also check it against a database of issued serial numbers, you wouldn't be able to just use a keygen. So every serial number that gets leaked to the "pirate community" can activate at most 3 copies of the game; and then maybe another 3 assuming poor communication amongst the people who allow manual activation over the phone. By that time the serial would be flagged as a pirated one.
Monopolies themselves are not illegal. Certain business practices may be illegal if you are considered to be a monopoly that would otherwise be perfectly acceptable. Typically anything which could be construed as leveraging your monopoly in one market to help you in another could come under scrutiny. But even then it's very much dependent on circumstances, which is why you can have a massive trial in which a company can be convicted of illegally abusing their monopoly... and then have nothing actually happen.
Possibly if a record label required you to purchase some specific device from a specific manufacturer in order to listen to their music they'd be doing something illegal; however that's very unlikely since individual labels don't have any kind of monopoly, much less an "illegal" one.
Yo momma's a numerical minority, but a relative supermajority by volume.
I love that this post was modded informative.
Volkswagen is a German company, not Russian..?
Okay, so that's the third, completely un-bizarre explanation. Thanks.
Okay, I forgot one important property of certificate-based authentication: even if you present your certificate to a hostile party, they can't use it to pretend to be you. That and mutual authentication pretty much negates phishing as an attack vector altogether, whether it's via social engineering, DNS spoofing or some other method of covertly hijacking communications between two parties. The only way to interfere with such a transaction would be to compromise the security of either the user's computer or the server. Or I guess you could try to recreate the user's private key through brute force, but that seems impractical enough to be a nonissue.
So taken together with your acknowledgement that the unanimous polling is probably overkill for web surfing we can conclude that a) "unanimous multi-polling" doesn't really solve anything (and certainly not the attacks this article is about) and b) we already have the tools necessary to provide a very strong level of protection for secure transactions over the internet.
This veered far away from "fix DNS spoofing", so to get it back on track:
We really need some way to detect the poison and purge it and notify users and admins that the poisoning happened.
Well there's some variations of your proposal that seem simpler. For example, what if the resolver sent its resolution requests to all the name servers for a particular domain, and only accepted the response if they all matched? Now an attacker has to simultaneously poison at least 2 responses. To up the ante, the resolver could additionally request another trusted resolver to also resolve it, which would also do the same thing. So now there's at least 4 responses you have to simultaneously poison, without requiring client-side changes or multiple independent pools.
This still results in any sites which return different responses for different requests suddenly disappearing from the internet though, which I don't think is an acceptable price to pay.
A simpler way to mitigate the problem would be to have your resolver cap the TTL. This limits the maximum amount of time your cache can be poisoned for, requiring attackers to continually re-poison it. This alone might make the cost:benefit ratio low enough to make it not worth doing.
Ultimately, I still think the long-term solution for the majority of resolvers is to detect and block people who are trying to poison their caches. While many won't be in a position to do this currently due to IP spoofing, that is a problem that really ought to be fixed anyway -- DNS poisoning is hardly the only abuse made possible by IP spoofing. The only ones who really can't protect themselves from this are public resolver operators like OpenDNS, as ISPs should be preventing their customers from sending packets from IP addresses which weren't assigned to them. Unfortunately many don't, and many that do only do it at their borders rather than on customer's individual links, so their resolvers are likely vulnerable to attacks from their clients.
Not having a go at you, but why is OSX sending an application "cmd+w" and not "close window" or somesuch, and "cmd+m" instead of "minimize window"? Have Mozilla gone out of their way to break the UI on MacOS, or does the MacOS window manager really expect every application to know what keystrokes are magical?
Both explanations seem pretty bizarre. Maybe there's a third?
Sharepoint 2007 is a good example. Editing of the content is via a browser-based interface, which is quite script heavy. What's interesting is just how script heavy it is. While testing on an old laptop we have connected to an external link, I was a bit dismayed at how slow loading our site was. I got the impression that the browser was pausing before displaying the page for some reason.
Opening up task manager, I saw that before IE displayed the page, it would spin on 50% CPU (on an old hyperthreaded P4) for over 5 seconds before finally rendering the page. After some experimenting which yielded consistent results, I tried Firefox and the difference was dramatic, to say the least.
The upshot of all this is that we may need to recommend to our clients that they use Firefox to edit their Sharepoint 2007 sites, because it provides a significantly better experience than IE does if you have older hardware. On my own desktop at work (a reasonably modern Core 2 Duo) IE does spike the CPU usage, but generally it's for less than a second or two so it's not really distracting. Firefox is faster, but both are quick enough that it doesn't make a real difference to a human.
Completely off-topic: I used refreshes of the task manager process listing to judge how long IE was spinning for. I always assumed the default setting was to refresh the list once per second, and some quick testing now confirms that that is what it does. If you go to View -> Update Speed, the default setting is "Normal". The status tip for this setting says "Updates the display every two seconds". Clearly a lie - or is it? If you select "Normal", then the display does in fact update every two seconds, and there doesn't seem to be any way to get it to go back to refreshing once per second.
Press a button and your surfing browser asks two other DNS servers, preferably separately managed, for a lookup of the name, and compares the IPs. Perhaps it also checks who owns the IPs, so that big sites can still load balance without using exotic tricks.
If a user suspected a site was fake, they wouldn't be providing it their credentials in the first place. If they don't suspect it's a fake, why would they ask for a second (or third) opinion?
I would assume that Akamai and Apple (for instance) should be able to arrange so that only IPs owned by Apple respond to requests for Apple's servers.
This seems... impractical. In order for an organisation to fully leverage Akamai's network, they'd have to pay for at least one dedicated IP address at every major ISP in the world. Maybe when the whole internet is on IPv6 that could be viable, but you'd still need some highly scalable way of authoritatively identifying who "owns" which IP address. I'm pretty sure the ARIN and APNIC and RIPE (etc.) WHOIS servers would melt if every DNS lookup also resulted in a ownership database query.
Checks done in the background put the user to sleep.
This I completely disagree with: checks done in the background are what prevents users from falling asleep at the wheel! Do you seriously believe that you could teach every internet user how to verify that a DNS and IP address chain is legitimate? If so, why are there hundreds of thousands of compromised systems out there whose owners either don't know or don't care that they're spewing garbage on to the internet 24x7? Even if we do somehow achieve this utopian enlightenment of even a significant minority of internet users, do you seriously believe that people will routinely do a full, serious check every single time they access a secure site? Even though 99% of the time everything checks out fine?
That's important to remember. The attack won't come when you expect it; it will come on an ordinary day when you're not on the look out for suspicious activity. This is why it's absolutely imperative that security verification does not require an alert user to consciously and conscientiously verify the identity of the site every single time they access it. Forcing people to do this just leads to complacency, because 99% of the time everything is legit and you're just wasting their time. You need a system that can detect the 1% of the time when things seem a bit suspect, and at that point enlist the aid of a human.
Where did this idea that the general purpose browser should be used for secure transactions come from?
Economic realities, I suppose. Where did this idea that a bank will be able to produce a "banking application" that's some kind of Fort Knox come from? What's the incentive? If forced to do this, the bank will produce something that is "good enough" to make their customers feel like the bank is taking security seriously, while minimising the cost of producing it. It will be an exercise in security theatre. You might improve this by legislating that banks must provide an application that meets certain requirements (which is why I said "if forced to do this"), but I have my doubts whether this would actually work. Or you could let the banks sell their application at a profit, but I'm not sure that'd work: consumers would largely opt for the cheapest options they can find.
Even if all this does actually somehow work, it's now tremendously expensive to do anything secure over the internet. All this cost might be acceptable for large financial institutions, but why are they the only ones deserving of "proper" security?
With that in mind, can you see why you and the bank shouldn't really trust each other without a certificate exchange? That does rely on you to refrain from exposing your certificate
I don't see that a certificate exchange is necessary. After all, your certific
ssl -- you can only trust your bank if your bank can trust you. They have to see your certificate, too. Where do you get your certificate?
Why can't you trust your bank if your bank can't trust you? My bank has an SSL certificate which does a reasonable job of ensuring that when I connect to online.westpac.com.au, I'm connecting to a server operated by Westpac, and not some other server that my hijacked DNS is mistakenly pointing me to, and that someone on a router between me and my bank isn't eavesdropping. It's unnecessary for my bank's server to trust me at this point; they trust me after I supply my customer number and password over the encrypted connection.
Yes, ideally there'd be more security than that, e.g. an RSA token and/or a client certificate. If I did have a certificate, I presume it would have been given to me by the bank either in person or via the post. Regardless, a username and strong password are "good enough" if you know that a) your own system is secure and b) you really are talking to the server you think you're talking to.
The servers within the pool regularly check each other and flag and sequester rogues.
What exactly do they check each other for? Every possible hostname? Every hostname they've ever looked up? Every hostname of popular sites? Every hostname for every financial institution that pool operator happens to know about?
When a client gets a mismatch, it would report that mismatch to all three pools, and the pools would send messages around to all servers to unwedge their caches for that IP address.
This seems troublesome. Either we verify with all the other pools that we really do have a mismatch whenever a client alerts us, in which case we make it really easy for people to DoS us and/or the other pools; or we don't verify it and just flush our caches, which makes it really easy for clients to DoS us and/or the DNS servers of the target site. The latter seems like it would make it much easier to poison caches as well, seeing how if your attempt fails you can just tell the servers to drop their cached records and make another lookup. Granted you have to poison a lot more servers at the same time, but you also greatly reduce the time between retries.
Yes, each bank supplies a dedicated browser for its own customers ... you can get cross platform browsers with most of the necessary functionality as library classes in Java and Perl, and probably other languages
Right, and you really think each bank (or even your particular bank) is going to supply a secure and accessible browser for every OS you want to use? Of course not. There's a lot of online banking interfaces that don't work properly in anything other than Internet Explorer, blissfully ignorant of the other 20%+ of browser market share.
I grant that this is technically possible, but it's just not realistic. Banks aren't browser vendors. Besides which, if a bank is going to issue their own special software for banking, why would they make a web browser and not a custom app? If the industry went this way, then I absolutely 100% guarantee you that we'd end up with a whole bunch of poorly designed custom applications with really crappy security that relies on obscurity more than anything else. I'm so confident that this would happen, I'd put money on it.
Yeah, I need to think this out some more, but that's the general idea.
Certainly. The following issues come to my mind immediately:
1. Why would anyone who is capable of setting up a pool of such servers (or a single server in the pool) with all this special code be incapable of applying patches to prevent their DNS servers from having their cache poisoned in the first place? You're creating a very complex system in order to solve a problem which is already pretty much solved by much simpler means (better randomization). The only reason this article
Anything that's important will be using SSL, so even if someone does hijack your bank's DNS entries your browser will warn you that their certificate isn't signed by someone you trust. The only real worry is from typos or bad links, which is why it's recommended practice to never click links in emails to go to sites that you're going to have to log in to, but rather to use a bookmark or type and check the address yourself.
As for the "check against lots of different servers" idea, there's three main problems.
1. If the "pools" are very independent of each other (i.e. different management) then it just makes DoS attacks against certain sites very easy (get in the pool, behave for a while, then start serving nonsense results for www.example.com - voila, anyone using your server to verify addresses will reject that domain).
2. If the pools are under the same management, then they're very likely to be running the same software version on the same platform under the same firewall protection, etc. So an attacker may need to compromise some more servers, but they're all identical.
3. For your financial institutions example, how does the browser know which "check servers" to use? You can't rely on a single reply from one of their authoritative servers, since you don't trust them. If you ask a bunch of other servers, then you're trusting all of them not to be trying to DoS the site in question (and also not to be poisoned themselves).
I guess you could be intending that each bank supplies a browser for use with its website, but then you take a lot of the convenience out of using online banking; in particular, cross-platform support would be a problem.