News Minimalist [1] is one way, where it aggregates stories across outlets and uses LLMs to remove clickbait from titles. It also assigns loose 'scores' to each story to approximate how 'important' it is, which I've found to be directionally useful.
Ultimately, it comes down to why one consumes news at all. If it's to have something to discuss around the water cooler or dinner table, that's a very different use case than someone trying to pattern match on world events for trading stocks or selling their wares.
I’m working on this as a personal project so I’m interested in other’s solutions!
I’m not working on it toooo hard. This is something I think some AI software tool might swoop in and solve before I can build something I’m happy with.
It would make it a bit harder to detect that you are using a VPN, but it shouldn't be hard for the ISP to detect that all your traffic is being sent encrypted to a particular IP address.
They wouldn't be able to see you are using X in particular. There may be very specific timing patterns that the X app or the X web app use when fetching related images, new posts, etc, but this also depends on how you scroll the site, and this seems infeasible to prove beyond any reasonable doubt, and also that any ISP would have logs with that granularity. As the parent said, you should make sure no DNS queries go outside of the VPN, for example.
Now, if you post to X, then it would be clear that you used it, which would be a problem according to the resolution, as long as you were in the country.
A long time ago (2011) when I was teaching the networking course at Brown, the final assignment in the course was to create the equivalent of iodine, IP-over-DNS tunneling [1]. Being a course assignment, the handout only outlines the solution. We provided a set of domain names and DNS servers on VMs for students to use.
After the course ended, one student going home did manage to use his assignment to get Internet access from the airport, as we had forgotten to turn off the DNS server nodes.
Over the years we had a lot of fun with creative final projects in the course besides IP-over-DNS, including web-based phone tethering, DNS spoofing, openflow-based SDN routing, LT (Erasure) Coding, a BitTorrent client, and a DNS-redirection-based CDN with leaderboard.
Really great research work from Kay Ousterhout. Sparrow extends the "power of two choices" [1] to a more general formulation, and makes it really cheap to find very good choices (i.e., low-load servers) to run a task, without having to check the load on every server. As the number of tasks and number of servers grow, keeping an accurate picture of the load on every server makes the scheduler become a bottleneck. Kay's work showed a very interesting point in this design space for fast and high-quality scheduling.
Her PhD work went on to really understand the performance of complex distributed programs, like large Spark jobs, and a lot of at least earlier performance instrumentation in Spark is due to her.[2]
Also, don't call from the same phone you received the call on, if on a landline. One time (I can't find the reference) scammers called from the bank, suggested the person called back to the number on their credit card. The person hung up, picked up, and the scammers had held the line, played a fake dial tone, and had someone else "pick up".
In USA telephones, unless you timetravel to "party lines" (when sets of local numbers had the same line, so picking up while a call was in use allowed people to listen or join in), hanging up any one end of a line disconnects the call the departing user from the call.
If the described scam happened, in should have required a simultaneous fault in the phone system. Or more likley, the scammer played a recorded sound of a disconnect+dialtone, which could tricker the target into dialing.
This is incorrect at least on Bell Atlantic's (and then Verizon's) network in the late 90s. Since there is no double-billing on landlines in the US, the person initiating the call is the only one that can immediately terminate a call to a landline. There's a timeout for the reverse direction, but it at least used to be fairly long.
Someone pulled a trick where they took advantage of this. Had a friend call and keep the line open. Then claim that you have the entire phone book memorized. To prove it, ask someone to name a random name, punch in 7 digits and hand it off to the person who named it. They ask for the name and your friend says "yes that's me" (or "they're not home now if the gender mismatches).
> There's a timeout for the reverse direction, but it at least used to be fairly long.
This brings up one of those cultural things: ever noticed how in movies and TV shows from the 80s and 90s, if the caller hung up, the person called immediately got a dial tone?
It's a trope that prop wranglers, set designers, and writers picked up because the telephone company around Los Angeles (Pacific Bell) had switches that would reset the line state for the destionation back to "ready for call", which meant dial tone, when the origin side disconnected. If the destination side disconnected, the origin would only be disconnected after approximately 20 seconds.
Almost all other exchanges would put the destination--after the origin disconnects--into an off-hook-but-not-ready and then, after 10 or so seconds, play the "if you'd like to make a call, please hang up and try again" recording, then Special Information Tones, then a rapid busy.
Yet because the service in and around LA is what a lot of people in the TV and movie business experienced, it is what got baked into those productions.
I was a rather violent sleeper when I was young and would occasionally knock the phone off the hook while sleeping. Then I woke up to the fairly loud rapid busy sound. Hadn't thought about that a while.
Interesting. I always assumed that the immediate dial tone after origin disconnected in movies & TV was for dramatic effect to let watchers know that the person hung up the phone.
Now that you mention it, I did vaguely used wonder why some phones took longer to hang up than others. Some, I would hear the receiver go onto its rest, and 'immediately' hear a dial tone. Some, it took a few seconds.
Related to what some other commenters pointed out…
- The delay did seem to get longer when call-waiting became avaliable in an area.
- Sometimes, right after pressing your own hook and then releasing it, I could not dial; I had to wait a couple seconds.
- I never used a system where you could hang up and have time to run to another extension, but I may have known a couple people who claimed they could? If so, I probably dismissed it as "weird".
- My direct experiences were with various regions of just three Bells, so another commenter's remarks about LA/PacBell were interesting.
The time required for a good hangup might vary a little bit from exchange to exchange. I recall occasionally being able to transfer to different handsets hanging up one before picking up the other. But not to the extent reported in some anecdotes where one end can hold the call open indefinitely.
This is definitely true. I remember being able to quickly press and release the hangup button on a single phone and if I was quick enough the other person would remain on the line. I don't recall exactly where the threshold was, but I believe it was around a half a second or so.
I remember being able to hang up the phone in one room, run to the next room, and pick up the phone and continue the conversation. My friends and I did this on several occasions.
This was in the Atlanta area, in the late 1980s.
IIRC, the originating party's on-hook will immediately disconnect the call, while if the receiving party goes on-hook, there is a short but significant delay before disconnect is finalized.
This may have something to do with service offerings such as call-waiting and 3-way, which depend on detecting a "flash" signal.
I believe that potential exploit only work(s|ed) in the UK telephone network, and maybe those of countries developed in parallel using similar technology. Either way, it is a zero-cost precaution so you might as well do it just in case.
They used to operate this way in the UK - the line would stay occupied until the call initiator hung up. We used to play with this when I was a kid, but I've not had a landline since early 2000s, so I've no idea if this survived the transition to digital exchanges. TBH I doubt it, and I know lots of people complained about it, because it was really annoying if someone who'd called you hadn't hung up properly as then you couldn't make any further calls yourself.
Could not agree more. I think one big problem with Bolsonaro's discourse about the election system -- he was absolutely correct that the current system is not fully verifiable -- is that it became too politicized, and that he or his supporters took this to mean that the election should not be trusted. This automatically made anyone arguing to improve the system be lumped in with those sewing doubts about the result, which eventually led to the backlash from the TSE and the whole Jan 8th debacle.
One big problem with the electoral court in Brazil is that it is the only public branch that concentrates the three powers in one entity: they legislate about elections, they execute the rules, and they judge any matters related to the election. As a result, they have chosen these arguments to shoot down any criticism or improvement suggestions to the election system.
The country deserves a non-politicized discussion on the ground of true technical and security merits of what the election system should be. Paper records with Risk-limiting audits would solve most of the problems. I agree with your [comments] above. The costs of implementing this pale in comparison to the benefits of having a more reliable voting process which is the basis of a strong democracy.
> and that he or his supporters took this to mean that the election should not be trusted
That's exactly what they should think. This is the system by which the power of the people is delegated to representatives. Why should they relinquish any power at all if there's any possibility the results were tampered with? They most certainly should not.
That's the standard of perfection the judge-king himself set when he said the system was "unquestionable". TSE needs to prove beyond shadow of doubt that it cannot be compromised. Anything short of that means the system cannot be trusted. So far I've seen nothing but censorship and persecution from the judge-kings. What are they so afraid of?
The paper vote records (anomymous, of course) become the source of truth. There are very well established methods (Risk-limiting Audits - https://en.wikipedia.org/wiki/Risk-limiting_audit) that can randomly sample a small fraction of the ballots to guarantee with high probability that the electronic results are correct. Without paper records, the source of truth lies with the code that was run to receive and register the votes, and that is almost impossible to verify and fully trust.
In Networking, two illustrations of congestion control are just fantastic IMO.
First one is [1], by Chiu and Jain (page 7, figure 5), showing that Additive Increase / Multiplicative decrease is the only simple policy that converges among 2 senders (with rates x and y) to a rate that is fair (along the y=x diagonal) and efficient (along the x+y=Bandwidth). This is the basis of the algorithm that made TCP (and the Internet as we know it today) possible.
The other one is this diagram from BBR [2] (from the paper in [3]), that shows how BBR sets the window ("amount in flight") to the bandwidth-delay product (BDP) of the bottleneck link (the "volume" of the pipe in a water analogy). The cool thing is that you can only measure the delay of the link if you window is <= the BDP, and you can only measure the bandwidth if your window is >= the BDP, so the algorithm has to hover around this point to make sure it can determine both.
Chiu-Jain plots are great for getting a grasp of AIMD. Another related one I like is the figure illustrating ack-clocking in Van Jacobson's original congestion control paper - Figure 1 here: https://ee.lbl.gov/papers/congavoid.pdf
