having intercepted a single request containing cookies, you gain full access to the account, potentially forever (depends on server's expiration policy and your ability to keep the sessions alive). so yes, for all intents and purposes it is just as bad.
> As usual, Google leads the pack in creating groundbreaking technology, and comes in dead last in dealing with the boring stuff, like dealing with security issues
and now you show me another free mail service of any significance that has IMAPS, POP3S, SMTPS and now HTTPS (yes, all with *S, because Gmail requires you to use SSL for SMTP, POP3 and IMAP, and has been doing so since the very beginning, HTTPS was available for use for a while, though not required or offered by default). if google is dead last, the internet must be swarming with secure mail services, right?...right?
starting at certain bitrates, there's simply not enough processing power to apply compression. modern general purpose CPU can gzip at just tens of megabytes per second, simpler and less effective algorithms may give you couple hundred MBytes/sec, which is still just a couple Gb/s.
now imagine you have couple dozen 10 gig ports, in and out. and that's just the beginning, some high-end gear has 100+ 10G ports, all lit. specialized ASICs can help, but they're not free either and ultimately don't take you very far, especially after throwing in all that memory required for processing. all in all, none of the high-end routing or switching gear does compression nowadays, it's simply not worth it, in dollars and milliseconds of added latency.
which is also a drawback on links with any kind of loss - one lost packet stall everything until it's retried. not to mention throwing away parallelism on good links - HTTP standard allows 2 concurrent connections to the server, most browsers open more, and the difference is easily noticeable.
rather, it is probably an oversimplified way of saying "the setup cost for every new SSL connection is significantly higher" - with all the back and forth happening during handshake. not a single byte of user data can be transferred before handshake happens, and that is $several x RTT, and can be significant.
well, actually... i sort of do.
look, google has already reported on sorting 1 PB in 6 hours on a 4000 node cluster. their implementation is in C++. yahoo's result is 16.25 hours on a 3800 node cluster and hadoop is written in java. even taking into account the 200 node difference, yahoo's implementation is ~2.6 times slower than google's. it may not all be java's fault, but still.
except that maintaining all that per-thread state takes additional kernel memory, and context switching thrashes cpu.
i'd say that 171 threads is excessive for 2 of even 4 core cpu.
Note that if you're using Firefox, its status bar may be misleading. I investigated causes of long page loads numerous times, and in many cases found that FF would actually be waiting on something other than what it says in the status bar.
Not defending GA here, I don't have actual stats for how slow/fast they are, but just noting that status bar information is not always correct.
the tone of the summary seems to suggest that while android is still vapor in terms of real devices, some other group is actually rolling out something.
except that something they are "rolling out" are specs.
which android also has plenty of. plus IDE. plus emulator.
...what was at the beginning. and at the beginning of google was the search algorithm, which at first was marketed and sold on its own premises. ironically, yahoo was among the first customers. then a better way of monetization was found. and google still sells search algorithm with no ads - in the form of the google search appliance. so yes, google started as and still is a search company. and search is still a major focus for them.
this is unlikely. one of the reasons being that unlike other webmail interfaces, gmail's does NOT use IMAP as its backend.
because it's free and on google scale.
on
Free IMAP On Gmail
·
· Score: 1
while $random_provider may have been offering it for some time, this is something different. it doesn't really require much skill to install cyrus or uw imapd and start charging 100$/year for that. i would be surprised if noone did it. but implementing it for free and on google scale is way, way more than that and needs planning and thought. first version of gmail was in development for quite some time before it was released in 2004.
this is really a random fraction, staged rollout. Just wait and you'll have it too in due time:)
being rolled out gradually to random subset users
on
Free IMAP On Gmail
·
· Score: 5, Informative
no point in looking for rollout patterns, user participation is being gradually ramped up and it's done in subsets of users that are basically random. at some point roll out will reach 100% and everyone will have the option. a little more patience is all that is needed:)
> I'm also curious about Google and the like. Do they not disclose their storage?
there's much more than that, but GFS is no SAN at all. google can do better than that, and does. GFS is all about cheap storage, lots of it. and yes, 14 P is basically nothing, in google terms. what article really is about is "who wasted more money on over-priced enterprisey SAN crap".
i remember lots of talking several years ago about Google building datacenters-in-a-box. what's interesting, is that they actually tried it, built some and found it impractical in the end. i wonder if this offering by Sun really takes off...
Slashdot Mirror
having intercepted a single request containing cookies, you gain full access to the account, potentially forever (depends on server's expiration policy and your ability to keep the sessions alive). so yes, for all intents and purposes it is just as bad.
> As usual, Google leads the pack in creating groundbreaking technology, and comes in dead last in dealing with the boring stuff, like dealing with security issues
and now you show me another free mail service of any significance that has IMAPS, POP3S, SMTPS and now HTTPS (yes, all with *S, because Gmail requires you to use SSL for SMTP, POP3 and IMAP, and has been doing so since the very beginning, HTTPS was available for use for a while, though not required or offered by default). ...right?
if google is dead last, the internet must be swarming with secure mail services, right?
starting at certain bitrates, there's simply not enough processing power to apply compression.
modern general purpose CPU can gzip at just tens of megabytes per second, simpler and less effective algorithms may give you couple hundred MBytes/sec, which is still just a couple Gb/s.
now imagine you have couple dozen 10 gig ports, in and out. and that's just the beginning, some high-end gear has 100+ 10G ports, all lit.
specialized ASICs can help, but they're not free either and ultimately don't take you very far, especially after throwing in all that memory required for processing.
all in all, none of the high-end routing or switching gear does compression nowadays, it's simply not worth it, in dollars and milliseconds of added latency.
> And most importantly: One standing connection.
which is also a drawback on links with any kind of loss - one lost packet stall everything until it's retried.
not to mention throwing away parallelism on good links - HTTP standard allows 2 concurrent connections to the server, most browsers open more, and the difference is easily noticeable.
rather, it is probably an oversimplified way of saying "the setup cost for every new SSL connection is significantly higher" - with all the back and forth happening during handshake. not a single byte of user data can be transferred before handshake happens, and that is $several x RTT, and can be significant.
the man in the middle would have to have a valid mail.google.com certificate for the attack to be seamless.
yes, we know how effective "invalid certificate" prompts are, but this is not a failure of the encryption mechanism.
funny business as in what? have you confused server's address with the reply?
Non-authoritative answer:
Name: slashdot.org
Address: 216.34.181.45
this is a perfectly correct reply: 216.34.181.45 belongs to sourceforge and is the right IP address for slashdot.org
well, actually... i sort of do. look, google has already reported on sorting 1 PB in 6 hours on a 4000 node cluster. their implementation is in C++. yahoo's result is 16.25 hours on a 3800 node cluster and hadoop is written in java. even taking into account the 200 node difference, yahoo's implementation is ~2.6 times slower than google's. it may not all be java's fault, but still.
"04.10.2008 - 10:54 AM" - April 10th.
this is the article mentioned in the original "Hotmail CAPTCHA sucks" slashdot post.
use new encryption key every day. throw away the key that is 9month+1day old. problem solved.
except that maintaining all that per-thread state takes additional kernel memory, and context switching thrashes cpu. i'd say that 171 threads is excessive for 2 of even 4 core cpu.
FYI, here's what it's like at Google: Google C++ Style Guide
Note that if you're using Firefox, its status bar may be misleading. I investigated causes of long page loads numerous times, and in many cases found that FF would actually be waiting on something other than what it says in the status bar. Not defending GA here, I don't have actual stats for how slow/fast they are, but just noting that status bar information is not always correct.
the tone of the summary seems to suggest that while android is still vapor in terms of real devices, some other group is actually rolling out something.
except that something they are "rolling out" are specs.
which android also has plenty of. plus IDE. plus emulator.
so, well... huh?
> What's Yahoo supposed to do when faced with a subpoena from the Chinese Government?
So Chinese govt comes knocking asking for logs.
Valid response would be "There aren't any [that we are required to turn over]."
To do that, of course, you need to keep your servers outside of China.
...what was at the beginning. and at the beginning of google was the search algorithm, which at first was marketed and sold on its own premises. ironically, yahoo was among the first customers. then a better way of monetization was found. and google still sells search algorithm with no ads - in the form of the google search appliance.
so yes, google started as and still is a search company. and search is still a major focus for them.
this is unlikely. one of the reasons being that unlike other webmail interfaces, gmail's does NOT use IMAP as its backend.
while $random_provider may have been offering it for some time, this is something different.
it doesn't really require much skill to install cyrus or uw imapd and start charging 100$/year for that. i would be surprised if noone did it.
but implementing it for free and on google scale is way, way more than that and needs planning and thought.
first version of gmail was in development for quite some time before it was released in 2004.
it does.
this is really a random fraction, staged rollout. Just wait and you'll have it too in due time :)
no point in looking for rollout patterns, user participation is being gradually ramped up and it's done in subsets of users that are basically random. :)
at some point roll out will reach 100% and everyone will have the option. a little more patience is all that is needed
Yes, it saves lots of space.
> It's not working out as brilliantly as the concept was laid out.
If I were a HotMail user, I'd start packing up.
> I'm also curious about Google and the like. Do they not disclose their storage?
there's much more than that, but GFS is no SAN at all. google can do better than that, and does.
GFS is all about cheap storage, lots of it. and yes, 14 P is basically nothing, in google terms.
what article really is about is "who wasted more money on over-priced enterprisey SAN crap".
i remember lots of talking several years ago about Google building datacenters-in-a-box.
what's interesting, is that they actually tried it, built some and found it impractical in the end.
i wonder if this offering by Sun really takes off...