Anybody remember the way Blackberry handled this before proper push messaging? The data connection was completely dead, they just got the mobile companies themselves to do it over the phone call connection (SMS?) to indicate when there was something to read at which point the data layer came up. Really efficient in those days, except you obviously paid a fee for 'Blackberry service'
Had a 6th gen for nearly 2 years running Fedora. Typing on it now, love it. A couple of points.
1. There's a couple of things to make it Linux friendly - TLP, plus the throttling fix. Even though I use Fedora the Arch Linux wiki is superb for this.
2. BIOS updates are done via software update which is superb.
3. The FN/action keys are the wrong way round, just change it in the BIOS.
4. Same goes for Fn/Ctrl keys - they can be swapped too in the BIOS.
5. Screen is beautiful. I've got the HDR one and it's brighter than any Macbook i've been sat next to on the train.
6. Never got the fingerprint reader or NFC to work, but i've not tried for a year tbf - this may be fixed.
7. Speakers are complete shite.
8. Keyboard is the best you'll get on a laptop this size, it's wonderful.
9. 2x USB-C/Thunderbolt is awesome. Only thing about the XPS 13 I use for work is that the USB-C is on both sides unlike the Lenovo, makes it easier to get a charge cable round.
I honestly love this laptop, even after 2 years I don't see the need for a upgrade.
What sort of battery life do you get on Linux, and how fast are you expecting the battery (batteries?) to degrade?
I tend to always try and find laptops with easily replaceable batteries (I've a t440s right now that I'm looking to upgrade), but the ultraslim things like the X1 look like it's a bit of a challenge, which puts me off somewhat.
I think around 8 hours from 100% to turn off. Bear in mind the battery is 2 years old.
I don't tend to have the screen too bright (live in the UK), Bluetooth disabled etc. Also I spend most of my life in Firefox / SSH / VSCode in that order.
Interesting, thanks. I've apparently got "1:47 (53%)" remaining right now, and that's with a 6-cell slice and 3-cell built-in battery. That's just with Firefox and Citrix open.
I seem to suffer pretty badly from battery anxiety, so 8 hours is a bit of a dream :)
I've just read all the comments here, it's a roller-coaster ride but is exactly what I saw with my self-hosted GL.
Each new release there'd be a new release with great new features - yay! - followed by 3-4 patch releases to fix the bugs. You eventually get worn down by it and don't bother using these things.
I see the same with other dual licensed stuff. Kong is a good example - bugs that actually stop routing traffic are eventually acknowledged, but with no feedback unless I keep chasing them. However i'll get regular emails with new products. They've got a new Service Mesh they announced recently. There's not a chance in hell i'll use it until they fix the bugs/issues i've reported in the core product.
Wasn't it 6 years ago when Snowden made public his revelations and Google said 'nope' and encrypted the lot? Who now sends traffic over these links and doesn't encrypt them?
So, what value do the SA government have in intercepting these links now?
There were plenty of small samples in the various Snowden powerpoint slides of stuff NSA incepted from the pipes.
It seems a ton of mobile apps are sending information with identifiers over HTTP (the ID is a key part for them legally to pick it up and store it in a DB, forever). I notified one developer that was sending real-time GPS data + an email address highlighted in one of the PPT slide's (just a screenshot of a spreadsheet-like table) and never got a response from the developer. It was a small Canadian company with an app with a few million downloads, so I told Citizenlab about it (don't remember the name, had something to do with sports IIRC).
This is a chart of TLS traffic sent via Chrome and across Google:
2019 = 94% of traffic encrypted for Chrome users which is great.
Linux users currently have the lowest when using Chrome with 86%. I'm curious why this is.
Again mobile apps seem to be the biggest problem right now and there was no red HTTPS sign when they sent your sensitive information over cleartext:
> Mobile devices account for the vast majority of unencrypted end user traffic that originates from a given set of surveyed Google services. Some older devices cannot support modern encryption, standards, or protocols.
Maybe Google PlayStore should start punishing apps for not using HTTPS? Just like how Google is trying to make the internet faster by ranking performant/mobile friendly sites higher.
The app testers should put fake identifying information in the various app forms + automatically measure the outbound HTTP traffic for cleartext versions of the IDs.
>> Linux users currently have the lowest when using Chrome with 86%. I'm curious why the is.
They probably browse quite a few old sites for documentation and tooling that are just not updated for HTTPS. A forum I post on to this day is still served over plain ole HTTP and they have no interest in changing.
Not always true, if you message them directly and ask them nicely they'll switch to https. I've even messaged a few to switch from TLS 1.0 to 1.2 as it will be soon obsolete.
About 80% of those I asked switched so I am calling it a success, especially compared to companies, I barely get a positive/any response there.
Android is separate from Linux in the report. Developers and tech people make up a significant (if not majority) share of Linux users.
A lot of popular Linux and developer related pages are HTTP only. I did a quick Google search for some Linux related tasks, and found plenty of sites that don't use HTTPS. e.g. man7.org, linuxhowtos.org, linuxcommand.org
The report does break down HTTPS traffic by country, and you're right that lower income countries do have a lower share of HTTPS traffic.
> Linux users currently have the lowest when using Chrome with 86%. I'm curious why this is.
This doesn't surprise me when you consider that package management over HTTP is considered ok since it's separately authenticated and verified is a very common view
That this view would also spread to not requiring HTTPS on documentation and other sites would also not be surprising
The Linux world really needs to get it's act together with providing confidentiality via SSL/TLS
I'm curious about stats for iOS, with its app transport security being enforced for store submissions. There are exceptions, but I certainly hope that Apple is verifying that those are actually necessary before allowing them. I'd love it if Apple took a step forward and warned periodically for http use (similar to how it periodically reminds you that apps have location permissions).
Aside: I know at least for some orgs, ATS was helpful in convincing the older 'why isn't http good enough?' folks to finally get their act together. It may be shocking, but some people are quite resistant to typing in that extra 's'.
If I develop web endpoints, I usually use http until I know the target domain and have acquired the needed certs. In a lot of cases this is one of the last steps in deployment.
>Modern IRC servers tend to support TLS on port 6697 and SASL for authentication.
The OC's point was by default, meaning/inferring clear-text is still the modus operandi for generally getting onto IRC services.
>Many applications still aren't encrypted by default, like IRC.
SSL and SASL aren't, precisely, user-friendly implementations with some clients (e.g.: IRSSI[0] - but if you're using IRSSI, you don't want a user-friendly GUI to begin with, so...).
SASL has less to do with the actual encryption mechanism and more to do with the authentication mechanism (think NTLM)[1].
If IRC services dropped clear-text, today, that would go a lot further to standardising (e.g.: making default) encryption but, back to the OC's original point, it is not the default today.
This is mostly irrelevant; users using Web IRC gateways, services like IRCCloud or clients like HexChat[1] do not have to configure the server unless it isn’t already present in the list. If they do, they already will have to manually configure either TLS or plaintext. There is no “default.”
I mention SASL because it is relevant to security posture, especially if the user wasn’t connecting via TLS. Although of course the server could allow PLAINTEXT in practice there’s no point in supporting that because IRC already had native plaintext server authentication.
Majority of email traffic is by now for sure use s2s encrypted. Also considering how big major players are most of mail never leave Google / Microsoft / etc servers anyway and connections between them always only ever go over TLS.
Almost all of the SMTP over TLS will be opportunistically encrypted only and usually with pretty bad protocol / cipher choices.
It probably means your email to your aunt isn't intercepted and shoved onto an enormous pile of decrypted email to be parsed for keywords. Probably. But that's about all.
Against an adversary determined to intercept:
- They can probably just strip STARTTLS, so that everything happens in plaintext
- Even if they can't do that because of MTA-STS or similar, they can probably just present self-signed certs and it'll pass the mandatory checks
- If they can't do /that/ either (no idea what proportion of email but it may well be in the minority) they can downgrade because unlike in HTTPS nobody is just saying "Old garbage bad, never do that or we'll scream" and so people keep doing it. SSLv3 may even work with a lot of mail servers.
Still, what we have now with opportunistic SMTP encryption is equivalent to what you get with snail mail. The spooks CAN read anybody's mail, but it's a hassle so they mostly don't read yours.
They're a lot better than I thought! (over 90% in each direction, although no data here about certificate verification and the presence or absence of backbone downgrade attacks)
If you run your own mail service, check out my colleague's project at
I was just about to post the same link. Outside the US the numbers are a lot lower. Outbound to some countries is 0%. South Africa wasn’t in the report though.
Who now sends traffic over these links and doesn't encrypt them?
Remember that the intelligence agencies don't only want today's data, they want yesterday's data. You get yesterday's data by storing it today. Then you can decrypt it at your leisure, or when computers become powerful enough to break through.
I know a lot of people on HN earn a living making sure internet traffic is encrypted. But honestly, I really believe there are multiple TLA's that can decrypt whatever they want in real time. Maybe not en masse, but certainly targeted streams.
How do you think they're decrypting in real time? Do you think there are backdoors in the crypto/protocols? Severe accidental flaws? How many times a speedup are you imagining?
State of the non-TLA art is that modern https is completely impractical to break, even with enormous server farms working for years, let alone in real time.
I have no idea how they're doing it. But I believe it can be done simply because the intelligence agencies have the best, largest, fastest, most advanced machines that money can buy. Machines that none of us have even heard of, that are years ahead of anything any of us will ever touch in our lifetimes.
Back of the envelope, to see scale: to brute force SHA-256 you need to try about 2^255 combinations, so you'd need to have 2^194x (1,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000x) the hashpower of the Bitcoin network (80 EH/s).
If you told me you thought they had cracked a common algorithm so they could do it in only 2^60 time that would at least be plausible. But the idea that they have hardware to straight up brute force it, though, is just impossibly wrong.
You literally can't brute force SHA-256, there's a very tiny physical limit on the amount of energy it costs to flip a bit of information. Turns out that, summed over all the possibilities, that adds up to way more energy than is in the entire solar system.
That image is a shows an NSA diagram of Google's network, with the links on the "public internet" side labeled "SSL" and on the "Google cloud" side labeled "clear text". You don't have to steal keys to exploit that, you just need physical attacks against the fiber links between Google's datacenters. Google had been working on encrypting that traffic, which was then massively accelerated when they learned it was being actively exploited: https://arstechnica.com/information-technology/2013/11/googl...
My pet conspiracy theory is that at least some large governments have quantum computers of useful strength.
It's probably more likely that they're just trudging along with side-channel attacks, CA fuckery, breaking into servers, and doing targeted attacks though. Cheaper and likely works well enough.
Yeah, zero days, phishing and coopting servers to send exploits to specific targets are what I meant by targeted attacks (and some of those overlap).
You're probably right on the quantum computers of course, but I like comparing it against what was publicly know about say cryptanalysis vs what the NSA knew in the DES days, and also similar situations in the ww2 days.
> Machines that none of us have even heard of, that are years ahead of anything any of us will ever touch in our lifetimes.
That's a pretty bizarre thing to believe. Who is building these machines? Intel? No other organization within the US has the lithography capabilities to manufacture cutting-edge computing hardware, much less "years ahead of anything any of us will ever touch in our lifetimes". Perhaps it's aliens?
In addition to what the other replies are saying, there's a lot to be gathered from metadata alone, even when the bulk of the data is encrypted. Knowing who is talking to who and at what time is difficult to mask and quite valuable information.
It took well over a decade for this acceptance to go from "conspiracy theory" to common sense in the tech community, and patches of cognitive dissonance still remain. What makes you think that opsec has adjusted so quickly, especially with nowhere straightforward to go? Consider that metadata-spewing HTTPS still passes for security.
