> If you find yourself wrestling with CSS layout, it’s likely you’re making decisions for browsers they should be making themselves. Through a series of simple, composable layouts, Every Layout will teach you how to better harness the built-in algorithms that power browsers and CSS.

Some free, some pay.

source: L

HTML: the good parts

source: HN

> Okay so here’s the thing: Cloudflare isn’t just the CDN provider for the instance, it is also the domain’s nameserver. That means that it holds all the DNS records that point mastodon.technology to the various IP addresses used for HTTP requests, email, and even public DKIM keys for mail server verification. These DNS settings are really, really important. If they get messed up, everything about the instance can break.

> So I split up the migration from Cloudflare to BunnyCDN into two phases: first migrate the CDN provider, and then migrate the DNS provider. Getting this right is really important, and I mostly did okay, but hopefully you can learn from my experiences.

source: L

> It’s no coincidence that this is a cryptography blog, which means that I’m not concerned with the same things as the general public. That is, I’m not terribly interested in debating the value of whistleblower laws (for some of that, see this excellent Twitter thread by Jake Williams). Instead, when it comes to Snowden’s leaks, I think the question we should be asking ourselves is very different. Namely:

> What did the Snowden leaks tell us about modern surveillance capabilities? And what did we learn about our ability to defend against them?

source: green

> In fact, shortly after I made my own personal home page, full of <marquee> tags, creative abuse of the <font> tag, and a color scheme which was hot pink and neon green, I showed it to a friend, who condescendingly said, “What, you didn’t even use frames?” He made me mad enough that I almost deleted my Geocities account.

Nice look back at how we used to do things.

> In this era, we’d call stuff like this “DHTML” (the D is for “dynamic”), and we traversed the DOM as a chain of properties, doing things like document.forms[0].inputs[0] to access fields on the form.

> HTTP Mock is the latest tool in HTTP Toolkit, a suite of beautiful & open-source tools for debugging, testing and building with HTTP(S), on Windows, Linux & Mac.

This does look useful.

Interesting implementation note: https://news.ycombinator.com/item?id=21072087

> The trick is that it starts the application to be intercepted for you, so it can control it a little. It then does some magic to get that specific instance of the application to trust the certificate. There’s a lot going on there, but as an example: Chrome has a --ignore-certificate-errors-spki-list to inject the hashes of extra CAs that can be trusted in this specific Chrome instance. When HTTP Toolkit starts a Chrome process, it adds that command line option, with the hash of your locally generated CA.

Source: https://github.com/httptoolkit/mockttp

source: HN

> As you can see, the text was (for reasons unknown to me) helpfully translated into the language of the country we happen to be in. Unfortunately I don’t speak either Dutch or Portuguese so I can only interpret this behaviour as a punishment encountered by people rude enough to dare travel abroad without learning the language spoken in the country they happen to be in, thereby breaking the worldview held by the particular programmer who happened to be responsible for creating the translation module for this amazing example of good web development practices.

source: L

> By cross-referencing just one hour of footage from public webcams with stories taken in Times Square, BuzzFeed News confirmed the full identities of a half dozen people.

source: grugq

> The Ninth Circuit has issued a Section 230(c)(2) opinion that creates significant problems for anti-spyware/spam/virus vendors (I’ll call them “anti-threat vendors”). The ruling will paralyze their decision-making, expose them to greater legal threats, and reduce their ability to protect consumers from unwanted software. This ruling makes the Internet less safe. I hope the Ninth Circuit will fix it via further proceedings.

> Nevertheless, the majority’s legal standard creates two obvious and significant problems. First, many spammers, virusmakers, and adware/spyware makers will claim–legitimately or not–to be direct or partial competitors with anti-threat vendors. In those situations, the threat purveyors will naturally claim that the blocking was motivated by anticompetitive animus. In fact, I would expect such anticompetitive animus claims to be routine for blocked entities, not an exception. Indeed, as the dissent noted, Zango claimed (not credibly) its adware was competitive with Kaspersky’s anti-threat software.

I would say it will be the AV companies facing bogus lawsuits who will lose the most, and probably not users, but it’s a bit of a pickle.

> This is a major case that will be of interest to a lot of people and a lot of companies. But it’s also pretty complicated and easy to misunderstand. This post will go through it carefully, trying to explain what it says and what it doesn’t say.

source: white

> This is a collection of thoughts from a maintainer of the Public Suffix List (PSL) about the importance of avoiding new Web Platform features, security, or privacy boundaries assuming the PSL is a good starting point.

> Equally terrifying, however, is how many providers only discovered the existence of the PSL once LE was using it to rate limit - meaning that their users were able to influence cookies and other storage without restriction, until an incidental change (wanting to get more certs) caused the server operator to realize.

source: HN

> So, you want to create amazing data visualizations on the web and you keep hearing about D3.js. But what is D3.js, and how can you learn it? Let’s start with the question: What is D3? While it might seem like D3.js is an all-encompassing framework, it’s really just a collection of small modules.

source: L

> Earlier this year Google’s Threat Analysis Group (TAG) discovered a small collection of hacked websites. The hacked sites were being used in indiscriminate watering hole attacks against their visitors, using iPhone 0-day.

> There was no target discrimination; simply visiting the hacked site was enough for the exploit server to attack your device, and if it was successful, install a monitoring implant. We estimate that these sites receive thousands of visitors per week.

> TAG was able to collect five separate, complete and unique iPhone exploit chains, covering almost every version from iOS 10 through to the latest version of iOS 12. This indicated a group making a sustained effort to hack the users of iPhones in certain communities over a period of at least two years.

> I’ll investigate what I assess to be the root causes of the vulnerabilities and discuss some insights we can gain into Apple’s software development lifecycle. The root causes I highlight here are not novel and are often overlooked: we’ll see cases of code which seems to have never worked, code that likely skipped QA or likely had little testing or review before being shipped to users.

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