They may be legally permitted to do so (if you disregard the blatant unconstitutionality), but that doesn't mean they're physically able to do so. Luckily a phone passcode is significantly harder to crack than a briefcase lock, especially if you have an failed login attempt limit enabled. AFAIK, they may not force you to open any locked containers without a warrant, even if they're allowed to rifle through all of the visible crap you've left sitting on the passenger seat. Though obviously that goes both ways - even if they're not allowed to force you to unlock your phone, they're perfectly capable of "convincing" you to doing so.
Can we get past this already? SSL is not heavyweight, and has not been for years. It's a couple percent of overhead*. Most authentication systems are going to have significantly more overhead than turning on SSL, since they'll be most likely hitting the filesystem or a database to retrieve session information on top of the actual code logic that goes into authentication.
I agree that an authentication system tied more tightly into the browser would be of great value, but it won't happen anytime soon if ever. See: IE6. Hell, even Safari is updated quite infrequently (and even then mostly just security patches, not feature releases), never mind the plethora of mobile browsers floating around these days. That also solves a completely different problem than SSL. There's no getting around the fact that in order to have hijack-proof sessions, all of the authentication data - whether in the form of a session cookie or some new, novel mechanism - needs to be sent encrypted. Not necessarily SSL, but that's more or less a solved problem so why not? I also quite like the idea of nobody knowing what URLs I'm hitting.
* Excluding the time spent tracking down that one damn analytics script that's pulling in a tracking pixel over http and making browsers throw up all over the place
Define "bs free stuff". Hotmail peaked years ago, but gmail is extremely popular for good reason and yahoo is also very heavily used. And of the probably dozen or so email addresses I have, they're ALL powered by gmail (even though only one of them is actually @gmail.com). Technically two of them are paid, but that's beside the point. I've dealt with having my own mail server. It sucks. And it's not like it's the service's fault that people choose crappy passwords.
Obviously it's all a matter of opinion, but they were all* IMO pretty decent strictly from a gameplay standpoint, and X held up relatively well in terms of story. I thought IX was crap and XII was mediocre at best, but XIII and (surprisingly) X-2 I found quite fun to play - in fact I'd quite recommend X-2 as a game with excellent mechanics, provided you ignore the fact that it somehow got Final Fantasy in its title.
*I haven't played either of the MMOs so can't opine on them
Twice the cost hopefully covers paying for your own benefits. Stuff like health insurance adds up incredibly quickly when your employer is not paying 80% of your premium (which in itself is overall cheaper per employee thanks to economies of scale and negotiating power). Not to mention all of the general overhead BS that's normally covered by your employer.
In terms of how costs break down, you'd probably come out ahead getting (for example) $20/hr as an employee vs $40/hr as a contractor. Not only do those $5 errands like more printer paper add up in hard costs, but the opportunity costs are massive when you're billing by the hour. Hint: unless you've hired an assistant, it's extremely unlikely that you can find the time for 40 billable hours in a work week.
Take that at face value as whether it's worth having the government work with contractors - there's a lot of stuff unrelated to actual dollars spent that factors in. But the above is just the reality of why contractors (need to) get paid significantly more per hour than salaried workers with benefits.
Look at the increase in quality of batteries, though. We're not going to have an overnight breakthrough, but we'll continue to reap the rewards of the breakthroughs from five years previously.
I can't comment for cars, but laptops certainly show this. Ten years ago, the battery for my laptop weighted as much as my entire laptop does today, lasted 1/4 as long and that computer was capable of far less (never mind the charging memory). All things considered, that could easily be a 10x gain in energy density over ten years.
And guess what - we do have fully electric cars these days. They're not widespread and are certainly in the early stages, but it's way more than we could have done ten years ago, let alone a hundred.
Of course, updating the trusted CA cert list shouldn't require a full system upgrade either. They have a kill switch for rogue apps; there should be a similar infrastructure in place for certificate revocation (is there? I don't know - doesn't sound like it. But there should be)
To be fair, this affects everything that uses the system certificates - anything from cURL to Chrome. Safari is included in that list. Almost every other desktop app is also affected - so something like a desktop RSS reader that pulls from Google Reader was equally vulnerable. Firefox (and maybe others) manage their own CA certs so they weren't directly affected, but had this been patched earlier it might have been that Firefox was the application that is still vulnerable.
You can be your own CA - it takes about three minutes to do with a couple openssl calls. I do it on my development VM so I can replicate our web stack as accurately as possible (in this case all it does is help catch mixed-content browser warnings, but that's still beneficial)
Getting people to trust (read: import the public key of) your personal CA is more of a problem. It works a lot better on intranets where the extra cert installation is part of setting up the machine. Having it automatically happen for your domain simply isn't possible - automatically trusting a source isn't trust at all, and verifying the authenticity of certificates relies on trust. Trusting certificates is important
What's the problem with a wildcard cert? Isn't that where the "paying good money" comes in? The only issue I've faced in that area is that you can't be issued a wildcard EV cert.
A micro-SD card can easily hold an OS installer and fit pretty much anywhere. Shouldn't be terribly difficult to get a master copy in somewhere. Hell, you could actually put it in a sneaker - either loose or a tiny slit in the sole. Worst case, put it in a protective rubber capsule of sorts and swallow the damn thing.
The only thing Amazon did that helped kill Borders is the Kindle - and it's hardly Amazon's fault that Borders couldn't keep up. I'd be astonished if sales tax made any appreciable impact on Borders' death.
I've placed Amazon orders from inside a Best Buy to get the better price*, but it's not worth the delay on books - certainly not over a dollar. On the rare occasion I found something of interest in dead tree form in any bookstore, I'd just buy it on the spot unless the Amazon price was very significantly lower. More often than not the difference was fifty cents or so. Big freaking deal.
* Because Amazon's price was lower, not because of sales tax. I did this many times while living in sales-tax-free NH. However, I have had big-ticket items shipped to my NH address while living in CA to avoid their absurdly high taxes. If the CA government was in any way remotely competent I'd agree with the "taxes buy civilization" idea, but that's just not the case here. Actually - scratch that. If any part of the government in this country was competent, I'd agree. Eliminate the waste, corruption, pensions, nepotism, and bullshit and we'll talk (I can deal with having someone I disagree with politically in office - it's not like they get anything done regardless. So long as "government contract" is always preceded by "lucrative", they can fuck right off)
The actual POST to the login page should always be going over https. And yes, it would be great if every website in the world was https all the time for anything requiring an active session, but there's no chance of that happening without at least the complete death of Windows XP (since no version of IE on XP supports SNI, and the millions of websites on shared hosting simply cannot use SSL without that because of IP reuse) or full IPv6 adoption. Still, I'd feel better knowing at the very least that my authentication request is secure even if the subsequent session cookie is vulnerable to hijacking on public networks. At least until some jackass stores my password in plaintext in the session cookie for their "clever" auth system.
After the user is authenticated the first time, you could set the HSTS header so that all subsequent requests (including ones typed directly into the URL bar) would automatically be transformed into https.
No getting around that first request, unfortunately, so long as http continues to exist. Still, if I required that level of security, I'd just fire up my VPN.
While I like the theory behind your approach, users don't care about security. At all. The ones that claim they do are either lying or developers (or ignorant; noting the strength of the password written on the sticky note by the keyboard). So if you want a secure site you have to do everything for them - merely encouraging good behavior is not going to help. 301'ing all http requests to https automatically is about the only thing you can do that users might actually notice - the rest is just following good development practices (secure-only session cookies, setting up your firewalls properly on your server, etc)
Unless there happens to be a pre-computed rainbow table that includes the salt of the password (likelihood: practically zero), you are still massively better off. In that case, you'll have to generate your own rainbow tables if there's a single salt for all entries, or go cry yourself into a corner in the hopefully more likely scenario where each entry has its own unique salt (because you now need to bang out a rainbow table for every entry in the users table).
Nearly all security is based on obscurity (you don't know my password; that's obscure information), so the more obscurity the better. It just happens that port 8080 is a lot less secure than "$0m3 s[]{}per séc®e7 p4sS\/\/0rd", so that better not be your only line of defense.
In reality, almost nobody* is going to call md5 via crypt() when a standalone md5() function exists, and people are often slow to deploy new versions of PHP - especially major shared hosting providers. Those who manage their own PHP installs and deploy shortly after release tend to have their own set of unit tests, which very likely would have caught this if their own code was affected (Hmm, I can't login anymore. Suddenly my password hash is only twelve characters long? That's not right...)
Of course, if you hit all of the worst cases and push this out, yeah, pretty serious problem.
* Yes, I've seen exceptions to that. Some weird AWS message signing comes to mind, IIRC. Hence "almost".
Yeah, but by playing more games, the whole thing *is* more expensive.
Unless of course you get back into the $/hr thing that someone was trying to avoid in the first place. I guess it depends on whether you prioritize your bank account balance over the efficacy of your spending.
Which is the subtle difference between the "b" and "strong" tags, and "i" vs "em". The former in each pair indicates the desired style, where the latter indicates a style-agnostic level of content emphasis.
It's important to remember that most people (especially non-programmers) don't think about what they're trying to accomplish, just what they've done in the past to replicate the desired outcome. As such, it's very important as a programmer to not blindly give people what they ask for. "Make this open in a new window" often translates into "make a certain piece of information available on a different page accessible to me in a way that won't interrupt my current workflow", so a better solution is may be to just display that information on the first page. The same applies for text styles applied by content producers and editors. They don't want bold text, they want strong emphasis and the way they're most used to seeing that accomplished is via bold text. So semantically, <strong> is a better choice - and it gives you the ability to do a better job (maybe red, underlined text at at standard weight gets the message of emphasis across better based on the page's other styles).
That being said, whoever stated in this comment chain that the new HTML5 tag semantics are poorly thought-out was right. section and div are logically the same (you divide stuff into sections, yes?), aside is frequently misinterpreted to be a sidebar (it's closer to an inline details section, not entirely unlike the title attribute on an abbr tag), etc. audio and video tags are conceptually great, but the format/codec clusterfuck makes them all but useless. The new input types are decent; most of the interesting stuff is really in newer JS functionality and CSS3 attributes. One of the biggest issues is that most of the new semantic tags were based around content publushing, and designed to supersede microformats; there's a very weird overlap when building web applications.
I think he was saying that an "offline web app" is basically an oxymoron.
If you want to use HTML to make an application that's designed to work offline, fine. It's the wrong tool for the job, but these days you can make it work. But if you're building a standalone app, that means you're going to have to make a lot of assumptions about the validity of client-supplied data if you're syncing with a remote server when online connectivity is available. Or go all-out, and do stuff ONLY client-side; and the only thing the server does is provide the initial content and effectively install the web app - in this case HTML and friends are just tools to develop a typical downloaded application.
A perhaps more appropriate implementation of HTML5's offline tools is akin to what Gmail does - allows you to continue working at 90% capacity if your connection flakes. Queue outgoing messages in local storage until network is restored, then send them off as soon as it's possible. Do some local caching so that you have access to at least your most recent messages. It's not designed to work offline 100% of the time (it's fundamentally reliant on server-supplied data) but you're not hosed when signal drops to nothing. Think "Google Gears".
PDF? Isn't that the general idea behind the "portable document format"? Send a PDF to the printer, call it a day. If they can print jpegs directly off memory cards that would seem like a relatively easy approach to a driverless system.
Is it somehow Amazon's fault that the developer didn't RTFM and understand EC2 is effectively the same as remoting into a system booted off a LiveCD with no hard drive attached? Great for computing rainbow tables or, indeed, farming BitCoins; rather poor choice for running a database.
Do you know my password? No? Security by obscurity.
Almost all security* is based on someone not knowing something. Very very often, that something is either a password or very large random number. Or the physical pattern on a key. Or door/alarm code. Or something read via RFID. Or the algorithm that determines the number on my RSA fob. More commonly when making that claim, it's just a nonstandard port for a service, hidden URL, or combination of several.
If an attacker has the exact same set of information that I have, then that attacker has access to the same systems I do. The amount of information they need (or the level of obscurity, if you will) determines the level of security. Something where you need to be on my VPN to get access to a whitelisted IP and then SSH in to the system where password-only auth is disabled is going to be a hell of a lot harder than something where you just need to know to hit port 8080 instead. But ultimately, my passwords and private keys are just very obscure information.
And in terms of end results, not being a target absolutely makes me more secure than an equivalent system that is a target.
* As far as authentication and encryption is concerned, at least. SQL injection and XSS protection being the two best examples where it comes down to actual implementation details.
For the problems Gmail has had over the years, its downtime is still insignificant compared to anything I've tried to deal with myself. And as far as I can remember, their only downtime has been the web interface, not the actual mail servers - so mail was still being received, and people using IMAP instead of the web interface didn't notice anything. Likewise, my internet connections (home and work) are far less reliable than what Google has.
Slashdot Mirror
"may" != "can"
They may be legally permitted to do so (if you disregard the blatant unconstitutionality), but that doesn't mean they're physically able to do so. Luckily a phone passcode is significantly harder to crack than a briefcase lock, especially if you have an failed login attempt limit enabled. AFAIK, they may not force you to open any locked containers without a warrant, even if they're allowed to rifle through all of the visible crap you've left sitting on the passenger seat. Though obviously that goes both ways - even if they're not allowed to force you to unlock your phone, they're perfectly capable of "convincing" you to doing so.
Can we get past this already? SSL is not heavyweight, and has not been for years. It's a couple percent of overhead*. Most authentication systems are going to have significantly more overhead than turning on SSL, since they'll be most likely hitting the filesystem or a database to retrieve session information on top of the actual code logic that goes into authentication.
I agree that an authentication system tied more tightly into the browser would be of great value, but it won't happen anytime soon if ever. See: IE6. Hell, even Safari is updated quite infrequently (and even then mostly just security patches, not feature releases), never mind the plethora of mobile browsers floating around these days. That also solves a completely different problem than SSL. There's no getting around the fact that in order to have hijack-proof sessions, all of the authentication data - whether in the form of a session cookie or some new, novel mechanism - needs to be sent encrypted. Not necessarily SSL, but that's more or less a solved problem so why not? I also quite like the idea of nobody knowing what URLs I'm hitting.
* Excluding the time spent tracking down that one damn analytics script that's pulling in a tracking pixel over http and making browsers throw up all over the place
Define "bs free stuff". Hotmail peaked years ago, but gmail is extremely popular for good reason and yahoo is also very heavily used. And of the probably dozen or so email addresses I have, they're ALL powered by gmail (even though only one of them is actually @gmail.com). Technically two of them are paid, but that's beside the point. I've dealt with having my own mail server. It sucks. And it's not like it's the service's fault that people choose crappy passwords.
Ugh, it seems that standing at the DMV all day has impaired my reading ability. Disregard that.
That was the joke (also, yes it has - look up IVF). Eliminate humans and their problems also disappear.
Obviously it's all a matter of opinion, but they were all* IMO pretty decent strictly from a gameplay standpoint, and X held up relatively well in terms of story. I thought IX was crap and XII was mediocre at best, but XIII and (surprisingly) X-2 I found quite fun to play - in fact I'd quite recommend X-2 as a game with excellent mechanics, provided you ignore the fact that it somehow got Final Fantasy in its title.
*I haven't played either of the MMOs so can't opine on them
Twice the cost hopefully covers paying for your own benefits. Stuff like health insurance adds up incredibly quickly when your employer is not paying 80% of your premium (which in itself is overall cheaper per employee thanks to economies of scale and negotiating power). Not to mention all of the general overhead BS that's normally covered by your employer.
In terms of how costs break down, you'd probably come out ahead getting (for example) $20/hr as an employee vs $40/hr as a contractor. Not only do those $5 errands like more printer paper add up in hard costs, but the opportunity costs are massive when you're billing by the hour. Hint: unless you've hired an assistant, it's extremely unlikely that you can find the time for 40 billable hours in a work week.
Take that at face value as whether it's worth having the government work with contractors - there's a lot of stuff unrelated to actual dollars spent that factors in. But the above is just the reality of why contractors (need to) get paid significantly more per hour than salaried workers with benefits.
They're more likely to have it handed to them, because they're mostly old and think email is for people who think for a living, not schmooze.
It's so reassuring to know that the politicians don't even pretend to think.
Look at the increase in quality of batteries, though. We're not going to have an overnight breakthrough, but we'll continue to reap the rewards of the breakthroughs from five years previously.
I can't comment for cars, but laptops certainly show this. Ten years ago, the battery for my laptop weighted as much as my entire laptop does today, lasted 1/4 as long and that computer was capable of far less (never mind the charging memory). All things considered, that could easily be a 10x gain in energy density over ten years.
And guess what - we do have fully electric cars these days. They're not widespread and are certainly in the early stages, but it's way more than we could have done ten years ago, let alone a hundred.
Of course, updating the trusted CA cert list shouldn't require a full system upgrade either. They have a kill switch for rogue apps; there should be a similar infrastructure in place for certificate revocation (is there? I don't know - doesn't sound like it. But there should be)
To be fair, this affects everything that uses the system certificates - anything from cURL to Chrome. Safari is included in that list. Almost every other desktop app is also affected - so something like a desktop RSS reader that pulls from Google Reader was equally vulnerable. Firefox (and maybe others) manage their own CA certs so they weren't directly affected, but had this been patched earlier it might have been that Firefox was the application that is still vulnerable.
Still, don't feed the trolls.
You can be your own CA - it takes about three minutes to do with a couple openssl calls. I do it on my development VM so I can replicate our web stack as accurately as possible (in this case all it does is help catch mixed-content browser warnings, but that's still beneficial)
Getting people to trust (read: import the public key of) your personal CA is more of a problem. It works a lot better on intranets where the extra cert installation is part of setting up the machine. Having it automatically happen for your domain simply isn't possible - automatically trusting a source isn't trust at all, and verifying the authenticity of certificates relies on trust. Trusting certificates is important
What's the problem with a wildcard cert? Isn't that where the "paying good money" comes in? The only issue I've faced in that area is that you can't be issued a wildcard EV cert.
Great. You've invented the CA.
A micro-SD card can easily hold an OS installer and fit pretty much anywhere. Shouldn't be terribly difficult to get a master copy in somewhere. Hell, you could actually put it in a sneaker - either loose or a tiny slit in the sole. Worst case, put it in a protective rubber capsule of sorts and swallow the damn thing.
The only thing Amazon did that helped kill Borders is the Kindle - and it's hardly Amazon's fault that Borders couldn't keep up. I'd be astonished if sales tax made any appreciable impact on Borders' death.
I've placed Amazon orders from inside a Best Buy to get the better price*, but it's not worth the delay on books - certainly not over a dollar. On the rare occasion I found something of interest in dead tree form in any bookstore, I'd just buy it on the spot unless the Amazon price was very significantly lower. More often than not the difference was fifty cents or so. Big freaking deal.
* Because Amazon's price was lower, not because of sales tax. I did this many times while living in sales-tax-free NH. However, I have had big-ticket items shipped to my NH address while living in CA to avoid their absurdly high taxes. If the CA government was in any way remotely competent I'd agree with the "taxes buy civilization" idea, but that's just not the case here. Actually - scratch that. If any part of the government in this country was competent, I'd agree. Eliminate the waste, corruption, pensions, nepotism, and bullshit and we'll talk (I can deal with having someone I disagree with politically in office - it's not like they get anything done regardless. So long as "government contract" is always preceded by "lucrative", they can fuck right off)
The actual POST to the login page should always be going over https. And yes, it would be great if every website in the world was https all the time for anything requiring an active session, but there's no chance of that happening without at least the complete death of Windows XP (since no version of IE on XP supports SNI, and the millions of websites on shared hosting simply cannot use SSL without that because of IP reuse) or full IPv6 adoption. Still, I'd feel better knowing at the very least that my authentication request is secure even if the subsequent session cookie is vulnerable to hijacking on public networks. At least until some jackass stores my password in plaintext in the session cookie for their "clever" auth system.
After the user is authenticated the first time, you could set the HSTS header so that all subsequent requests (including ones typed directly into the URL bar) would automatically be transformed into https.
No getting around that first request, unfortunately, so long as http continues to exist. Still, if I required that level of security, I'd just fire up my VPN.
While I like the theory behind your approach, users don't care about security. At all. The ones that claim they do are either lying or developers (or ignorant; noting the strength of the password written on the sticky note by the keyboard). So if you want a secure site you have to do everything for them - merely encouraging good behavior is not going to help. 301'ing all http requests to https automatically is about the only thing you can do that users might actually notice - the rest is just following good development practices (secure-only session cookies, setting up your firewalls properly on your server, etc)
False.
Unless there happens to be a pre-computed rainbow table that includes the salt of the password (likelihood: practically zero), you are still massively better off. In that case, you'll have to generate your own rainbow tables if there's a single salt for all entries, or go cry yourself into a corner in the hopefully more likely scenario where each entry has its own unique salt (because you now need to bang out a rainbow table for every entry in the users table).
Nearly all security is based on obscurity (you don't know my password; that's obscure information), so the more obscurity the better. It just happens that port 8080 is a lot less secure than "$0m3 s[]{}per séc®e7 p4sS\/\/0rd", so that better not be your only line of defense.
No, it actually was a bug in the way the function was called, not the library itself - see comment number four: https://plus.google.com/113641248237520845183/posts/g68d9RvRA1i
In reality, almost nobody* is going to call md5 via crypt() when a standalone md5() function exists, and people are often slow to deploy new versions of PHP - especially major shared hosting providers. Those who manage their own PHP installs and deploy shortly after release tend to have their own set of unit tests, which very likely would have caught this if their own code was affected (Hmm, I can't login anymore. Suddenly my password hash is only twelve characters long? That's not right...)
Of course, if you hit all of the worst cases and push this out, yeah, pretty serious problem.
* Yes, I've seen exceptions to that. Some weird AWS message signing comes to mind, IIRC. Hence "almost".
Yeah, but by playing more games, the whole thing *is* more expensive.
Unless of course you get back into the $/hr thing that someone was trying to avoid in the first place. I guess it depends on whether you prioritize your bank account balance over the efficacy of your spending.
Which is the subtle difference between the "b" and "strong" tags, and "i" vs "em". The former in each pair indicates the desired style, where the latter indicates a style-agnostic level of content emphasis.
It's important to remember that most people (especially non-programmers) don't think about what they're trying to accomplish, just what they've done in the past to replicate the desired outcome. As such, it's very important as a programmer to not blindly give people what they ask for. "Make this open in a new window" often translates into "make a certain piece of information available on a different page accessible to me in a way that won't interrupt my current workflow", so a better solution is may be to just display that information on the first page. The same applies for text styles applied by content producers and editors. They don't want bold text, they want strong emphasis and the way they're most used to seeing that accomplished is via bold text. So semantically, <strong> is a better choice - and it gives you the ability to do a better job (maybe red, underlined text at at standard weight gets the message of emphasis across better based on the page's other styles).
That being said, whoever stated in this comment chain that the new HTML5 tag semantics are poorly thought-out was right. section and div are logically the same (you divide stuff into sections, yes?), aside is frequently misinterpreted to be a sidebar (it's closer to an inline details section, not entirely unlike the title attribute on an abbr tag), etc. audio and video tags are conceptually great, but the format/codec clusterfuck makes them all but useless. The new input types are decent; most of the interesting stuff is really in newer JS functionality and CSS3 attributes. One of the biggest issues is that most of the new semantic tags were based around content publushing, and designed to supersede microformats; there's a very weird overlap when building web applications.
I think he was saying that an "offline web app" is basically an oxymoron.
If you want to use HTML to make an application that's designed to work offline, fine. It's the wrong tool for the job, but these days you can make it work. But if you're building a standalone app, that means you're going to have to make a lot of assumptions about the validity of client-supplied data if you're syncing with a remote server when online connectivity is available. Or go all-out, and do stuff ONLY client-side; and the only thing the server does is provide the initial content and effectively install the web app - in this case HTML and friends are just tools to develop a typical downloaded application.
A perhaps more appropriate implementation of HTML5's offline tools is akin to what Gmail does - allows you to continue working at 90% capacity if your connection flakes. Queue outgoing messages in local storage until network is restored, then send them off as soon as it's possible. Do some local caching so that you have access to at least your most recent messages. It's not designed to work offline 100% of the time (it's fundamentally reliant on server-supplied data) but you're not hosed when signal drops to nothing. Think "Google Gears".
PDF? Isn't that the general idea behind the "portable document format"? Send a PDF to the printer, call it a day. If they can print jpegs directly off memory cards that would seem like a relatively easy approach to a driverless system.
Is it somehow Amazon's fault that the developer didn't RTFM and understand EC2 is effectively the same as remoting into a system booted off a LiveCD with no hard drive attached? Great for computing rainbow tables or, indeed, farming BitCoins; rather poor choice for running a database.
Do you know my password? No? Security by obscurity.
Almost all security* is based on someone not knowing something. Very very often, that something is either a password or very large random number. Or the physical pattern on a key. Or door/alarm code. Or something read via RFID. Or the algorithm that determines the number on my RSA fob. More commonly when making that claim, it's just a nonstandard port for a service, hidden URL, or combination of several.
If an attacker has the exact same set of information that I have, then that attacker has access to the same systems I do. The amount of information they need (or the level of obscurity, if you will) determines the level of security. Something where you need to be on my VPN to get access to a whitelisted IP and then SSH in to the system where password-only auth is disabled is going to be a hell of a lot harder than something where you just need to know to hit port 8080 instead. But ultimately, my passwords and private keys are just very obscure information.
And in terms of end results, not being a target absolutely makes me more secure than an equivalent system that is a target.
* As far as authentication and encryption is concerned, at least. SQL injection and XSS protection being the two best examples where it comes down to actual implementation details.
For the problems Gmail has had over the years, its downtime is still insignificant compared to anything I've tried to deal with myself. And as far as I can remember, their only downtime has been the web interface, not the actual mail servers - so mail was still being received, and people using IMAP instead of the web interface didn't notice anything. Likewise, my internet connections (home and work) are far less reliable than what Google has.