Advice to avoid public Wi-Fi is mostly out of date

https://www.eff.org/deeplinks/2020/01/why-public-wi-fi-lot-safer-you-think

by DiabloD3 • 6 years ago

206 114 6 years ago

Passive interception is less of an issue because so many sites are using tls, but in the case of a mitm attack isn't https stripping still a problem unless the site is using hsts?

kevinsimper2• 6 years ago

You would have to trust a root certificates from your mitm attacker, so it is not a problem.

resoluteteeth2• 6 years ago

When you first access a site, unless the site is using HSTS you are going to go to an insecure version so a mitm can proxy the request and remove tls or redirect you to another site. This is what is known as "https stripping."

iso16315• 6 years ago

Block outgoing connections on port 443. MITM anything on port 80 which forwards to the server on port 443.

Your browser then loads www.whatever.com as http, even if the server doesn't allow http.

HSTS means if you've been to www.whatever.com before you'll be blocked. If you've never been before that doesn't help though.

In that fashion, typing www.mybank.com could redirect you to http://www.mybank.com (mitm) then to https://www.mybank.com-login.com/, where you get a green padlock.

andreareina• 6 years ago

I know someone who got caught out by this. Bank's front page was http, so the attackers mitm'ed that. Ebanking link was swapped out for an https page they controlled, allowing the credentials to be harvested before redirecting to the bank.

IshKebab3• 6 years ago

Not really because most sites you visit you've already visited before. HTST preload only helps for the first visit to a site. After that it makes no difference.

kevinsimper2• 6 years ago

The EFF is awesome with Let's Encrypt! It was really a dreadful task to buy and renew certificates, especially as out infrastructure back then wasn't that automated.

I think this article is a response to all those ads from VPN companies. They do try to scare people about public WiFi's.

giancarlostoro2• 6 years ago

One thing I would love to see in the future is the addition of LetsEncrypt support for major web servers like Nginx and Apache. I think this could go a long way. In the case of Apache it would be one of those "mod" type of packages. Someone feel free to let me know if this is already the case though, I would love to make note of it.

Edit:

Looks like Apache has one called 'md':

https://httpd.apache.org/docs/trunk/mod/mod_md.html

Your move Nginx? :)

atonse• 6 years ago

Really what we need is what Caddy ended up being. Best practices rolled in as defaults.

That’s why I use caddy just about everywhere that isn’t a load balancer.

zzzcpan3• 6 years ago

One thing I would love to see in the future is the addition of LetsEncrypt support for major web servers like Nginx and Apache. I think this could go a long way.

This is not as useful as you think. In nginx you only need a couple of extra lines of configuration to let an external program issue and renew certificates independently from nginx, without reloads, etc. Definitely not worth developing a C nginx module that starts a helper process that does that just so that a few people who run nginx on a single server could get their certificates issued with only one line of configuration.

mason55• 6 years ago

If you’re running nginx on Nix you can do it with just a couple config settings

seeekr• 6 years ago

What you're asking for already exists. The certbot package already takes care of that [1]. No need to develop anything extra for nginx. [1] https://certbot.eff.org/lets-encrypt/ubuntuxenial-nginx

mping• 6 years ago

Err, no it is not safe unless you trust the app you are running to validate the certificate chain. Not so long ago, I found out my bank's app didn't validate the cert and I could happily put a proxy and intercept all calls.

ben_w• 6 years ago

That’s an interesting point. As an app developer, I’d assumed that would be handled automatically by the OS.

What’s the best way to test for certificate validity? (In my case I’m interested in iOS, but the same concern must exist on all platforms).

VBprogrammer• 6 years ago

Unless the libraries you are using are fubar then you normally have to explicitly tell it to ignore certificate chain errors i.e. requests.get(..., verify=False)

knute• 6 years ago

In my experience, the OS _does_ handle that automatically. If the app isn't verifying it, it's because they went out of their way to disable certificate validation.

Which is alarming.

estel• 6 years ago

On iOS certificates will be validated by CFNetwork provided you haven't disabled ATS.

jeremy_wiebe• 6 years ago

With apps there’s two levels of validation that you can do, and only one is done by the OS.

The most common, and automatic, is the verification of the chain of trust. On iOS this happens automatically if you use the standard network APIs against an HTTPS URL.

