Google QUIC-ly left privacy behind in its quest for a speedier internet, boffins find Google's QUIC (Quick UDP Internet Connections) protocol, announced in 2013 as a way to make the web faster, waited seven years before being implemented in the ad giant's Chrome browser. But it still arrived before privacy could get there. A trio of researchers from China have found that QUIC is more vulnerable to web …
Don't forget the American government... Internet Engineering Task Force (IETF), which let's face it, USA gov. is the only reason QUIC exists.
It's very odd to me that people CHOOSE to use Google anything, similarly to how it's odd that people CHOOSE to pay taxes.
You can't really avoid paying taxes (unless your name is Donald J Trump) but you can avoid using google directly.
Starve the beast of information on your good self. Don't give it willingly. Make them work really hard for it.
The same goes for all so-called social media platforms.
Avoiding using Google directly only ignores a small percentage of its ubiquity. It's bloody hard to avoid it indirectly because so many sites use it for search, mapping and location lookup which simply don't work if you block Google across the board. You could still not use these sites, of course, and let them know that Google has lost them a customer, but some of them only allow allow direct contact through social media, so you'll need an account to complain.
The web's tightening.
Actually, this is the type of privacy that Google is very enthusiastic about: the kind that prevents your ISP from knowing what you do. They generally go to great length to encourage that kind of privacy, because then they are the only one who can spy on you...
sod off google. We know your game. You want us to get hooked on your stuff just like hard drugs.
Just say no to Google in each and every way you can.
Perhaps (who am I kidding) when you start to pay each country you operate in, its proper amount of business taxes you might get a bit more sympathy.
Oh, and while you are at it sort your own staff policies out. Those lawsuits you are getting his with could prove very expensive. Treat your workers properly and you will get more respect from the rest of us. Amazon should do the same.. in fact, they are worse, far worse.
Yeah, well, maybe, nice rant and all, but QUIC is an open standard and in no way exclusive to Google.
For example, one of the co-chairs of the QUIC working group is employed by the BBC. Another by NetApp. The third one works for FaceBook.
The story isn't really about how Google can monitor your internet usage, they don't need QUIC for that if you are using Chrome and signed in with a Google account then your already sending them all the data they need.
Its more how your ISP or authoritarian government could use it to finger print you, and considering this research was done by some people from China they probably have more to worry about the rise of QUIC compared to HTTPS than the rest of us.
"Its more how your ISP or authoritarian government could use it to finger print you, and considering this research was done by some people from China they probably have more to worry about the rise of QUIC compared to HTTPS than the rest of us."
And yet, they published. Or were allowed to publish, depending on your point of view. So either the Chinese spooks feel it's not useful or have something better.
And yet, they published. Or were allowed to publish, depending on your point of view. So either the Chinese spooks feel it's not useful or have something better.
Or the spooks allowed the publication because they thought it was an anti-Google piece of research.
So the attack accuracy on HTTPS is 33% then, as "73% higher" is meant in its usual sense; 1.73 times 33 is 57. Some people would say that 57% is only 24% higher than 33%, because they would want to use the same base for the difference as for attack accuracy on QUIC so as to stick to addition and subtraction instead of multiplication.
"Some people would say that 57% is only 24% higher than 33%, because they would want to use [...] addition and subtraction instead of multiplication."
They are allowed to do that if they want, but only if they use the right words. Those would be "57% is only 24 percentage points higher than 33%". If you say X is Y% higher/lower/of Z, it means multiplication and it always will. If you don't do that, you get this XKCD.
"I would argue that you should never use percentages to indicate an augmentation or reduction of a number which is itself a percentage. If you say "50% higher", it can mean from 2% to 3% or from 66% to 99%."
That's a problem with percentages in any use case. 50% could also be the difference between two units and three units or 30000 and 45000. It's a tool for multiplicative comparison, whether it's a rate or an amount, you can use it badly. And yes, there's an XKCD for that too. If you don't like that lack of clarity, don't use percentages for comparison.
The Internet Protocol stack has been around for a generation or more so most people take it for granted and never look closely at what's going on in it and why. TCP in particular has always been a bit of a mess, its improved a lot since its earliest incarnations but its still grossly inefficient of both computing and network resources. Once you add FTP type protocols on top of TCP -- which is what HTTP and its derivatives are -- then you compound the inefficiency by superimposing a pretty naff datagram protocol on top of a full duplex stream protocol (which in turn is superimposed on a datagram protocol). All that Google has done is cut out the middlemen but putting the HTTP like protocols directly on datagrams (i.e. UDP). Whether or not a UDP based protocol is easier to track than a TCP one is a trick of the protocol light and could be easily dealt with if it were particularly important.
One of the side effects of the abstraction libraries used by applications programmers is that they're really no further on than just grabbing a socket of a particular type, opening a connection and sending data. They never question what's going on under the hood -- they send data and time out replies, they don't bother with framing (you'd be surprised at the number of programmers who send a block of data into a stream (TCP) socket and expect the identical block to turn up at the listener -- the fact it often does causes them to think that if it doesn't then its a bug rather than inherent property of the protocol). The problems caused by bad handling of network data are rife over the Web and are only less obvious becuase of the consistend over use of resources.
Anyway, I think Google's being sane and rational. Feel free to generate your own deep, dark, conspiracy. At least I know how the thing works.
I am old enough to remember the pre-Internet circus getting things to communicate - every manufacturer had its own networking stuff so it was NEVER fun, and at times not even worth the effort.
Criticising TCP cause it's not perfect without acknowledging the great service the Internet has done humanity is unfair.
The fact that it became possible to connect just about anything with anything in a way that works pretty well is amazing - start bundling all sorts of things to get efficiency may just be the road to complexity hell.
The principles of the "dumb network" and the UNIX "do one thing and do it well" are best no forgotten
"QUIC attack accuracy can reach about 95 per cent with only 40 packets and Simple features, compared to about 60 per cent attack accuracy for HTTPS "
So, the takeaway from this is that HTTPS has a 60% chance of revealing what you're doing, and QUIC is worse than that.
Bad news all around.
Google is banned in China. QUIC is not banned in China. QUIC is an open standard, which can be run by anyone and impacts others. People will research new technologies like that. The research doesn't claim that Google did this deliberately, and they probably didn't, but still points out a vulnerability. It doesn't seem in any way an attack on Google.
As noted above, this doesn't help Google to spy on you; rather it helps your government and your ISP to spy on you. It's not even in Google's interest, because it helps their competition — and indeed, Google is usually all interested in making your connection secure with DNS-over-HTTPS, because it screws ISPs.
Let me make sure I have this right: You can use QUIC fingerprinting to "infer" which websites a target is accessing, with 57% accuracy? Big deal... I can identify the website a target is accessing with 100% accuracy on HTTPS over TCP, because the domain name is printed at the head of the HTTPS connection in plain text! The reason it's there is so that the software on a shared hosting server knows which site to route the incoming connection to. I have been successfully using this for years to detect streaming video traffic over HTTPS using an L7 filter so it can be prioritized with QoS.
----------35.244.247.133:443 outgoing HTTPS data dump----------
..C-.3.I.$h....Q... 8.:.U..>.. ..p.P9T....gK.*.((..%z..N_.SY.....+./.....,.0.
. ........./.5........#.!...incoming.telemetry.mozilla.org..........
----------172.217.7.238:443 outgoing HTTPS data dump----------
............].....{..=.%...&2...'....n.5..T )..m.x......nAAg...Ry0*..<.7.Z..$.......+./.....,.0
....../.5.......www.youtube.com.................................#.........h2.http/1.1...
---------------------------
See?
ESNI
https://blog.cloudflare.com/encrypted-sni/
Of course, with servers hosting only one or two sites, you can just look at the destination IP address, which is also why the original unencrypted scheme was no less secure than when you had one site per addr:port
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
