There are *lots* of ways to trick people into using your evil URL and IP address instead of the real bank's URL and IP address. The allegedly-elegant method that Mikko's proposing makes some of those tricks harder to use, but it's an arms race, and if some of the bad guys can't use the wimpy methods, they'll get out the stronger ones that may not work on as many victims, but will do much more damage to the victims they do get.
Some of the phishing methods are purely technical, but most are a combination of technology and social engineering. Changing the TLD makes the technology part a bit harder, but provides a nice big hook to hang the social engineering part on.
Unfortunately, the best customers for phishers usually aren't using Firefox - they're either using the browser that came with their PC, or else the one that came with their AOL account.
And if they're using the one that came with their PC, they may very well have several extra toolbars to "help" them use the Internet, though that can be a problem for phishers because other crackers may get the bank account info before they do.
911/E911's a huge technical/administrative pain
on
AT&T Dumps VOIP Customers
·
· Score: 5, Interesting
The 911 system, especially E911, is deeply tied into the technical and financial structure of the old monopoly telco / government bureaucracy system, and breaks badly if you try to change it, and the FCC and some state regulations forcing new-technology carriers like VOIP to work with it forces all the brokenness and cost onto the carriers.
The existing system has an interface from the telcos to the emergency operator system that has a large number of assumptions about what the phone network looks like, as well as telco-style interface technology, and would require major redesign to accommodate different technologies - but the emergency operator systems don't have a funding source that lets them do that, so the regulators are making the carriers interface to them like old telcos, even if they really really aren't. Here are some of the kinds of assumptions that need to be worked with:
A phone sits in one place in a building.
The building sits in one place.
The place where the building sits has one police station, one fire company, and one or more ambulance companies that serve it.
There's a wire from the telco to the building.
The caller wants the police/fire/ambulance to show up at the building.
There's a phone number associated with the wire (not the phone.)
There's a specific telco that supports that phone number, and the telco has records about the building and phone. (Number portability regulations did entertaining things to that one...)
If the phone's supported by a PBX, and the phone has an individual number usable for outgoing calls, there are telco records that indicate which floor the phone's on, but otherwise the emergency vehicle should show up at the front door. (Even *that* had a lot of complexity to it.)
If you move the phone, at least to a different floor, or change the phone number, or move the phone number to a different building, you'll let the telco know.
The regulations can be different for wireline telcos, because they know where the real wires are, than for non-wireline telco-like carriers (like Vonage, and the pre-merger long-distance AT&T.)
Hey, no they can't! 911 has to work everywhere! - regardless of any infrastructure differences.
It's a really ugly mess (and CALEA makes it far worse for anybody it applies to.) There are some service providers who can handle the interface equipment parts of PSAP connectivity, but you still need to find a way to make your databases have *some* resemblence to the information the regulators need - even if it inherently *doesn't* work that way.
For cell phones, at the time the Feds wanted to make 911 work, it was obvious that the wireline assumptions just wouldn't work, because your cellphone is usually not at the place your phone bill or phone number live, and even aside from the FBI wiretap-freaks wanting to radically expand their surveillance capabilities, it's a hard problem if you want accurate location information - and the PSAP structure isn't usually very good at dealing with non-street-addressed location information. I've got a fairly recent GSM-based phone, but the last time or two that I've tried to report car accidents in San Francisco, the 911 operators have connected me to the California Highway Patrol rather than the local police, because the CHP seems to know how to deal with moving callers, while the PSAP system would otherwise need to guess whether I was inside the SF city limits, or in Daly City or Brisbane, based on my description of what freeway signs I was near, and assign the call to the correct police department.
The new regulations on VOIP carriers, as far as I can tell, seem to assume that any carrier who's connecting to the wireline public telephone system and isn't a known cellphone carrier can be treated as a wireline carrier even if that's not what their system does. It's a big problem.
Unfortunately, "Fixed Addresses" are one of the IPv6 features that might or might not happen, because the reasons for using or not using them are the same as in IPv4 (though that doesn't really address whether you need to use servers or how easy it is to do wiretapping.) The main reasons broadband carriers prefer dynamic addresses and charge more for static are
Customers don't have to configure their PCs or firewall routers for IP addresses if they use DHCP, and they can just plug the stuff in and have it work, so you cut down on installer technician work and help desk handholding work. In the IPv6 world, there are mechanisms for autoconfiguring your host number (e.g. use 0000+MACaddress) but they still require either configuring your/64 etc. network number into your router or else using some other kind of server, so the problems are pretty similar, and the handholding is more complex because IPv6 gives you more options.
Some carriers really like PPPoE, because it makes it easier for them to correlate network connections with billing and shut you off if you haven't paid them or they catch you spamming. This is more of an issue for cable companies than DSL, since most DSL is ATM-based, which makes it pretty easy to do the same things at Layer 2.
Customers who want static addresses are usually willing to pay more, and if you're willing to pay more, carriers absolutely want to charge you more. This is especially true for people who want static addresses so they can use business VPNs, because the carriers perceive they can get you to pay more since it's for business.
US cable modem companies developed an early fear of customers running servers, because they were worried about perceived performance, and they didn't have the technical capability for rate-limiting individual users - they were especially worried that some customer might by running a pr0n server at home that used up the upstream performance of their whole neighborhood. The telco DSL servers exacerbated this fear by running the "Web Hog" TV commercials, which were dishonest but effective.
But even if you've got a fixed IP address with IPv6, you're less likely to communicate it to somebody by printing it on your business card and handing it to them than you were with your IPv4 address - you're probably going to use a presence server of some kind (whether it's SIP or something proprietary like Skype), or at least a DNS server (bob@voip.example.com), or email it to them, and all of those mechanisms introduce potential vulnerabilities if you're not careful with them. 128-bit end-to-end encryption is enough to keep anybody from breaking into your phone call, so the obvious attack methods are to get you to relay the voice channel through somewhere, or else relay the key exchange through somewhere that can be cracked.
I don't know if it's still true, but the last time I looked at uCLinux, it had a rather different approach to memory management than regular Linux, and was designed for devices that didn't have real memory manager chips. Is that still the case, or is it more mainstream now?
If we've colonized the place, then we'll have the capability of generating ethanol. Combining that with Martian ice should let you make margaritas, or at least dacquiris, which should take care of what you need...
There are two kinds of web sites in this business - ones that actually have interesting content and ones that don't. If you're the kind of site that only gets business by Getting Lucky, not by being interesting, then you're probably also competing with a bunch of other sites with equal lack of value, and there are too many of them to shoot down. There'll be exceptions (e.g. your link spammer isn't totally inept, just totally sleazy, so he'll give you a cut-rate price to link-spam them all at once, but he's still inept enough not to give the competitors an offer to rat you out as well...)
Strikes me as a game with no future in it. Extortion, on the other hand, might be profitable if you're the type who can get away with that successfully.
Google tries to give people the most interesting web sites first, and they do a good enough job that people trust Google as their search engine. Because Google can't do that by having real people read and rank all the billions of web page out there, they use robots to guess how interesting humans will find the site. If you want the robots to guess that your sites look more interesting than some other site, you can do a couple of things
Make sure the robots can find the interesting information on your site. It's important, but for all the hype the SEO people give you about their services, you can fit the implementation details into about half a page of advice on labelling stuff, like "Use Keywords" and "Make your navigation human-readable, not 4-dimensional Flash animation".
Make the information on your site more interesting to humans than the information on the other site.Business that "Depend on Google for Sales" are usually not very interesting to humans - there's no reason that your web site selling whatevers is any more interesting than anybody else's web site selling the same things. If your site were *actually* more interesting, people would be typing "YourName Whatevers"; if you got your turn on Page 1 last month for people searching for "Whatevers ForSale", and you're Feeling Lucky, well, don't expect it to last. SEOs sometimes say that they're trying to help with this, and sometimes they actually are - marketing consulting things like telling you what's boring about your sites and ways to actually improve your content, or telling you to advertise so people have heard your name. But usually people who sell this kind of advice don't call themselves SEOs.
Try to lie to the robots so they'll guess that your site is more interesting than it actually is. That's the real SEO game; Google Hell is for people who got caught and pissed off the robots and their masters (bwah-hah-hah!) or who accidentally did something that looked like they were trying to do that. If "accidentally" means "hired a consultant who said he'd help you raise your Google rankings so you'll get free money from the sky\\\Internet", well, bummer for you, man.
Try to lie to the robots so they'll guess that the other site is less interesting than it is. It's mean, nasty, and evil, and normally there are too many other sites that are trying to inflate their reputations that it doesn't work. Save this for cases when you're trying to prove that your Administration isn't a Miserable Failure.
How big is Google's share of the search market? It's hard to tell what to believe in the press, but most of the estimates I've seen run to about 40%, with the other big players being Yahoo, MSN, and AOL. Sure, it's the search engine *I* use, and it's the only one that's become a verb without running TV commercials to do it, but it's still not like losing your ranking in Google means you're blacklisted from cyberspace.
On the other hand, if Google, Yahoo, MSN, and AOL all think your pages aren't interesting, maybe they... aren't interesting.
Looks like a lot more than 2.5 Gbps, though most of the connections aren't bigger than that. I don't know whether the part of CAT that matters to you is IIG or NIX, but it looks like there are a lot of connections to other Internet carriers in the region, either within Thailand or else out to IIJ, C&W, etc. The TOT gateways aren't much bigger than 2.5 Gbps, but there's a total of 19+ Gbps, which is pretty respectable for a country the size of Thailand.
If you look at a map of the undersea cable routes between South-East Asia and the US, or South-East Asia and North-East Asia, where "South-East Asia" includes the big markets of Hong Kong, Southern Taiwan, Guangzhou, Singapore, and traffic from India that routes through Singapore or HK, as well as smaller markets like Malaysia, Indonesia, Thailand, Vietnam, etc., and "North-East" includes Shanghai, Beijing, Korea, Japan, and Northern Taiwan, everything runs between Taiwan and Philippines except for a couple of cables that head down to Australia (which is *really* the long way around) and a segment of the China-US Cable that goes between Taiwan and the mainland. And except for traffic that could take the Sydney-Guam-Japan route, or some traffic that could take land routes across China, everything north-south had to go at least to Hawaii and back, or usually to North America.
There are a *lot* of cables on that route. The December 2006 Taiwan quake took out N-1 or maybe N-2 of the cables there, and multiple segments of several of them. The cables had enough diversity to deal with problems like ship anchors and fishing nets; the earthquake trashed them all at once, and mostly in deep water. There weren't close to enough cable repair ships on that side of the world to fix them all at once, and weather delayed the repairs as well (plus repairs are a lot slower in deep water.) You can see some good maps at telegeography.com.
This cable sounds like a big big win. I haven't seen a map of the route yet, just press releases, but if it goes around the other side without going all the way down to Sydney, it'll not only cut a few tens of milliseconds off the route, and add a lot of (potential, if not necessarily actually lit up for a while) bandwidth, but it'll make a major difference to reliability. The Telekom Malaysia PR person said: "This low-risk route was designed to avoid the volatile and hazardous Pacific Ring, thus mitigating the effects from natural disasters like earthquakes and tsunamis."
> The non-drowsy stuff you can get without a prescription is just
Claritin used to be prescription, but it's now OTC, and it's come down from a buck a pill to something more reasonable. Try it; you might like it. It's not as heavy-duty as benadryl or my old standard clorpheniramine, but it's not bad for a once-a-day pill. There's also clemastine fumarate (aka Tavist), which is a not-very-drowsy antihistamine that's usually an 8-12 hour dose; I get a little spacy on it but not usually enough to bother me, and YMMV. Both used to be available either plain or with sudafed before the meth wars; I suepect they've probably also come out with a phenylephrine version. (Sigh - usually PE doesn't work as well for me as Sudafed.)
I normally prefer to buy single-ingredient pills and mix my dosages myself, just as you do, but sometimes there are convenient enough combinations.
I haven't looked at DJBDNS for dynamic applications, only for more conventional ones.
But one of the main *points* of building a system like that, (other than expressing one's personal crabbiness about the rest of the world:-) is that by building components with limited functionality and using pre-existing standard tools to do the things that pre-existing standard tools already do well, you can restrict the security exposure of your new components, and can design them to use only the privileges and powers they need to get their jobs done, generally be small enough to debug, and be small enough to fix bugs in without introducing significant new vulnerabilities. The Unix design philosophy of building small tool components that you can use together as opposed to large monoliths was valuable two decades ago when we were still using Vaxen and Sun-3s, and it's still valuable today.
Most of the time you don't *need* anywhere near 10% of the features of BIND - usually you don't even need 50% of the features of DJBDNS either. BIND isn't quite the Mos Eisely kitchen sink of network protocol applications, because that honor goes to Sendmail, and both of those systems *have* improved a lot in the last few years, but it has justly acquired a reputation of having been a quick hack from two decades ago that's grown into an ancient shambling horror of creeping features.
There are small applications where something simple like DJBDNS is enough. There are a reasonable range of applications where it's not, and for some of them BIND is a good choice, or some of the newer alternatives. And then there are applications that are complex, as opposed to large, where what you need is really a relational database system with some front-ends to provide DNS-lookup interfaces, and for those you might want to roll your own if there aren't good tools available already - otherwise you'll find yourself writing hunks of perl scripts to extract data from the database and turn it into BIND input and vice versa.
InfoBlox is Cricket Liu et al - you'll probably recognize his name as the author of the O'Reilly DNS book. I've generally heard good things about their products, though I haven't used them myself.
Unfortunately, router performance with IPv6 still is a big issue - just because routers have hardware-based forwarding for IPv4 and have IPv6 capability doesn't mean that the IPv6 on most of their varieties of port cards is really hardware-based.
MPLS moves some of these decisions from the really fat core MPLS switches to the IP-to-MPLS edge or middle-tier routers, but they still have the same scalability problems to solve. IPv6 does better for private networks, where you're not trying to route to the whole Internet, just to a single customer's networks plus maybe a carrier's value-added services, plus you can do a better job of route aggregation - but you still need to do packet forwarding.
Also, IPv6 tends to need lots more memory, especially for BGP, simply because the addresses are longer, and router vendors whose names start with C used to have serious issues with that, and still charge way too much for their RAM; I haven't dealt much with routers starting with J, but maybe they do a bit better? IPv6 was supposed to fix the whole scalability problem by letting us assign address space hierarchically, but that trick didn't really work when confronted with real-world issues like customers who need diverse ISPs for reliability, and unfortunately ugly kluges like shim6 don't strike me as likely to solve that problem.
That's not really true - while it's fairly popular to make multi-symptom cold medicines, with Sudafed, antihistamine, tylenol/aspirin, expectorant, and dextromethorphan, those aren't the ones that get advertised as non-drowsy. Sudafed and its relatives get sold by themselves as non-drowsy, and as you say they're stimulant. The other main non-drowsy allergy meds are things like Claritin, which is an anti-histamine that doesn't make you drowsy, and while they also formulate it with a stimulant decongestant, they advertise both of them as non-drowsy. Allegra's pretty much the same way, available by prescription either straight or with decongestant; I find it's a bit more effective for me most of the time.
Dextromethorphan cough suppressant doesn't make most people drowsy in the doses normally taken for cough suppression. It's also often packaged with an expectorant or decongestant or Tylenol. On the other hand, it's also taken in large doses as a recreational dissociative (see Erowid for commentary), which can be really dangerous if you're consuming formulations that mix in other drugs.
As far as dentists using novocaine and nitrous when you've taken other drugs, novocaine's very localized, and dental patients are very commonly taking codeine or stronger relatives. Nitrous is pretty self-regulating when administered with normal dental apparatus - if you're getting too much, you breathe through your mouth to get more air, or if you want more, you breathe more though your nose, and if you pass out, you'll have your mouth open. My normal trip to the dentist is followed by a trip to Peet's or Starbucks and enough time for the nitrous to finish wearing off before I go home, but I didn't bother mentioning caffeine among the drugs I'd taken that trip:-)
Leaving aside the parent article's sense of humor on the topic, Richi's blog article doesn't really add up technically. IPv6 will eventually be necessary to handle the IPv4 address shortage, and maybe some of the mobile IP work in IPv6 won't get ported to IPv4, but probably anything useful will.
IPv4 has several flavors of priority marking, including TOS and DSCP; most of the MPLS (private routed IP) carriers out there are using DSCP to provide 3 to 6 priority levels, which their customers typically use to give high priority to VOIP, maybe high priority to video, medium priority to corporate data applications, and low priority to things like email, web, and ftp that aren't latency-sensitive. Some ISPs support these markings on their public internet service as well, at least on some of their services (e.g. higher-speed corporate-priced circuits, but not necessarily on DSL where the routers don't always support it.) The real limitation there is getting ISPs to agree with each other on which of the 64 available markings to use, how many values, and of course, how to charge (preferably a flat rate.)
As far as peering infrastructure investment goes, the big carriers are spending madly on this to prevent bottlenecks. It's a bit different in the US, where ~20-25 big carriers peer with each other, than in the UK, where everybody peers at LINX, but the problem for Richi should be whether his ISP buys enough LINX bandwidth to keep up with their users. Last I heard LINX and AMSIX were doing mostly ok on keeping up with demand, as long as the ISPs kept up.
Static IP addresses are really a critical issue, and NAT traversal problems are closely related. IPv6 may make this a bit easier, but basically it's an ISP administrative convenience issue (so they don't have to help customers configure PCs) and a firewalling issue (NAT's a cheap beginning on real firewalls, so everybody uses it), and the various flavors of IPv6 autoconfig may eventually replace some of it.
IPv6's big problems for now are router performance, chicken&egg issues with content providers and lack of motivation until the big addressing crunch hits.
A few years back I was coming home from the dentist, and realized that getting stopped would be a really really bad thing. My voice would have been all slurry because my mouth wazh shtill numb frub da novocaine, so they'd want to test me, novocaine's a cocaine relative, the codeine I'd had earlier in the day is an opiate, I'd had some sudafed to keep my breathing clear while they worked on me, so they'd test that as amphetamines, and ibuprofen causes false positives on the standard cheap marijuana tests. Hadn't had any alcohol that day, and they can't really test for nitrous (and it had worn off before I left the dentist), but otherwise I'd have had a perfect score unless they also test for weird stuff like mescaline or something...
... i.e. just about as long as laptops have been usable. Wireless eavesdropping and TEMPEST issues were a common discussion topic back in the Cypherpunks era, among the technical experts as well as among the tinfoil hat crowd, and a number of us had worked with TEMPEST professionally.
My ~1995 laptop (486? Pentium 60? MHz) would display on my parents' TV screen when I visited them. (No, I didn't live in their basement, I'd just avoided having a TV in my house back then:-) It wasn't in sync, so there were three partial screen images scrolling slowly, and there weren't enough pixels, but it was readable enough to be obvious that a real receiver would be able to display the output cleanly. My guess was that the culprit wasn't really the LCD drivers, but the auxiliary VGA port on the back of the laptop; I no longer remember if I tried turning that on and off, or exactly which laptop model it was, but Google probably knows.
The real difficulties are getting enough focus to only grab signals from the laptop you're looking for, and not all the other CRTs and TVs and LCDs around, which is why you're reading an interview with an expert like Markus Kuhn and not just some 1337 k1dd13z, and doing so without parking a big antennaful van on the street in front of your target.
If you look at the real security threats here, there are two sides -
Crackers trolling for whatever they can find, like passwords and credit card numbers they can abuse, who are willing to eavesdrop on anybody nearby, such as people in an airport
Cops and spooks and secret police who are targeting *you*, in which case you've got much more serious security problems than whether your laptop screen can be eavesdropped.
If your ISP wants to eavesdrop on all your unencrypted mail, they can, even if they're not your email provider.
If you use a POP or IMAP email provider, rather than direct delivery to your Unix box, they've got just as much ability to eavesdrop as a webmail provider does.
I've got a wide range of different email providers, mostly web-based, for different applications with different privacy needs.
My main really-for-me personal email goes to an ISP where I run procmail and have a shell account and then use a PC-based mail client.
My DSL provider also has a shell and email account, which forwards to my main email, and almost never gets anything except admin and billing mail from the ISP.
Registration email for web sites usually goes to dodgeit.com for stuff that's really disposable.
I've got one webmail system that mostly gets people who might spam me, but might not spam me, and will be sending email in the future. Conference registrations are one example. It's a free account, so if there's too much spam I can chuck it.
Gmail gets one or two technical mailing lists. That's mainly because I wanted to play with gmail, and partly because I wanted to be able to comment on some of the lists from an email account that's not my work account or my long-term home account. And now I need a gmail account to use the Mountain View free wireless, so it's helpful there.
I read some Yahoogroups, so I've got a Yahoo email account.
Unfortunately, Google and Yahoo are trying to absorb Youtube and Flickr, and I was perfectly happy having logins there that were some variant on "anonymouscoward4". Gmail's login ID already absorbed my Orkut ID, which wasn't all that annoying because I'd stopped using Orkut by then.
I got a couple of AOL IM id's so I could play with an instant messaging appliance. The appliance turned out to be not very exciting, but it was worth a $20 experiment.
I've got other emails scattered here and there, like the places I run some mailing lists from, and dusty PCs scattered around various labs and friends' garage PCs and maybe a game system or two.
My cat used to have a Hotmail account, but when they decided you could only get one if you were over 13, she couldn't access it any more because she'd told them her real age instead of lying about it.
Online newspapers that want demographics usually get my zipcode as 90210, and my age as whatever year they give as an example, and a random gender. Unfortunately this sometimes means they show me banner ads for things in Beverly Hills instead of here, but what's an anonymous coward got to complain about?
There are three reasons you might not see these things over your city -
Stealthy UAVs are hard to see!
The things might not actually work very well.
Your local police and politicians may have some other boondoggle they like better than this one.
Various people have been proposing blimps and other aerostats for cellular and data applications, and every year there's another announcement that they'll be launching Real Soon Now. But they don't. On the other hand, with Glorious Homeland Security Anti-Terrorist Funding, your local police might be able to buy them anyway. The US Military has proposed a fleet of a dozen blimps watching our borders for Drug Enforcement, watching for small planes that are too hard to see from ground-based radar. I don't know if that's been launched yet or not.
What happened to you is unfortunately a pattern. Mail forwarding breaks a lot of assumptions that spam filters and similar tools use. You've already encountered the problem that forwarding your dad's email to his hotmail account forwards his spam too, but there are other problems. The right solution for your dad might be for you to run a webmail system on your own box so he doesn't have to use hotmail.
For instance, SPF lets you say "all mail from example.com comes from IP address 1.2.3.4", but if fred@example.com sends mail to yourdad@yourdomain.com, and you forward it to yourdad@hotmail.com, hotmail is going to receive mail claiming to be from fred@example.com with your IP address on it, and reject it as a forgery. And since any recipient of a mailing list could be a forwarded address, the folks who run mailinglist@example.com can't just use SPF to prevent forgers from imitating them. (That's especially annoying if mailinglist@example.com is a good phishing target, e.g. paypal, ebay, online banks.) It's actually somewhat ironic that SPF has this problem - one of its main authors and proponents, Meng Weng Wong, runs pobox.com, an early mail forwarding service...
One of the other people commented that his university does spam filtering on outgoing forwarded mail. It's not a really precise approach, since you lose some of the information about where the mail came from, but if you're already using sender-IP-based spam filters on the inbound side you're covering most of that need. (Also, you really should be greylisting incoming mail to chase off the anklebiters.) I use pobox.com as an email forwarding provider, and they provide a fairly extensive set of spam filter options that their users can select. For instance, I don't want any email that originated in Nigeria or is in a Chinese or Russian character set, but your university may have students from Nigeria and students who read Chinese and Russian, so you wouldn't just block those messages wholesale.
Back when I ran a Cypherpunks Remailer, I was considering setting it to only forward encrypted messages; that way they not only would be private, but it wouldn't look like *my* system was sending spam or abusive emails so I wouldn't have to deal with complaints. A related idea was to automatically encrypt any email to known recipients; if you have a working mail encryption system, you could do the same for forwarding email, but of course that's not a good match for a Hotmail account where the recipient may not have PGP or similar tools.
Typos - Domains used to cost $35 from Verisign or its predecessors. Making a mistake was really annoying. At $6, who cares?
Trademark Conflicts - you can't always tell that somebody else in the world (or even the US) isn't using a name that's pretty similar to the one you're trying to register. You could offer to sell it to them, but that's treading on abusive domain name squatting and can lead to high legal costs. Even so, it's still going to cost you more than $6 to deal with the issue; maybe giving it back should still cost you $1.
Unexpected Typo Conflicts - Maybe you weren't typosquatting, but there's some site or search term that generates lots of traffic that's *not* what you're interested in, and you're getting lots of traffic that's really for some word in Italian or Polish. Again, at $6, you might just not care, but if you've got an incentive to return the name to the namespace for people who legitimately want it, that'd be a good thing. If you *can't* return it, youll probably point it at some domain-parker site where you get advertising revenue and maybe point the visitors to the site they were really looking for.
They're not just stealing the name because they hope to extort money selling it back to you or your competitors - they're mainly doing this because they make money selling advertising banners, and stealing a real name means they'll get some traffic from real users of that name, in addition to anything they might get because the domain name used keywords people might search for.
It's scum messing up the domain name space's usefulness, and it ought to be stopped.
The Registry charges Registrars a standard fee for registering a name for a year - it was $6, but I think it's just gone up by 10% or so. The Registrars charge whatever the market will bear for their services, making money on convenience or cooperation for abuse, etc. The $6 fee isn't particularly cost-based; it was a scam from the beginning, but it's supposed to cover their costs for handling transactions, maintaining reliable database storage, etc.
The "Add Grace" period lets you return domain names for free, for instance if you've made a typo in the domain name or somebody notifies you that your name collides with their trademark. It's not totally stupid, because it means there's *some* incentive to return incorrect names instead of keeping them for the full year or forever. On the other hand, in practice it's been a miserable failure from the time "domain name investors" discovered they could do "market research" by brute-force domain tasting, rather than predicting what names are actually worth paying money for before buying them. Mostly, it made sense back when domain names cost $35 from Verisign.
IMHO, the right Registry price for returning domain names during the "Add Grace" period should be about 50% - it's enough to cut down on the high-volume typosquatters, but still provide some incentive to return names. More importantly, the price of buying a domain name should include a CAPTCHA to cut down on this kind of namespace pollution.
Slashdot Mirror
Some of the phishing methods are purely technical, but most are a combination of technology and social engineering. Changing the TLD makes the technology part a bit harder, but provides a nice big hook to hang the social engineering part on.
And if they're using the one that came with their PC, they may very well have several extra toolbars to "help" them use the Internet, though that can be a problem for phishers because other crackers may get the bank account info before they do.
The existing system has an interface from the telcos to the emergency operator system that has a large number of assumptions about what the phone network looks like, as well as telco-style interface technology, and would require major redesign to accommodate different technologies - but the emergency operator systems don't have a funding source that lets them do that, so the regulators are making the carriers interface to them like old telcos, even if they really really aren't. Here are some of the kinds of assumptions that need to be worked with:
- A phone sits in one place in a building.
- The building sits in one place.
- The place where the building sits has one police station, one fire company, and one or more ambulance companies that serve it.
- There's a wire from the telco to the building.
- The caller wants the police/fire/ambulance to show up at the building.
- There's a phone number associated with the wire (not the phone.)
- There's a specific telco that supports that phone number, and the telco has records about the building and phone. (Number portability regulations did entertaining things to that one...)
- If the phone's supported by a PBX, and the phone has an individual number usable for outgoing calls, there are telco records that indicate which floor the phone's on, but otherwise the emergency vehicle should show up at the front door. (Even *that* had a lot of complexity to it.)
- If you move the phone, at least to a different floor, or change the phone number, or move the phone number to a different building, you'll let the telco know.
- The regulations can be different for wireline telcos, because they know where the real wires are, than for non-wireline telco-like carriers (like Vonage, and the pre-merger long-distance AT&T.)
- Hey, no they can't! 911 has to work everywhere! - regardless of any infrastructure differences.
It's a really ugly mess (and CALEA makes it far worse for anybody it applies to.) There are some service providers who can handle the interface equipment parts of PSAP connectivity, but you still need to find a way to make your databases have *some* resemblence to the information the regulators need - even if it inherently *doesn't* work that way.For cell phones, at the time the Feds wanted to make 911 work, it was obvious that the wireline assumptions just wouldn't work, because your cellphone is usually not at the place your phone bill or phone number live, and even aside from the FBI wiretap-freaks wanting to radically expand their surveillance capabilities, it's a hard problem if you want accurate location information - and the PSAP structure isn't usually very good at dealing with non-street-addressed location information. I've got a fairly recent GSM-based phone, but the last time or two that I've tried to report car accidents in San Francisco, the 911 operators have connected me to the California Highway Patrol rather than the local police, because the CHP seems to know how to deal with moving callers, while the PSAP system would otherwise need to guess whether I was inside the SF city limits, or in Daly City or Brisbane, based on my description of what freeway signs I was near, and assign the call to the correct police department.
The new regulations on VOIP carriers, as far as I can tell, seem to assume that any carrier who's connecting to the wireline public telephone system and isn't a known cellphone carrier can be treated as a wireline carrier even if that's not what their system does. It's a big problem.
But even if you've got a fixed IP address with IPv6, you're less likely to communicate it to somebody by printing it on your business card and handing it to them than you were with your IPv4 address - you're probably going to use a presence server of some kind (whether it's SIP or something proprietary like Skype), or at least a DNS server (bob@voip.example.com), or email it to them, and all of those mechanisms introduce potential vulnerabilities if you're not careful with them. 128-bit end-to-end encryption is enough to keep anybody from breaking into your phone call, so the obvious attack methods are to get you to relay the voice channel through somewhere, or else relay the key exchange through somewhere that can be cracked.
I don't know if it's still true, but the last time I looked at uCLinux, it had a rather different approach to memory management than regular Linux, and was designed for devices that didn't have real memory manager chips. Is that still the case, or is it more mainstream now?
If we've colonized the place, then we'll have the capability of generating ethanol. Combining that with Martian ice should let you make margaritas, or at least dacquiris, which should take care of what you need...
Strikes me as a game with no future in it. Extortion, on the other hand, might be profitable if you're the type who can get away with that successfully.
On the other hand, if Google, Yahoo, MSN, and AOL all think your pages aren't interesting, maybe they ... aren't interesting.
Looks like a lot more than 2.5 Gbps, though most of the connections aren't bigger than that. I don't know whether the part of CAT that matters to you is IIG or NIX, but it looks like there are a lot of connections to other Internet carriers in the region, either within Thailand or else out to IIJ, C&W, etc. The TOT gateways aren't much bigger than 2.5 Gbps, but there's a total of 19+ Gbps, which is pretty respectable for a country the size of Thailand.
There are a *lot* of cables on that route. The December 2006 Taiwan quake took out N-1 or maybe N-2 of the cables there, and multiple segments of several of them. The cables had enough diversity to deal with problems like ship anchors and fishing nets; the earthquake trashed them all at once, and mostly in deep water. There weren't close to enough cable repair ships on that side of the world to fix them all at once, and weather delayed the repairs as well (plus repairs are a lot slower in deep water.) You can see some good maps at telegeography.com.
This cable sounds like a big big win. I haven't seen a map of the route yet, just press releases, but if it goes around the other side without going all the way down to Sydney, it'll not only cut a few tens of milliseconds off the route, and add a lot of (potential, if not necessarily actually lit up for a while) bandwidth, but it'll make a major difference to reliability. The Telekom Malaysia PR person said: "This low-risk route was designed to avoid the volatile and hazardous Pacific Ring, thus mitigating the effects from natural disasters like earthquakes and tsunamis."
Claritin used to be prescription, but it's now OTC, and it's come down from a buck a pill to something more reasonable. Try it; you might like it. It's not as heavy-duty as benadryl or my old standard clorpheniramine, but it's not bad for a once-a-day pill. There's also clemastine fumarate (aka Tavist), which is a not-very-drowsy antihistamine that's usually an 8-12 hour dose; I get a little spacy on it but not usually enough to bother me, and YMMV. Both used to be available either plain or with sudafed before the meth wars; I suepect they've probably also come out with a phenylephrine version. (Sigh - usually PE doesn't work as well for me as Sudafed.)
I normally prefer to buy single-ingredient pills and mix my dosages myself, just as you do, but sometimes there are convenient enough combinations.
But one of the main *points* of building a system like that, (other than expressing one's personal crabbiness about the rest of the world :-) is that by building components with limited functionality and using pre-existing standard tools to do the things that pre-existing standard tools already do well, you can restrict the security exposure of your new components, and can design them to use only the privileges and powers they need to get their jobs done, generally be small enough to debug, and be small enough to fix bugs in without introducing significant new vulnerabilities. The Unix design philosophy of building small tool components that you can use together as opposed to large monoliths was valuable two decades ago when we were still using Vaxen and Sun-3s, and it's still valuable today.
Most of the time you don't *need* anywhere near 10% of the features of BIND - usually you don't even need 50% of the features of DJBDNS either. BIND isn't quite the Mos Eisely kitchen sink of network protocol applications, because that honor goes to Sendmail, and both of those systems *have* improved a lot in the last few years, but it has justly acquired a reputation of having been a quick hack from two decades ago that's grown into an ancient shambling horror of creeping features.
There are small applications where something simple like DJBDNS is enough. There are a reasonable range of applications where it's not, and for some of them BIND is a good choice, or some of the newer alternatives. And then there are applications that are complex, as opposed to large, where what you need is really a relational database system with some front-ends to provide DNS-lookup interfaces, and for those you might want to roll your own if there aren't good tools available already - otherwise you'll find yourself writing hunks of perl scripts to extract data from the database and turn it into BIND input and vice versa.
InfoBlox is Cricket Liu et al - you'll probably recognize his name as the author of the O'Reilly DNS book. I've generally heard good things about their products, though I haven't used them myself.
MPLS moves some of these decisions from the really fat core MPLS switches to the IP-to-MPLS edge or middle-tier routers, but they still have the same scalability problems to solve. IPv6 does better for private networks, where you're not trying to route to the whole Internet, just to a single customer's networks plus maybe a carrier's value-added services, plus you can do a better job of route aggregation - but you still need to do packet forwarding.
Also, IPv6 tends to need lots more memory, especially for BGP, simply because the addresses are longer, and router vendors whose names start with C used to have serious issues with that, and still charge way too much for their RAM; I haven't dealt much with routers starting with J, but maybe they do a bit better? IPv6 was supposed to fix the whole scalability problem by letting us assign address space hierarchically, but that trick didn't really work when confronted with real-world issues like customers who need diverse ISPs for reliability, and unfortunately ugly kluges like shim6 don't strike me as likely to solve that problem.
Dextromethorphan cough suppressant doesn't make most people drowsy in the doses normally taken for cough suppression. It's also often packaged with an expectorant or decongestant or Tylenol. On the other hand, it's also taken in large doses as a recreational dissociative (see Erowid for commentary), which can be really dangerous if you're consuming formulations that mix in other drugs.
As far as dentists using novocaine and nitrous when you've taken other drugs, novocaine's very localized, and dental patients are very commonly taking codeine or stronger relatives.
Nitrous is pretty self-regulating when administered with normal dental apparatus - if you're getting too much, you breathe through your mouth to get more air, or if you want more, you breathe more though your nose, and if you pass out, you'll have your mouth open. My normal trip to the dentist is followed by a trip to Peet's or Starbucks and enough time for the nitrous to finish wearing off before I go home, but I didn't bother mentioning caffeine among the drugs I'd taken that trip
IPv4 has several flavors of priority marking, including TOS and DSCP; most of the MPLS (private routed IP) carriers out there are using DSCP to provide 3 to 6 priority levels, which their customers typically use to give high priority to VOIP, maybe high priority to video, medium priority to corporate data applications, and low priority to things like email, web, and ftp that aren't latency-sensitive. Some ISPs support these markings on their public internet service as well, at least on some of their services (e.g. higher-speed corporate-priced circuits, but not necessarily on DSL where the routers don't always support it.) The real limitation there is getting ISPs to agree with each other on which of the 64 available markings to use, how many values, and of course, how to charge (preferably a flat rate.)
As far as peering infrastructure investment goes, the big carriers are spending madly on this to prevent bottlenecks. It's a bit different in the US, where ~20-25 big carriers peer with each other, than in the UK, where everybody peers at LINX, but the problem for Richi should be whether his ISP buys enough LINX bandwidth to keep up with their users. Last I heard LINX and AMSIX were doing mostly ok on keeping up with demand, as long as the ISPs kept up.
Static IP addresses are really a critical issue, and NAT traversal problems are closely related. IPv6 may make this a bit easier, but basically it's an ISP administrative convenience issue (so they don't have to help customers configure PCs) and a firewalling issue (NAT's a cheap beginning on real firewalls, so everybody uses it), and the various flavors of IPv6 autoconfig may eventually replace some of it.
IPv6's big problems for now are router performance, chicken&egg issues with content providers and lack of motivation until the big addressing crunch hits.
A few years back I was coming home from the dentist, and realized that getting stopped would be a really really bad thing. My voice would have been all slurry because my mouth wazh shtill numb frub da novocaine, so they'd want to test me, novocaine's a cocaine relative, the codeine I'd had earlier in the day is an opiate, I'd had some sudafed to keep my breathing clear while they worked on me, so they'd test that as amphetamines, and ibuprofen causes false positives on the standard cheap marijuana tests. Hadn't had any alcohol that day, and they can't really test for nitrous (and it had worn off before I left the dentist), but otherwise I'd have had a perfect score unless they also test for weird stuff like mescaline or something...
My ~1995 laptop (486? Pentium 60? MHz) would display on my parents' TV screen when I visited them. (No, I didn't live in their basement, I'd just avoided having a TV in my house back then:-) It wasn't in sync, so there were three partial screen images scrolling slowly, and there weren't enough pixels, but it was readable enough to be obvious that a real receiver would be able to display the output cleanly. My guess was that the culprit wasn't really the LCD drivers, but the auxiliary VGA port on the back of the laptop; I no longer remember if I tried turning that on and off, or exactly which laptop model it was, but Google probably knows.
The real difficulties are getting enough focus to only grab signals from the laptop you're looking for, and not all the other CRTs and TVs and LCDs around, which is why you're reading an interview with an expert like Markus Kuhn and not just some 1337 k1dd13z, and doing so without parking a big antennaful van on the street in front of your target.
If you look at the real security threats here, there are two sides -
- Stealthy UAVs are hard to see!
- The things might not actually work very well.
- Your local police and politicians may have some other boondoggle they like better than this one.
Various people have been proposing blimps and other aerostats for cellular and data applications, and every year there's another announcement that they'll be launching Real Soon Now. But they don't. On the other hand, with Glorious Homeland Security Anti-Terrorist Funding, your local police might be able to buy them anyway. The US Military has proposed a fleet of a dozen blimps watching our borders for Drug Enforcement, watching for small planes that are too hard to see from ground-based radar. I don't know if that's been launched yet or not.For instance, SPF lets you say "all mail from example.com comes from IP address 1.2.3.4", but if fred@example.com sends mail to yourdad@yourdomain.com, and you forward it to yourdad@hotmail.com, hotmail is going to receive mail claiming to be from fred@example.com with your IP address on it, and reject it as a forgery. And since any recipient of a mailing list could be a forwarded address, the folks who run mailinglist@example.com can't just use SPF to prevent forgers from imitating them. (That's especially annoying if mailinglist@example.com is a good phishing target, e.g. paypal, ebay, online banks.) It's actually somewhat ironic that SPF has this problem - one of its main authors and proponents, Meng Weng Wong, runs pobox.com, an early mail forwarding service...
One of the other people commented that his university does spam filtering on outgoing forwarded mail. It's not a really precise approach, since you lose some of the information about where the mail came from, but if you're already using sender-IP-based spam filters on the inbound side you're covering most of that need. (Also, you really should be greylisting incoming mail to chase off the anklebiters.) I use pobox.com as an email forwarding provider, and they provide a fairly extensive set of spam filter options that their users can select. For instance, I don't want any email that originated in Nigeria or is in a Chinese or Russian character set, but your university may have students from Nigeria and students who read Chinese and Russian, so you wouldn't just block those messages wholesale.
Back when I ran a Cypherpunks Remailer, I was considering setting it to only forward encrypted messages; that way they not only would be private, but it wouldn't look like *my* system was sending spam or abusive emails so I wouldn't have to deal with complaints. A related idea was to automatically encrypt any email to known recipients; if you have a working mail encryption system, you could do the same for forwarding email, but of course that's not a good match for a Hotmail account where the recipient may not have PGP or similar tools.
Typos - Domains used to cost $35 from Verisign or its predecessors. Making a mistake was really annoying. At $6, who cares?
Trademark Conflicts - you can't always tell that somebody else in the world (or even the US) isn't using a name that's pretty similar to the one you're trying to register. You could offer to sell it to them, but that's treading on abusive domain name squatting and can lead to high legal costs. Even so, it's still going to cost you more than $6 to deal with the issue; maybe giving it back should still cost you $1.
Unexpected Typo Conflicts - Maybe you weren't typosquatting, but there's some site or search term that generates lots of traffic that's *not* what you're interested in, and you're getting lots of traffic that's really for some word in Italian or Polish. Again, at $6, you might just not care, but if you've got an incentive to return the name to the namespace for people who legitimately want it, that'd be a good thing. If you *can't* return it, youll probably point it at some domain-parker site where you get advertising revenue and maybe point the visitors to the site they were really looking for.
It's scum messing up the domain name space's usefulness, and it ought to be stopped.
The $6 fee isn't particularly cost-based; it was a scam from the beginning, but it's supposed to cover their costs for handling transactions, maintaining reliable database storage, etc.
The "Add Grace" period lets you return domain names for free, for instance if you've made a typo in the domain name or somebody notifies you that your name collides with their trademark. It's not totally stupid, because it means there's *some* incentive to return incorrect names instead of keeping them for the full year or forever. On the other hand, in practice it's been a miserable failure from the time "domain name investors" discovered they could do "market research" by brute-force domain tasting, rather than predicting what names are actually worth paying money for before buying them. Mostly, it made sense back when domain names cost $35 from Verisign.
IMHO, the right Registry price for returning domain names during the "Add Grace" period should be about 50% - it's enough to cut down on the high-volume typosquatters, but still provide some incentive to return names. More importantly, the price of buying a domain name should include a CAPTCHA to cut down on this kind of namespace pollution.