You can take it a step further and avoid MITM attacks where the middle party is able to mint trusted certs by doing something called certificate pinning. This is a manual verification that the certificate used by the server you’re connecting to has certain properties that you know match your API server’s.

usrusr• 6 years ago

It's handled by your http client which may or may not be part of the OS or even something in between (speaking of Android, it's probably far more likely to be on the OS side on iOS but if the OS allows raw TCP then it can't really keep an app from running its own http(s) on top of it).

A frequent problem on android that might lead some to throw validation under the bus, is that certificate validation is much less robust than the one in browsers, particularly on old devices. A typical scenario is that the certificate of one of your backend approaches EOL, ops dutifully obtain a new one and it checks out nicely on all browsers. But a whole bunch of older Androids that might make up a quarter of your user base of you are unlucky has never heard of the root certificates involved so the app becomes unusable. A similar situation can arise if you have clients that check revocation (good) but don't check for alternative signature chains like a modern browser would do (not so good).

The correct way to solve these situations is extending the server configuration with another certificate chain that is valid on the devices in question, no doubt about that. But when the app is not a core use of the backend and there server is not run by the same organization, breaching the wall of "but it works in all browsers, clearly the error must be on your side" defense can be quite hard. Nontechnical leadership will be extremely tempted to do the writing thing.

swiley• 6 years ago

While you’re probably not going to be instantly attacked, I still wouldn’t do online banking on a public network.

numpad0• 6 years ago

Every commercial network is a public network in a sense

billyhoffman• 6 years ago

Honest question... why not?

Modern banks use HTTPS throughout. The banks I use all have HSTS and use preloading so no hijacking to a non-HTTPS site. I use a password manager so if somehow I do get hijacked and get sent to a phishing site, and even if that phishing site is using a Lets Encrypt cert to prevent the “Not Secure” banner in a modern browser, my password manager isn’t going to recognize the domain so it would not let me attempt to log in even if I wanted to.

brlewis• 6 years ago

People who think app store approval is a reliable quality gate, please take note.

hannob• 6 years ago

If your app does that then it's not particularly safe over an encrypted wifi either.

The solution is to fix that app, not to rely on a very weak defense that may help you in a fraction of the possible attack scenarios.

tinus_hn• 6 years ago

Good luck fixing your bank app. For a consumer it’s a lot easier to avoid situations where your communication is easily intercepted than it is to change the code of their banking apps.

tootie• 6 years ago

Was that Chase? I read about it a while ago that there was a flaw in the Java API that made it ignore cert warnings by default.

I feel like this needs to be an OS-level requirement. All network comms should be encrypted and any unencrypted traffic needs to be allowed with a user opt-in.

alias_neo4• 6 years ago

A problem I see quite regularly is self-CA is an afterthought, many don't write their software for self-CA and so when people have issues, the top answer is "turn off verification".

Between that, and the number of "important" pieces of software that don't certificate pin, it really rubs me the wrong way.

Many people have no idea that any one of the CAs installed in your browser or device can sign a certificate for any domain and most software won't care.

sneak• 6 years ago

Passive attacks from open wi-fi allowing everyone in 100m range to read your traffic and active MITM are entirely different classes of attacks, with entirely different barriers to entry.

GlitchMr• 6 years ago

Unfortunately, while HTTPS is very common, this isn't really the case with HSTS Preload, so active MitM attacks are still a threat.

moviuro• 6 years ago

Even just HSTS is not widely deployed. Here in France for instance:

* top 1 banking, top 18 FR https://www.ssllabs.com/ssltest/analyze.html?d=labanqueposta... no HSTS

* top 2 banking, top 20 FR https://www.ssllabs.com/ssltest/analyze.html?d=credit-agrico... no HSTS

* top 1 taxes, top 30 FR https://www.ssllabs.com/ssltest/analyze.html?d=www.impots.go... with CAA, HSTS (not preload), OCSP Must-Staple! (that's a surprise)

* top 3 banking, top 45 FR https://www.ssllabs.com/ssltest/analyze.html?d=caisse%2depar... no HSTS

Hopefuly, by 2030 banks will have caught up to the 2018 standard for "secure".

IshKebab3• 6 years ago

I wrote a wifi hotspot app for Android that could MitM HTTPS requests as you suggest about 8 years ago. Even back then it didn't work very well because even without HSTS preload, most people aren't visiting new websites for the first time on your free public Wifi.

Ajedi32• 6 years ago

