True - but the situation rarely occurs, and the phishing threat is real enough that we shouldn't implement this. A "flush DNS cache" option hidden in a menu somewhere would be a better option.
Putting the IP in the hosts file will work fine. Your browser sees '192.168.1.10 example1.com' in the hosts file, then connects to 192.168.1.10 and asks for example1.com. No problem, right?
That's a terrible idea - the phishers would be all over that. Anyone who needs to override DNS should know how to do so themselves - and a IP-based address is useless for long-term use, so you wouldn't be able to use them in stable links either.
Most likely it would take a long time (years, maybe decades) to reach a dangerous size. However, once it consumes enough of the core to produce a hollow cavity, we might begin feeling it on the surface.
Virtually all bittorrent clients support a distributed hash table, and inter-client peer exchange protocol, which means that as long as you have the.torrent metafile you can bootstrap yourself into the torrent (neither DHT nor peer exchange uses DNS at all in fact, except perhaps when the client is first installed to bootstrap). The only impact would be on obtaining said.torrent file, which is explicitly out of bittorrent's problem domain.
This doesn't mean we shouldn't try protecting what we can. Just because there's other badness in the world doesn't mean we shouldn't try to stamp out the little patches of badness that are within our reach. After all, if personal information can leak that easily, why use https in the first place?
there close to a billion people on the net that wouldnt tell what to do when faced with such a disastrous looking warning as ff 3 prints out when met with a self signed ca.
also there are equally many people that would rather skip visiting/subscribing to a site when they see the hassle ff3 puts out.
This is exactly why this is the correct behavior. Consider Joe Bloggs, visiting their online bank from a random WiFi point. Suddenly they get a cryptic popup, something about "SSL" and "self-signed". Whatever, they click ok and login. The next day a few thousand dollars leaves their account.
The self-signing warning needs to be scary, and not just a simple "ok", or ordinary users will click through on autopilot. Given how many people connect through cases where a MitM is possible (open WiFi, unpatched DNS), it's important to protect them from this possibility. If you have need to connect to a self-signed site, you can always whitelist it, as long as you understand the implications of doing so (ie, if you're on an untrusted connection - and 99% of the userbase has no idea how to evaluate that - don't do it).
Good luck getting that fissible material out without anyone noticing. Or overriding the emergency shutoffs (in the case of chernobyl, they actually had to jam wrenches into valves to keep the thing from shutting down on its own). I don't think it's exactly feasable for a few errant workers to make it go boom on their own...
So why not just reboot the peripheral's driver and keep going? Heck, if the driver's going to crash/anyway/, and you have the choice between killing the driver and killing the entire OS, it seems like a pretty sound decision to kill just the driver. Even if in some cases this isn't useful, crashing the entire machine is never useful.
The transfer is only when you first upload it (and again when you download it of course). If you're not uploading or downloading, just leaving it there, it's $0.15/gb/mo.
I'm not sure I can trust that as much as S3... but I guess that's a judgement call everyone has to make for themselves:) At least S3 has provisions for upkeep costs, unlike files forever...
With S3 you'd pay $15/mo (+bandwidth) to have it hosted online, instantly accessible.
Will it still be around 20 years from now? One can't be certain, but if not, I'm sure you'll have enough warning to copy things off to another medium, and I'm sure there'll be similar services to take its place if need be.
The support thread talks about both, so I'd assume they (or their insurance, anyway) is paying out the nose for dozens of contractors to come in on short notice right about now.
Slashdot Mirror
Idle-free slashdot, thanks to yahoo pipes
... not slashdot.
IANAL, but don't you only get statutory damages if you register your copyright?
Often there is such a blurb, but the dev just uses some off-the-shelf installer and throws the GPL into the 'EULA GOES HERE' box.
True - but the situation rarely occurs, and the phishing threat is real enough that we shouldn't implement this. A "flush DNS cache" option hidden in a menu somewhere would be a better option.
Putting the IP in the hosts file will work fine. Your browser sees '192.168.1.10 example1.com' in the hosts file, then connects to 192.168.1.10 and asks for example1.com. No problem, right?
You can easily use the hosts file to redirect any domain name to whatever IP you like.
That's a terrible idea - the phishers would be all over that. Anyone who needs to override DNS should know how to do so themselves - and a IP-based address is useless for long-term use, so you wouldn't be able to use them in stable links either.
Most likely it would take a long time (years, maybe decades) to reach a dangerous size. However, once it consumes enough of the core to produce a hollow cavity, we might begin feeling it on the surface.
On google docs: http://docs.google.com/Presentation?id=dd9j7tj4_107hd7g9bfs
Virtually all bittorrent clients support a distributed hash table, and inter-client peer exchange protocol, which means that as long as you have the .torrent metafile you can bootstrap yourself into the torrent (neither DHT nor peer exchange uses DNS at all in fact, except perhaps when the client is first installed to bootstrap). The only impact would be on obtaining said .torrent file, which is explicitly out of bittorrent's problem domain.
This doesn't mean we shouldn't try protecting what we can. Just because there's other badness in the world doesn't mean we shouldn't try to stamp out the little patches of badness that are within our reach. After all, if personal information can leak that easily, why use https in the first place?
99% of the userbase would ignore that bar, and log into their bank anyway.
This is exactly why this is the correct behavior. Consider Joe Bloggs, visiting their online bank from a random WiFi point. Suddenly they get a cryptic popup, something about "SSL" and "self-signed". Whatever, they click ok and login. The next day a few thousand dollars leaves their account.
The self-signing warning needs to be scary, and not just a simple "ok", or ordinary users will click through on autopilot. Given how many people connect through cases where a MitM is possible (open WiFi, unpatched DNS), it's important to protect them from this possibility. If you have need to connect to a self-signed site, you can always whitelist it, as long as you understand the implications of doing so (ie, if you're on an untrusted connection - and 99% of the userbase has no idea how to evaluate that - don't do it).
Good luck getting that fissible material out without anyone noticing. Or overriding the emergency shutoffs (in the case of chernobyl, they actually had to jam wrenches into valves to keep the thing from shutting down on its own). I don't think it's exactly feasable for a few errant workers to make it go boom on their own...
So why not just reboot the peripheral's driver and keep going? Heck, if the driver's going to crash /anyway/, and you have the choice between killing the driver and killing the entire OS, it seems like a pretty sound decision to kill just the driver. Even if in some cases this isn't useful, crashing the entire machine is never useful.
Glib has something more or less exactly like this, minus the private_history_data (what's that supposed to be for?)
Varargs is only usable if you can determine via some other means the types and number of your arguments.
You could always do one eye at a time :)
Please note that replying voids your modpoints. :)
The transfer is only when you first upload it (and again when you download it of course). If you're not uploading or downloading, just leaving it there, it's $0.15/gb/mo.
I'm not sure I can trust that as much as S3... but I guess that's a judgement call everyone has to make for themselves :) At least S3 has provisions for upkeep costs, unlike files forever...
With S3 you'd pay $15/mo (+bandwidth) to have it hosted online, instantly accessible. Will it still be around 20 years from now? One can't be certain, but if not, I'm sure you'll have enough warning to copy things off to another medium, and I'm sure there'll be similar services to take its place if need be.
The support thread talks about both, so I'd assume they (or their insurance, anyway) is paying out the nose for dozens of contractors to come in on short notice right about now.
Wouldn't people who want such redundancy consider putting the other server in another DC?