Not quite... Dropbox, as the service provider, does NOT have the right to say what is or is not copyrighted content -- unless they hold the copyright. Under the DMCA (and to claim it as such) they would have to receive a notice from the copyright holder (or their registered agent(s)) pointing out what they believe to be infringing. Dropbox is then obligated to remove those files and notify the user. As the SP, they have no say in the matter -- no matter how obviously incorrect the claim may be, they cannot say "you're full of shit" and ignore it. It's up to the user to file the "you're full of shit" counter claim.
Deleting files and claiming there was a DMCA request when their wasn't isn't covered in the DMCA. It's certainly fraud and misrepresentation of the facts, but legally actionable is open to debate.
Agreed. The usual answer will be no, unless you have very deep pockets. The effort to recover data is almost always not worth what you're trying to recover.
The whole reason for them being discarded is they'd started to fail or past their safe usable lifetime. Anyone willing to buy them is simply burning money.
Not the way they're doing it. Evap cooling vaporizes the water. Once it's vapor, it's hard to drink, irrigate, etc. with it. You'll have to wait for it to condense back into liquid (ala rain, snow, sleet, etc.) before it's "usable" again. As others point out, that's very rarely a closed system -- the rain comes down hundreds of miles away.
The way many (some?) office buildings are cooled, on the other hand, does not vaporize the water. It takes water from the muni supply, runs it through a coil, and returns it (a bit hotter) to the muni supply. That works rather well for an office building. The heat load in a datacenter is way too high for that -- it takes too high a volume and would vent much higher temp water than most cities will accept.
If you have $90k to buy one, I don't think you'll be basing your buying decision on what those nuts have to say. And their track is not even remotely "the real world." I'd trust them about as much as I test Telsa's diagnostic data -- which they could just as easily doctor or manufacture.
Yes, it is. But if it's like any of the systems I've worked with over the years (and some I wrote myself), it's faster to ask the user than go dig it up. The first thing we asked for was "customer number and/or circuit id". Yes, we can find that from a company name, postal address, ip address, or the billing account name (which for a company can take several guesses.) (and at BTI, being a phone company... a phone number.)
What they need depends on what system they're using.
Everyone will have a static prefix. Privacy extentions randomly generate the rest of the address, and change it often (eg. 24hrs). And this assumes ISPs are going to assign static prefixes instead of DHCP6-PD -- which could be dynamic. You'll have the exact same issue as today... you cannot reliably trace an address to a specific machine and specific human being.
[Even in my house, where I'm the only perm. resident, it's never 100% assured that I'm the one generating traffic. There are dozens of people with devices that can access my wireless network. And 3 that have keys that can access the wired network. Plus the possiblity of remote users doing things -- with or without permission.]
Have we even built a new reactor in the US since 1974? Duke Power tried to build one in Cherokee, SC, but there was so much bitching and other bullshit, they abandoned the project. (sold to E.O. Studios who filmed The Abyss there.)
So, yes, this *could* happen to us, but huge earthquake + tsunami is so unlikely, I'm not worried about it. The thing that *does* worry me is the fact that our plants are ~40 years old. (and they were only designed to run 30 years.)
You make it sound like it'll shutdown quickly like a coal fired plant. A coal power plant will shutdown within minutes of killing the coal feed -- stop blowing coal dust into the tower, and the fire goes out. A thorium breeder reactor will continue to run for quite some time before it's sufficently depleted. It's similar to a log in camp fire.
burn a hole in the earth straight through to China
I've always loved that... for starters what's most likely to happen is the molten goo hits the water table resulting in a flash boil the blows toxic, radioactive crap everywhere. The less likely possiblity (and this is WAY remote) is that it burns burns all the way through the mantle and becomes lava. (then you have lava and toxic, radioactive crap everywhere.:-))
No. Because ssl session setup doesn't involve AES. The ssl encrypted packet stream can use AES, but that's never been the really expensive part of ssl.
This depends entirely on your specific environment. If you have only a few dozen ssl sessions per hour, then it's basically zero. If you have 100 per minute, you'll start to notice it. 300-400 sessions per second and you'll be out shopping for hardware. SSL session negotiation is an expensive operation. If you're lucky, it'll be a rare enough event.
It's also up to the CLIENT to resume the session. If you close your browser, any ssl session information is lost. The next time you fire up the browser and connect to a site, it will have to start the process over again. With tabbed browsers, I don't know how often most people restart -- I tend to leave opera running for weeks, but chrome gets started/stopped a dozen times per day. (as does IE and safari) And then, opera will only use a session for so long before starting a new one.
Small correction... the request doesn't happen until the ssl session is setup. Meaning certificate(s) and key negotiation has completed. At that point, it's too late to select the correct certificate. The protocol was changed years ago to allow a "hint" in the client-hello to tell the server which host you are aiming for so it can select the correct cert. Some OSes/browsers were never updated to support it -- XP being among them.
Well, that and the serial number of the FOB you want to clone. which you can get off the FOB or out of the server's database. (and the user's PIN. and login ID.)
I think you've underestimated the male demographic that, well, hangs out on 4chan and watches anime. "come here and f*** me" would work 99.999% of the time.:-)
It looks like a dynamic address because of it's DNS PTR. Or because the netblock is listed as "residential" in (r)WHOIS. Or, if some RBLs are to be believed, because the ISP told them to list it. (I put zero stock in such claims.)
That said, my 24.xxx biz.rr.com addresses are not on anyone's blocklist that I've ever been able to find. And none of the addresses map to "mail.domain.com". On the other hand, my VZB DS3 doesn't have any DNS PTR's so many (most?) mail servers refuse to deal with those addresses. [I don't send mail from them, so I don't care.]
And what block would that be? IANA, ARIN, et. al. have never assigned a block "for cable modems". Netblocks are assigned to organizations and they use them as they need. One cannot assume and thing that start "24." is a cable modem and should therefore be ignored. (while there are CMs in 24/8, every address is not a CM nor are all CMs in 24/8)
Pure NAT -- what linux calls "simple nat" -- is not a firewall. What all the linksys's, netgears, and d-links of the world do is a firewall. Connection tracking and protocol helpers are every bit the same as a pure firewall; they're just rewriting addresses as well. SPI happens in both cases.
Right. Trust the buggiest OS in the world to be your firewall. I guess you've missed the memo's about the various bugs that foul up windows even with the firewall on. Linux has had a few as well, for that matter. Cisco's router and firewall products have had similar problems, too.
As much as it is your religion that "NAT is not a firewall", NAT is what protects 99% of the internet today. People will not realize they need to take steps to protect their computers -- or even know what a firewall is.
Again, IPSec is end-to-end encryption. It does NOT mean the protocol itself (or even how it does IPSec) is remotely secure. Forcing every IPv6 stack to contain a full IPSec layer is bloat at it's finest. Btw, just because the stack has to support it doesn't mean applications will use it.
IPv4 and IPv6 are entirely different protocols. They cannot talk to each other. PERIOD. Technically, it's possible to write a v6 stack that can understand a v4 packet, but the reverse is impossible... IPv4 stacks cannot make sense of v6 packets. v4 and v6 are as alien to each other as IPX and Appletalk. This is why the transition is such a horrible fucking mess. You have to run both, everywhere. Or resort to application specific protocol proxies. In case you missed it, IPv6 compatible IPv4 addressing has been depreciated for years. (so long ago my Cisco 1760 (long past EOL) won't let me enter such an address.)
NAT is gone in IPv6. Period. Anyone attempting it will be facing a never ending battle of broken applications. End to end transparency is fundamental to IPv6. IPSec will make sure you cannot screw with an application's traffic.
DHCP was a bolt-on compromise. In it's current form, DHCPv6 is a bad joke. Look at what you can do with DHCPv4. Now look at what you can do with DHCPv6.
IPSec does not mean the protocol (IPv6) has been designed with any thought given to privacy (hello, SLAAC) or security. IPv4 has IPSec but the protocol itself still has had numerous problems in both areas. Plus, IPSec alone makes the network stack over a megabyte just about everywhere. This isn't a problem for Windows(tm), but is a huge issue for the millions of tiny devices found everywhere today (TV's, STB's, clocks, blu-ray players, phones, cell phones, cable modems, dsl modems, routers, switches, etc., etc., etc.)
Face it. IPv6 is a failure. We're going to be forced to use this mistake for many decades. It was designed by idiots who were more concerned with their own religion and political agendas than building the next gen protocol to be useful for many decades (centuries?) IPv4, in contrast, was designed by very bright minds. The technology they designed is still in use 30 years later with very little modification. An IPv4 ethernet device built in 1982 still works flawlessly in modern IPv4 networks. An IPv6 device designed just 10 years ago doesn't fair so well in today's IPv6 networks -- for one, SLAAC is a 64bit prefix now; it was 80 then.
NAT was a real mess in the begining due to various protocols assuming they knew what the host's IP address was and rolled it into the data flowing between systems. That assumption caused problems long before NAT existed; there just weren't enough people with multi-homed systems to scream about it. NAT made that assumption wrong 100% of the time, for everyone. Protocol helpers are required to deal with those things. In the era of NAT, protocols are designed without making such assumptions. Unless, of course, you're an idiot. (see also: SIP)
What we're going to see in a world sans-NAT, is a return to the 80's and 90's where the internet is "naked". As anyone should well know by now, NEVER connect a windows box directly to the internet. People will not be smart enough to setup firewalls, or even realize they need one. NAT is their firewall today. And despite the religious wars, NAT IS their firewall.
Actually, the lack of adoption is partly (mostly?) to blame on the standard being pure shit... designed by committee, by academics who have never run a real world network. Too many personal political agenda's are wired into this thing... NO NAT! No DHCP -- SLAAC fixes everything (except it doesn't) MUST include full IPSec. No attention on privacy or security.
What was RFC'd over a decade ago is not what IPv6 is today. And it will continue to change until the seemingly endless mountains of stupid are corrected.
How is the "public" being misled when they weren't sent a copy? If you're a PE, you sure as hell should be able to spot engineering work... by, oh say, the fucking PE seal and signature.
Slashdot Mirror
Not quite... Dropbox, as the service provider, does NOT have the right to say what is or is not copyrighted content -- unless they hold the copyright. Under the DMCA (and to claim it as such) they would have to receive a notice from the copyright holder (or their registered agent(s)) pointing out what they believe to be infringing. Dropbox is then obligated to remove those files and notify the user. As the SP, they have no say in the matter -- no matter how obviously incorrect the claim may be, they cannot say "you're full of shit" and ignore it. It's up to the user to file the "you're full of shit" counter claim.
Deleting files and claiming there was a DMCA request when their wasn't isn't covered in the DMCA. It's certainly fraud and misrepresentation of the facts, but legally actionable is open to debate.
Agreed. The usual answer will be no, unless you have very deep pockets. The effort to recover data is almost always not worth what you're trying to recover.
The whole reason for them being discarded is they'd started to fail or past their safe usable lifetime. Anyone willing to buy them is simply burning money.
Not the way they're doing it. Evap cooling vaporizes the water. Once it's vapor, it's hard to drink, irrigate, etc. with it. You'll have to wait for it to condense back into liquid (ala rain, snow, sleet, etc.) before it's "usable" again. As others point out, that's very rarely a closed system -- the rain comes down hundreds of miles away.
The way many (some?) office buildings are cooled, on the other hand, does not vaporize the water. It takes water from the muni supply, runs it through a coil, and returns it (a bit hotter) to the muni supply. That works rather well for an office building. The heat load in a datacenter is way too high for that -- it takes too high a volume and would vent much higher temp water than most cities will accept.
If you have $90k to buy one, I don't think you'll be basing your buying decision on what those nuts have to say. And their track is not even remotely "the real world." I'd trust them about as much as I test Telsa's diagnostic data -- which they could just as easily doctor or manufacture.
Yes, it is. But if it's like any of the systems I've worked with over the years (and some I wrote myself), it's faster to ask the user than go dig it up. The first thing we asked for was "customer number and/or circuit id". Yes, we can find that from a company name, postal address, ip address, or the billing account name (which for a company can take several guesses.) (and at BTI, being a phone company... a phone number.)
What they need depends on what system they're using.
Everyone will have a static prefix. Privacy extentions randomly generate the rest of the address, and change it often (eg. 24hrs). And this assumes ISPs are going to assign static prefixes instead of DHCP6-PD -- which could be dynamic. You'll have the exact same issue as today... you cannot reliably trace an address to a specific machine and specific human being.
[Even in my house, where I'm the only perm. resident, it's never 100% assured that I'm the one generating traffic. There are dozens of people with devices that can access my wireless network. And 3 that have keys that can access the wired network. Plus the possiblity of remote users doing things -- with or without permission.]
Have we even built a new reactor in the US since 1974? Duke Power tried to build one in Cherokee, SC, but there was so much bitching and other bullshit, they abandoned the project. (sold to E.O. Studios who filmed The Abyss there.)
So, yes, this *could* happen to us, but huge earthquake + tsunami is so unlikely, I'm not worried about it. The thing that *does* worry me is the fact that our plants are ~40 years old. (and they were only designed to run 30 years.)
You make it sound like it'll shutdown quickly like a coal fired plant. A coal power plant will shutdown within minutes of killing the coal feed -- stop blowing coal dust into the tower, and the fire goes out. A thorium breeder reactor will continue to run for quite some time before it's sufficently depleted. It's similar to a log in camp fire.
burn a hole in the earth straight through to China
I've always loved that... for starters what's most likely to happen is the molten goo hits the water table resulting in a flash boil the blows toxic, radioactive crap everywhere. The less likely possiblity (and this is WAY remote) is that it burns burns all the way through the mantle and becomes lava. (then you have lava and toxic, radioactive crap everywhere. :-))
No. Because ssl session setup doesn't involve AES. The ssl encrypted packet stream can use AES, but that's never been the really expensive part of ssl.
This depends entirely on your specific environment. If you have only a few dozen ssl sessions per hour, then it's basically zero. If you have 100 per minute, you'll start to notice it. 300-400 sessions per second and you'll be out shopping for hardware. SSL session negotiation is an expensive operation. If you're lucky, it'll be a rare enough event.
It's also up to the CLIENT to resume the session. If you close your browser, any ssl session information is lost. The next time you fire up the browser and connect to a site, it will have to start the process over again. With tabbed browsers, I don't know how often most people restart -- I tend to leave opera running for weeks, but chrome gets started/stopped a dozen times per day. (as does IE and safari) And then, opera will only use a session for so long before starting a new one.
Small correction... the request doesn't happen until the ssl session is setup. Meaning certificate(s) and key negotiation has completed. At that point, it's too late to select the correct certificate. The protocol was changed years ago to allow a "hint" in the client-hello to tell the server which host you are aiming for so it can select the correct cert. Some OSes/browsers were never updated to support it -- XP being among them.
Well, that and the serial number of the FOB you want to clone. which you can get off the FOB or out of the server's database. (and the user's PIN. and login ID.)
I think you've underestimated the male demographic that, well, hangs out on 4chan and watches anime. "come here and f*** me" would work 99.999% of the time. :-)
It looks like a dynamic address because of it's DNS PTR. Or because the netblock is listed as "residential" in (r)WHOIS. Or, if some RBLs are to be believed, because the ISP told them to list it. (I put zero stock in such claims.)
That said, my 24.xxx biz.rr.com addresses are not on anyone's blocklist that I've ever been able to find. And none of the addresses map to "mail.domain.com". On the other hand, my VZB DS3 doesn't have any DNS PTR's so many (most?) mail servers refuse to deal with those addresses. [I don't send mail from them, so I don't care.]
It's not about *who* you are, but what class of service you're paying for. Business class services cost more, and thus have less restrictions.
And what block would that be? IANA, ARIN, et. al. have never assigned a block "for cable modems". Netblocks are assigned to organizations and they use them as they need. One cannot assume and thing that start "24." is a cable modem and should therefore be ignored. (while there are CMs in 24/8, every address is not a CM nor are all CMs in 24/8)
Pure NAT -- what linux calls "simple nat" -- is not a firewall. What all the linksys's, netgears, and d-links of the world do is a firewall. Connection tracking and protocol helpers are every bit the same as a pure firewall; they're just rewriting addresses as well. SPI happens in both cases.
Right. Trust the buggiest OS in the world to be your firewall. I guess you've missed the memo's about the various bugs that foul up windows even with the firewall on. Linux has had a few as well, for that matter. Cisco's router and firewall products have had similar problems, too.
As much as it is your religion that "NAT is not a firewall", NAT is what protects 99% of the internet today. People will not realize they need to take steps to protect their computers -- or even know what a firewall is.
Again, IPSec is end-to-end encryption. It does NOT mean the protocol itself (or even how it does IPSec) is remotely secure. Forcing every IPv6 stack to contain a full IPSec layer is bloat at it's finest. Btw, just because the stack has to support it doesn't mean applications will use it.
IPv4 and IPv6 are entirely different protocols. They cannot talk to each other. PERIOD. Technically, it's possible to write a v6 stack that can understand a v4 packet, but the reverse is impossible... IPv4 stacks cannot make sense of v6 packets. v4 and v6 are as alien to each other as IPX and Appletalk. This is why the transition is such a horrible fucking mess. You have to run both, everywhere. Or resort to application specific protocol proxies. In case you missed it, IPv6 compatible IPv4 addressing has been depreciated for years. (so long ago my Cisco 1760 (long past EOL) won't let me enter such an address.)
NAT is gone in IPv6. Period. Anyone attempting it will be facing a never ending battle of broken applications. End to end transparency is fundamental to IPv6. IPSec will make sure you cannot screw with an application's traffic.
DHCP was a bolt-on compromise. In it's current form, DHCPv6 is a bad joke. Look at what you can do with DHCPv4. Now look at what you can do with DHCPv6.
IPSec does not mean the protocol (IPv6) has been designed with any thought given to privacy (hello, SLAAC) or security. IPv4 has IPSec but the protocol itself still has had numerous problems in both areas. Plus, IPSec alone makes the network stack over a megabyte just about everywhere. This isn't a problem for Windows(tm), but is a huge issue for the millions of tiny devices found everywhere today (TV's, STB's, clocks, blu-ray players, phones, cell phones, cable modems, dsl modems, routers, switches, etc., etc., etc.)
Face it. IPv6 is a failure. We're going to be forced to use this mistake for many decades. It was designed by idiots who were more concerned with their own religion and political agendas than building the next gen protocol to be useful for many decades (centuries?) IPv4, in contrast, was designed by very bright minds. The technology they designed is still in use 30 years later with very little modification. An IPv4 ethernet device built in 1982 still works flawlessly in modern IPv4 networks. An IPv6 device designed just 10 years ago doesn't fair so well in today's IPv6 networks -- for one, SLAAC is a 64bit prefix now; it was 80 then.
NAT was a real mess in the begining due to various protocols assuming they knew what the host's IP address was and rolled it into the data flowing between systems. That assumption caused problems long before NAT existed; there just weren't enough people with multi-homed systems to scream about it. NAT made that assumption wrong 100% of the time, for everyone. Protocol helpers are required to deal with those things. In the era of NAT, protocols are designed without making such assumptions. Unless, of course, you're an idiot. (see also: SIP)
What we're going to see in a world sans-NAT, is a return to the 80's and 90's where the internet is "naked". As anyone should well know by now, NEVER connect a windows box directly to the internet. People will not be smart enough to setup firewalls, or even realize they need one. NAT is their firewall today. And despite the religious wars, NAT IS their firewall.
Actually, the lack of adoption is partly (mostly?) to blame on the standard being pure shit... designed by committee, by academics who have never run a real world network. Too many personal political agenda's are wired into this thing... NO NAT! No DHCP -- SLAAC fixes everything (except it doesn't) MUST include full IPSec. No attention on privacy or security.
What was RFC'd over a decade ago is not what IPv6 is today. And it will continue to change until the seemingly endless mountains of stupid are corrected.
How is the "public" being misled when they weren't sent a copy? If you're a PE, you sure as hell should be able to spot engineering work... by, oh say, the fucking PE seal and signature.
In NC, you don't need a PE, or even one day in college, to be a bridge inspector. Take a class, pass a test, and *BAM* you're a bridge inspector.