250 GB is both transparent and a real shitload of bandwidth.
This is 7 hour a day, 7 days a week, of 720p HDTV video over Hulu. It takes a LOT to reach this point.
Additionally, beacuse any user who gets terminated will undoubtedly ALSO terminate their cable TV and phone services with Comcast, its something that a company would not want to do lightly.
This was put in place per Comcast's talk at the IETF largely to IMPROVE VoIP service from Vonage et al. You look back to 2006, before this was deployed, and there were lots of complaints about "Comcast is disrupting Vonage and other voip services..."
Those complaints largely dissapeared after Comcast started policing P2P uploads.
All someone needs to do is correlate your ID# with you (easy enough to do on many occasions). Once you have that, its no longer a meaningless ID number, but a unique personal tracking number.
For a long time, IPv4's limited address space looked to be a problem. And that was the #1 business case behind IPv6.
The problem is, NAT came around at just the right time. Most businesses only need a couple of external addresses, and many end-users don't need one at all.
The real reason for processes instead of threads is cheap & dirty crash isolation. Who cares about RPC time, you don't do THAT much of it in a web browser.
But with more and more apps being composed IN the browser, you need isolation to get at least some crash isolation between "apps"
It will take any OTHER connection the user makes on a wireless link, redirect THAT to point to http://yoursite.com/ answer that request with a SYN, and now the browser spits out the cookie.
If each downloaded movie is encoded at 720p at 2.5 Mbps, thats nearly 8 hours of movies a day, or 4 rentals. 4 x $4 x 30 = $480/month in rental fees alone.
This is NOT a fix to the root problem of the Kaminski vulnerability.
The root problem is the cases where athority/additional/unasked-answers are accepted, and there are plenty of variants this "patch" does not affect. EG.
Answer: whatever.foo.com CNAME www.foo.com www.foo.com A 66.6.66.6 Authority: (usual goop).
If www.foo.com is not yet cached (and often even if it is), this will set it as a Kaminski variant.
Although I'm a huge believer in Leap of Faith, I believe it should be used in addition to, not instead of, valid certificates for SSL.
There are just simply too many users "the first time" to any given site for leap-of-faith to be useful.
Especially since your proposed policy ("Always leap-of-faith") would mean ANY conventional phishing site could trivially use SSL and present a nice happy lock icon, because its a NEW site from the browser's viewpoint, even though the user is fooled into thinking its his legitimate bank.
No its not. Because if you condition users to it, they will always accept it, which allows you a trivial downgrade attack to self-signed HTTPS.
Its like the padlock icon: we conditioned the users to "see the padlock, its safe", and so all you need to do is put a padlock icon IN THE PAGE and the users think its safe.
Conditioning the users to accept self-signed certs is a BAD thing.
I think self-signing is great for HTTP and with SSH-style leap of faith. But self signed is far less useful than a real cert (because even when social engineered, a real cert allows you to say "registrar X f-ed up".) for HTTPS. And conditioning users to accept self-signed certs for HTTPS is a mistake.
The GX cookie will be set to secure, but an attacker can STILL cause problems unless you set the preference, because if the attacker redirects you to http://mail.google.com/ it STILL WORKS. I just created a new default account, logged in through https:/// and you can get the browser to go through http:/// just fine.
Unless you set the preference, explicitly, you are vulnerable to mike perry's attack.
Google waited for a YEAR before doing anything, and only added the preference about the time when they heard of Mike's talk, "Exploiting 365th day vulnerabilities..."
Its not like google hasn't had ONE YEAR of warning on this!
Slashdot Mirror
Ransomware crypto is not that effective: Backups are good, and the problem is payment is traceable.
And RC4 isn't good for ransomware crypto, it IS broken, badly so.
250 GB is both transparent and a real shitload of bandwidth.
This is 7 hour a day, 7 days a week, of 720p HDTV video over Hulu. It takes a LOT to reach this point.
Additionally, beacuse any user who gets terminated will undoubtedly ALSO terminate their cable TV and phone services with Comcast, its something that a company would not want to do lightly.
This was put in place per Comcast's talk at the IETF largely to IMPROVE VoIP service from Vonage et al. You look back to 2006, before this was deployed, and there were lots of complaints about "Comcast is disrupting Vonage and other voip services..."
Those complaints largely dissapeared after Comcast started policing P2P uploads.
All someone needs to do is correlate your ID# with you (easy enough to do on many occasions). Once you have that, its no longer a meaningless ID number, but a unique personal tracking number.
For a long time, IPv4's limited address space looked to be a problem. And that was the #1 business case behind IPv6.
The problem is, NAT came around at just the right time. Most businesses only need a couple of external addresses, and many end-users don't need one at all.
Forensics on RAM are much harder, because it would probably be a single cached screenshot, so you don't HAVE history, only the current ones.
The iPhone takes a screenshot, but they never said in the FA whether its actually written to flash or not!
Given the limited write cycles of Flash, I would hope that Apple just keeps it in RAM.
EG, the mediacritic places it down with the Incredible Hulk, and Penny Arcade harshed it.
THen you use a mechanical generator, as it is probably cheaper to get 1W out of a OLPC-spool generator or the like.
40mW in 10 MPH wind for $5: Scale to 1W would take an array of 25 at a cost of $125.
This would be, looking at his prototype, about 50cm x 100cm...
The cost/watt however, is just astronomically bad. A 1 kW wind turbine is $3000 (which would produce ~400W at that windspeed)...
Its really a clever idea, but just not efficient enough to be economical, even to just glow an LED lamp.
The real reason for processes instead of threads is cheap & dirty crash isolation. Who cares about RPC time, you don't do THAT much of it in a web browser.
But with more and more apps being composed IN the browser, you need isolation to get at least some crash isolation between "apps"
Otherwise, they, well, couldn't distribute your blog or your photo album!
CookieMonster is an active tool.
It will take any OTHER connection the user makes on a wireless link, redirect THAT to point to http://yoursite.com/ answer that request with a SYN, and now the browser spits out the cookie.
If you want to manually examine a site you visit:
Clear all cookies.
Log in.
Clear all cookies marked as "SECURE" (in firefox, preferences->privacy->show cookies. Delete JUST the cookies marked as "Encrypted connections only").
Go back to the site. Can you act as if you are logged in? If so, the site is COMPLETELY insecure.
If each downloaded movie is encoded at 720p at 2.5 Mbps, thats nearly 8 hours of movies a day, or 4 rentals. 4 x $4 x 30 = $480/month in rental fees alone.
Braid is proabably the best example of how to really do challenge while limiting frustration.
In particular, "you can't die" really changes platformers.
Well, Kaminski doesn't save packets over a normal race.
Its point is "Race until win" rather than "race once per TTL".
Thus in a normal race for www.foo.com, you can run the race once per TTL, and then have to wait if you fail.
With the kaminski race, you can keep running it until you succeed.
This is why Kaminski attacks are all about glue policy.
This is NOT a fix to the root problem of the Kaminski vulnerability.
The root problem is the cases where athority/additional/unasked-answers are accepted, and there are plenty of variants this "patch" does not affect. EG.
Answer:
whatever.foo.com CNAME www.foo.com
www.foo.com A 66.6.66.6
Authority:
(usual goop).
If www.foo.com is not yet cached (and often even if it is), this will set it as a Kaminski variant.
Although I'm a huge believer in Leap of Faith, I believe it should be used in addition to, not instead of, valid certificates for SSL.
There are just simply too many users "the first time" to any given site for leap-of-faith to be useful.
Especially since your proposed policy ("Always leap-of-faith") would mean ANY conventional phishing site could trivially use SSL and present a nice happy lock icon, because its a NEW site from the browser's viewpoint, even though the user is fooled into thinking its his legitimate bank.
No its not. Because if you condition users to it, they will always accept it, which allows you a trivial downgrade attack to self-signed HTTPS.
Its like the padlock icon: we conditioned the users to "see the padlock, its safe", and so all you need to do is put a padlock icon IN THE PAGE and the users think its safe.
Conditioning the users to accept self-signed certs is a BAD thing.
I think self-signing is great for HTTP and with SSH-style leap of faith. But self signed is far less useful than a real cert (because even when social engineered, a real cert allows you to say "registrar X f-ed up".) for HTTPS. And conditioning users to accept self-signed certs for HTTPS is a mistake.
Its "Developer praises game that he had nothing to do with".
Its a professional critic review.
And braid is as mind-blowing as everybody says.
The article is WRONG:
The GX cookie will be set to secure, but an attacker can STILL cause problems unless you set the preference, because if the attacker redirects you to http://mail.google.com/ it STILL WORKS. I just created a new default account, logged in through https:/// and you can get the browser to go through http:/// just fine.
Unless you set the preference, explicitly, you are vulnerable to mike perry's attack.
Google waited for a YEAR before doing anything, and only added the preference about the time when they heard of Mike's talk, "Exploiting 365th day vulnerabilities..."
Its not like google hasn't had ONE YEAR of warning on this!
Actually, that doesn't work.
You see, Google doesn't set GX as secure unless you manually select the preference to "Always use secure".
Thus even if you are a good user and always type in https, unless you changed the preference, Mike's tool can read your mail!