What you propose would not stop the attacker diverting users to the WRONG https site, this is especially an issue with sites that use third party payment processors. There is nothing to stop an attacker registering say "angelpay.co.uk" (an unregistered domain at the time of writing) and setting up what looks like a payment processing site there.

The problem is that there are many sites were the operators think "we don't need any encyrption" or "we only need to encyrpt specific pages" but aren't looking at the bigger picture.

For example a web store, many web stores only use ssl for their payment pages (or redirect to a third party for payment). They think this is fine as in normal operation the credit card information is encrypted but it gives plenty of scope for an active attacker to steal the credit card information.

I would expect the sales will have a positive marginal profit, that is the costs directly associated with the sale will be less than the income directly associated with the sale.

Of course having a positive marginal profit on every sale does not mean you will make a profit overall (and thus be able to stay in buisness). To do that you need to cover all your fixed costs too. It's perfectly possible that selling to everyone at the russian price would not cover the fixed costs but selling to russians at that price is neverthless the way to maximise overall profit.

Trying to allocate "profit" to individual sales in a buisness dominated by upfront fixed costs is fairly meaningless.

The GP was exaggerating, It's actually lost about half it's value. Also steam already has code to enforce region locking on games sold through other channels and already has code to set different prices for different countries. So I would assume this was a fairly minor tweak from a technical perspective.

Simpler? yes, more profitable? no.

The ammount people are prepared to pay for goods varies with how rich they are and with existing norms in their country. Therefore the pricepoint that balances number of sales against profit from each sale is different in different countries. This is especially true for digital goods which have negligable marginal cost to the seller.

The problem with a system of conditionally serving http->https redirects based on known client capabilities (and serving internal links in a way that they stick with the same protocol the user used to request the page) is that once you start redirecting most of your users to https then incoming links (and unless you are really careful probablly some internal links too) will start to use https as people copy and paste the urls.

As well as the direct anoyance to users of older browsers if search engines can't follow incoming links to your site then you are going to be disadvantaged in search rankings.

I see serveral reasons for a site like /. to use ssl.

1: protecting logins, with password reuse being so common every unenrypted site that allows logins is a potential way for someone with a packet sniffer to gather valuable username/password combinations. I suspect this is the main reason behind chromes proposal.
2: protecting integrity, especially on a tech news site someone could inject fake stories as a means of social engineering to get people to install malware. A similar agrument may apply to using browser vulnerabilities to push malware (though on a machine used for general web browsing https would only help there if nearly the whole web was using it). Yet another possibilty is that an attacker rewrites urls so that when people follow links from an unencrypted site to a site that is supposed to be https they get diverted either to a plain http url or to a https url the attacker controls.
3: protecting privacy, a government with oppresive plans may want to know who is active on stories related to government oppression.

Yes there is a price to be paid in terms of reduced ability for service providers to cache, in terms of more admin effort and in terms of CPU time.

Indeed, and it's even worse than you suggested. Normally what you would want to do after a vulnerability like heartbleed that put your private key at risk* is

1: obtain a new certificate
2: install the new certificate
3: revoke the old certificate

Unfortunately as a startssl free user you can't easilly do that. Not only do revocations cost money, they also have stupid policies about duplicate certificates which mean you have to either buy the new cert from a different CA, upgrade to the paid/verified startssl tier** or incur substantial downtime by revoking the old certificate first.

