621–630 of 799 posts
Earlier quoted context omitted.
If you live in a democracy, you already do run your own country. Vote accordingly. Get involved in politics.
The problem is democracy and capitalism are incompatible, so that "if" is doing some really heavy lifting.
Earlier quoted context omitted.
Look at the last 30 years of computing history? When online banking was first created it was an absolute chaos zone. Everyone was accessing it from desktop machines riddled with viruses and malware. There are endless stories of being discovering their life savings had been wired to Belarus by some malware running on their machine that had grabbed their banking credentials when they logged in. https://www.google.com/s…
> Secondly, it's a lot more convenient to use a device that's always with you than a dedicated standalone single-use computer. The price the owner pays for this is that they're locked out of their own expensive general-purpose computing device while still having to bear all the inconveniences (babysit OS updates, configure stuff, keep it charged, have the battery fail, buy a new device every five years, etc.) In the…
Sometimes I see people captured by the train station unable to check out. They usually find someone with a charger but technically the formula is to fine them for not having a ticket. Then one might still need to buy a ticket to continue the journey. (bring cash)
Phones are usually empty when things [already] aren't going as planned.
Earlier quoted context omitted.
Yes, but that’s not the threat model I was alluding to. The threat model was, you get tricked into executing malware, that will steal your passkey (and your entire password database in fact), and log your master password as soon as you use it. When the passkey is protected behind an HSM (TPM, Yubikey, Tkey…), even a compromise of your main computer can’t steal it. Attackers can still temporarily log in on your behalf…
Yes, I agree that device-bound credentials (DBC?) are a really big deal here. Just wanted to get the story straight. When it comes to the notion of requiring DBCs without also requiring remote attestation, how do you deal with solving the problem of virtualized credential devices, e.g. swtpm? If some application wants to leverage DBCs, it will make some DBC API call, e.g. call out to a TPM. However, without some sort…
It’s definitely something I would want, but as you hinted at yourself, if there’s no remote attestation, the user can just use a software TPM. So, a company using passkeys has two choices:
- Enforce DBC with remote attestation. This raises the security floor, but enforces device vendor lock-in, and prevent users from selecting unapproved, but potentially even more secure, devices.
- Do not enforce DBC. This lets users use less secure virtualised devices, but there’s no vendor lock-in, and those who want may use the latest most secure device ever.
Which alternative is appropriate is now a social & political problem. My opinion is that for general computers released to the general public, remote attestation is never legitimate. Even with the best of intentions it is fundamentally uncompetitive, and they make it way too easy to go full Evil Corp. Specialised appliances and employees however are different stories.
---
Anecdotally, I have worked on TPM provisioning a couple years back, and I had to warn my hierarchy that doing it the way they specified, the TPM could be impersonated: we checked the signature of the certificate, but failed to compare the certificate root with the manufacturer’s keys. My boss didn’t believe me, until I showed the production code happily provisioned a software TPM, without detecting the impersonation. (Actually, he didn’t believe me even then, I had to go over him to the security specialist.)
This was totally a case of remote attestation. But I believe this particular case was legitimate, because it was a specialised appliance (electric car charging station), that was meant to process payments, similar to a gas station terminal.
Earlier quoted context omitted.
Never spent money on an app on my phone.
You still suffer, because developers who don't want to pay the Apple tax on their apps simply avoid the App Store. You have no access to many good apps at all. Including FLOSS.
The only things I’d really miss on a phone ecosystem is like, game emulation and some more esoteric network data/file management functions. These are things that are almost inherently outside the range of interests for the vast majority of people and the main reason they’re restricted is because they’re so piracy adjacent that it’s basically impossible to extricate them from association with a whole bunch of technically illegal use cases.
Little wonder then, that both the App Store proprietor AND App Store vendors would have an interest in locking those out to maintain the health of that platform as a viable place to run a business through.
The superhuman efforts that folks on HN make to find technical workarounds and solutions is wonderful to see, but we must realize that this is not a technical problem. It's a social and legislative one. It can't be fought on technical grounds. The push back has to be via putting pressure on politicians by making regular people more aware. Right now, the vast majority of users are being bombarded with a one sided narr…
> In my experience, once the issue is framed as 'Google will decide what you can do with your phone' every single person is immediately outraged. Apple already does this and practically no one is outraged
Earlier quoted context omitted.
DRM is a technology and is inherently evil. Web attestation is DRM for the web, and is inherently evil. Age ID is a technology and is inherently evil. We have over 30 years of the world wide web and for these more than 3 decades this was never a problem. Suddenly, we "need" to create new technology that seem to be security features, but are essentially just being used for evil, thus being inherently bad. It's not lik…
DRM is arguably a specific use of various generic technology ranging from whitebox cryptography to trusted computing. I don't think remote attestation (or even more so its umbrella technology, trusted computing) is nearly as specifically targeted as DRM. > We have over 30 years of the world wide web and for these more than 3 decades this was never a problem. Suddenly, we "need" to create new technology that seem to b…
A technology squarely and 100% percent intended to give people other than the end user the ability to sleep soundly at night knowing those dastardly end users can't muck with their software (the non-end user) on their (the end user's) devices is only a tool for the authoritarian minded. Sorry mate, but if you're sitting here thinking it's useful and neutral, you are part of the problem, because you're eyes-wide-shutting the fact the only people gaining from the technology are those that already have a terrible trustworthy-ness record in terms of not abusing the sovereignty of another person's machine.
Show me an industry that ships source code, and manuals with all software that runs on the device, along with hardware manuals and the manuals to write your own drivers and doesn't use hardware primitives to enforce their business models over you, then we can talk about an industry where "trusted computing" might be neutral to the end user. History has not seen this relationship bore out, however.
The "Trust" in "Trusted Computing" has only ever been realistically unidirectional in terms of favoring entrenched industry players. As a rule of thumb, if the primary benefactors of a feature are over 90% legal fictions; your feature ain't neutral. It's hostile to humanity. Period.
Earlier quoted context omitted.
does it piss you off that punct isn't used properly anymore and that, commas, can happen anywhere? Are you one of those who still has use for em-dash?
> Are you one of those who still has use for em-dash? I still like ‘em!
Earlier quoted context omitted.
I say this in good faith: oh, stop.
does it piss you off that punct isn't used properly anymore and that, commas, can happen anywhere? Are you one of those who still has use for em-dash?
2.) I'm comfortable with varied comma stylization.
3.) My personal usage of the em-dash hasn't changed in a few decades and I don't see it doing so just because a bunch of folks only just recently learned it exists.
Earlier quoted context omitted.
> In my experience, once the issue is framed as 'Google will decide what you can do with your phone' every single person is immediately outraged. Apple already does this and practically no one is outraged
Yes, but most people don't realize it, simply because they have been conditioned from the beginning that the only way to run anything on an iOS device is via the app store. With Apple customers, a better argument to make is to say that Apple applies a 30% 'tax' on all activity on their phones. That they are being forced to pay more compared to non Apple users in spite of having bought their device fair and square.
Also, you're overestimating the fees. Few apps or services hit the 30% threshold or stay there for long (the fee for subscriptions drops in the second year).
The real problem IMHO is Apple taking a significant amount out of developer pay checks. Users are fine. The impact is on developers.
Earlier quoted context omitted.
The biggest mistake is that people trusted a company that, in reality, isn't that different from Apple. Just because everyone claimed Android as the true open source alternative to iOS, when only AOSP was that.
Yea agree. I reeeeally dont get why Google or Apple have good reputation at all.
Apple (under Jobs) sold themselves as counter-culture, they used popstars (unironically), and design, to sell the idea that if you were your own person, or followed fashion, then you bought Apple.
I think the goodwill from those days still provides the foundations of their cultural position now. Although they chip away at those foundations.
OpenAI looked like it could follow Google's early model, until it didn't.