Yep. Not only is HTTPS stripping still a problem, but active attackers can do all sorts of other nasty things as well, like force the user's browser to initiate plaintext HTTP requests to non-HSTS sites and then use that to steal cookies from third party domains, or achieve persistent XSS by poisoning the user's browser cache. See https://samy.pl/poisontap/ for a great example of that attack in action.

skrebbel2• 6 years ago

refresh my understanding, if i manually type "https" into the address bar, then i can't be MitM'ed through lack of HSTS, right?

detaro• 6 years ago

correct, assuming you don't let yourself get tricked into trying without https.

rovr138• 6 years ago

You could be.

If you are, you’ll get a message that the very isn’t valid.

Unless there’s an attack on cert providers or someone adds a cert to your device.

The cert approach can be seen in some corporate environments.

eximius• 6 years ago

Specifically preload or HSTS?

Because HSTS gets you most of the protection you need while being able to recover if something goes horribly wrong.

Set your HSTS timeout to greater than the gap between user visits and it does prevent active MitM.

You're only unprotected for first time visits being actively intercepted or particularly long gaps where HSTS can expire (both of which are hard targets).

tsukurimashou• 6 years ago

Don't most of public Wifi (airports especially) have their own CA to MiTM SSL connections just like most companies do to inspect HTTPS traffic?

iso16315• 6 years ago

No, because that will simply fail.

I did see it once on a train in the UK, but that's the only time I've seen https MITM.

fulafel• 6 years ago

This only works if your mitm ca is preinstalled in the client device.

Maximus9000• 6 years ago

airports especially

Indeed, lets not forget what the Snowden leaks said about airports:

https://www.cbc.ca/news/politics/csec-used-airport-wi-fi-to-...

IshKebab3• 6 years ago

I've never seen this. They usually just block all HTTPS connections and rely on automatic captive portal detection in modern OSes. Occasionally I've had wifi that had a captive HTTP portal but would allow HTTPS through anyway.

acdha2• 6 years ago

I haven’t seen that in about 15 years: the experience is horrible and will get tons of complaints.

PaulHoule2• 6 years ago

I remember in 2005 when you could just start up Ethereal, run it for a minute, and get many people's email passwords, email, everything...

I think Wi-Fi security is going to be a major FUD talking point for the telecoms as they try to justify high prices, 5G, and the rest of their trip.

5G as it exists now does little to compete with WiFi because (in the millimeter wave form) it doesn't pass through walls. The overwhelming majority of data consumption happens indoors, so it can't make for a revolution in the market unless you get a huge number of antennas and/or cells installed indoors.

That's immensely problematic because building managers aren't going to want to have Verizon, AT&T, T-Mobile and maybe someday Dish Network stomp through their buildings, drill holes, do damage, etc.

There has been talk of wholesale access networks, which would be a great idea (e.g. a neutral vendor installs indoor infrastructure that gets rented by the carriers...) but the carriers are dead set against it.

ozim• 6 years ago

But 5G is not meant for in house consumption. It is meant for crowded spaces like train stations, supermarkets to offload other bands. Then you get micro cells installed indoors inside of supermarkets. (what I mean by supermarket means mall and all those kind of shopping centers)

It is meant also for all kinds of smart sensors in area, but not like home sensors but utilities. We have that with LoRa, but it is really small data amounts, where 5G would be used for sensors that need more data, like smart traffic lights? Then you won't have to connect your old traffic lights to some cable network and they would get good connection capabilities.

Right now 4G is not used everywhere, in less dense areas you only get 3G. Of course providers will install base stations for 5G in places where it is economically possible. Places that have 3G now are not getting 5G anytime soon. It is also understandable that 900MHz is better for longer range than 1800MHz.

PaulHoule2• 6 years ago

5G below 6GHz really requires dynamic spectrum sharing with 4G. Once that is standardized, carriers can gradually switch out 4G for 5G with modest but real benefits.

I was part of a group that installed some radio gear on the roof of the local mall and I can say that the building manager of the mall was a tough customer. It really helped that he liked our (union) electrician and was certain we wouldn't contribute any leaks to the roof.

Carriers used to use the IBEW and CWA and had some standards for the quality of work done. Today carriers tend to use non-union contractors -- some of those people are excellent to OK but some are real idiots that any property owner would want to keep far away.

