Earlier quoted context omitted.
Cars come with AndroidAuto (and whatever is for iOS). Only apps signed by Google can communicate with AndroidAuto. I don't want to use a Google phone or app to display OSM on my car's media screen. Why is this legal?
Once you're talking about interactive information displays in cars that can be accessed while the vehicle is in motion, traffic and highway safety regulations start cropping up. When you ask "Why is this legal," try rephrasing it to, "Why is it legal for companies to make it so difficult to play Doom on my BMW's touch screen," and you will probably arrive at the answer.
I read the federal government’s Zero-Trust Memo so you don’t have to
281–290 of 369 posts
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#282Earlier quoted context omitted.
I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaningfully access networked services, all those who compile their own artifacts (even from completely identical source code) will be excluded from accessing that remote side/service.…
> I think 3. is very harmful for actual, real-world use of Free Software. It has been a long, slow but steady march in this direction for a while [1]. Eventually we will also bind all network traffic to the individual human(s) responsible. 'Unlicensed' computers will be relics of the past. [1] https://boingboing.net/2012/01/10/lockdown.html
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#283Earlier quoted context omitted.
Google does 1, 2, and 3 internally. If you join https://landing.google.com/advancedprotection/ you can get something similar for personal public accounts.
I prefer to keep my email as dumbly secured as possible. I’ll never forget this one time I was on my sailboat with no cell service and only an open WiFi connection from shore. I couldn’t login to anything via sms auth. Same thing with FIDO keys when traveling. Lost luggage? No logging in for you until you get home to get your backup? Cut your finger while cooking? No logging in for you! Have to wear a face mask? No l…
As for lost luggage, I carry mine on my keychain, another one in the laptop itself (USB-C Yubikey) and one in my safe at home - if all three are ever destroyed or lost I also have backup codes available as password protected notes on several devices.
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#284Earlier quoted context omitted.
This should be obvious from your comment but I think it's worth calling something out explicitly here: a bank that does that is mandating that you accept either Apple's or Google's terms of service. That's a lot of power to give to two huge companies. I think we'd do well to provide the option to use open protocols when possible, to avoid further entrenching the Apple/Google duopoly.
That is a job for the government. They should have made electronic payments and electronic accounts for everyone a utility many years ago.
You need a bank account to do basically anything and yet consumer banking is largely unregulated (in the consumer relation sense, they are regulated on the economic side of course). Payments take upwards of 24h and only during work hours (?!?), there are no "easy switch" rewuirements, mobile apps use shit like SafetyNet and I've had banks legit tell me "just buy a phone from this list of manufacturers"... PSD2 is trash that only covers B2B interoperability and mandates a security method that has been known as broken since its invention (SMS 2FA).
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#285Earlier quoted context omitted.
Well, the fact that I can't do credit card payments for some banks if I don't have an iphone or non rooted, google android phone is a problem which already exists. Worse supposedly this is for security, but attackers which pulled of a privilege escalation tend to have enough ways to make sure that non of this detection finds them. In the end it just makes sure you can't mess with your own credit card 2FA process by n…
> but attackers which pulled of a privilege escalation tend to have enough ways to make sure that non of this detection finds them The point of these restrictions is to ensure that your device isn't unusually vulnerable to privilege escalation in the first place. If you let them, some users will root their phone, disable all protections, install an malware-filled Fortnite apk from a random website then stick their cr…
> they're not obligated to deal with whatever insecure garbage you turn your phone into
Banks probably should be obligated to let you connect over standard protocols.
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#286Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#287This sounds really beautiful, and I am saving the link for future reference. I'm curious about the DNS encryption recommendation. My impression was that DNSSEC was kind of frowned upon as doing nothing that provides real security, at least according to the folks I try to pay attention to. Are these due to differing perspectives in conflict, or am I missing something?
DNSSEC is security in the other direction( DNS server -> client ). All DNSSEC does is securely sign all the responses to DNS queries. so DNSSEC is the answer to, can I trust this IP is valid for the name news.ycombinator.com. DNS over TLS/HTTPS just says, nobody but the DNS server I use can see I'm wanting news.ycombinator.com's IP. It's mostly useless at the moment, since other gaps exist leaking essentially the sam…
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#288Earlier quoted context omitted.
Three people sharing a personal account, with one of them frequently traveling internationally, is such an unusual usage pattern that I'd be really disappointed with a service provider if they _didn't_ flag it for extra verification.
This is the problem with this kind of thing. It just perfectly captures the privilege/shelter of the programmers who come up with these heuristics of “obviously unusual”. You just described the usage pattern of a pilot with a family, a truck driver, a seaman, etc. It’s only unusual if your definition of usual is “relatively rich, computer power user”.
If you don't own your own device and rely on third-party devices to access the service, good luck to you...
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#289Earlier quoted context omitted.
Not really. What's the use case there, everyone sharing a Google account? I travelled a lot for work, and never had issues with account access. Nor did my wife ever have issues related to accounts. We don't share Google accounts though. It sounds like that user has personal accounts being used by three people for business use... Which isn't "A seaman and his family".
> What's the use case there, everyone sharing a Google account? Yes. Everyone having their own distinct accounts is a property of high computer literacy in the family. Many of my older extended family members have a single email account shared by a husband and wife. Or in one case the way to email my aunt is to send an email to an account operated by a daughter in a different town. Aunt and daughter are both signed i…
As usual with the "personas" scenarios, people creates their unrealistic scenario (just like when talking about UX or design). These personas you are describing will probably fall back to low-tech methods in most of the cases, they won't fail to take a plane because GMail locked them out due to unusual activity when they are trying to show the ticket QR in the airport. They will just print it (or have someone print it for them) beforehand.
> The seaman in this scenario has a smartphone with the email signed in. It’s also signed in on the family computer at home. Both the wife and him send email from it. Maybe a kid does to from a tablet. This isn’t that difficult.
You just missed to add that they use their shared email to communicate between them by using the "Sent" folder. To be more realistic, the seaman right after buying his Android phone will create without realizing a new Google account because he doesn't probably know that he could use the email account he is already using at home. But, enough with made-up examples to prove our own points.
Re: I read the federal government’s Zero-Trust Memo so you don’t have to
#290Earlier quoted context omitted.
I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaningfully access networked services, all those who compile their own artifacts (even from completely identical source code) will be excluded from accessing that remote side/service.…
>> 3. Context aware authorization. So not just "can this user access this?" but attestation about device state! That's extremely cutting edge - almost no one does that today. > I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaning…
Depends what you think big corporations' centrally managed IT equipment is like.
Theoretically, it could mean you get precisely the right tools to do your job, with the ideal maintenance and configuration provided effortlessly.
But for some organisations, it means mandatory Internet Explorer and Flash for compatibility with some decrepit intranet, crapware like McAfee that slow the system to a crawl, baffling policies like not letting you use an adblocker, and regular slow-to-install but unavoidable updates that always happen just as you're giving that big presentation.