> 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.

> 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

> 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).

> Most readers of this blog will be familiar with the traditional security key user experience: you register a token with a site then, when logging in, you enter a username and password as normal but are also required to press a security key in order for it to sign a challenge from the website. This is an effective defense against phishing, phone number takeover, etc. But modern security keys are capable of serving the roles of username and password too, so the user experience can just involve clicking a login button, pressing the security key, and (perhaps) entering a locally-validated PIN if the security key doesn’t do biometrics. This is possible with the recently released Chromium 76 and also with Edge or Firefox on current versions of Windows.

> That begs the question: what’s the difference between a PIN and a password? On the surface: nothing. A security key PIN is an arbitrary string, not limited to numbers. (I think it was probably considered too embarrassing to call it a password since FIDO’s slogan is “solving the world’s password problem”.)

> There is a class of UI performance problems that arise from the following situation: An input event is firing faster than the browser can paint frames.

> In a previous post, I discussed Lodash’s debounce and throttle functions, which I find very useful for these kinds of situations. Recently however, I found a pattern I like even better, so I want to discuss that here.

Follow up: https://nolanlawson.com/2019/08/14/browsers-input-events-and-frame-throttling/

source: L

> The site’s now characteristic tone of performative erudition—hyperrational, dispassionate, contrarian, authoritative—often masks a deeper recklessness. Ill-advised citations proliferate; thought experiments abound; humane arguments are dismissed as emotional or irrational. Logic, applied narrowly, is used to justify broad moral positions. The most admired arguments are made with data, but the origins, veracity, and malleability of those data tend to be ancillary concerns. The message-board intellectualism that might once have impressed V.C. observers like Graham has developed into an intellectual style all its own. Hacker News readers who visit the site to learn how engineers and entrepreneurs talk, and what they talk about, can find themselves immersed in conversations that resemble the output of duelling Markov bots trained on libertarian economics blogs, “The Tim Ferriss Show,” and the work of Yuval Noah Harari.

This is a pretty fun read I think, even for people who don’t like HN. Or perhaps especially so. Some great, and dismal, quotes. Even ngate makes an appearance.

source: HN

> HTTP requests are traditionally viewed as isolated, standalone entities. In this paper, I’ll explore forgotten techniques for remote, unauthenticated attackers to smash through this isolation and splice their requests into others, through which I was able to play puppeteer with the web infrastructure of numerous commercial and military systems, rain exploits on their visitors, and harvest over $70k in bug bounties.

> The protocol is extremely simple - HTTP requests are simply placed back to back, and the server parses headers to work out where each one ends and the next one starts. This is often confused with HTTP pipelining, which is a rarer subtype that’s not required for the attacks described in this paper. By itself, this is harmless. However, modern websites are composed of chains of systems, all talking over HTTP. This multi-tiered architecture takes HTTP requests from multiple different users and routes them over a single TCP/TLS connection:

source: grugq

> The phone numbers add tracking before connecting to a restaurant so that Grubhub can bill for a marketing fee.

> “There’s a button where you could hit play and so I was like, what is this?” he said. “I hit play, and the first call was me on the phone, which freaked me out because I didn’t know I was being recorded.” The call was a customer who had his restaurant confused with another restaurant. It took four minutes to figure this out before the customer hung up without placing an order. “I got charged almost $8 for that phone call.”

source: HN

> Every indication is that the attacker exploited a type of vulnerability known as Server Side Request Forgery (SSRF) in order to perform the attack. SSRF has become the most serious vulnerability facing organizations that use public clouds. SSRF is not an unknown vulnerability, but it doesn’t receive enough attention and was absent from the OWASP Top 10.

> SSRF is a bug hunters dream because it is an easy to perform attack and regularly yields critical findings, like this bug bounty report to Shopify. The problem is common and well-known, but hard to prevent and does not have any mitigations built in to the AWS platform.

> It is a regular occurrence to hear about open source developers selling their browser extensions, only for their users to be exploited later on by the new owners.

One of the reasons I’m wary of extensions. Least audited and least controlled code delivery mechanism for many systems.

source: L

> Advocates of any technique or technology can be a bit heavy-handed when it suits them if they’re not being careful–myself included. But I’m not sure if that’s the case here. When you stop to consider all the implications of poor performance, it’s hard not to come to the conclusion that poor performance is an ethical issue.

> Poor performance can, and does, lead to exclusion. This point is extremely well documented by now, but warrants repeating. Sites that use an excess of resources, whether on the network or on the device, don’t just cause slow experiences, but can leave entire groups of people out.

source: HN

> Whenever I’m grumpy about an update to a technology I use, I try to perform a self-audit examining why I’m unhappy about this change. It’s a helpful exercise since we are all by nature resistant to even minor alterations to the technologies we use every day (which is why website redesign is now a synonym for bare-knuckle boxing), and this feeling only increases with age. Sometimes the grumpiness is justified, since one of your tools has become duller or less useful in a way you can clearly articulate; other times, well, welcome to middle age.

> The New York Times recently changed their iPad app to emphasize three main tabs, Top Stories, For You, and Sections.

source: MR

> The rise and rise of ad-blockers (and ad-blocker-blocker-blockers) is without parallel: 26% of Internet users are now blocking ads, and the figure is rising. It’s been called the biggest boycott in human history.

> Adversarial interoperability occurs when someone figures out how to plug a new product or service into an existing product or service, against the wishes of the company behind that existing product or service.

Plus a history of ads on the web.

source: HN

This covers a lot of ground. I liked this quote, even though there’s much more to the post.

> Canonicalization is a quagnet, which is a term of art in vulnerability research meaning quagmire and vulnerability magnet. You can tell it’s bad just by how hard it is to type ‘canonicalization’.

source: HN

> This is my question: why do we put up with websites that we don’t like looking at? I think most people would answer that question with another question: What choice do we have?

source: L

> I’ll list some of them here and some of the thinking behind them. Just about everything here has happened at some point in time, and probably has happened more than once... way more than once.

I like a lot of this. Very much.

> On the other hand, if you only need 53 bits of your 64 bit numbers, and enjoy blowing CPU on ridiculously inefficient marshaling and unmarshaling steps, hey, it’s your funeral.

> We develop a novel technique that uses Facebook’s advertiser interface to check whether a given piece of PII can be used to target some Facebook user, and use this technique to study how Facebook’s advertising service obtains users’ PII. We investigate a range of potential sources of PII, finding that phone numbers and email addresses added as profile attributes, those provided for security purposes such as two-factor authentication, those provided to the Facebook Messenger app for the purpose of messaging, and those included in friends’ uploaded contact databases are all used by Facebook to allow advertisers to target users. These findings hold despite all the relevant privacy controls on our test accounts being set to their most private settings.

source: green