Who is responsible for preventing a child from running into a busy road and being hit by a car? And why, on the internet, does that responsibility seem to fall on everyone else?
Shouldn’t Windows just show a huge warning explaining the implications of such actions when a user who has never used the Windows Run function nor PowerShell suddenly attempts to run some suspicious code pasted form the clipboard?
Yes, the only differences are that mCaptcha is 100% FOSS and uses variable difficulty factor, which makes it easy to solve Proof-of-Work under normal traffic level but becomes harder as an attack is detected.
Yes, WebAuthn is an open standard, but it seems that Passkeys can only be synced using Google password manager and I don't see any API that would allow the user to use a different password manager as is the case with the auto fill API.
Ah, that's interesting. So if I use Apple keys to log in to sites, I can never log in to them with my Android phone? That's unfortunate, though I don't see this being sustainable for too long, I imagine (and hope) they'll open it up to alternate authenticators soon.
Based on the way implementers at those companies have talked about it, I don't think that's the desired long-term state of affairs. One thing Adam Langley mentioned in https://www.buzzsprout.com/1822302/11122508-passkeys-feat-ad... was that the BLE handshake identifies the cloud service to use because they need to support corporations using their own services for all of their devices. Hopefully there'll be enough demand for that to ensure it's fully implemented soon.
Do you know if it's possible to see a list of stored passkeys in Android? I installed the Play Service beta, managed to create a passkey and sign in, but can't see the list of credentials anywhere in the UI.
There will be, in the password manager settings on Android (under Settings, "Passwords & Accounts" and "Google"), but it will unfortunately take a couple of more days to roll that out to the beta.
I think that once users realize how difficult it is to transfer passkeys between their PC and mobile device, they will just ababdon them. The only risk I see is that passkeys will be synced between Android and Chrome.
I really hope that there will be an API for Passkeys like there is an API for password managers on Android.
DNS has known privacy issues, but this solution just (conviniently for them) shifts trust and data from the network operator to Google DNS or another central provider
Again, why? What bad thing could Comcast do to you? I know they're like a regional semi-monopoly, but they don't control anything else in your internet life.
Who knows if some 'suspicious' DNS queries sent to Google will accidentally set off some tripwire that causes them to lock you out of half the internet: https://news.ycombinator.com/item?id=30771057
Shudder sure. But why not run your own DNS? Pick a desktop, Pi, server or similar and run a full resolver like unbound. You'll never have issues because your ISPs DNS is slow or dead, and you'll be talking to the root servers directly.
That's the great thing about this feature, you can! Set up a DoH server, configure it on your phone, and you'll have your personal, encrypted-in-transit DNS server that you can use from anywhere!
By leveraging Oblivious DOH you can even encrypt your DNS traffic securely to your upstream DNS provider without having to set up your own recursive resolver (which would only lead to privacy issues).
Depends on your setup. You can tunnel your DNS through a Wireguard link to some cloud server if you want or you can use something like ngrok to expose the port publicly.
Every hop adds latency, though, so I'd recommend using as direct a connection as you can get. DNS latency can make your internet experience a real pain!
I've worked it out myself, there's a Rust crate called doh-proxy that contains a binary that's essentially a DoH server for a DNS server you specify and if you set it up right it'll just open a DoH server on a port you specify. Kind of a pain to debug, but once it works, it works pretty well. Can take a TLS cert or can work without TLS and a reverse proxy.
DNSSEC protects against that for well-configured domains, though you can't assume people put in the effort.
You can use ODoH (https://blog.cloudflare.com/oblivious-dns/) to double-encrypt your DNS requests and forward them through an external server, disconnecting your query from your response, and encrypting your upstream DNS requests. You can pick any relay from this list: https://download.dnscrypt.info/dnscrypt-resolvers/v3/odoh-re... (need to de-base64 them to get the actual domain) and any upstream DOH server you prefer.
> DNSSEC protects against that for well-configured domains
This isn't effective against DNS-level censorship, though. A DNSSEC validation error is just as effective as a fake NXDOMAIN or bogus IP at keeping me from visiting the correct site.
It works in the sense that at least you can know your ISP is messing with your DNS. If they mess with DNS, they might as well just block an IP (range), so a DNS alternative probably won't bypass most censorship. You're better off with a decent VPN at that point.
I temporarily agree with this, but once TLS ECH gets widely deployed then I won't. I can see an ISP blocking a single domain, but not all of Cloudflare just because it's hosted there.
I'm still trying to add http3 to my DNS server and can't test DoH. But based on the other comments, it looks like a custom DNS server will use DoH if supported?
iOS has 2 solutions to this. They have a push models where you “share” the file to the next app you want to use. And they also have a traditional file store model where all apps can request to save and request to load files.
Critically, apps can not directly read your files, they can show a button which will open the OS file picker and the user can pick a file to open which then provides access to the app.
This means that opening a game does not instantly expose all of your sensitive files.
> Critically, apps can not directly read your files, they can show a button which will open the OS file picker and the user can pick a file to open which then provides access to the app.
Unfortunately this model breaks down for any kind of file type that doesn't simply consist of a single, atomic file, e.g. various constellations of media files (playlists, subtitles, multi-part videos), multi-part archives, HTML files, georeferenced imagery with sidecar files, etc. etc.
iOS apps can be given access to files and folders created in other apps. I have no idea when this was added, I didn't use iOS between 3.x and 14.x, but it's there.
https://juno.sh/ios-file-system/ for some info about how it works from the perspective of an application that might need to access other apps' data.
