HN user
Back before ClusterFlutter (which was just a lot of Java object type-casting, large multi-dimentional arrays, and overflow math) botting was pretty easy to write yourself with very little JVM knowledge.
Bans were (and still are) pretty hard to come by as long as you pay for a membership.
Great scripting language, but has a pretty troubled past.
Once the original creator moved on from ownership, the new owner also had a business with Runescape botting.
The story is that it didn't go well for the maintainers of Autohotkey until another person took the reigns.
This might be a good plug for Morphie or Revanced patches to automate the patch process.
a basic level of device security across all iMessage threads I have
Is that really true though? Jailbroken phones, iMessage may still work. Any device security gets thrown out the window.
You also can't expect everyone to have an Apple device for security, which we've seen time and time again SS7 being weak - So is the requirement to remove SS7, for everyone to jump on the Apple train?
I see Beeper as doing Apple a service, not so much a competing platform, but a gateway to the iMessage ecosystem - 'Hey, this would be pretty cool to use without this app and have it native' vs the 'Only Apple devices can use this.'
More and more of the internet is now moving behind Cloudflare
This is a big double-standard here on HN. Everyone hates Google for making decisions on behalf of the internet as a whole; yet Cloudflare has done the exact same thing with a different OSI layer.
I'm not very trusting of Google, but I certainly dont trust Cloudflare any more-so, because they keep things much closer to the chest.
For the overflow, Jagex with RuneScape did it in Java. They also did stupid Object arrays 7 or so levels deep, doing casts on casts in between. The bytecode itself made the actual runtime slow to a crawl (anywhere from 5 to 10x slowdown.) This was circa 2014.
Spit-balling; when will they put GSM chips in them? The cost of a data-plan could easily be reached with estimated figures for ads and selling usage data.
For maven, to push artifacts via the correct mvn deploy:deploy-file requires a S3 wagon (transport layer) software to actually make the S3 calls. For bigger orgs, having everyone use a wagon is a non-starter.
All I'm seeing this does is give the proper http endpoints so you dont need the wagon. Is it worth ~2x the price, no, but it's better than the other enterprise-y solutions.
Samesite won't break it if you set it none. Eg samesite=none Google failed to set it before the official rollout.
Reason is that sso effectively uses an iframe or popup to a 3rd party auth provider (Google, Microsoft, Auth0...) Provider saves a cookie with that state (from something like accounts.google.com) and usually reads it back from first party context.
If samesite is not set to none, supporting browsers are not allowed to write cookies on the auth domain from the firstparty context, and so the firstparty scripts don't think it ever happened, even though it did. First party scripts can't read it and so sso failed.
It should be noted that SameSite was broken with Google Sign-in because Google themselves never set the None attribute before they reverted the rollout in April. [0]
This is a killer for all federated login systems.
[0] https://github.com/google/google-api-javascript-client/issue...
Corrected; Thanks.
Didn't realize the US was that bad.
Going full tinfoil hat...
We've seen the GDP number manipulated during this crisis, Gov propping the economy up with lots of self-debt that we cant pay back.
We've seen that other developed counties in the world bawk at us. Example being the American woman who killed a guy in the UK by driving on the wrong side; and the US said she had diplomatic immunity, when she did not. [0]
Crime stats... Crime isnt crime if it isnt punished or even taken to the courts proper. A sitting president was impeached, but not removed from office. He was charged with high-crimes. If you need a statistic, just look at how stacked the government is from a 2-party system.
I'd completely agree that America is fucked.
Maybe I'm just skeptical and a cynic, but...
VPN with an in-app purchase
Lets pay for a product, and they have the ability to sell that data.
I get, acting like a pi-hole and what-not but, a VPN for that task seems overkill.
I'm not saying that the product doesn't have it's use, but it is not how DoH should work.
I'm trying to bolster the point that they are promoting logs and more importantly, blocking DNS queries.
How can I trust the DoH endpoint if I know they have an active product whose purpose is to log and not give back the requested IP.
I never heard of NextDNS.
I am appalled.
From their site: https://nextdns.io
See what's happening on your devices with in-depth Analytics and real-time Logs.
Protect your kids and control what they can access online.
Their pricing page is also extremely troubling.
We may adjust this later on based on actual costs at scale, but it will follow this logic.
What the hell is this Mozilla... This is not a company you should be dealing with. They tell you up front that they log and monitor... They also aren't at scale, and have to learn lessons the hard way with outages.
Mozilla is dead to me now.
Edit:
As others have pointed out, Mozilla's own policies: https://wiki.mozilla.org/Security/DOH-resolver-policy
Transparency Requirements, section 2.
Where on earth is a transparency report for NextDNS? They were started in March, and I would think that Mozilla would check their requirements before giving the 'lets add them.'
Proxmox is good with the large exception of high speed interconnects.
If I have Mellanox IB cards in my servers, proxmox fails to handle ipoib without a lot of legwork. Compare that to something like oVirt; that supports it out of the box.
There is very little incentive for me to recommend a proxmox subscription to any of my clients because having >= 40 gbit interconnects is far better than using lags on single gbit. High traffic internal applications, (and migration!) benefit so much from those interconnects.
crusading against DoH favor a different centralized DNS standard, DoT
I think that there are 2 camps against DoH. 1. Default centralization to specific points. EG firefox using cloudflare first and foremost, nobody else. 2. DoH adding complexity. DoT was (practically) superseeded with DoH anyway, if for nothing more than adoption.
criticism against DoH that says it's wrong for browsers to co-opt DNS resolution at all, and that they should use the system's resolver. This is nonsense.
So... your argument is that I can't trust the OS to 'do the right thing' but I should trust the browser, because they know best? If you can't trust the OS, then how could I possibly trust a browser running on the said, untrusted OS?
Honestly asking how you came to that conclusion because the train of trust is broken on the OS level, so anything above is moot.
DoH simply don't believe DNS lookups should be private
Problem with DoH is that it is private up to the endpoint. Nobody can listen on the request, but nobody is preventing the endpoint from telling everyone else that 'Joe Smith visited Youtube at {timestamp} Once the endpoint has the request, they have your info and can just as easily sell that to telcos.
End-to-End encryption and privacy is only as good as the people on the other side. Can't trust Alice with your message, then don't send it.
modernizes the DNS protocol
If by modernize you mean convolutes. If I have a resolver on my network serving qwer.localnet. Browser asks cloudflare, returns nxdomain, then my system resolver asks for it; that is far more latency and is far from the modern proper solution for speed and privacy. Cloudflare now knows that I have a local domain, qwer.localnet.
Discovered this Fun fact last night; the systemd resolver since V242, used cloudflare as a fallback DNS. [0] The fallback has been Google and quad9.
In theory (haven't tested it,) this means that even if I give 0 DNS servers on a DHCP request, and I ignore any DNS requests to the gateway (if I wanted a machine totally unable to resolve) I can't do that because a distro choice to use the systemd resolver.
[0] https://github.com/systemd/systemd/blob/master/NEWS#L751
All ISPs have privacy policies. 99% of all privacy policies are either copy/pasted from elsewhere or written in legalese so that company can do whatever they want. 'Internal business use' is a nice fodder for 'Selling data to increase this general ledger account for later business use.'
An audit is almost always under bad pretenses. If I spend $$$ on an audit company, the company itself has bias.
The difference between third-party audits and government issued audits (think food safety) is that the government has nothing to gain by a positive, or negative result.
IANAL, just cynical of people.
Except for the shadow profiles that they make of the 'non-users.'
Whether you like it or not, Facebook et al are tracking you regardless if you have an account.
How is that relevant with telemetry? If anything, that would make it harder to block their analytic domains and stop it.
I think what he means is why not use ++ in the click handler. We don't need a function to increment something.
Standard HTML, onclick="var++"
Exactly.
They very clearly allow it to be changed in a config; and I'm willing to bet my socks that Azure is not giving Hashicorp 'deployment structure' information based on a partner id.
well, first thing on my list if I can't boot; good 'ol USB live boot to read dmesg and syslog.
Which a live boot, you can install packages such as microcode updates.
Which is just gravy, because the whole DoH crowd is against ISP monitoring and selling it.
Goes to show that the only thing Doh/DoT/et al. did was to make things more complicated and harder to work with.
That's non-targeted attacks. Nothing stops the targeted attacks.
Sure, they might not be able to listen in on those https connections, but if they wanted to attack/listen to this Joe Smith over here, they are more than capable, and still do it.
Yes, however the difference here is that Chrome is looking at the OS resolver itself first; not just disregarding it, or looking for a magic domain. Chrome is being opt-in, Firefox is being opt-out.
Chrome DoH use cases:
For the average home user, fine; they're either using what the ISP DNS is, or the public ones (1.1.1.1, 8.8.8.8 ....) If those are on the 'accepts DoH from us', then it'll use DoH to the appropriate destination.
For the corporate environment, their internal DNS might not support DoH, and as such, Chrome will not even try to use DoH.
The key is that it is respecting the OS DNS settings, not the ability to not resolve a magic domain. If I opt to setup DoH internally, the understanding is that I know what I'm getting into.
They can, it just takes extra steps.
Firefox tries DoH via Cloudflare, for an internal domain that returns NXDOMAIN (Cloudflare can't answer for your internal resolver,) then they fall back to local resolvers, which is OS based (DHCP or statically set.)
The response time to complete the internal request goes up, because you're sending data to Cloudflare, they can't find it, then the 'normal' response time for internal resolvers.
Edit: Made more clear.
I hardly see how the OP is FUD. What the article states is true; just because you can opt-out doesn't mean it's wrong.
Where you are drawing the line is the opt-out to disable it, as opposed to the convention of opt-in.
Think about companies in the 50-200 employee range; As a sysadmin, I have to purposefully go out of my way to put that domain (use-application-dns.net)[1] in my root resolver, and point it to NXDOMAIN.
I can't do it if another provider is managing my DNS (ISP, cloud service...); it also doesn't actually guarantee that it is off.
If a user has chosen to manually enable DoH, the signal from the network will be ignored and the user’s preference will be honored.
The basic IT mantra has been 'If it aint broke, don't fix it.' Mozilla itself is moving fast and breaking things; which is why we have standards in the first place.
For god sake, there isn't even a proper RFC to select yes or no to DoH.
I, as a sysadmin, must not only implement the domain in my resolver, but I also must keep in my mind that if a user is using Firefox, that there are things it does internally that are not right, and it is easier for me to have my users on Chrome, because it is less of a headache for me.
[1] https://support.mozilla.org/en-US/kb/configuring-networks-di...
How can you block it, if the browser itself is doing the communication, over https no-less?
DoH was made to stop censorship, which includes blocking; if you could just block it, then whats the point of DoH?