> We’re alerted hundreds of times per day. Some are useful and non-invasive, like an oven burner turning orange when it’s hot. Some are needed, like a critical security update, while others are just generally helpful, like a feature suggesting something new. But when they appear at inopportune moments, even the most useful notifications often have detrimental results like anxiety, frustration, and reduced productivity. While a pop-up might be nearly invisible to one person, to another it might stop a critical task completely for hours. We must examine when our communications are helpful vs. harmful.

source: E

> This is not to say that this type of ad hoc, spontaneous Romanization of Cantonese has not already existed for some time. Indeed, young people have been using it extensively for texting, on social media, etc. for years. What’s new is that it is now consciously being employed to out fake protesters who do not know Hong Kong Cantonese and its informal writing system.

> This library implements application-guided rewriting of binary functions at runtime. Binary functions can be optimized and specialized based on runtime information. In contrast to transparent binary optimization, only selected binary functions are rewritten. No metadata (e.g. debug information) is required.

source: E

> In a world of changing technology, there are few constants - but if there is one constant in security, it is the rhythmic flare-up of discussions about disclosure on the social-media-du-jour (mailing lists in the past, now mostly Twitter and Facebook).

> In this blog post, I would like to highlight a few aspects of the discussion that are important to me personally - aspects which influenced my thinking, and which are underappreciated in my view.

source: grugq

If you don’t have time for the challenges themselves, reading this review a few times until the lessons are internalized may be a good substitute.

> How practical these attacks were. A lot of stuff that I knew was weak in principle (like re-using a nonce or using a timestamp as a ‘random’ seed) turns out to be crackable within seconds by an art major writing crappy Python.

https://cryptopals.com/

source: grugq

Paper: https://www.usenix.org/conference/usenixsecurity19/presentation/antonioli

> We present an attack on the encryption key negotiation protocol of Bluetooth BR/EDR. The attack allows a third party, without knowledge of any secret material (such as link and encryption keys), to make two (or more) victims agree on an encryption key with only 1 byte (8 bits) of entropy. Such low entropy enables the attacker to easily brute force the negotiated encryption keys, decrypt the eavesdropped ciphertext, and inject valid encrypted messages (in real-time). The attack is stealthy because the encryption key negotiation is transparent to the Bluetooth users. The attack is standard-compliant because all Bluetooth BR/EDR versions require to support encryption keys with entropy between 1 and 16 bytes and do not secure the key negotiation protocol. As a result, the attacker completely breaks Bluetooth BR/EDR security without being detected. We call our attack Key Negotiation Of Bluetooth (KNOB) attack.

source: green

> Why we left Medium, and how!

A bit more detail here than just, oh look, we moved.

Also, interesting that they managed to keep almost identical look and feel (for people who like the design of medium), but it loads super fast. Proves medium could be doing a lot better, if motivated.

> Now that the text is public, we can finally do a well-informed evaluation.

> This bill is terrible in many ways. Among other problems, it grossly misunderstands Section 230’s mechanics, its desired policy consequences would be horrible, and it is misdrafted to advance those objectives.

> It doesn’t bring me any joy to dunk on a bill like this. Like Sen. Hawley’s bill, it almost certainly was meant as a piece of performative art to “play to the base” rather than as a serious policy proposal. But even as performative art, it highlights how Section 230 is grossly misunderstood by politicians inside DC, and it’s a reminder that modifying Section 230 requires extreme care because even minor changes could have dramatic and very-much-unwanted consequences.

> What if we could make everyday checkboxes more beautiful and more intuitive? It’s easier than you think. We only need a small amount of CSS and JavaScript to make considerable improvements to your average checkbox UX.

> In 1969, pharmaceutical company Burroughs Wellcome commissioned renowned modernist architect Paul Rudolph to design its new corporate headquarters and research facility in Durham, North Carolina. The result was a visionary modular complex whose geometries created a futuristic melding of spaces and forms.

source: E

> We present a state-of-the-art high-quality real-time SISR algorithm designed to work with japanese animation and cartoons that is extremely fast (~3ms with Vega 64 GPU), temporally coherent, simple to implement (~100 lines of code), yet very effective. We find it surprising that this method is not currently used ‘en masse’, since the intuition leading us to this algorithm is very straightforward. Remarkably, the proposed method does not use any machine-learning or statistical approach, and is tailored to content that puts importance to well defined lines/edges while tolerates a sacrifice of the finer textures.

source: HN

> Phone lines, while not initially designed to transfer binary data, turned out to be a good enough way to do so—up until the 2000s, at least. From sending faxes to browsing the Internet, people relied on effectively the same copper wires they used with Ma Bell-leased telephones. But while most of the personal tech evolved towards greater connectivity, landline phones mostly got better only at the ergonomics of calling and dialing. Today’s Tedium is dedicated to the few ones which dared to be smarter.