So far as serious IoT goes I think the coverage problems will still dog IoT. With fiber you can get 100% coverage -- it costs money, but there is no site that can't be served.

Will cell phones carriers will tell you they cover 98% of POPs, when you investigate it might be more like they cover 89% of POPs. With wireless systems you make a rather large capital investment that rapidly erodes in value to get to that 89% coverage but then the cost explodes from there.

theandrewbailey• 6 years ago

Even if a WPA2 wifi point has a password, isn't the encryption key shared among all connections? I.e, if an attacker has the wifi password, it nullifies the wifi encryption? I recall that fixing this was one of WPA3's selling points.

Cogitri• 6 years ago

Not exactly, you need more information than just the WiFi password in order to decrypt the traffic: https://superuser.com/questions/156869/can-other-people-on-a...

mayniac• 6 years ago

As other people have mentioned, HTTPS without HSTS still makes MitM a problem.

And there are still other attacks possible on public wi-fi networks which don't involve MitM-ing HTTP(s) traffic. MitM DNS traffic and you can do nasty things: https://github.com/infobyte/evilgrade

Amorymeltzer• 6 years ago

So when you visit HTTPS sites, anyone along the communication path... can see their domain names (e.g. wikipedia.org) and when you visit them. But these parties can’t see the pages you visit on those sites (e.g. wikipedia.org/controversial-topic), your login name, or messages you send.

I believe this is the reason Turkey blocked the entirety of Wikipedia[0], which was recently lifted[1]. They wanted to block specific pages that revealed negative information (and I believe they did at some point), but when Wikipedia went https only[2] the only avenue was to block the entire domain.

0: https://en.wikipedia.org/wiki/Block_of_Wikipedia_in_Turkey

1: https://wikimediafoundation.org/news/2020/01/15/access-to-wi...

dkarras2• 6 years ago

Am Turkish, and not really. There is no evidence of Turkey caring about what the individual citizens visit (except in case of a crime investigation etc.) Bans in Turkey works like this: Turkey sees something they don't like on the Internet, Turkey reaches the company / individuals behind it (they can be anywhere in the world) and tells them "take it down or we will block your access to Turkish citizens and you'll lose revenue / traffic". If the site owners comply nothing happens. If site owners refuse for any reason, they block the site so it is not accessible from Turkey. In the older days, they used to do it through DNS but it was easy to circumvent. Now they use other methods so changing your DNS isn't enough, but a VPN works just fine.

This was also the case before https wasn't as common BTW. Turkey either didn't have the technical capability to block individual pages (even back then) or they were seeking to punish the site by blocking access in whole.

A site like wikipedia values integrity more so they don't take pages down without good reason. But companies seeing Turkish citizens as a revenue source generally comply. If you browse Twitter in Turkey, it is common to see tweets where it just says something like "this tweet is blocked in your country" - Turkey reaches twitter to mark the tweet invisible and that individual tweet goes away. IIRC it also applies to entire profiles - I'm not a frequent twitter user but I remember seeing entire profiles blocked by country.

frandroid• 6 years ago

The parent post didn't mention individual citizens.

duxup• 6 years ago

I feel like asking the site to take something down ... is effectively caring about who sees it. Otherwise you wouldn't do that.

danShumway• 6 years ago

But these parties can’t see the pages you visit on those sites (e.g. wikipedia.org/controversial-topic)

This is... not entirely wrong, but overly simplified. My impression is that TLS fingerprinting is sometimes-to-often good enough to figure out which exact page of a static website that a user is visiting[0].

That's not to say TLS is useless, or that the fingerprinting isn't hard enough that some adversaries won't just give up, it's just that the protections are more complicated, and it's not quite as simple as just saying, "I have TLS, I'm fine."

[0] http://rabexc.org/posts/guessing-tls-pages

air7• 6 years ago

I think jumps the gun a little.

When sharing a network, there are other attack vectors into people's unhardened laptops except browser MITM. Do you have any unprotected shared folders? Can someone brute force your login via RDP? Can you account for all the listening ports running on your device?

A NAT provides strong protection by simply firewalling you from the outside world. It's so common that the focus (rightfully) zoomed in on MITM as that is the only thing "left", but in a shared network, the adversary may reside on the inside nulling that protection. Most users have not taken precautions against this.

Oh, and shoulder surfing.

Kocrachon• 6 years ago

Yeah this article is only covering a specific attack vector, to claim that public Wifi is nearly risk free because of HTTPS is a very dangerous statement to make. The risk of public wifi was far from just having your traffic spied on.

gruez2• 6 years ago

Can someone brute force your login via RDP?

probably a non-issue since it isn't enabled by default.

Can you account for all the listening ports running on your device?

that's what firewall (which are typically default deny for incoming) is for.

reaperducer• 6 years ago

Do you have any unprotected shared folders?

It's surprising how many people have unprotected shared folders. And for some reason they very often are full of music.

Spend a few days on a hotel's wifi and you can slurp up thousands of other people's MP3's.

JohnFen3• 6 years ago

They're talking exclusively about web browsing, though. There's more to net access than the web.

Personally, I just always use a VPN (and a firewall to ensure that no traffic flows except through the VPN). Then I don't have to worry as much.

EduardoBautista• 6 years ago

HTTPS is not limited to web browsing. It's also how the vast majority of desktop apps communicate on with web servers.

logicallee• 6 years ago

Isn't domain information still in the clear? (What specific domain you're connecting to.)

tialaramex4• 6 years ago

The exact hostname is delivered in SNI (serverNameIndication) during connection yes. Figuring out a safe reliable way to encrypt this data is an ongoing work item for the TLS Working Group after TLS 1.3 wrapped up. If you have a recent Firefox (possibly only in Nightlies?) you can see one possible approach work with Cloudflare sites which opted in. You will also need encrypted DNS (DPRIVE e.g. DNS over HTTPS) or it's largely pointless.

gwbas1c• 6 years ago

I still http-only links on Hacker News regularly.

saurik4• 6 years ago

But these parties can’t see the pages you visit on those sites (e.g. wikipedia.org/controversial-topic), your login name, or messages you send. They can see the sizes of pages you visit and the sizes of files you download or upload.

Given the pattern of sizes of data you request, one can do seemingly-amazing things such as figure out what area of Google Maps someone is looking at based on the visible map tiles or figure out what movie someone is watching on Netflix based on the MPEG fragments or guess what article someone is reading on Wikipedia based on the pattern of requested media files. Note that these are each practical attacks that people have implemented; I have also seen a strong argument for a type ahead search attack based on the sequence of search response sets but I don't know if it has been implemented and it feels harder to pull off reliably.

sp332• 6 years ago

It's only a little more data than an passive attacker would have with encrypted wifi.

saurik4• 6 years ago

That's an interesting point, but because browsers decided not to use HTTP/1.1 pipelining and encrypted SNI is still only an optional thing in TLS 1.3, the clean signal you get from the separate connections, each of which is tied to a hostname, makes these attacks extremely cheap and "practical" in a way that isn't quite as true when you are dealing with commingled data from all of the user's simultaneous connections, many of which might be to the same host; like, seeing "the user requested 32 map tiles with these individual sizes" is very different from "the user requested a bunch of map tiles--maybe 32ish--and they total in size to this amount... that or they are watching a YouTube video". This article might be a lot more valid once the web has upgraded to HTTP/2, particularly if it manages to adopt encrypted SNI.

kelnos• 6 years ago

Sure, and if you're under a repressive regime or have reason to think that someone is targeting you, you should probably still avoid public WiFi (and take a bunch of other countermeasures as well). But for the majority of people, who just care that their banking info isn't compromised (etc.), public WiFi is fine.

saurik4• 6 years ago

And if that is what the article said, I wouldn't be annoyed; but it went out of its way to claim that people wouldn't know what pages you were visiting, and that's a naive misinterpretation of what encryption is buying you.

jancsika• 6 years ago

Hm... is there some kind of transit quantization plugin for a VPN like Wireguard? Like maybe data is sent in blocks of small, medium, large, or none.

saurik4• 6 years ago

I haven't integrated support for this yet, as I am still working out how I want to best handle the return path, but I definitely am going to be getting this feature into Orchid in the near future.

maltalex• 6 years ago

Even if HTTPS is deployed, and even if the client actually verifies the certificate, untrusted networks are still risky.

There are many attacks against HTTPSs itself (e.g. DROWN [0]), bugs (like the Windows 10 crypto bug [1] from just a couple of weeks ago), irresponsible CAs (e.g. symantec [2]), and hacked CAs (e.g. DigiNotar [3]).

Are things better than they were before Let's Encrypt? Sure. But is the advice against public Wi-Fi out of date? I don't think so.

