Re: Adding security features
On 2/3/20 11:51 AM, Marvin Renich wrote:
As a specific example of unnecessary default security, take the "https
everywhere" campaign. Having https available on most servers is
definitely good. However, if you explicitly go to
http://www.google.com/ you are redirected to the https version. Of all
the (hundreds of?) billions of google searches done every day, how many
of them would really cause any harm at all if the communications were
unencrypted?
I think you've picked a really bad example, and I'm not sure if that's
because you grabbed something out of the air without really examining
it, but just in case it's not...
I think, first, you're asking the wrong question. Almost no one, and
definitely not the people we're setting the defaults for, would remember
to pick between http:// and https:// each time they're doing a search.
After all, we're presuming the default. So even if it turns out a small
percentage of searches, it can easily mean that it's a large percent of
*users*.
And it probably is. When I think of my own searches, sure, most are for
boring things like looking up an API. Or random computer
troubleshooting, or whatever. At first blush, even if those were public,
seems relatively harmless. But sometimes I search for e.g.,
medical/health things that I'd definitely be upset if they were public.
Of course, http doesn't mean public, but it definitely can — public WiFi
is everywhere, for example. That alone, I think, makes https-by-default
make sense for web searches.
But there is more. I've heard about plenty of research that it doesn't
actually take that many search queries to get a pretty good profile of a
person. All those queries that are innocuous taken individually when put
together get a lot more sensitive. I'd definitely rather not share that
info with my ISP, who of course could easily get it w/o https. (Choices
here are Verizon and Comcast, who do you trust less to not try this and
sell the results to the highest bidder?).
There is still more. Google results are heavily customized based on your
past searches, and include ads based on, well, everything Google knows
about you. Which (again, for the person defaults are targeted at) is a
lot. So even innocuous searches can wind up including private things in
the results. E.g., Google has at some point had results from Gmail in
the web search results (no idea if they currently do).
We've only considered eavesdropping so far. But Google is a high-profile
site, used by almost everyone, That makes it a very tempting target for
active attacks — everything from ISPs injecting their own ads and
content (not a hypothetical, even some large ISPs do this) to targeted
attacks (e.g., when a user gets a scary security warning about running
something from visiting Google.com, I bet "yes" is a much more likely
answer). And of course all the attacks essentially on Google; e.g.,
inject some JavaScript to fake clicks on ads on results pages. Etc.
Finally, the cost really isn't that high...
Yet the entire computer-using segment of society pays the
price for higher bandwidth and CPU usage.
The funny thing about forcing the deployment of HTTPS everywhere is that
it got everyone on board with improving the protocols and
implementations. HTTP/2 (and eventually /3) and TLS/1.3 aren't really
that much slower than they would be w/o the encryption, modern ciphers
are plenty fast even on fairly low-end hardware, etc. We've even made
good progress on reducing the extra round-trips required (via session
resumption, multiplexing, and TLS False Start). On very slow links
(e.g., dial up modem), it's probably painful to lose link-layer
compression... but I can't imagine how dreadful the modern web must be
on dialup.
It's been a shame to lose web caches in some cases, too.
Reply to: