Your browser supplies HTML5 Geolocation. But it sounds like the submitter is having problems with GeoIP detection. That's a server-side issue and relies on subscription databases for identifying where physically on the globe an IP might map to. It's also horribly inaccurate as the submitter has found.
Short Answer: Signup for a VPN or Proxy service with an exit point in the region you want.
Longer Answer: IP-based geography detection (GeoIP for short) depends on the databases and services that various providers are leveraging. It's inherently inaccurate. Good luck getting these fixed as there are a bunch of different services (including the W3C) that you would need to get updated. Are you sure your routing exit point isn't actually in Ireland? My company's IP address maps to an exit point in San Francisco, even though I'm located in Los Angeles.
HTML5 location detection is pretty accurate, insofar as it relies on your browser to tell the site/service where you are. You should be able to force that setting in your browser.
You spend money on food regardless if you have any income. Ergo, food expenses are not direct costs associated with your income.
If you have to wear a uniform to your job, and pay for it yourself, then it is certainly tax deductible. Just like travel, meals, etc.
Rule of thumb - if you could do without it when unemployed, but it's required for your *particular* employment, then it's a direct expense that you can probably deduct.
The problem is that most voters simply don't know what to care about. Voters worry about irrelevant issues like abortion, gay marriage, inequality, and racism, while not worrying enough about the stuff that matters, like banking regulation, tax policy, nepotism, and crony capitalism.
That's not true, and it's a tired trope I keep hearing over and over. Voters do care, but they care about different things. Some people care more about sociological issues, whereas others care more about socioeconomic issues.
Their month-to-moth offer is still Unlimited, and says so in the language. And I have the opportunity to sign a new contract, and lock in the same service (for example, to subsidize a phone).
They are trying to use contract language to redefine Unlimited to mean something other than Unlimited, but still call it Unlimited to avoid.
With current LTE speeds, it is possible to hit the "soft" threshold for a monthly data use in less than 90 seconds.
If they want everyone off the plan, they could change the terms and call it "Throttled" and not be lying. But they want to have their cake and eat it too. They know that if they truly ended the plans, customers would take the opportunity to walk to another carrier.
I have Grandfathered Unlimited with AT&T. They're screwing us.
Unlimited used to mean Unlimited. Now "Unlimited" means if you use more data than our basic tiered plan, we are going to arbitrarily throttle your speeds to those available when you first bought into the plan (Edge, vs LTE).
It is very clearly a reduction of service for "Unlimited" users to encourage them to drop the plan for the tiered pricing, which has no speed restrictions. Verizon just got slapped around by the FCC for doing this. AT&T is due.
Back in dial-up days, companies tried the same kind of crap and got punished for it. Eventually ISPs shifted to truly unlimited plans. Later, rinse, and repeat.
The VPN traffic itself would be taxable traffic through your ISP. VPN just masks the content and final destination of the traffic. It doesn't mask the fact that there is traffic to begin with.
If every employee suddenly were running up internet costs, you can bet your ass companies will start blocking internet access unless you go through the hassle of proving you need it.
Say goodbye to free wifi at coffee shops.
Your phone would be affected as well, so there goes more skyrocketing costs.
No-one will download security updates if they now have to pay for the transmission.
The result of this would be the internet in the affected country reverting to user behaviors, features, and services from 10 years ago as it would introduce a sever stifling effect on data usage. Your described pattern would be what most people would do, and the internet as we've grown to know it would die.
This was a big plot point in a scifi novel I read years ago. A group of people willingly underwent amputation to reduce the mass of legs, allowing them to add more people to their launch crew.
If I remember correctly, there is a staged automobile accident, causing the main character to lose his legs (not knowing it was intentional) resolving the problem of being separated from the love interest who would be on the shuttle.
This is really going to bother me until I can remember what novel it was.
They've already been around for years. A few extra sensor provided by the drone kit instead of the iPhone. This just makes them cheaper because your kit doesn't need as many sensors.
I understand the difference between authentication and authorization. Onsite signup provides both authentication and authorization in a single process. 3rd party signup (OpenID) can *only* provide authentication, it can never provide authorization. An additional step is required tIn this regards it's no different from shared public keys.
OpenID is more complicated for the end user to manage, AND it puts additional technical burden on them to understand. How am I (the average user, not the site admin) supposed to know my OpenID is compromised? How do I fix it? How do I know the server that provides my OpenID is compromised? Keeping track of a password phrase is fundamentally a much simpler problem for the end user. Where do you want to place more burden of responsibility? Site operators, or end users?
You're saying that you don't want Google to trust authentication from anywhere else because you want to trust that any authentication coming from Google is equivalent to valid authorization, which helps you prevent spambots from signing up for your service
No, I'm saying as a site owner, I don't want to trust authorization from just anywhere, because logged-in users are core to my service model. To make things easier on my users, I allow signups with common third party ID services, because I understand their authorization mechanisms. But now I've sacrificed my control over my users.
Fully peer-to-peer authorization (which is what OpenID provides) is effectively fully-public authorization. In which case, if it's public, why do you even need peer-to-peer authentication?
Again, we're saying the same thing about the fundamentals of the mechanism and problems. But we differ in our beliefs on the motivations. You say the failure of OpenID is malicious intent on the part of the big corporate players to create locked-in ecosystems. I say that's a side effect and the failure stems from the inherent need of a site owner (big or small) to effectively manage their userbase with minimal burden on the users.
If I trust Google IDs, and allow people to signup to my site with Google IDs, that is a fairly good way of limiting malicious bots from signing up on my site. But I've now accepted Google's signup policies as my own.
When Google suddenly lets spammers create 1000s of IDs, my site is now vulnerable to massive automated signups. Because I have no way of identifying a legitimate Google ID user from a spam Google ID user. I have offloaded my trust to Google.
Multiply that out to an infinite number of ID providers, and it makes relying on logins for user verification a useless exercise. At that point, I need an additional channel of confirmation (hence the "2" in "2 factor authentication").
The problem isn't trust. The problem is that these companies want walled gardens that they control.
Wrong, wrong, wrong. If I don't trust Facebook or Google's account creation policies to prevent Nigerian spammers from creating spambot accounts, how in the world could I ever expect them to trust mine? It has nothing to do with a walled garden, and everything to do with trusting a 3rd party to have good policies in place.
So your answer is "trust the user". Basic security and site administration tells you "don't trust the user".
My "very few" comment comes from this. You cannot trust the user. Widespread OpenID (or any similar system) effectively devolves into peer-to-peer authentication. This can be a good thing, for limited scenarios. But widespread adoption would require many services to fundamentally change what their service offers, not just how they authenticate.
I also am talking about "trust" as in "trustworthy", not the security technical definition. I think we're saying the same thing, but I lay the blame on an inherent aspect of the system, not on the Google/MS/Facebook big players in the space.
Any site owner (be it Google or Mom's BBQ Shack) cannot accept third party authentication, without implicitly relying on whatever user creation policies that third party uses to control their audience.
If tomorrow Google suddenly opened the floodgates and said spambots could create all the Google IDs they wanted, then practically overnight you would see wholesale disabling of Google ID authentication on sites that currently use it.
The reality is that no-one other than the really big players get enough public attention to be considered trustworthy for 3rd party authentication. Allowing unrestricted third-party authentication services by definition means allowing anonymous accounts. And truly anonymous accounts are diametrically opposite from having logged-in users.
My point is that this isn't a Google/big data tracking/hate the corps issue. The point of user logins are to provide you (the site owner) controls over your userbase. If you offload your logins to 3rd parties, you are sacrificing most (if not all) of those controls.
Here's a real example - I run a site that has a private area. Users are authenticated using Facebook (because I don't want to force extra logins on them). It's cut down on the vast majority of bogus signup attempts, but only because Facebook is relatively good about preventing spambots from creating accounts. But there's no way in hell I would allow Mom's BBQ Shack to provide authentication (aka, OpenID) because I have no visibility or public evaluation on how Mom's BBQ Shack creates logins. For all I know, Mom's BBQ Shack is really just a spam king, and I just allowed spambot logins on my system.
We have a couple of great examples of truly anonymous, distributed systems, where every node is equal allowed behavior: Email and Usenet. Spam problems on both are fundamentally insolvable without breaking the systems to rely on outside methods of trust. The same applies for an authentication service. You cannot have a fully open and anonymous system, without it allowing for anonymized abuse.
Ok, continue the metaphor... the majority of the users will pick near the middle of the page: the sample set is reduced by an order of magnitude again. I'm sure there's a psychological predicative to the left page or the right page, there goes another 50%.
Not to mention, you started with a sample size of around a quarter-million English words to begin with, so now you're down to around 100K possible options. Humans will naturally rule out words they don't intuit are random. Like rejecting the word "random" or "password" for this scenario. You put together enough psychological conditions like this and you can easily reduce the sample set to a few hundred words that would be used by a majority of users.
A case-sensitive 8-digit alpha numeric password (no special characters or spaces) has 62^8 possible "words", and that already isn't considered secure enough.
The word system works, only if people generally don't use words. If everyone uses unadulterated words, then the whole thing breaks down into a dictionary attack with a fairly limited password space (the size of the dictionary to the power of the number of words required) .
The problem exactly is trusting 3rd party services.
Google, Facebook, MS may have all implemented it, but none would trust third party authentication. They all made their authentication available to website providers.
As a result, since no-one trust arbitrary unknown services, the result is the only commonly accept 3rd party auth servers are Google, Facebook, MS, twitter, etc.
OAuth, OpenID, OpenID 2.0, and any other truly distributed login systems are doomed to failure. They serve as nice protocols, but ultimately the relationships of trust between the managing entities are more important. Yes, you can run your own auth servers. No one will trust you as an individual implementer because there is fundamentally no way to differentiate you from a malicious person who can also run their own auth servers.
Nope, still the same problem. Very few sites (even tiny web forums and such) are willing to trust arbitrary 3rd party. Google and FB, sure, because they are so big and a known entity, but not an arbitrary 3rd party.
Remote 3rd party authorization solves only on piece of the problem that onsite auth solves: confirming user login to an existing account. There are other problems, like ensuring unique, non-spam/bot users, that can't be done with remote authentication unless you trust the policies of the remote autnenticator.
If tomorrow Google suddenly opened the floodgates and said spambots could create all the Google IDs they wanted, then practically overnight you would see wholesale disabling of Google ID authentication.
OAuth, OpenID, OpenID 2.0, and any other truly distributed login systems are doomed to failure. They serve as nice protocols, but ultimately the relationships of trust between the managing entities are more important. Yes, you can run your own auth servers. No one will trust you as an individual implementer because there is fundamentally no way to differentiate you from a malicious person who can also run their own auth servers.
We do, it's called Open ID, which is what Google leverages for their single-signon (not sure if FB is their own solution or not). It was a really popular thing about 5-10 years ago and got a ton of attention. I think even MS enabled it.
The problem with it is this: everyone was willing to let open their servers be the authenticating source for OpenID, but no one was willing to trust a 3rd party's servers to do the same.
So I can create identity authentication galore at mydomain.example.com, but if Google isn't willing to trust mydomain.example.com, then it's not very useful as a unified login authenticator.
Humans are very predictable when attempting to be random. Just using your dictionary example, the vast majority of people (say 75-95%) would pick something in the middle third of the dictionary, because opening to page A or page Z would instinctively be considered not random enough.
Just ask people to cut a deck of cards. It will be exceedingly rare for the the person to cut the deck anywhere but close to the middle 25% of the deck. It's clearly not a sufficient act of randomness, which is why we shuffle, not just cut the deck when playing card games. We have someone other than the dealer perform the cur operation as a simple test to limit the dealer's ability to cheat.
Same thing with a dictionary. Your approach can work, if everyone had sufficiently random dictionaries to begin with. But to the average person, picking a "random" word will result in word association, something psychologists have a field day studying.
The thing is, with a good password manager, there's no reason to have a weak password, even for the sites that you aren't worried about.
And there you hit the nail on the head. There is no *good* password manager. Safari's password generator and keychain comes close because it follows you between desktop and mobile devices, but it limits you to Apple's browsing products. Chrome is next best, but again, only works in Chrome browsers, and doesn't have built-in password generation.
I use Keepass and keep the secured file on dropbox to sync across devices. But yet again, limited to where I feel safe pulling from dropbox, and requires a 3rd party app that will be unavailable (or insecure) on shared devices. Plus, it's tedious to open, try to find what you're looking for, and copy/paste out. In-browser integration is required feature to actually get widespread adoption.
Have you ever needed to implement side-wide search functionality? (note, this is not the same thing as a global web search company like Google, Bing, etc)
If you have, and it involved anything more than turning on a checkbox in your platform, then you have almost undoubtedly encountered or considered Solr.
I'd blame most of the problems with CSS on the lack of support across browser vendors. It took soooo long for even the most basic features to be supported, that rendering differences lead to a culture of hacks (remember when people would put in explicitly invalid CSS to trigger certain IE behaviors?) because styles couldn't be built the right way.
Event today there are some fairly cool pieces of CSS (background-position: center center; background-size: cover) that are amazingly useful, but because of incomplete browser support, people end up with lots of extra HTML, CSS, and Javascript.
Because using tables for layout was itself a hack.
Tables were meant for tabular content. You know, the kind of thing you might get out of a spreadsheet or report. The nice thing about tabluar content structure is you can have sort controls, or headers, footers, etc.
Try to achieve today's web designs with tables, and then try to place tabular content in the page.... yeah, good luck separating them and styling properly without CSS.
The worst part about table based layouts was that if you needed to remove or add something to the layout, you had to rework the entire layout table to make it work.
And even worse, once you start nesting languages within each other (like HTML inside a JSP, JS, PHP, etc...) then any attempts at consistency for indentation is completely unachievable.
Slashdot Mirror
Your browser supplies HTML5 Geolocation. But it sounds like the submitter is having problems with GeoIP detection. That's a server-side issue and relies on subscription databases for identifying where physically on the globe an IP might map to. It's also horribly inaccurate as the submitter has found.
Short Answer:
Signup for a VPN or Proxy service with an exit point in the region you want.
Longer Answer:
IP-based geography detection (GeoIP for short) depends on the databases and services that various providers are leveraging. It's inherently inaccurate. Good luck getting these fixed as there are a bunch of different services (including the W3C) that you would need to get updated. Are you sure your routing exit point isn't actually in Ireland? My company's IP address maps to an exit point in San Francisco, even though I'm located in Los Angeles.
HTML5 location detection is pretty accurate, insofar as it relies on your browser to tell the site/service where you are. You should be able to force that setting in your browser.
You spend money on food regardless if you have any income. Ergo, food expenses are not direct costs associated with your income.
If you have to wear a uniform to your job, and pay for it yourself, then it is certainly tax deductible. Just like travel, meals, etc.
Rule of thumb - if you could do without it when unemployed, but it's required for your *particular* employment, then it's a direct expense that you can probably deduct.
That's not true, and it's a tired trope I keep hearing over and over. Voters do care, but they care about different things. Some people care more about sociological issues, whereas others care more about socioeconomic issues.
Their month-to-moth offer is still Unlimited, and says so in the language. And I have the opportunity to sign a new contract, and lock in the same service (for example, to subsidize a phone).
They are trying to use contract language to redefine Unlimited to mean something other than Unlimited, but still call it Unlimited to avoid.
With current LTE speeds, it is possible to hit the "soft" threshold for a monthly data use in less than 90 seconds.
If they want everyone off the plan, they could change the terms and call it "Throttled" and not be lying. But they want to have their cake and eat it too. They know that if they truly ended the plans, customers would take the opportunity to walk to another carrier.
I have Grandfathered Unlimited with AT&T. They're screwing us.
Unlimited used to mean Unlimited. Now "Unlimited" means if you use more data than our basic tiered plan, we are going to arbitrarily throttle your speeds to those available when you first bought into the plan (Edge, vs LTE).
It is very clearly a reduction of service for "Unlimited" users to encourage them to drop the plan for the tiered pricing, which has no speed restrictions. Verizon just got slapped around by the FCC for doing this. AT&T is due.
Back in dial-up days, companies tried the same kind of crap and got punished for it. Eventually ISPs shifted to truly unlimited plans. Later, rinse, and repeat.
I hope that was a joke.
The VPN traffic itself would be taxable traffic through your ISP. VPN just masks the content and final destination of the traffic. It doesn't mask the fact that there is traffic to begin with.
If every employee suddenly were running up internet costs, you can bet your ass companies will start blocking internet access unless you go through the hassle of proving you need it.
Say goodbye to free wifi at coffee shops.
Your phone would be affected as well, so there goes more skyrocketing costs.
No-one will download security updates if they now have to pay for the transmission.
The result of this would be the internet in the affected country reverting to user behaviors, features, and services from 10 years ago as it would introduce a sever stifling effect on data usage. Your described pattern would be what most people would do, and the internet as we've grown to know it would die.
Event signup (free)
https://www.eventbrite.com/
Have them start with that, and then ask them what does or doesn't work.
Then, estimate labor to build, maintain, and support custom work.
This was a big plot point in a scifi novel I read years ago. A group of people willingly underwent amputation to reduce the mass of legs, allowing them to add more people to their launch crew.
If I remember correctly, there is a staged automobile accident, causing the main character to lose his legs (not knowing it was intentional) resolving the problem of being separated from the love interest who would be on the shuttle.
This is really going to bother me until I can remember what novel it was.
They've already been around for years. A few extra sensor provided by the drone kit instead of the iPhone. This just makes them cheaper because your kit doesn't need as many sensors.
I understand the difference between authentication and authorization. Onsite signup provides both authentication and authorization in a single process. 3rd party signup (OpenID) can *only* provide authentication, it can never provide authorization. An additional step is required tIn this regards it's no different from shared public keys.
OpenID is more complicated for the end user to manage, AND it puts additional technical burden on them to understand. How am I (the average user, not the site admin) supposed to know my OpenID is compromised? How do I fix it? How do I know the server that provides my OpenID is compromised? Keeping track of a password phrase is fundamentally a much simpler problem for the end user. Where do you want to place more burden of responsibility? Site operators, or end users?
No, I'm saying as a site owner, I don't want to trust authorization from just anywhere, because logged-in users are core to my service model. To make things easier on my users, I allow signups with common third party ID services, because I understand their authorization mechanisms. But now I've sacrificed my control over my users.
Fully peer-to-peer authorization (which is what OpenID provides) is effectively fully-public authorization. In which case, if it's public, why do you even need peer-to-peer authentication?
Again, we're saying the same thing about the fundamentals of the mechanism and problems. But we differ in our beliefs on the motivations. You say the failure of OpenID is malicious intent on the part of the big corporate players to create locked-in ecosystems. I say that's a side effect and the failure stems from the inherent need of a site owner (big or small) to effectively manage their userbase with minimal burden on the users.
No, you misunderstand me.
If I trust Google IDs, and allow people to signup to my site with Google IDs, that is a fairly good way of limiting malicious bots from signing up on my site. But I've now accepted Google's signup policies as my own.
When Google suddenly lets spammers create 1000s of IDs, my site is now vulnerable to massive automated signups. Because I have no way of identifying a legitimate Google ID user from a spam Google ID user. I have offloaded my trust to Google.
Multiply that out to an infinite number of ID providers, and it makes relying on logins for user verification a useless exercise. At that point, I need an additional channel of confirmation (hence the "2" in "2 factor authentication").
Wrong, wrong, wrong. If I don't trust Facebook or Google's account creation policies to prevent Nigerian spammers from creating spambot accounts, how in the world could I ever expect them to trust mine? It has nothing to do with a walled garden, and everything to do with trusting a 3rd party to have good policies in place.
So your answer is "trust the user". Basic security and site administration tells you "don't trust the user".
My "very few" comment comes from this. You cannot trust the user. Widespread OpenID (or any similar system) effectively devolves into peer-to-peer authentication. This can be a good thing, for limited scenarios. But widespread adoption would require many services to fundamentally change what their service offers, not just how they authenticate.
I also am talking about "trust" as in "trustworthy", not the security technical definition. I think we're saying the same thing, but I lay the blame on an inherent aspect of the system, not on the Google/MS/Facebook big players in the space.
Any site owner (be it Google or Mom's BBQ Shack) cannot accept third party authentication, without implicitly relying on whatever user creation policies that third party uses to control their audience.
If tomorrow Google suddenly opened the floodgates and said spambots could create all the Google IDs they wanted, then practically overnight you would see wholesale disabling of Google ID authentication on sites that currently use it.
The reality is that no-one other than the really big players get enough public attention to be considered trustworthy for 3rd party authentication. Allowing unrestricted third-party authentication services by definition means allowing anonymous accounts. And truly anonymous accounts are diametrically opposite from having logged-in users.
My point is that this isn't a Google/big data tracking/hate the corps issue. The point of user logins are to provide you (the site owner) controls over your userbase. If you offload your logins to 3rd parties, you are sacrificing most (if not all) of those controls.
Here's a real example - I run a site that has a private area. Users are authenticated using Facebook (because I don't want to force extra logins on them). It's cut down on the vast majority of bogus signup attempts, but only because Facebook is relatively good about preventing spambots from creating accounts. But there's no way in hell I would allow Mom's BBQ Shack to provide authentication (aka, OpenID) because I have no visibility or public evaluation on how Mom's BBQ Shack creates logins. For all I know, Mom's BBQ Shack is really just a spam king, and I just allowed spambot logins on my system.
We have a couple of great examples of truly anonymous, distributed systems, where every node is equal allowed behavior: Email and Usenet. Spam problems on both are fundamentally insolvable without breaking the systems to rely on outside methods of trust. The same applies for an authentication service. You cannot have a fully open and anonymous system, without it allowing for anonymized abuse.
Ok, continue the metaphor... the majority of the users will pick near the middle of the page: the sample set is reduced by an order of magnitude again. I'm sure there's a psychological predicative to the left page or the right page, there goes another 50%.
Not to mention, you started with a sample size of around a quarter-million English words to begin with, so now you're down to around 100K possible options. Humans will naturally rule out words they don't intuit are random. Like rejecting the word "random" or "password" for this scenario. You put together enough psychological conditions like this and you can easily reduce the sample set to a few hundred words that would be used by a majority of users.
A case-sensitive 8-digit alpha numeric password (no special characters or spaces) has 62^8 possible "words", and that already isn't considered secure enough.
The word system works, only if people generally don't use words. If everyone uses unadulterated words, then the whole thing breaks down into a dictionary attack with a fairly limited password space (the size of the dictionary to the power of the number of words required) .
The problem exactly is trusting 3rd party services.
Google, Facebook, MS may have all implemented it, but none would trust third party authentication. They all made their authentication available to website providers.
As a result, since no-one trust arbitrary unknown services, the result is the only commonly accept 3rd party auth servers are Google, Facebook, MS, twitter, etc.
OAuth, OpenID, OpenID 2.0, and any other truly distributed login systems are doomed to failure. They serve as nice protocols, but ultimately the relationships of trust between the managing entities are more important. Yes, you can run your own auth servers. No one will trust you as an individual implementer because there is fundamentally no way to differentiate you from a malicious person who can also run their own auth servers.
Nope, still the same problem. Very few sites (even tiny web forums and such) are willing to trust arbitrary 3rd party. Google and FB, sure, because they are so big and a known entity, but not an arbitrary 3rd party.
Remote 3rd party authorization solves only on piece of the problem that onsite auth solves: confirming user login to an existing account. There are other problems, like ensuring unique, non-spam/bot users, that can't be done with remote authentication unless you trust the policies of the remote autnenticator.
If tomorrow Google suddenly opened the floodgates and said spambots could create all the Google IDs they wanted, then practically overnight you would see wholesale disabling of Google ID authentication.
OAuth, OpenID, OpenID 2.0, and any other truly distributed login systems are doomed to failure. They serve as nice protocols, but ultimately the relationships of trust between the managing entities are more important. Yes, you can run your own auth servers. No one will trust you as an individual implementer because there is fundamentally no way to differentiate you from a malicious person who can also run their own auth servers.
We do, it's called Open ID, which is what Google leverages for their single-signon (not sure if FB is their own solution or not). It was a really popular thing about 5-10 years ago and got a ton of attention. I think even MS enabled it.
The problem with it is this: everyone was willing to let open their servers be the authenticating source for OpenID, but no one was willing to trust a 3rd party's servers to do the same.
So I can create identity authentication galore at mydomain.example.com, but if Google isn't willing to trust mydomain.example.com, then it's not very useful as a unified login authenticator.
Humans are very predictable when attempting to be random. Just using your dictionary example, the vast majority of people (say 75-95%) would pick something in the middle third of the dictionary, because opening to page A or page Z would instinctively be considered not random enough.
Just ask people to cut a deck of cards. It will be exceedingly rare for the the person to cut the deck anywhere but close to the middle 25% of the deck. It's clearly not a sufficient act of randomness, which is why we shuffle, not just cut the deck when playing card games. We have someone other than the dealer perform the cur operation as a simple test to limit the dealer's ability to cheat.
Same thing with a dictionary. Your approach can work, if everyone had sufficiently random dictionaries to begin with. But to the average person, picking a "random" word will result in word association, something psychologists have a field day studying.
And there you hit the nail on the head. There is no *good* password manager. Safari's password generator and keychain comes close because it follows you between desktop and mobile devices, but it limits you to Apple's browsing products. Chrome is next best, but again, only works in Chrome browsers, and doesn't have built-in password generation.
I use Keepass and keep the secured file on dropbox to sync across devices. But yet again, limited to where I feel safe pulling from dropbox, and requires a 3rd party app that will be unavailable (or insecure) on shared devices. Plus, it's tedious to open, try to find what you're looking for, and copy/paste out. In-browser integration is required feature to actually get widespread adoption.
Have you ever needed to implement side-wide search functionality? (note, this is not the same thing as a global web search company like Google, Bing, etc)
If you have, and it involved anything more than turning on a checkbox in your platform, then you have almost undoubtedly encountered or considered Solr.
I'd blame most of the problems with CSS on the lack of support across browser vendors. It took soooo long for even the most basic features to be supported, that rendering differences lead to a culture of hacks (remember when people would put in explicitly invalid CSS to trigger certain IE behaviors?) because styles couldn't be built the right way.
Event today there are some fairly cool pieces of CSS (background-position: center center; background-size: cover) that are amazingly useful, but because of incomplete browser support, people end up with lots of extra HTML, CSS, and Javascript.
Because using tables for layout was itself a hack.
Tables were meant for tabular content. You know, the kind of thing you might get out of a spreadsheet or report. The nice thing about tabluar content structure is you can have sort controls, or headers, footers, etc.
Try to achieve today's web designs with tables, and then try to place tabular content in the page.... yeah, good luck separating them and styling properly without CSS.
The worst part about table based layouts was that if you needed to remove or add something to the layout, you had to rework the entire layout table to make it work.
And even worse, once you start nesting languages within each other (like HTML inside a JSP, JS, PHP, etc...) then any attempts at consistency for indentation is completely unachievable.