[0] https://en.wikipedia.org/wiki/DROWN_attack [1]: https://techcrunch.com/2020/01/14/microsoft-critical-certifi... [2]: https://wiki.mozilla.org/CA:Symantec_Issues [3]: https://en.wikipedia.org/wiki/DigiNotar

diebeforei485• 6 years ago

VPN companies have been using the "omg public wifi scary" meme to market their products. I agree with EFF here.

3xblah• 6 years ago

"So when you visit HTTPS sites, anyone along the communication path - from your ISP to the Internet backbone provider to the site's hosting provider - can see their domain names (e.g. wikipedia.org) and when you visit them."

Except wikipedia.org does not require SNI.

Most HTTPS sites do not require SNI.

Not every client sends SNI by default. OpenSSL's s_client does not. There are others.

    printf "GET /wiki/MediaWiki HTTP/1.1\r\nHost: en.wikipedia.org\r\nConnection: close\r\n\r\n"|openssl s_client -showcerts -connect mediawiki.org:443 -ign_eof

Some sites "require" SNI, but then do not check it against the Host header. A client can send any SNI.

    The server certificate says *.wikipedia.org.

But there are numerous websites sharing the IP addresses for wikipedia.org, not all of them serving Wikipedia content. One example is mediawiki.org.

What if a website padded all its pages to be the same size.

badrabbit• 6 years ago

What is up with these b.s posts about open or public wifi being safe this week? A few days ago there was a twitter thread by a security person at a hotel claimig their open wifi is safe.

I won't detail all the many harms you can suffer (or the threats that will readily cause you harm),but let me state just one argument related to eff's silly (and dangerously harmfull ) statement here:

1) when you type in a domain in your navigation bar, your browser attempts to connect to unencrypted http(port 80)

2) if (big if!) The site supports https it will do an http 301 redirect to the https version of the site.

3) An attacker needs to intercept just one such redirect to have an opportunity for credential theft or content injection (downloads,exploits,etc...)

3) your browser does indeed remember these redirects going forward,which is great.

4) Except if you configured your browser to forget all history. Or if you happen to remember a site you visited a while ago (perhaps on a different device) and just typed it in to navigate. Or if you typed in something to search but your browser navigates to it,or many other opportunities for pwnage!

5) you don't care about that? Well attackers are happy to setup a malicious captive portal(captive portal checks are plain http for all browsers I know of) and use that directly or to social engineer installation of an app you "need" to connect (oh,mitmproxy has a nifty captive portal like page you can customize to install a CA cert on the device for TLS interception)

I won't even begin to talk about at least half a dozen additional classes of MITM attacks that can be used, even with wpa3 and client isolation! What you have to understand is that vulns that would normally be low severity are amplified in this sort of a network, due to the sheer magnitude of threat exposure.

I can't complain about most people being ignorant to good infosec practices(we have to understand+educate) but man this stings! The eff makes one of my favorite extensions HTTPSEverywhere, how can they post this? It takes a long time to educate people about good security practices.

oliwarner• 6 years ago

This seems like weird advice to give out.

Sure, it's not as dangerous as it was... Or is it? All the tools are mature now. Documentation is rife. A seven year old with a Raspberry Pi can set up a hotspot and spike your DNS. This thread contains a litany of security papercuts across the whole stack. DNS, shitty apps, crappy server configs and sites that just don't care.

So yeah, it's no 1999. You're probably not getting your FTP password sniffed off a public network these days, but there are still plenty of reasons for me to use 4G or WireGuard instead of trustless networks.

Public Wi-Fi will remain firmly on my "list of things to worry about" until I can audit all traffic from my devices.

pvtmert• 6 years ago

tl:dr;

  "You would be safe in active war-zone (eg. syria) because you are civillian and do not carry any weapons with you"

No, you are not safe at all. Lets assume public wifi requires acceptance of terms and conditions.

- Redirects all pages (from your Mac/Ip address) to their server

- There is checkbox on the page for ToS/ToC approval and 'Continue' button

- Behind the scenes clickjacking/framebusting happens [0]

- You get PWNd or monetized.

- also being fingerprinted by company. eg: amiunique.org

Given conditions, they can inject ads/cookies to track you even after you go away. (eg. at home)

[0] https://blog.innerht.ml/google-yolo/

Advice to avoid public Wi-Fi is mostly out of date

Related Stories