I bet a lot of people just said screw it and waited until the certificate expired before rekeying (and possiblly by the time the cert did expire had forgotten about the issue and didn't rekey then either).

*AIUI heartbleed wasn't a particually easy vulnerability to actually expolit to get the key, it's not like say the Debian openssl vulnerability where the keys were unquestionablly compromised.
**a class 2 (paid/verified) cert and a class 1 (free) cert in the same name apparrently don't count as duplicates because they are issued from different intermediates and even if they did paid certs unlike free ones allow secondary names which works arround the issue.

That*'s certainly an issue and is why the warnings are the way they are. Possible soloutions would include a new url scheme or extending the http standard to support a starttls type scheme to allow encrypted connections with the http url scheme (the downside of the latter is it will give the attacker hints that the connection is likely to be unauthenticated).

I strongly disagree with the people who say encrypted but unauthenticated is as bad as unencrypted. Yes a targetted attack can use man-in-the-middle techniques but if anyone starts doing that on a large scale they are likely to get noticed.

*And the related issue that when you set a form submission url as https you are declaring your intent to have the form submitted over a secure connection.

hmm, I can't say i've ever had any problems getting certs from them, despite usually having let the client cert expire and having to start from scratch when renewal time comes.

I've heard of people being denied certs because their site was "commercial" and they have the annoying habbit of issuing the cert to you some time before putting it on their ocsp server but I never heard anything about over-capacity before.

I imagine for people already driving there won't be much change in cost. Once you've been on the road five years or so the insurance companies have a pretty good idea if you are a high risk driver or not from your records (both insurance records and traffic offense records).

Where things could get nasty is for people new to manual driving, I would think the combiantion of "inexperianced" and "wants to drive for fun rather than utility" is going to end up as a pretty high risk category. At least here in the UK it's already prohibitively expensive for a new young driver to insure a fast car and even with a basic econobox it's not unheard of for the insurance to cost more than the car (One teenager here even resorted to driving a tractor because car insurance was unaffordable,e).

Which means 50 years later there would be relatively few people on the road with sufficient manual driving experiance to get manual driving insurance at a reasonable price.

At least here in the UK it's still perfectly legal to ride on horseback or in a horse drawn vehicle on normal roads* at any time. It's reccomended to get training first but unlike with motor vehicles there is no legally mandated licensing requirement.

One big difference between horses and cars is that horses are high maintinance. They have to be fed, mucked out etc whether you are using them or not. Cars on the other hand can hapilly sit in a garage for months at a time. So owning a "play car" is much less of a commitment than owning a horse. I could see that changing how things play out.

*Motorways are as the name suggets for motor vehicles only.

Latex has it's good and bad points.

good points
maintains mental distinction between input and output
maintains a reasonable level of semantic information
reliable and reasonablly fast for large documents
produces really nice typeset output
handles equations well
handles captioning and cross-referencing well
makes a reasonable job at layout before tweaking

bad points
only a few image formats work, with traditional latex it's EPS or bust, pdflatex is a bit better but it still pretty limited with PDF being the only vector format supported (which is fun as most pdf creators don't want to create arbitary sized pdfs so you often have to print to pdf then use a seperate tool to remove the borders) and the only bitmap formats supported being png and huffman jpeg (at least in my experiance artimetic coded jpeg doesn't work and gives an unhelpful error message, that caused some head scratching)
the layout engine is reasonablly smart but not smart enough to get a layout i'm happy with without tweaking and the compile-build-view cycle gets annoying during layout tweaking.
the whole system feels like hacks built on top of hacks. The parameters to hyperef to avoid ugly boxes don't work in all versions (not sure if they work in the latest now, I certainly remember having to downgrade when working on my thesis because of this). Hyperref links go to the float caption rather than the float itself unless you add another hack package called hypcap but that in turn requires further hackery to work with custom figure types (such as figures placed by the side of the text rather than inline with it..
table handling leaves a lot to be desired requiring significant manual tweaking for any nontrivial table.
there are way too many markup sensitive characters, this means that significant editing is often required after pasting in plain text.
requires running a bunch of tools in the right order and sometimes multiple times to process a document

Thats my experiance from writing a phd thesis with the thing anyway.

I'd guess a combination of a small population and a large petrochemical industry pushes them up in the rankings (note that the rankings in question are per-capita).

Being a small island probablly doesn't help, in particular small islands are often short on fresh water which pushed them to energy intensive desalination. It can also make it difficult to achive economies of scale in power generation.

AIUI EE is currently owned by deutsche telekom and france telecom, so this is one former state monopoly telco buying a buisness off other fromer state monopoly telcos, not a takeover of an indpendent buisness.

Note that while " large ISP/Telco company." is not wrong it's something of an understatement. BT is the former state monopoly telco in the UK.

AIUI BT openreach (the part of BT that owns the physical lines) has an effective monopoly for about half of the UK households. For most of the rest they are competing against virgin media but virgin media don't sell wholesale. Theres a few small upstarts arround too but they tend to have negligable coverage areas.

Fortunately we have reasonablly effective regulation which allows competition at the service provider level despite the monoploy at the physical line level.