Hacker Newsnew | past | comments | ask | show | jobs | submit | swinglock's commentslogin

This is why I used ReadItLater and now Instapaper. It's integrated in my ebook reader too.

Subscription Bookmarking apps will never be part of my workflow.

Men in the middle including predatory ISPs can not only spy but also enrich. Injecting JavaScript and embedding ads is the best case scenario. You don't want that.

In addition even without bad actors TLS will prevent random corruption due to flaky infrastructure from breaking the page and even caching those broken assets, preventing a reload from fixing it. TCP/IP alone doesn't sufficiently prevent this.


> JavaScript

Why do you allow that RCE in the first place?


Most users have JS enabled nowadays. Much of the web doesn't work without it. It was just an example.

TCP ensures what gets sent on one side gets received on the other side. TLS just encrypts the data. So even without TLS, random corruptions won't happen unless someone does MITM attack.

No it does not. I've had this happen in legacy systems myself. The checksums of TCP/IP are weak and will let random errors through to L7 if there are enough of them. It's not even CRC and you must bring your own verification if it's critical for your application that the data is correct. TLS does that and more, protecting not only against random corruption but also active attackers. The checks you get for free are to be seen only as an optimization, letting most but not all errors be discarded quick and easy. Just use TLS.

I saw myself years ago that Verizon injected marketing tracking headers into http traffic. My ISP was the MITM.

https://www.eff.org/deeplinks/2014/11/verizon-x-uidh


IPv6 and CGNAT growth has finally started to suppress IPv4 prices. There was a huge pump when hyperscalers decided they needed more. But IPv6 keeps growing and is the majority of traffic in many networks. If you own significantly more IPv4 addresses today than you need, I would dump them on the market yesterday. Spend some of the profits to move to IPv6 if still needed.


Well but then attackers just compile a kernel with a rootkit that hides the hack and itself from the APIs of the BPF program, so it has to deal with that too or it's trivially bypassed.

Anticheat and antivirus are two similar but different games. It's very complicated.


The bpf api isn't the only telemetry source for an anti cheat module. There's a lot of other things you can look at. A bpf api showing blanks for known pid descendent trees would be a big red flag. You're right that it's very complicated but the toolchain is there if someone wanted to do the hard work of making an attempt. It's really telemetry forensics and what can you do if the cheat is external to the system.


I'm surprised curlx_strcopy doesn't return success. Sure you could check if dest[0] != '/0' if you care to, but that's not only clumsy to write but also error prone, and so checking for success is not encouraged.


I guess the idea is that if the code does not crash at this line:

    DEBUGASSERT(slen < dsize);
it means it succeeded. Although some compilers will remove the assertions in release builds.

I would have preferred an explicit error code though.


assert() is always only compiled if NDEBUG is not defined. I hope DEBUGASSERT is just that too because it really sounds like it, even more so than assert does.

But regardless of whether the assert is compiled or not, its presence strongly signals that "in a C program strcpy should only be used when we have full control of both" is true for this new function as well.


Yeah, thought the same. Expect some CVEs in the future.


What kind of CVE would you expect? The destination buffer will always contain a valid null-terminated string (as long as the buffer size is not zero).


This is especially bizarre given that he explains above that "it is rare that copying a partial string is the right choice" and that the previous solution returned an error...

So now it silently fails and sets dest to an empty string without even partially copying anything!?


The latest DLSS and FSR are good actually. Maybe XeSS too.


This used to be a feature to protect spinning hard drives. Why this would exist today and why it would throttle anything is bizarre.


You should block the whole /64, at least. It's often a single host. It's often but not always a single host, that's standardized.


Usually a /64 is a "local network", so in the case of consumer ISPs that's all the devices belonging to a given client, not a single device.

Some ISPs provide multiple /64s, but in the default configuration the router only announces the first /64 to the local network.


Presumably a compromised device can request arbitrarily new ipv6 from the dhcp so the entire block would be compromised. It would be interesting to see if standard dhcp could limit auto leasing to guard reputation of the network


Generally, IPv6 does autoconfiguration (never seen a home router with DHCPv6), so no need to ask for anything. Even for ipv4, I've never seen a home router enforce DHCP (even though it would force the public ip).

But the point stands, you can't selectively punish a single device, you have to cut off the whole block, which may include well-behaved devices.


In mobile networks it's usually a single device.


It's working. It will not be settled.


> There were too many apps; all they wanted was the phone app, but it doesn’t default to the keypad, which was too much for them to find.

Then why buy an iPhone? There are phones designed for seniors that do just that. You don't need to pay 10-30x more for functionality you don't need and can't understand. Buy a Doro if you just want to call.


> Buy a Doro if you just want to call.

The thing is that even the elderly want to do more than just that. Some want to be on Facebook. Some want to do their banking, especially if their PC is 17 years old and a smartphone makes for a cheaper purchase than a new PC.

A Doro or equivalent is if you literally only call (and maybe text), but even the elderly generally want to (or are functionally forced/compelled to) do more on their phones.


Can a person who can’t find the keypad tab at the bottom of the Apple Phone app really use Facebook or internet banking?


This. If they can't make a trivial call, do not ever ever let them touch web browser or anything like that. They'll click on a first lottery ad and be scammed instantly.


You'd be surprised what sufficient motivation can achieve.


The Jitterbug was made for these seniors that insist on calling when a text would suffice.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: