mkipper
Joined 7 years ago
Joined 7 years ago
But this exploit shows that it's still almost impossible to protect yourself from motivated attackers with local access. All of that security stuff needs to get initialized by code that the SoC vendor puts in ROM, and if there's an exploit in that, you're hooped.
I work with a a decent number of Americans who either moved here or are here temporarily, and I can't say there has been any tension. I think most Canadians who are staunchly anti-US are also aware that plenty of Americans aren't happy with their government. I can't say I've seen any vitriol towards the average American person.
Google has been working on Fuschia for a decade, and far as I can tell, the only place it was ever deployed was to a Google smart home hub 5 years ago. The only Fuschia news I've heard since then was about layoffs and killing projects related to it (e.g. Chrome on Fuschia).
If Google isn't moving any of their own phones over to Fuschia after a decade of work, it's hard to imagine them unilaterally flipping Android to it and forcing the hand of every Android OEM to follow suit.
My wife is a speech pathologist and hooked me up to a DAF machine for some research, and the effect was totally shocking to me as a layperson. I think I did worse than average, but I was basically unable to speak with delayed sidetone.
Your API is constrained by the actual TCP protocol. Even if the sender uses this message-oriented TCP API, the receiver can't make any guarantees that a packet they receive lines up with a message boundary, contains N messages, etc etc, due to how TCP actually works in the event of dropped packets and retransmissions. The receiver literally doesn't have the information needed to do that, and it's impossible for the receiver to reconstruct the original message sequence from the sender. You could probably re-implement TCP with retransmission behaviour that gives you what you're looking for, but that's not really TCP anymore.
This is part of the motivation for protocols like QUIC. Most people agree that some hybrid of TCP and UDP with stateful connections, guaranteed delivery and discrete messages is very useful. But no matter how much you fiddle with your code, neither TCP or UDP are going to give you this, which is why we end up with new protocols that add TCP-ish behaviour on top of UDP.
You can argue about "the expectation" of privacy all you want, but this is completely detached from reality. My assumption is that almost no third parties I share information with have magic immunity that prevents the information from being used in a legal action involving them.
Maybe my doctor? Maybe my lawyer? IANAL but I'm not even confident in those. If I text my friend saying their party last night was great and they're in court later and need to prove their whereabouts that night, I understand that my text is going to be used as evidence. That might be a private conversation, but it's not my data when I send it to someone else and give them permission to store it forever.
I last used it for an embedded project, which are sometimes a pain to set up in an IDE (cross-compiler, sysroot, debug server, etc.), and I was shocked by how easy it was to get going and how smooth it felt compared to most IDEs.
So I don't think you're alone feeling this way. Even with a good foundation in the theory and math, I think most people hit a wall with radios at some point. All the people I worked with who intuitively "got" RF stuff had been doing nothing else professionally for over a decade.
Sure the switch will only accept encrypted L2 traffic...but that encrypted link is set up via MKA, which is a part of the 802.1X standard. If you don't have 802.1X authenticating the endpoint, you don't have MKA setting up the encrypted link between that endpoint and the switch and you don't have MACsec.
So if you're trying to prevent a bad guy from getting on your LAN, you need 802.1X, whereas MACsec is an optional extra (a very useful extra if you're worried about MITM attacks). But 802.1X is still doing the heavy lifting w.r.t access control.
I remember playing Myst as a not-particularly-bright grade schooler and banging my head against puzzles for weeks without making any progress. It wasn't some great intellectual challenge -- I was just bored and didn't have any other games to play. I can't imagine I would have stuck with it if I could have watched YouTube or played Fortnite instead.
If I remember right, handling SNMPv3 traps required some messy key stuff so the agent still sent SNMPv2 traps, but there was no requirement for keys for GET/SET.
If I buy a tool and damage your property with it, you can sue me, not the tool manufacturer. If I think the tool malfunctioned and led to that damage, I can sue the tool company to try and recoup the damages I had to pay to you. Both parties can be liable for different things.