Plus this great anecdote:

> The mild criticism (“not proving the success that Sir Alan Sugar had hoped” was all that was ever written about the phone) pushed Sugar to send a message to all 95,000 service subscribers, asking them to send an email to Charles Arthur, the newspaper’s tech editor.

> Netflix has discovered several resource exhaustion vectors affecting a variety of third-party HTTP/2 implementations. These attack vectors can be used to launch DoS attacks against servers that support HTTP/2 communication.

Son of Slowloris returns!

> While this added complexity enables some exciting new features, it also raises implementation questions.

Here comes trouble...

> The Security Considerations section of RFC 7540 (see Section 10.5) addresses some of this in a general way. However, unlike the expected “normal” behavior—which is well-documented and which implementations seem to follow very closely—the algorithms and mechanisms for detecting and mitigating “abnormal” behavior are significantly more vague and left as an exercise for the implementer. From a review of various software packages, it appears that this has led to a variety of implementations with a variety of good ideas, but also some weaknesses.

source: HN

> I often find it valuable to write simple test cases confirming things work the way I think they do. Sometimes I can’t explain the results, and getting to the bottom of those discrepancies can reveal new research opportunities. This is the story of one of those discrepancies; and the security rabbit-hole it led me down.

> Any application, any user - even sandboxed processes - can connect to any CTF session. Clients are expected to report their thread id, process id and HWND, but there is no authentication involved and you can simply lie. Secondly, there is nothing stopping you pretending to be a CTF service and getting other applications - even privileged applications - to connect to you.

> Even without bugs, the CTF protocol allows applications to exchange input and read each other’s content. However, there are a lot of protocol bugs that allow taking complete control of almost any other application.

https://github.com/taviso/ctftool

Regarding disclosure: https://bugs.chromium.org/p/project-zero/issues/detail?id=1859#c10

> Compiling with the GCC sanitizers and then fuzzing the resulting binaries might find real bugs. But not all such bugs are security issues. When a CVE is filed there is some pressure to treat such an issue with urgency and push out a fix as soon as possible. But taking your time and making sure an issue can be replicated/exploited without the binary being instrumented by the sanitizer is often better.

I don’t think anything went wrong here, but some interesting details.

source: L

> If you are working on a custom control, a complex widget, or a novel interface element to integrate into a project, library, or framework, there are some core features you need to build.

> These represent not just what works for users across the most contexts and preferences, but also what usability, accessibility, and internationalization practitioners (among many others) review to evaluate whether a solution can be used (purchased, integrated, discarded).

> So began an unusual stay at the first luxury hotel to grow out of a cultish New York gym. Soon to follow would be other health-enhancing treats, including a deep-tissue massage with CBD oil and a flash freeze in a cryotherapy chamber at minus 100C (minus 150C, if you include wind-chill).

Unusual.

> In 1989 the thin-hulled Exxon Valdez supertanker ran aground in Prince William Sound, Alaska, pouring a quarter of a million barrels of oil into the surrounding waters. At the time, it was America’s worst offshore spill, and a huge blow to the reputation of the ship’s owner, Exxon. The firm paid $3bn to clean up the area and settle legal claims, and to improve safety the American government ordered the phasing out of single-hull ships such as Exxon Valdez. All vessels used worldwide by Exxon’s corporate descendant, ExxonMobil, are now double-hulled. But that is not all. The disaster gave rise to a cultlike culture of discipline within ExxonMobil that helped turn it into the profitmaking beast it is today.

If we haven’t yet seen a sufficiently nasty data breach to motivate cleanups, I don’t think we want to.

> While most users probably would have no idea what to make of this, I happened to know what it means– Chrome is warning me that the system configuration has instructed it to leak the secret keys it uses to encrypt and decrypt HTTPS traffic to a stream on the local computer.

source: HN

> Your operating system will deceive you and re-assemble the string you sock.recv(n) differently from the ones you sock.send(data). But here is the deceptive part. It will work sometimes, but not always. These bugs will be difficult to chase. If you have two programs communicating over TCP via the loopback device in your operating system (the virtual network device with IP 127.0.0.1), then the data does not leave your RAM, and packets are never fragmented to fit into the maximum size of an Ethernet frame or 802.11 WLAN transmission. The data arrives immediately because it’s already there, and the other side gets to read via sock.recv(n) exactly the bytestring you sent over sock.send(data). If you connect to localhost via IPv6, the maximum packet size is 64 kB, and all the packets are already there to be reassembled into a bytestream immediately! But when you try to run the same code over the real Internet, with lag and packet loss, or when you are unlucky with the multitasking/scheduling of your OS, you will either get more data than you expected, leftover data from the last sock.send(data), or incomplete data.

Not strictly a python problem, either.

source: Dfly