I'm Malaysian. They even messed up DoH for the popular DNS providers like Google and Cloudflare. I think they are routing 1.1.1.1 to their own DNS, so when you try to connect to DoH you get SSL_ERR_BAD_CERT_DOMAIN. The only option it seems is to VPN or play the cat and mouse game now to find a DNS that hasn't been rerouted yet
"Democracy" is a bit of a red herring here. Democracy doesn't mean the government can't censor you or restrict what information or media you can consume. Democracy just means that the voters have consented to whatever legal framework is in place, and to whatever their leaders want to do within that framework.
And that's the thing: in many democracies around the world, if there was a referendum on the law to blocking copyright infringement, online gambling, or pornography at the ISP level, I think many would pass that law.
(Certainly there are "democracies" out there that only pay lip service to the concept, and have fixed elections and repression of dissent or opposition. I'm not talking about those.)
Sarawak here (on unifi). My network uses self setup multi DNS path with enforcing encryption so no biggie but I tried some nonetheless. Quad 8, 1 are fine atm, while Quad 9 traceroute returned !X.
router DNS redir to pihole(Not the shitey FiberHome) -> pihole to internal(bind9 plain local to Adguard Proxy DoQ) -> self hosted tunneled whitelist DNS quicdoq DoQ, Adguard DNS DoQ (upstream quad 101, others.)
I have a similar setup, it will not be immune if they start implementing in your area. They were rolling out by areas before they reversed course. Your upstream will stop working unless you proxy it through another network
It's between ChatGPT being on there or something else like Claude... OpenAI cannot afford to let the masses know there is something out there that is just as good
if you are at a stage where this matters you will not be using Array.shift or even Array for that matter. JavaScript has lower level facilities for this.
There are a few convenient scapegoats here but ultimately in this case it is not biometric unlock that enabled this but rather characteristic of the Active Directory's design (I'm not sure I will call it a weakness).
For Android and iOS if you forget your PIN code I believe you are screwed, as in no one can decrypt your device for you.
Actually it is not just an issue with AD design, but the AD design only makes it slightly worse. The underlying issue is that biometrics are not required to retrieve the biometric key from DPAPI and instead of authenticating with Windows Hello, any program could just simply ask DPAPI for the key.
My understanding from a quick reading is that Bitwarden essentially used Windows Hello to ask "is the user there" and if so, asked DAPI to give Bitwarden the secret vault credentials which it happily did because that's its job.
The problem with this was that the vault credentials in DAPI was not safe from other programs running as the user, nor from domain admins which could use the recovery key stored on the AD server (which they did in their attack after gaining admin access).
The solution was to use Windows Hello the way it was meant. That is, to store an asymmetric key pair, where the private key is hidden and protected by the biometrics or hardware security key, and use that to encrypt the secret vault credentials before storing them in DAPI.
Have you looked into how (whether?) Windows Hello actually checks which app is asking it to perform a private key operation?
On Android, this is tied to the app UID, and on iOS/macOS it's tied (I believe) to the developer team identifier. Hopefully there's a similar mechanism on Windows...?
It doesn't, or at least it doesn't for traditional applications. UWP (store apps) might, but I've never seen it.
To be fair, identifying an app when not delivered through some locked down store mechanism is actually problematic. DPAPI is tied to the user/machine account along with additional entropy provided by the application itself. It would be nice if MS added an option for DPAPI to use a hash of the name blessed by a CA in a valid code signing cert. However, that wouldn't matter in this case, since they had domain admin and could easily manipulate the cert store.
Self-signed code signing certificates would seem to be a good compromise (like e.g. Android does it).
Even a hash over the executable (+loaded DLLs) would work in a pinch. Breaks app binary updates, but for a “stay logged in and unlock via biometrics“ feature (as opposed to “store this credential forever”), that might be acceptable.
> The goal is to enhance the user experience and interface, making it more user-friendly and visually appealing
I don't want to sound discouraging, but the thing you need to realize is most of us are here because we like its user interface, not despite it. If you're looking to enhance the site you should improve on its strengths, not change it to something it isn't.
Hacker News loads instantly all the time and I think I speak for most here that we don't want all these extra JS or Next React wizardry.
I'll have to admit, that "modern" website loads a bit faster for me (1.23s vs 1.83s), but that's probably because its visitors count is way lower than on original HN. And, funny thing, the single resource that increases load time over a second is hot-linked y18.svg from HN.
Transfer sizes are so much different: 276.73 kB vs 14.23 kB transferred with compression. And original HN still could improve transfer size by removing IE8 support for triangle icon rotation from CSS.
To conclude: UI and UX experiments are a good thing, keep them coming, as web technologies are not standing still.
Forget small companies. Apple is famously known for blocking import of 3rd party parts for repair, but refuses to sell such parts to independent repair shops before recently.
If every app need to poll different servers periodically or, listen for pushes, it will be a nightmare for battery life and be a big detriment to phone resource usage.
Sure, but shouldn't this be e2e encrypted? You could probably come up with a scheme such that Apple doesn't know the contents, sending app or recipient device.
This is up to app developers to implement themselves. The mechanism Apple provides for this is UNNotificationServiceExtension, which allows an app to step in before a notification is delivered so that it can do things like decrypt it.
Encryption should have been the default in the official framework/API to begin with. But I assume E2EE wasn't a concern for Apple/Google back then, and now it's to late to change everything without a lot of pain.
Apple previously didn't have any problems making breaking changes to their stuff, they even switched their whole CPU architecture and said "deal with it". If E2EE was really a concern to Apple, they'd implement it.
Push notifications just have the convenience of even technical people often not knowing that most of them are routed directly through Apple/Google. So how should your average user know? It's free data and nobody complains about it how they would with messengers eg
> Apple previously didn't have any problems making breaking changes to their stuff, they even switched their whole CPU architecture and said "deal with it"
What? Apple put a tonne of effort into continuity between arches. You think Rosetta is them saying “deal with it”?
> Apple put a tonne of effort into continuity between arches.
Still can't run windows on an M* mac, can you? Why? Because there is literally no documentation for the CPU and they didn't really follow any standards. They just built some shit that literally only Marcan probably knows how it actually works. Even the people who made it probably don't know how it works, only how it is supposed to work.
It should. I am sure that Apple will be working on this now. It’s unfortunate that they didn’t implement it before. Maybe Apple itself didn’t realise that this data was being taken by the authorities, and the parts of Apple that did know were not allowed to inform engineering.
Pretty much. Google Play services runs as like a root process that can (among other things) bypass all the security checks that the OS usually has. That includes those annoying update confirmation dialogs which make it impossible to install updates automatically without user interaction.
> Pretty much. Google Play services runs as like a root process that can (among other things) bypass all the security checks that the OS usually has.
Unnecessarily mind you, GrapheneOs proved that you can get the vast majority of GMS functionality without it needing to run as root.
Even Gpay would work if google allowed it.
> That includes those annoying update confirmation dialogs which make it impossible to install updates automatically without user interaction.
This has changed with android 12, third-party sources can now auto update an app after a user accepts the initial prompt go install it.
> That includes those annoying update confirmation dialogs which make it impossible to install updates automatically without user interaction.
Important to note this has changed starting with android 12, now you just need accept installing the app, and the source can update the app without interaction.
Droidify (third party fdroid client) supports it, among others like Aurora store.
Specifically GMS runs as a "privileged app" (that's what priv-apps stands for) which can declare access to permissions in the manifest that non-privileged apps can't even ask for.
